Khi nào ngừng viết câu chuyện của người dùng và bắt đầu viết mã?

Khi khám phá những câu chuyện cho lần chạy nước rút đầu tiên, làm thế nào để bạn biết khi nào nên dừng viết và tiến về phía trước?

Tôi đã hỏi một vài người mà tôi biết, và về cơ bản câu trả lời tôi nhận được là, nó phụ thuộc vào bối cảnh dự án tồn tại và cách thức thời gian của dự án nói chung.

Có cách nào chuẩn để biết khi nào nên dừng viết truyện người dùng không, và nếu vậy, cơ sở cho việc này là gì và nó áp dụng như thế nào cho các lần chạy nước rút trong tương lai?

Bạn cần ước tính từng câu chuyện một khi bạn đã viết nó ra - điều này giả định rằng bạn đang sắp xếp các câu chuyện của mình theo thứ tự ưu tiên và chúng được xây dựng đủ để phát triển.

Khi bạn đã ước tính đủ cho một lần lặp, hãy bắt đầu viết mã.

Khi bạn có một sản phẩm tồn đọng hoàn chỉnh, và câu chuyện người dùng hoàn thành tốt trong tất cả các trường hợp. Sau đó chia chúng thành các lần lặp và bắt đầu lập trình.

Hai hoạt động không đối kháng.

Viết truyện là về việc xác định các nhu cầu mong muốn dưới sự ràng buộc của việc cung cấp giá trị kinh doanh.

Bắt đầu mã xảy ra ở giữa nước rút. Để bắt đầu một lần chạy nước rút, điều kiện tiên quyết duy nhất là tồn đọng nước rút được xác định - được ưu tiên bởi PO (người viết truyện) và được chọn bởi nhóm.

Bạn nên dừng viết truyện (= dừng dự án), khi lợi ích cận biên khi thực hiện câu chuyện so với chi phí thực hiện và chi phí vận hành thực tế của chức năng được xác định là không đáng kể.

Bạn nên bắt đầu viết mã trong ngữ cảnh của một lần chạy nước rút, khi câu chuyện được hiểu (phân tích) và kiểm tra và thực hiện được xác định (thiết kế) - phương pháp phát triển phần mềm cổ điển.

khi các câu chuyện trở nên đủ chi tiết để biến thành logic lập trình .. và khi các lập trình viên có thể trao một số điểm nhất định phù hợp với dòng thời gian nước rút ..

một câu chuyện ước tính khoảng 50 giờ / điểm câu chuyện sẽ rất khó khăn (IMO) để thực hiện cuộc đua nước rút kéo dài hơn một tuần .. phá vỡ câu chuyện tiếp theo sẽ cho phép những người khác đảm nhận các phần khác nhau của nhiệm vụ, nhưng nếu mã không thể được phát triển song song, sau đó có thể ngắn như bạn có thể đi.

Có cách nào chuẩn để biết khi nào nên dừng viết truyện người dùng không, và nếu vậy, cơ sở cho việc này là gì và nó áp dụng như thế nào cho các lần chạy nước rút trong tương lai?

Cá nhân tôi không biết về một phương pháp tiêu chuẩn. Nó thực sự đi đến sự kết hợp giữa phương pháp của bạn và kỳ vọng của khách hàng.

Tôi đã thấy rằng tốt hơn là bắt đầu viết mã ngay khi bạn có những câu chuyện "đủ" từ khách hàng của mình để bắt đầu. Như những người khác đã nói, điều này có thể là cho một lần lặp duy nhất, tuy nhiên nó có thể là nhiều hơn. Biện pháp của bạn đủ nên được hướng dẫn bởi tần suất bạn dự định phát hành mã làm việc cho khách hàng của mình và thay vì khách hàng đưa cho bạn và danh sách vô tận các câu chuyện (nhiều trong số đó có thể sẽ không bao giờ được thực hiện, hoặc có thể thay đổi, hoặc có thể không đưa ra thời hạn phát hành chính của bạn), tốt hơn hết là hỏi khách hàng của bạn về 3-5 tính năng ưu tiên quan trọng nhất và cao nhất đầu tiên. Khi chúng được thực hiện và phát hành cho khách hàng của bạn, bạn thu thập 3-5 tính năng quan trọng nhất tiếp theo, v.v. Yêu cầu nhiều hay ít tùy thuộc vào thời gian lặp đi lặp lại của bạn.

Khách hàng hoặc hợp đồng hoặc thời hạn của bạn có thể hướng dẫn bạn khi nào thực sự ngừng yêu cầu câu chuyện, nhưng trong khi đó, bạn đã yêu cầu câu chuyện và dừng lại thường xuyên như bạn đã lặp đi lặp lại. Khi theo thỏa thuận, bạn và khách hàng cảm thấy sản phẩm đã hoàn thành đủ, bạn có thể quyết định sẽ làm gì với bất kỳ câu chuyện còn sót lại nào mà khách hàng có thể chưa đưa ra cho bạn.

Ưu điểm chính của phương pháp này là cuối cùng bạn cung cấp giá trị lớn nhất cho khách hàng, và khi dự án phát triển và thời gian trôi qua, lượng giá trị bạn đang cung cấp cho khách hàng giảm xuống đến mức khách hàng có thể làm cho quyết định về "20% tính năng cuối cùng" mà họ có thể mong muốn mà thực sự không bao giờ được sử dụng. Nó cũng cắt giảm thời gian lãng phí vào các mục ưu tiên tầm thường và thấp, đặt trách nhiệm (và căng thẳng) của việc ưu tiên và lên lịch lặp lại cho khách hàng, và tất cả chỉ dựa trên nhu cầu của khách hàng. Điều đó không có nghĩa là tuy nhiên bạn không nên cung cấp hướng dẫn cho khách hàng để tránh những vướng mắc khó khăn trong việc lên lịch trình có thể trở nên rõ ràng khi bạn nói những yêu cầu với khách hàng.

Hãy đọc Phát triển phần mềm tinh gọn của Poppendeicks nếu bạn muốn mô tả chi tiết hơn về phương pháp này trong bối cảnh rộng hơn.

bạn không bao giờ ngừng viết truyện .. Chỉ là khi bạn có đủ câu chuyện cho lần chạy nước rút 1, bạn sẽ thực hiện kế hoạch chạy nước rút và nhóm của bạn sẽ bắt đầu làm việc theo thời gian tồn đọng nước rút ..

Chủ sở hữu sản phẩm sẽ tiếp tục chải chuốt các sản phẩm tồn đọng, tức là viết nhiều câu chuyện của người dùng hơn, phá vỡ các câu chuyện lớn, ví dụ như sử thi, thành một câu chuyện nhỏ hơn, xây dựng nhiều hơn về các tiêu chí chấp nhận câu chuyện, ưu tiên ...