Rất nhiều trình theo dõi vấn đề hỗ trợ một cái gì đó gọi là "cột mốc". Tôi chưa bao giờ tìm thấy việc sử dụng chúng. Có vẻ như các cột mốc chỉ hữu ích khi bạn thực hiện các cú đẩy lớn, theo lịch trình, nhưng không phải nếu bạn đưa ra các tính năng mới và sửa lỗi khi chúng được hoàn thành.

Khi nào / làm thế nào bạn sẽ sử dụng các mốc quan trọng để tổ chức phát triển nhanh?

Một số nhóm nhanh nhẹn sử dụng chúng để liên lạc với khách hàng khi anh ta có thể mong đợi có phiên bản mới của phần mềm (ngay cả khi phiên bản đó chưa hoàn chỉnh). Điều này cho phép khách hàng lên kế hoạch di chuyển sang phiên bản mới, trước khi nó được phát hành.

Ví dụ, đối với một phần mềm được phát triển theo cách nhanh nhẹn và được phát hành mỗi 6 tháng , sau đây có thể là các mốc quan trọng.

Alpha 1 - 19/12

Bộ tính năng đầu tiên đến, thường là lỗi. Điều này rất hữu ích để thử chúng và đưa ra phản hồi

Alpha 2 - 23 tháng 1

Bộ tính năng tiếp theo, cộng với một số bản sửa lỗi cho phản hồi trong Alpha

Beta 1 - 27 tháng 2

Tất cả các tính năng cho phiên bản hiện tại đều ở đó và sẽ không có ai được thêm vào cho đến khi phát hành cuối cùng. Phát triển mới sẽ có trong phiên bản tiếp theo. Bạn vẫn có thể đề xuất một số điều chỉnh nhỏ cho hiện tại.

Beta cuối cùng - 27 tháng 3

Hành vi của tính năng này hoàn toàn bị đóng băng, trừ khi tìm thấy lỗ hổng nghiêm trọng. Chỉ có lỗi sẽ được sửa.

Ứng cử viên phát hành - ngày 10 tháng 4

Phiên bản cuối cùng sẽ được phát hành. Không có lỗi được cho là được tìm thấy ở đây. Nếu một số được tìm thấy, một ứng cử viên phát hành mới được tạo ra.

Bản phát hành cuối cùng - ngày 17 tháng 4

Phiên bản được hỗ trợ được phát hành ra công chúng, vì không tìm thấy lỗi nào cho ứng viên phát hành

(Lưu ý: Tôi đã không theo dõi chính xác ngữ nghĩa ubfox ở đây)

Với kế hoạch phát hành trong tay, một khách hàng có thể lên kế hoạch trước. Nếu một tính năng mới thực sự được mong đợi, anh ta có thể thử nghiệm nó trong giai đoạn alpha để đảm bảo rằng nó phù hợp với những gì được yêu cầu. Các lập trình viên có thể bắt đầu thử nghiệm tính năng mới trong giai đoạn beta. Kiểm tra hồi quy có thể bắt đầu trong giai đoạn phát hành ứng cử viên.

Biết khi nào phần mềm sẽ được phát hành và những gì nó sẽ chứa là vô cùng quan trọng đối với nhiều người dùng. Sử dụng cột mốc, bạn có thể biết điều gì sẽ xảy ra và khi nào . Tư duy nhanh nhẹn vẫn còn đó, biểu hiện bằng thực tế là trước một ngày nhất định, bộ tính năng là biến . Điều này không giống như cách thác nước , nơi bạn lên kế hoạch cho cả các tính năng và ngày phát hành . Và dĩ nhiên, phiên bản tiếp theo không được thiết lập, một lần nữa không giống như phương pháp thác nước.

Vì vậy, để trả lời câu hỏi của bạn: Trong nhanh nhẹn, cột mốc được sử dụng để chỉ ra khi nào quyết định và hành động quan trọng sẽ được thực hiện , ngay cả khi những hành động và quyết định đó có thể thay đổi.

Tôi nghĩ mục đích của cột mốc để thấy bức tranh lớn về chương trình / ứng dụng ứng dụng phát hành / tính năng (hoặc bất cứ điều gì khác mà nhóm phát triển).

Nó có thể hữu ích cho các nhà phát triển / công nhân:

Tôi có thể tưởng tượng một hệ thống theo dõi vấn đề với nhiều tác vụ, lỗi, tính năng, vv Nó có trường mốc. Tôi nghĩ rằng nếu nhóm của bạn có hai cột mốc và chỉ một người thích khách hàng của bạn, thì nhóm của bạn bắt đầu thực hiện các nhiệm vụ này hoặc sửa các lỗi này hoặc phát triển các tính năng được đánh dấu bằng cột mốc này.

Nó có thể hữu ích cho các nhà quản lý:

Đó là điều rất quan trọng mà bản phát hành sẽ được phát hành cho môi trường sản xuất của khách hàng. Trong trường hợp này, cột mốc được phát hành cho môi trường sản xuất. Nhưng cột mốc có thể được đánh dấu gói các tính năng.

Nó có thể hữu ích cho khách hàng:

Có thể, khách hàng muốn hiển thị chương trình này hoặc phiên bản bị lỗi chương trình hoặc các tính năng mới của chương trình cho người / tổ chức khác. Vì vậy, khách hàng cần phiên bản ổn định của chương trình. Tôi nghĩ rằng khi chương trình đạt được cột mốc này Nó sẽ ổn định và đáng tin cậy.

