Có bao nhiêu câu chuyện người dùng cho mỗi người nên được hoàn thành trong mỗi lần chạy nước rút? [đóng cửa]

Chỉ cần chạy qua con số này và tự hỏi liệu có nguồn nào khác biết nhiều hơn sẽ giúp xác nhận những con số này không:

Dựa trên dữ liệu tôi đã phân tích trên các lần chạy nước rút thành công, tôi xác định rằng một nhóm nên trung bình khoảng 1 đến 1-1 / 2 câu chuyện của người dùng (các mục tồn đọng của sản phẩm thuộc bất kỳ loại nào, thực sự) cho mỗi người chạy nước rút.

NGUỒN: Blog của Mike Cohn về " Sự nổi bật hàng ngày nên là cá nhân hay từng câu chuyện ?"

Năng suất bị ảnh hưởng bởi một số yếu tố - văn hóa tổ chức, kinh nghiệm với ngôn ngữ và công cụ, kiến ​​thức về dự án, chi tiết cụ thể của quy trình đang được sử dụng, các yếu tố bên ngoài như quy định và capabilties của nhóm như một đơn vị gắn kết. Đây là lý do tại sao, khi ước tính các dự án, dữ liệu hữu ích nhất là của nhóm cụ thể sẽ tiến hành công việc. Khi bạn khái quát hóa cho tổ chức, ngành công nghiệp, và sau đó trong suốt các dự án phần mềm, năng suất trở thành một lĩnh vực mờ nhạt.

Một trong những lợi thế của phát triển lặp là bạn trải qua tất cả các giai đoạn nhiều lần trong một dự án, cho phép bạn hiểu rõ hơn về quy trình và nhóm. Bạn có thể bắt đầu với dữ liệu tổ chức từ các dự án trong quá khứ, nhưng rất nhanh chóng (2-4 lần lặp) có được dữ liệu cụ thể theo nhóm để lập kế hoạch dự án.

Con số mà bạn trích dẫn (1-1,5 câu chuyện của người dùng mỗi lần chạy nước rút) là mức độ trừu tượng cao nhất. Thời điểm tốt nhất để sử dụng số này là khi bạn không có dữ liệu cụ thể trong ngành từ bất kỳ miền nào mà sản phẩm của bạn rơi vào, không có dữ liệu tổ chức và không có dữ liệu cụ thể của nhóm - ngay từ đầu trong các dự án đầu tiên của bạn sử dụng Scrum. Nó có thể đến từ các nhóm sử dụng tất cả các loại biến thể của Scrum, bao gồm kết hợp Scrum với các kỹ thuật cải tiến quy trình khác (Kanban, CMMI, Lean). Tôi tin tưởng sử dụng con số này vì nó đứng vững, vì Mike Cohn và Mountain Goat Software là những chuyên gia tư vấn nhanh nhẹn được kính trọng. Tuy nhiên, ngay khi bạn có dữ liệu từ tổ chức của mình (hoặc, thậm chí tốt hơn, nhóm của bạn), hãy sử dụng dữ liệu đó để lập kế hoạch chạy nước rút.

Đây sẽ là một điều tồi tệ để lo lắng hoặc thậm chí cố gắng đo lường, con số này sẽ thay đổi rất nhiều bởi kỹ năng lập trình viên, sự phức tạp của câu chuyện, kinh nghiệm của lập trình viên và đội ngũ, kinh nghiệm của những người tạo ra câu chuyện, khả năng duy trì của cơ sở mã .. .

Bạn nên lo lắng về những điều như mọi người dường như đang đóng góp cho khả năng tốt nhất của họ, hôm nay khách hàng có vui hơn hôm qua không, mọi người / hầu hết có nghĩ rằng quy trình này hoạt động tốt hơn quy trình trước chúng tôi đã thử không?

Tôi nghĩ ở cấp độ chi tiết tốt nói rằng "mọi người nên hoàn thành 1,5 câu chuyện trên mỗi lần chạy nước rút" là cách giải thích rủi ro của phân tích. Những gì tôi đã tìm thấy là theo thời gian, nhóm nghiên cứu giải quyết các câu chuyện có độ phức tạp tương tự. Nó tạo thành một đường cơ sở mà theo đó bạn có thể lập kế hoạch phù hợp trong tương lai. Nói cách khác là vận tốc. Tôi không bao giờ thích đo vận tốc theo số lượng câu chuyện mà là theo điểm câu chuyện. Nói chung, mặc dù nó được rửa vì sự khác biệt về kích thước giữa các câu chuyện (những câu chuyện nhỏ hơn bù đắp cho những câu chuyện lớn hơn).

