Trong nhanh nhẹn, các nhiệm vụ cơ sở hạ tầng cơ bản khi bắt đầu dự án được lên kế hoạch và phân bổ bằng cách sử dụng các khung quản lý nghiêm ngặt như TFS trực tuyến như thế nào?

Ở đây tôi đang trong quá trình phân tích và ước tính một dự án phát triển phần mềm mới tương đối nhỏ. Tôi đã xem qua các câu chuyện của người dùng được đề xuất bởi khách hàng và đặt các nhiệm vụ theo từng mục, với một ước tính và một số ghi chú ngắn gọn về cách thực hiện nhiệm vụ. Có tiêu chí chấp nhận. Tất cả phải tốt với thế giới.

Khi nhìn vào công việc tôi đã lên kế hoạch, tôi nhận ra còn thiếu một thứ gì đó. Sẽ có sự ban đầu ban đầu chỉ đơn giản là thiết lập những thứ mà chúng ta có thể bắt vít. Những thứ thuộc về tất cả các câu chuyện của người dùng, không phải là một câu chuyện người dùng cụ thể.

Ví dụ, một phần của ứng dụng này là một dịch vụ phân tích cú pháp XML. Từ quan điểm của người dùng, có những câu chuyện cụ thể trong đó những điều khác nhau sẽ cần được thực hiện tùy thuộc vào nội dung của XML. Trên thực tế, viết một trình phân tích cú pháp XML - các bit tìm kiếm một tệp, đọc nó và lấy dữ liệu liên quan trước khi quyết định làm gì với nội dung - là một phần của tất cả những câu chuyện đó. Như đang gói nó trong một dịch vụ windows với một trình cài đặt, vv Đây là một nhiệm vụ tập trung vào nhà phát triển không liên quan trực tiếp đến người dùng.

Một ví dụ khác có liên quan từ ứng dụng cụ thể này là lấy và viết lại một khối mã kế thừa kém, hữu ích cho các chức năng của ứng dụng này. Một lần nữa, điều này không có kết quả ngay lập tức cho người dùng nhưng đó là công việc cần thiết. Trường hợp lập kế hoạch và thực hiện công việc này "sống" trong kế hoạch dự án tập trung vào câu chuyện của người dùng?

Tôi đã thấy mọi người giải quyết điều này bằng cách viết các câu chuyện của người dùng "Là một nhà phát triển, tôi muốn ..." nhưng như đã được thảo luận ở nơi khác, đây không phải là một câu chuyện của người dùng . Đó là một nhà phát triển.

Tôi đang tìm kiếm một câu trả lời cụ thể cho vấn đề này, để giúp tôi (và những người khác) lập kế hoạch cho các dự án bằng cách sử dụng các khung quản lý chặt chẽ như TFS trực tuyến. Chúng không có chức năng tạo ra "câu chuyện của các bên liên quan" hoặc các giải pháp meta mơ hồ khác được đề cập trong câu trả lời cho Làm thế nào để một nhóm Scrum giải quyết các nhiệm vụ cơ sở hạ tầng trong cuộc họp lập kế hoạch?

Tôi thích các câu trả lời khác nói rằng hãy đặt mã "công cụ" nhiều nhất có thể vào Lặp lại 0. Tuy nhiên, đôi khi, các loại công cụ này xuất hiện sau khi dự án đã bắt đầu. Có lẽ trong Lặp lại 3, bạn nhận ra rằng bạn cần một tiện ích phân tích cú pháp XML tổng quát để được sử dụng cho các câu chuyện khác nhau trong tương lai.

Trong trường hợp đó, Câu chuyện người dùng đầu tiên dựa trên các tác phẩm kiến ​​trúc nội bộ này là câu chuyện mà chúng thuộc về . Nếu bạn chuẩn bị làm việc trên Câu chuyện số 345 và nó sẽ phụ thuộc vào trình phân tích cú pháp XML của bạn trước khi có thể được tính là 'xong', thì trình phân tích cú pháp có thể sử dụng lại của bạn sẽ được đính kèm dưới dạng công việc để câu chuyện đó được hoàn thành.