Nếu khách hàng, người quản lý và công nhân kiểm tra lỗi, taks và các tính năng trong trình theo dõi vấn đề, tôi nghĩ rằng Betters biết cột mốc của họ.

Khi bạn bắt đầu một dự án phát triển - bất kể phương pháp nào -, bạn phải luôn có một kế hoạch sơ bộ mà bạn đang theo dõi, về các tính năng "phải có", các tính năng cốt lõi, các tính năng "thực sự quan trọng" mà bạn muốn phát triển và trong đó đặt hàng. Lý tưởng nhất là bạn cũng có một tầm nhìn về thời gian thực hiện. Viết ra kế hoạch này dưới dạng các cột mốc làm cho điều này minh bạch cho bất kỳ ai tham gia vào dự án.

Trong bất kỳ loại dự án thực tế, kế hoạch này phải được điều chỉnh theo thực tế theo thời gian. Có thể người ta phải gán lại các tính năng cho các mốc khác nhau, đôi khi người ta xác định những thứ ít quan trọng hơn trước đây, đôi khi người ta phải thêm một số yêu cầu / tính năng bị thiếu vào kế hoạch phát triển của mình và đôi khi người ta có thể phải thay đổi danh sách các cột mốc . IMHO sự khác biệt chính giữa dự án "thác nước" và dự án "nhanh nhẹn" là trong một dự án nhanh, bạn thành thật với khách hàng về nhu cầu thích nghi từ ngày 1. Trong các dự án thác nước, bạn không có cơ chế tích hợp để thay đổi lên kế hoạch trước khi sản phẩm "sẵn sàng" (và có thể bị lỗi). Trong các dự án nhanh,

Cũng có một sự khác biệt tại thời điểm bạn phân tích các chi tiết chính của các yêu cầu cho bất kỳ cột mốc nào. Các dự án thác nước có xu hướng phân tích quá mức mọi tính năng của từng cột mốc trước đó, trong các dự án nhanh, bạn thường sẽ chỉ phân tích một tính năng của cột mốc tiếp theo theo chiều sâu.

Vì vậy, tôi đặc biệt nói trong các dự án nhanh, một kế hoạch quan trọng giúp các bên liên quan hiểu rằng sự phát triển không hoàn toàn tùy ý hoặc ngẫu nhiên, và bạn vẫn tuân theo một kế hoạch tổng thể.

Một câu hỏi khác là nếu bạn cần tính năng "cột mốc" từ trình theo dõi vấn đề của bạn. Một kế hoạch cột mốc thường chỉ là một tài liệu ở định dạng tài liệu yêu thích của bạn, vì vậy bạn có thể dễ dàng hiển thị nó cho bất kỳ bên liên quan nào trong dự án của bạn. Bạn phải tự quyết định xem nó có mang lại cho bạn bất kỳ lợi ích nào để đưa các mốc quan trọng vào hệ thống theo dõi vấn đề của bạn hay không, nếu bạn muốn duy trì nó theo một cách hoàn toàn khác.

Bạn đã trả lời câu hỏi của riêng bạn. "... hữu ích khi bạn làm lớn, đẩy theo lịch trình ..."

Vì bạn chỉ đang thực hiện công việc bảo trì và cập nhật nên các cột mốc không có ý nghĩa gì cả. Ngoại trừ : ngay cả khi chọn các tính năng lặp đi lặp lại, thật tuyệt khi có một cái nhìn tổng quan về nơi tất cả các tính năng đang hướng đến để giữ cho sự phát triển nhanh không bị mất kiểm soát và để dự án cảm thấy gắn kết.

Các mốc quan trọng đưa ra một điểm để đo lường mức độ đáp ứng các mục tiêu dài hạn và một điểm để dừng lại và xem xét việc lặp lại theo hướng nào trong tương lai.

Các cột mốc rất hữu ích cho sự tham gia của khách hàng, ví dụ: Khi phát triển một nguyên mẫu, một cột mốc sẽ cho phép nhóm biết những mục công việc nào phải được hoàn thành để có một nguyên mẫu sẵn sàng để trình bày.

Nó cũng hữu ích cho việc triển khai tiến hóa cũng như cung cấp một lộ trình kiểm toán phát triển. Trong một nhóm tôi đã làm việc trước đây, trưởng nhóm sẽ tách ra khỏi kho lưu trữ chính để giữ một phiên bản của sản phẩm ở cột mốc cụ thể đó. Điều này cho phép chúng tôi thể hiện sự quản lý cao hơn về sự phát triển của sản phẩm và chứng minh ngân sách.

Mỗi tính năng là một cột mốc quan trọng, theo định nghĩa

một hành động hoặc sự kiện đánh dấu một sự thay đổi hoặc giai đoạn quan trọng trong sự phát triển

Tính hữu ích của việc theo dõi cá nhân hoặc nhóm cột mốc cho bạn dự án và của bạn trong nhóm và bạn khách hàng chủ yếu là một vấn đề của hương vị / phong cách

Một số nhóm / khách hàng thích kiểm tra các cột mốc mỗi ngày hoặc lâu hơn, những nhóm khác là nội dung để làm điều đó ít thường xuyên hơn

ĐỊA CHỈ: Từ khóa là 'đáng kể' - mang tính chủ quan. Các cột mốc của bạn có thể thay đổi. :)