Thật tuyệt khi thấy anh ấy thảo luận về sự khác biệt về thời gian chạy nước rút (những lần chạy nước rút dài hơn có xu hướng giải quyết những câu chuyện lớn hơn) và quy mô đội trong tác động ở đây. Ngoài ra, kéo lại bức màn (tức là có các nhiệm vụ chi tiết liên quan đến các câu chuyện) cung cấp khả năng hiển thị nhiều hơn về những gì cần hoàn thành câu chuyện (mà cuối cùng là những gì bài đăng đó nói về - khả năng hiển thị).

Vì vậy, theo nguyên tắc thông thường, Cohn đang nói mục tiêu khoảng 1-1,5 câu chuyện cho mỗi nhà phát triển trên mỗi lần chạy nước rút. Nhiều hơn thế, và bạn có nguy cơ không nghe thấy tiến trình của một câu chuyện cho đến khi bạn chìm sâu trong nước rút. Lean giải quyết vấn đề này bằng cách để lại những câu chuyện trong hồ sơ tồn đọng cho đến khi chúng sẵn sàng để được phát triển. Điều Mike đang nói là công việc phát triển hiệu quả của bạn nên được giới hạn ở mức 1,5 lần trong đó X là quy mô của nhóm phát triển.

Đối với tôi, nó phụ thuộc vào nước rút của bạn hoặc tùy thuộc vào mức độ nhiệm vụ được thực hiện. Từ kinh nghiệm hiện tại của tôi, tôi đang làm việc trên một hệ thống, chúng tôi đã tạo ra một số câu chuyện của người dùng. cho mỗi tuần chúng tôi sẽ làm những câu chuyện được chỉ định sẽ được thực hiện trong tuần đó, nếu tất cả các nhiệm vụ được thực hiện. chúng tôi chuyển sang lần chạy nước rút tiếp theo mặc dù chúng tôi đang đi trước thời hạn. (Giả sử nhiệm vụ đã được thực hiện chính xác)

trong nhóm của tôi cho mỗi người có 3 câu chuyện cần phải hoàn thành. và tôi ngạc nhiên khi chúng ta đang vượt qua giới hạn của mình.

nó chỉ phụ thuộc vào lập trình viên. nhưng những thứ như thế này không phải là một vấn đề. Vấn đề ở đây là khách hàng sẽ nhận được những gì họ muốn hoặc yêu cầu.

Điều cuối cùng tôi nghe được là số lượng thành viên trong nhóm là 1,5 / 2x.

Cũng lưu ý rằng Mike Cohn không ám chỉ bạn nên sử dụng những con số này, anh ta chỉ nói đơn giản rằng trong nhiều năm trong ngành và nhiều đội bóng mà anh ta đã huấn luyện, anh ta đã tìm thấy 1,5x / 2x câu chuyện cho mỗi thành viên trong nhóm để làm việc tốt nhất. Anh ấy đã đưa ra câu trả lời này khi tôi hỏi anh ấy những gì anh ấy coi là kích thước câu chuyện người dùng lý tưởng.

Câu hỏi của Daft, nhưng không phải là câu trả lời được đưa ra thông qua a) ước tính nhóm nội bộ về điểm câu chuyện (hoặc bất cứ điều gì) từ bất kỳ phiên lập kế hoạch nước rút nào và sau đó b) vận tốc nước rút và / hoặc phát sinh?

Đôi khi chúng ta tiếp cận các ngôi sao trong lần chạy nước rút đầu tiên và sau đó nhanh chóng phát hiện ra không phải tất cả các câu chuyện đều là những gì chúng dường như (một điều luôn ẩn giấu). Sau đó, chúng tôi điều chỉnh lại ước tính nước rút tiếp theo của chúng tôi cho câu chuyện tiếp theo kéo xuống từ hồ sơ tồn đọng.

Tối đa một hoặc hai tầng cho mỗi nhà phát triển là loại mà hầu hết các dự án ứng dụng di động của nhóm tôi đã hạ cánh - trên một loạt các tổ chức, dự án và nhà phát triển nền tảng.