Nhóm của tôi đã sử dụng phương pháp trên và nó dường như hoạt động tốt với chúng tôi.

Nếu đó là cơ sở hạ tầng, nó thường được đưa vào Iteration Zero. Lặp lại số 0 là gì? Đó thường là thời gian giữa khởi động và lập kế hoạch trước khi lặp lại thực tế bắt đầu.

Một ví dụ, nói rằng chúng ta cần một dịch vụ web mới. Vì vậy, tôi cần tạo dự án, thiết lập tích hợp liên tục, thiết lập kho lưu trữ kiểm soát nguồn, thiết lập tập lệnh xây dựng và triển khai tự động, v.v. Người dùng không thực sự quan tâm đến những điều này, nhưng chúng tôi cần những điều này bất kể.

Vì vậy, công việc đó sẽ được thực hiện trong lần lặp 0. Vào thời điểm lặp 1 bắt đầu, đã có một trình bao dự án mới sẽ biên dịch, có một kịch bản xây dựng tự động và sẽ triển khai. Bây giờ, không có chức năng người dùng nào ở đó, nhưng nó đã sẵn sàng.

Tôi vẫn sẽ theo dõi và lập kế hoạch công việc này như là một phần của công việc lặp 0.

Việc tái cấu trúc nghe có vẻ như một câu chuyện kỹ thuật có thể đi trong bất kỳ lần lặp nào.

Phụ thuộc vào cơ sở hạ tầng.

Nếu cơ sở hạ tầng là rất quan trọng, hoặc phải tuân thủ các quy định tuân thủ phức tạp, thì bạn có thể có một nhóm cơ sở hạ tầng riêng biệt, người có thể có một lịch trình của riêng họ. Nó có thể là Agile, nó có thể là thác nước. Trong trường hợp này, việc xây dựng cơ sở hạ tầng sẽ được quản lý trong dự án của bạn như một sự phụ thuộc bên ngoài .

Nếu cơ sở hạ tầng sẽ được quản lý bởi nhóm của bạn và chỉ thiết lập một lần, bạn có thể sử dụng kỹ thuật lặp 0 mà Jon mô tả.

Nếu việc thiết lập cơ sở hạ tầng sẽ mất vài lần lặp (ví dụ: có thể bạn thiết lập máy chủ xây dựng của mình ngay bây giờ nhưng máy chủ QA và máy chủ preprod sẽ được xây dựng sau một chút) thì quá trình xây dựng của chúng có thể được quản lý dưới dạng PBI không hoạt động. PBI chức năng có thể có một số phụ thuộc nhất định vào những điều này, mà bạn có thể mã hóa trong TFS bằng liên kết "tiền thân".

Và tất nhiên bạn có thể trộn và kết hợp tất cả các bên trên. Ví dụ: bạn không thể làm gì nhiều nếu không có máy chủ xây dựng liên tục, vì vậy bạn có thể đặt nó ở lần lặp 0. Trong khi đó, máy chủ preprod của bạn có thể được xác định là nhiệm vụ cho các lần lặp 2 và 3 và chúng có thể có các phụ thuộc bên ngoài vào nhóm DBA của bạn ( ai không Agile), người sẽ phân bổ các cá thể DB trong trung tâm dữ liệu của bạn. Hoặc có thể bạn phải chờ cấp giấy chứng nhận SSL được cấp cho một số tính năng nhất định; chúng có thể đi trong lần lặp 4, và bất kỳ vật phẩm chức năng nào dựa vào các certs đó phải được liên kết với chúng với mối quan hệ tiền nhiệm / kế nhiệm.

Trong mọi trường hợp, hãy nhớ:

1. Luôn xác định tiêu chí chấp nhận rõ ràng. Những kẻ phần cứng có xu hướng khó chịu khi đứng lên một máy chủ và gọi nó được thực hiện khi nó chưa được xác nhận.
2. Trong lần khởi động lặp lại của nhóm của bạn, nhóm sẽ cần kiểm tra các phụ thuộc và tính khả dụng của chúng trước khi cam kết với bất kỳ PBI hoặc mục công việc nào.