Đội liên tục không đạt được mục tiêu nước rút

Chúng tôi là một công ty phần mềm nhỏ với một sản phẩm.

Chúng tôi sử dụng scrum và các nhà phát triển của chúng tôi chọn các tính năng mà họ muốn đưa vào mỗi lần chạy nước rút. Thật không may trong khoảng thời gian 18 tháng qua, nhóm đã không cung cấp các tính năng mà họ cam kết cho một lần chạy nước rút.

Tôi đã đọc rất nhiều bài đăng / câu trả lời nêu rõ điều gì đó "phần mềm được hoàn thành khi nó hoàn thành, không sớm, không muộn ... nó không giúp gây áp lực cho nhóm, để đặt nhiều người hơn vào nó, ... "Tôi đã nhận được phản hồi tương tự từ một trong những nhà phát triển khi tôi hỏi làm thế nào chúng ta có thể cải thiện tỷ lệ chạy nước rút thành công. Ồ, và vâng, chúng tôi sử dụng quá khứ .

Câu hỏi của tôi về cơ bản là:

Khi nào công bằng để tìm kiếm vấn đề về chất lượng của các nhà phát triển?

Tôi bắt đầu nghĩ rằng nếu bạn có thể chọn công việc / tính năng của riêng mình mà vẫn thất bại trong mỗi lần chạy nước rút: - Bạn không thể giám sát sự phức tạp của mã của riêng bạn; - hoặc mã phức tạp đến mức không ai có thể giám sát sự phức tạp.

Tui bỏ lỡ điều gì vậy?

Trước tiên bạn nên hỏi, 'ai quan tâm'?

Hoàn thành chạy nước rút cảm thấy tốt, và ở một số công ty dẫn đến cookie từ cha mẹ scrum. Nhưng thử nghiệm cuối cùng là liệu công ty có đạt được mục tiêu hay không.

Trên đây là lịch sự. Nếu công ty đang thành công trong khi không bao giờ hoàn thành nội dung theo kế hoạch của một lần chạy nước rút, bạn cũng có thể sử dụng Kanban: bạn sắp xếp các hồ sơ tồn đọng, bạn làm việc trên những gì quan trọng nhất và bạn không lo lắng quá nhiều về các lần lặp được xác định.

Một trong những giá trị của các lần lặp được xác định là thúc đẩy cải tiến quy trình (hoặc loại bỏ các yếu tố kém hiệu quả trong một số tâm lý). Bạn không nhận được điều đó ngay bây giờ. Vì vậy, bạn có thể áp dụng phần còn lại của quy trình để cải thiện quy trình (và cuối cùng hoàn thành các lần chạy nước rút) hoặc bạn có thể quyết định rằng bạn thích những gì bạn có.

Tui bỏ lỡ điều gì vậy?

ĐÚNG!

Bạn đã đi 18 tháng - hoặc một nơi nào đó trong khu phố 36 lần chạy nước rút với những hồi tưởng, nhưng bằng cách nào đó không thể khắc phục nó? Ban quản lý đã không giữ cho nhóm chịu trách nhiệm, và sau đó ban quản lý của họ không chịu trách nhiệm cho việc họ không chịu trách nhiệm cho nhóm?

Bạn đang thiếu rằng công ty của bạn không đủ năng lực .

Vì vậy, làm thế nào để khắc phục nó. Bạn (nhà phát triển) ngừng cam kết với quá nhiều công việc. Nếu những câu chuyện quá lớn mà bạn không thể làm điều đó, thì bạn cần chia những câu chuyện thành những phần nhỏ hơn. Và sau đó bạn phải bắt mọi người có trách nhiệm để hoàn thành những gì họ nói họ sẽ hoàn thành. Nếu hóa ra họ chỉ có thể thực hiện một tính năng nhỏ được thực hiện trong mỗi lần chạy nước rút, thì hãy tìm hiểu tại sao và làm cho nó tốt hơn (có thể liên quan đến việc thay thế nhà phát triển). Nếu hóa ra họ không thể tìm ra cách cam kết với số lượng công việc hợp lý, bạn sẽ sa thải họ .

Nhưng trước đó, tôi sẽ xem xét quản lý để mọi thứ diễn ra lâu như vậy và tìm hiểu tại sao họ không làm việc của họ .

Tôi muốn đề nghị bạn thực hiện một thay đổi nhỏ và thử Kanban trong vài tuần thay vì Scrum . Nó có thể làm việc tốt hơn cho nhóm của bạn.

Trong khi Scrum thúc đẩy năng suất bằng cách giới hạn thời gian làm việc có sẵn trong một lần chạy nước rút, Kanban thúc đẩy năng suất và vận tốc bằng cách giới hạn số lượng các vấn đề hoạt động, đồng thời. Dự toán thời gian không còn là một phần của quá trình. ( nguồn )

Tóm lại, Kanban là gì?

Kanban cũng là một công cụ được sử dụng để tổ chức công việc vì mục đích hiệu quả. Giống như Scrum, Kanban khuyến khích công việc được chia thành các phần có thể quản lý và sử dụng Bảng Kanban (rất giống với Bảng Scrum) để hình dung công việc đó khi tiến trình trong quy trình làm việc. Khi Scrum giới hạn số lượng thời gian được phép để hoàn thành một lượng công việc cụ thể (bằng cách chạy nước rút), Kanban giới hạn số lượng công việc được phép trong bất kỳ một điều kiện nào (chỉ có rất nhiều nhiệm vụ có thể được thực hiện, chỉ có rất nhiều nhiệm vụ có thể được thực hiện -lập danh sách.)

SCRUM và Kanban giống nhau như thế nào?

Cả Scrum và Kanban đều cho phép các nhiệm vụ lớn và phức tạp được chia nhỏ và hoàn thành một cách hiệu quả. Cả hai đều đặt một giá trị cao về cải tiến liên tục, tối ưu hóa công việc và quy trình. Và cả hai đều chia sẻ sự tập trung rất giống nhau vào một luồng công việc có thể nhìn thấy rõ, giữ cho tất cả các thành viên trong nhóm trong vòng lặp trên WIP và những gì sẽ đến.

Xem phần còn lại của chi tiết từ liên kết này

Câu hỏi của tôi về cơ bản là: khi nào thì công bằng khi tìm kiếm vấn đề về chất lượng của các nhà phát triển

Không có đủ thông tin trong bài viết của bạn để trả lời câu hỏi đó. Không có cách nào để biết họ thất bại bởi vì họ không đủ năng lực, hay thất bại bởi vì họ cam kết thực hiện nhiều công việc hơn là hợp lý.

Nếu tôi là một nhà phát triển tài năng đến khó tin, trong một nhóm các nhà phát triển tài năng vô cùng, và chúng tôi không hoàn thành câu chuyện X trong hai lần chạy nước rút (hoặc 36!), Chúng tôi có bất tài không? Hoặc, chúng ta chỉ hút theo ước tính? Điều đó phụ thuộc vào việc các câu chuyện là "tạo màn hình đăng nhập" hay "gửi một người đàn ông an toàn đến sao hỏa".

Vấn đề bắt đầu với những câu chuyện tồi tệ và / hoặc ước tính xấu

Ước tính là khó. Thực sự khó khăn. Con người mút nó, đó là lý do tại sao Scrum khiến chúng ta chia nhỏ thành các khối không nên mất hơn một hoặc hai ngày và để tập hợp các nhóm nhỏ trong số các khối đó mà chúng ta chắc chắn có thể hoàn thành trong một khoảng thời gian ngắn . Các khối càng lớn và khoảng thời gian càng dài thì ước tính của chúng ta càng kém chính xác.

Cửa hàng của bạn như thế nào? Họ có được viết tốt, với tiêu chí chấp nhận tốt? Có phải mỗi người đủ nhỏ để làm chỉ trong vài ngày? Nếu không có những câu chuyện được viết tốt (đó là lỗi của toàn bộ nhóm phát triển, bao gồm cả chủ sở hữu sản phẩm), nhóm không thể dự kiến ​​sẽ thực hiện ước tính tốt.

Vấn đề được giải quyết bằng những hồi tưởng tồi

Dường như điều bạn đang làm sai là bạn không tận dụng lợi thế của quá khứ. Bạn đã đi được 18 tháng mà không giải quyết được vấn đề này, vì vậy nhóm nghiên cứu không chú ý đến vấn đề này hoặc không giải quyết được vấn đề này.

Có phải mỗi hồi cứu kết thúc với ít nhất một mục hành động để nhóm thực hiện, để làm tốt hơn trong lần chạy nước rút tiếp theo. Có phải mỗi quá trình hồi cứu bao gồm nói về các mục hành động từ lần chạy nước rút trước để xem chúng đã được thực hiện chưa và chúng có hiệu quả không?

Giải pháp không phải là đổ lỗi, đó là học

Bước đầu tiên là ngừng tìm kiếm sự đổ lỗi, và thay vào đó, bắt đầu làm việc để cải thiện đội ngũ. Nhóm của bạn có lẽ không bất tài, chỉ kém về ước tính và lập kế hoạch. Buộc nhóm hoàn thành một cuộc chạy nước rút, ngay cả khi điều đó có nghĩa là họ chọn một câu chuyện duy nhất và kết thúc sớm một tuần. Nếu họ không thể làm điều đó, thì họ không đủ năng lực, hoặc những câu chuyện đơn giản là quá phức tạp. Câu trả lời cho câu hỏi đó nên rõ ràng.

Một khi họ có thể hoàn thành một câu chuyện, họ sẽ biết chắc chắn rằng họ có thể thực hiện X số điểm câu chuyện trong một lần chạy nước rút. Toán đơn giản sẽ giúp trả lời câu hỏi liệu họ có thể làm nhiều câu chuyện hơn hay không.

Cải tiến liên tục là giải pháp

Một khi họ hoàn thành một câu chuyện trong một lần chạy nước rút, đã đến lúc xem họ có thể làm hai câu chuyện không. Lót, rửa sạch, lặp lại. Khi họ bắt đầu thất bại trong các mục tiêu chạy nước rút, bạn đã tìm thấy giới hạn cho khả năng ước tính của họ. Quay trở lại số điểm câu chuyện từ câu chuyện trước và bám vào đó một lúc.

Tại mọi thời điểm, hãy xem xét lại một cách nghiêm túc. Nếu họ không hoàn thành một cuộc chạy nước rút, hãy tìm hiểu tại sao và hành động theo nó. Họ có quá nhiều điều chưa biết? Họ có sự pha trộn sai các kỹ năng? Ước tính của họ tốt như thế nào? Nếu họ ước tính một câu chuyện là X điểm, thì nó có đòi hỏi một lượng công việc tương đối như những câu chuyện linh mục đáng giá X điểm không? Nếu không, sử dụng điều đó để điều chỉnh các điểm của câu chuyện sắp tới.

Bạn nói rằng bạn "sử dụng hồi tưởng." Nhưng nhóm thực sự làm gì trong những hồi tưởng này? Vì bạn đã đi 18 tháng mà không một lần giải quyết khía cạnh này trong quy trình của mình, tôi đoán câu trả lời là: không có gì rất hữu ích.

Đối với tôi, hồi cứu là phần quan trọng nhất của quá trình. Vứt bỏ hoặc thay đổi bất cứ điều gì khác về scrum tất cả những gì bạn muốn (theo thỏa thuận chung của nhóm trong quá trình hồi cứu, tất nhiên), nhưng cam kết thường xuyên dành thời gian để nói về cách quy trình này hoạt động cho mọi người, chia sẻ những gì đã hoạt động và những gì đã làm 't làm việc, và đề xuất ý tưởng để cải thiện. Tiếp tục cố gắng cải thiện quy trình của bạn từng chút một trong mỗi lần chạy nước rút, và sớm hay muộn, bạn có thể có một cái gì đó hoạt động khá tốt.

Trong trường hợp của bạn, quá trình đó dường như không hoạt động. Vì các mục tiêu chạy nước rút không được đáp ứng, nên thận trọng khi tập trung vào hồi tưởng tại sao lại như vậy. Rõ ràng, nhóm đã đảm nhận quá nhiều công việc cho nước rút. Nhưng tại sao họ lại làm vậy?

• Họ đã đánh giá thấp sự phức tạp của công việc?
• Có phải quản lý đã gây áp lực để họ đảm nhận nhiều công việc hơn nhóm nghĩ rằng nó có thể xử lý?
• Có phải họ có quá nhiều gián đoạn / khẩn cấp đã lấy đi nguồn lực từ việc hoàn thành công việc theo kế hoạch?
• Có phải họ đã gặp phải những vướng mắc khiến trì hoãn hoàn thành công việc (giả sử, chờ tài sản từ một nhóm thiết kế bên ngoài)?
• Và thậm chí: một hoặc nhiều thành viên trong nhóm không có khả năng thực hiện công việc?

Đây là những câu hỏi mà nhóm nên tự hỏi mỗi lần chạy nước rút trong 18 tháng qua. Sau đó, được trang bị các câu trả lời, họ có thể đề xuất cải tiến quy trình được đề xuất để thử nghiệm cho lần chạy nước rút tiếp theo. Chúng có thể bao gồm:

• Đảm nhận công việc ít hơn trong lần chạy nước rút tiếp theo (duh!)
• Hãy thận trọng hơn trong ước tính
• Nói cho bất cứ ai đang thúc ép chúng tôi làm nhiều việc hơn để giải quyết, vì chúng tôi đã đảm nhận nhiều hơn những gì chúng tôi có thể hoàn thành ngay bây giờ
• Quản lý gián đoạn tốt hơn và điều chỉnh số lượng công việc trong lần chạy nước rút tiếp theo để phù hợp với các trường hợp khẩn cấp không thể tránh khỏi
• Khắc phục các nút thắt cổ chai hoặc lập kế hoạch xung quanh những điểm bạn không thể tránh
• Đừng gán câu chuyện cho các thành viên trong nhóm, những người không thể hoàn thành chúng (và riêng biệt, tìm ra phản ứng của ban quản lý để giải quyết tình huống với một thành viên trong nhóm hoạt động kém, từ đào tạo và cố vấn đến sa thải)

Đây là loại cuộc trò chuyện đáng lẽ phải xảy ra mỗi lần chạy nước rút trong 18 tháng qua. Đó không phải là về việc gây áp lực cho nhóm hoặc thêm nhiều tài nguyên, mà là sử dụng các quá trình hồi tưởng của bạn để cải thiện quy trình của bạn một cách liên tục. Điều đó rõ ràng không xảy ra ở đây.

Bạn sẽ nghĩ rằng đến lần chạy nước rút thứ 15 với những mục tiêu bị bỏ lỡ, nhóm sẽ thảo luận điều này trong quá trình hồi tưởng của họ rất nhiều lần, đến mức họ quyết định chỉ thực hiện những mục tiêu nước rút tối thiểu nhất có thể chỉ vì muốn hoàn thành một mục tiêu. Đến lần chạy nước rút thứ 25 chưa hoàn thành, tôi chỉ cần chạy nước rút với một thay đổi chuỗi duy nhất và không có gì khác. Nếu nhóm không thể quản lý điều đó trong một lần chạy nước rút, vấn đề thậm chí còn tồi tệ hơn bạn cho phép.

Để rõ ràng, như một số ở đây đã chỉ ra, mục tiêu chạy nước rút là dự báo, không phải là cam kết sắt và mục tiêu bị thiếu không phải là dấu hiệu của bất cứ điều gì ngoài việc đưa ra dự báo không chính xác. Một nhóm tuyệt vời có thể bỏ lỡ hàng tấn mục tiêu vì họ là những nhà dự báo tồi, trong khi một đội khủng khiếp có thể đáp ứng mọi mục tiêu và không cung cấp bất kỳ giá trị thực tế nào. Nhưng nếu dự báo của bạn sai theo cùng một hướng trong 18 tháng liên tiếp, thì một phần của quy trình của bạn không hoạt động. Sử dụng các hồi cứu của bạn để sửa chữa quy trình để dự báo của bạn gần với thực tế thực tế về những gì nhóm có thể cung cấp cho mỗi lần chạy nước rút.

"phần mềm được thực hiện khi nó được thực hiện, không sớm hơn, không muộn hơn."

Điều này đúng, nhưng với mỗi nhiệm vụ mà các nhà phát triển của bạn bắt đầu thực hiện, mọi người trong tổ chức của bạn có hiểu Định nghĩa Hoàn thành cho từng nhiệm vụ không?

Có vẻ như một trong những vấn đề lớn nhất của bạn là Ước tính , nhưng các nhà phát triển chỉ có thể cung cấp ước tính thực tế khi họ có một "định nghĩa hoàn thành rõ ràng và được xác định rõ ràng". (Bao gồm các vấn đề về quy trình của công ty - ví dụ: tài liệu người dùng, gói công việc trên một bản phát hành chính thức, v.v.)

Không có gì đáng ngạc nhiên khi việc ước tính quá mức đang gây ra vấn đề, vì hầu hết các nhà phát triển đều thấy rằng việc ước tính thời gian cần thiết để hoàn thành một nhiệm vụ là khó khăn nhất mà họ được hỏi.

Tuy nhiên, hầu hết các nhà phát triển có xu hướng xử lý hợp lý (mặc dù lạc quan ) về số lượng nỗ lực họ có thể bỏ ra, trong một khoảng thời gian nhất định.

Vấn đề thường là các nhà phát triển đấu tranh để tạo ra mối quan hệ giữa một nhiệm vụ và tổng số nỗ lực cần có khi họ xử lý thông tin không đầy đủ - đặc biệt nếu họ bị áp lực phải đưa ra tất cả các câu trả lời trước một nhiệm vụ thực sự lớn .

Điều này tự nhiên dẫn đến ước tính thời gian trở nên mất kết nối với thực tế và họ mất đi những thứ như quy trình xây dựng và tài liệu người dùng.

Ngắt kết nối có xu hướng bắt đầu ngay từ đầu khi nhiệm vụ được mô tả; và nó thường được kết hợp bởi một người không có kỹ thuật lập ra một danh sách các yêu cầu mà không có bất kỳ manh mối nào về số lượng nỗ lực cần thiết.

Đôi khi những người trong quản lý cấp cao chỉ định các nhiệm vụ và hoàn toàn bỏ qua các vấn đề về quy trình của công ty; Không có gì lạ khi quản lý cấp cao nghĩ rằng những việc như xác định các bài kiểm tra hoặc tạo bản dựng được phát hành chính thức hoặc cập nhật tài liệu người dùng chỉ xảy ra một cách kỳ diệu mà không mất thời gian hay công sức. cần thiết.

Đôi khi các dự án thất bại trước khi một nhà phát triển thậm chí đã viết một dòng mã bởi vì ai đó, ở đâu đó không thực hiện đúng công việc của họ.

Nếu nhóm phát triển không tham gia vào việc đồng ý các yêu cầu hoặc nắm bắt các tiêu chí chấp nhận, thì đó là sự thất bại của quản lý - bởi vì điều đó có nghĩa là ai đó không hiểu biết về mã và các vấn đề kỹ thuật đã khiến doanh nghiệp đưa ra một bộ yêu cầu chưa hoàn chỉnh, và để dự án mở để giải thích sai, phạm vi leo, mạ vàng, vv

Nếu nhóm phát triển có liên quan đến việc nắm bắt và đồng ý các yêu cầu, thì đó có thể là một thất bại của nhóm, người chịu trách nhiệm làm rõ các chi tiết (và tiêu chí chấp nhận - tức là "Giao hàng trông như thế nào? Khi nào nó được thực hiện ?" ). Nhóm phát triển cũng chịu trách nhiệm nói KHÔNG khi có các vấn đề ngăn chặn khác hoặc nếu một yêu cầu chỉ là không thực tế.

Vì vậy, nếu các nhà phát triển có liên quan đến việc nắm bắt các yêu cầu:

• Đội có cơ hội ngồi lại với người quản lý sản phẩm để làm rõ các yêu cầu / định nghĩa thực hiện không?
• Đội có hỏi đủ câu hỏi để làm rõ các yêu cầu ngụ ý / giả định không? Làm thế nào thường là những câu hỏi được trả lời thỏa đáng?
• Đội có yêu cầu tiêu chí Chấp nhận (định nghĩa hoàn thành) trước khi đưa ra ước tính không?
• Làm thế nào tốt tiêu chí chấp nhận thường được nắm bắt cho mỗi nhiệm vụ? Đây có phải là một tài liệu mơ hồ với chi tiết thưa thớt hay nó mô tả chức năng hữu hình và từ ngữ mà một nhà phát triển có thể dịch rõ ràng thành một bài kiểm tra?

Cơ hội là năng suất của nhóm của bạn không phải là vấn đề; nhóm của bạn có thể đang nỗ lực hết sức có thể để phát triển. Các vấn đề thực sự của bạn có thể là một hoặc nhiều điều sau đây:

• Yêu cầu không đầy đủ và mơ hồ.
• Yêu cầu / nhiệm vụ quá lớn ở nơi đầu tiên.
• Giao tiếp kém giữa đội ngũ phát triển và quản lý cấp trên.
• Thiếu các tiêu chí chấp nhận được xác định rõ ràng trước khi các nhiệm vụ được giao cho nhóm.
• Đặc điểm kỹ thuật không đầy đủ hoặc mơ hồ / mơ hồ của các bài kiểm tra chấp nhận. (tức là Định nghĩa Xong)
• Không đủ thời gian phân bổ để xác định / đồng ý tiêu chí chấp nhận.
• Các nhà phát triển đã không cân nhắc thời gian để kiểm tra mã cơ sở hiện tại hoặc sửa các lỗi hiện có
• Các nhà phát triển đã kiểm tra mã cơ sở hiện tại nhưng không nêu ra các lỗi như Chặn các vấn đề trước khi đưa ra các ước tính về các yêu cầu
• Quản lý đã thấy các vấn đề / lỗi và quyết định rằng các lỗi không cần phải sửa trước khi viết mã mới.
• Các nhà phát triển chịu áp lực chiếm 100% thời gian của họ, mặc dù có thể 20% (hoặc một số tương tự) thời gian của họ có thể bị chiếm bởi các cuộc họp, phiền nhiễu, email, v.v.
• Các ước tính được thỏa thuận theo mệnh giá và không ai điều chỉnh phòng cho lỗi hoặc dự phòng (ví dụ: "Chúng tôi đã quyết định việc này sẽ mất 5 ngày, vì vậy chúng tôi sẽ mong đợi nó được thực hiện trong 8.").
• Ước tính được mọi người (nhà phát triển và quản lý) coi là số duy nhất thay vì số "phạm vi" thực tế - nghĩa là
  • Ước tính trường hợp tốt nhất
  • Ước tính thực tế
  • Ước tính trường hợp xấu nhất

... Danh sách có thể còn dài hơn thế nữa.

Bạn cần thực hiện một số "tìm hiểu thực tế" và tìm hiểu chính xác lý do tại sao các ước tính luôn bị ngắt kết nối với thực tế. Là phần mềm cơ sở hiện có xấu? Có thiếu bảo hiểm thử nghiệm đơn vị? Các nhà phát triển của bạn có tránh giao tiếp với quản lý không? Quản lý có tránh giao tiếp với các nhà phát triển không? Có sự mất kết nối giữa kỳ vọng quản lý và kỳ vọng của nhà phát triển khi nói đến "Định nghĩa hoàn thành" không?

Lời khuyên của tôi để khởi động lại đội là chọn câu chuyện nhỏ nhất có thể cho mỗi đội, mỗi lần chạy nước rút và hoàn thành một câu chuyện đó và chỉ một câu chuyện đó!

Tôi đồng ý với các áp phích khác, hoặc nhóm không đủ năng lực hoặc họ đang cố gắng làm quá nhiều thứ.

Bắt đầu với những thứ nhỏ nhất, những câu chuyện được phân loại nhiều nhất và hoàn thành một lần chạy nước rút. Yêu cầu nhóm hoàn thành một cuộc chạy nước rút và thành công, và điều đó sẽ giúp họ thấy cách ưu tiên thời gian và các cam kết công việc. Theo thời gian, nhóm sẽ có thể đảm nhận ngày càng nhiều công việc hơn cho đến khi họ đạt được năng suất cao nhất.

Bạn nên thu thập dữ liệu và xây dựng mức độ tin cậy dựa trên hiệu suất trong quá khứ.

http://www.leadagile.com/2013/07/agile-health-metrics-for-predictability/

Ví dụ đơn giản nhất là với nước rút thời gian liên tục, chẳng hạn như hai tuần một lần. Ước tính có bao nhiêu điểm câu chuyện nhóm sẽ hoàn thành trong vòng hai tuần. Sau khi nước rút hai tuần kết thúc, hãy xem có bao nhiêu điểm câu chuyện đã thực sự hoàn thành. Theo thời gian, bạn có thể thấy bạn ước tính 15 điểm, nhưng chỉ hoàn thành 10. Trong trường hợp đơn giản đó, bạn có thể bắt đầu di chuyển về phía trước với một điều chỉnh vận tốc để bạn chỉ lập kế hoạch 10 điểm cho mỗi lần chạy nước rút. Hoặc bạn có kế hoạch hoàn thành 66% công việc ước tính.

Bằng cách xây dựng mức độ tin cậy với độ lệch chuẩn, bạn có thể nói với ban quản lý: theo mục tiêu dự án hiện tại, chúng tôi hy vọng chỉ có 50% độ tin cậy chúng tôi có thể hoàn thành trong 3 tuần, nhưng độ tin cậy 95% chúng tôi có thể hoàn thành trong 5 tuần.

Ý tưởng đằng sau Agile và Scrum là xây dựng một vòng phản hồi chặt chẽ để bạn có thể đánh giá quá trình của mình. Bạn phải hỏi "Nó đã bị hỏng ở đâu?", Vì nó dường như đã bị hỏng hoàn toàn.

1. Lập kế hoạch những gì bạn sẽ làm và lập danh sách của nó
   • Điều này nên bao gồm chọn các mục từ một hồ sơ tồn đọng của các mục cần phải hoàn thành. Trước khi bất cứ điều gì được đưa vào danh sách việc cần làm cho lần chạy nước rút, nhóm cần phải đồng ý rằng họ hoàn toàn hiểu điều đó và họ ước tính sẽ mất ít hơn một lần chạy nước rút để hoàn thành.
   • Lý tưởng nhất là tồn đọng được sắp xếp theo thứ tự ưu tiên (cho doanh nghiệp) và bạn có thể lấy theo thứ tự ưu tiên.
   • Nếu các mục từ backlog quá lớn, hãy chia chúng thành các phần nhỏ hơn. Sau đó chia các phần nhỏ thành các nhiệm vụ riêng lẻ có thể hoàn thành trong một ngày hoặc ít hơn.
   • Đừng mong đợi kế hoạch này dễ dàng hay nhanh chóng.
2. Thực hiện trên các mục từ danh sách trong một khoảng thời gian xác định (chạy nước rút)
3. Xem lại những gì bạn đã hoàn thành
   • Những câu chuyện đã được hoàn thành?
   • Nếu không có câu chuyện nào được hoàn thành, thì những nhiệm vụ tạo nên câu chuyện đã kết thúc?
   • Nếu không có nhiệm vụ nào được hoàn thành, vậy chính xác thì mọi người đã làm gì vào thứ Hai tuần trước? Thứ ba tuần trước ?, V.v. - tại thời điểm này, đã đến lúc phải hướng nội ...

4. Khắc phục sự cố (phân tích phản hồi và điều chỉnh)

   • Những thứ đã hoàn thành mất bao lâu?
   • Điều gì ngăn cản nhiệm vụ hoàn thành?
   • Các thành viên trong nhóm chia nhỏ các câu chuyện (tính năng) thành các nhiệm vụ có thể hoàn thành trong 1 ngày hoặc ít hơn? Nếu không, hãy làm điều này và biến nó thành một phần của danh sách việc cần làm.
   • Những thay đổi trong danh sách nhiệm vụ hoặc các mục trong danh sách nhiệm vụ đã được thực hiện trong giai đoạn nước rút? Đây có phải là một nguyên nhân cho việc không hoàn thành? Nếu có, đừng thay đổi danh sách hoặc các tính năng. Ném tính năng đã thay đổi vào backlog cho đến khi nó ổn định.
   • Làm thế nào bạn có thể giảm kích thước và phạm vi của một vài mục thành một cái gì đó có thể được hoàn thành trong một lần chạy nước rút? Chọn một cái gì đó nhỏ như cải tiến đăng nhập, sửa lỗi đơn giản, đánh máy, chỉ để hoàn thành một số thứ để cho nhóm có được một thước đo về những gì họ có thể làm. Nếu bạn không thể làm điều này, sau đó dừng chạy nước rút và lập kế hoạch lại .

5. Quay lại bước một và lặp lại cho đến khi phát hành ...

Có những trở ngại về tài liệu, các vấn đề ghép nối tạo ra sự phụ thuộc, các vấn đề giao tiếp, không đủ thông tin trong các yêu cầu không? ... Cái gì? Các nhà phát triển đã dành thời gian cố gắng học các công nghệ mới? Họ đã dành số lượng lớn thời gian trong thiết kế? Có phải những thứ như học tập chiếm trong danh sách nhiệm vụ nước rút?

Bạn có nghĩ rằng nhóm của bạn nghĩ rằng họ đã cô lập vấn đề của họ mỗi lần hồi cứu? Đội đã hành động để khắc phục vấn đề. Có phải nhóm không trả lời và quản lý chỉ đơn giản là ra lệnh cho các giải pháp và quá trình hành động?

Trong khoảng thời gian dài, một cái gì đó là sai hệ thống, không chỉ đơn giản với các nhà phát triển. Tại một số thời điểm (trước khi một năm kết thúc) ai đó trong nhóm (bao gồm cả chủ scrum) nên hỏi, dù chúng ta có thể hoàn thành những gì, dù nhỏ đến đâu?

Trong tình huống của bạn hồi tưởng là quá muộn.
Bạn có đang tổ chức các cuộc họp độc lập hàng ngày và thực sự nhận được tình trạng từ mọi người về những gì họ đã làm trong 24 giờ trước không?
Là bậc thầy scrum sử dụng các cuộc họp đó để đo lường sự tiến bộ của mỗi nhà phát triển so với mục tiêu của họ?
Bạn cần sử dụng đoạn đó của phương pháp Scrum để theo dõi tiến trình khi bạn đi. Nó sẽ cung cấp cho bạn cái nhìn sâu sắc tốt về những gì mọi người đang làm.
Họ có bị phân tâm không? Dành quá nhiều thời gian cho cà phê, hoặc giúp đỡ người khác về SE / SO, hoặc đọc tin tức, hoặc thực hiện kiểm tra mà không chiếm? Hay họ thực sự đi xuống, đầy hơi trước mắt và hoàn toàn cam kết quá mức? Quan điểm hàng ngày sẽ cung cấp cho bạn một ý tưởng tốt. Nó cũng sẽ giúp giữ cho các nhà phát triển tập trung vào nhiệm vụ trong tay, vì vậy họ không phải thừa nhận họ đã không làm gì ngày hôm qua.
Và tất nhiên, nếu họ báo cáo tiến trình ổn định trong suốt giai đoạn nước rút và cuối cùng vẫn không giao hàng, thì họ đã nói dối và có lẽ đã đến lúc một nhà phát triển mới.

Ước tính nỗ lực và thời gian cần thiết để hoàn thành một nhiệm vụ phức tạp, chẳng hạn như mã lập trình, là khó khăn. Như Joel Spolsky nói:

Các nhà phát triển phần mềm không thực sự muốn lập lịch trình. Thông thường, họ cố gắng để thoát khỏi mà không có một. Họ sẽ làm điều đó khi hoàn thành!

Tuy nhiên, các công ty cần thời hạn để hoạt động. Như Joel đề xuất, hãy thử sử dụng Lập kế hoạch dựa trên bằng chứng sẽ mang lại ước tính thời gian với xác suất liên quan, việc quản lý có thể liên quan đến bất kỳ loại rủi ro nào.

Scrum làm một vài điều.

Đầu tiên, nó khuyến khích ưu tiên. Nhà cung cấp công việc phải nói những gì họ muốn được thực hiện trước tiên, và không nói "mọi thứ đều quan trọng như nhau".

Thứ hai, nó tạo ra một số sản phẩm có thể sử dụng ngay cả khi không phải mọi thứ đã hoàn thành. Đó là điểm có một "sản phẩm có khả năng vận chuyển" vào cuối mỗi lần lặp.

Thứ ba, nó cung cấp một vòng phản hồi chặt chẽ hơn. Bằng cách khẳng định rằng mọi thứ sẽ được "thực hiện" vào cuối giai đoạn nước rút, bạn tránh được vấn đề "90% tính năng hoàn thành, nhưng chỉ thực hiện được một nửa"; khi đẩy đến thời hạn, bạn có thể gạt những thứ cần phải sang một bên để có vẻ như bạn sắp hết thời hạn, hoặc bạn có thể giả mạo nó. Bằng cách có một định nghĩa về việc đã hoàn thành và nhấn mạnh vào những việc đang được thực hiện, bạn sẽ biết liệu có điều gì khó hơn so với trước đó thay vì sau này.

Forth, nó tránh được hàng tồn kho bằng cách di chuyển kế hoạch chi tiết gần để thực hiện công việc. Lên kế hoạch cho những thứ xa vời là một hình thức kiểm kê: vốn dành cho các tài nguyên không có sẵn để bán hoặc sử dụng ngay cho khách hàng. Hàng tồn kho như vậy có thể bị thối rữa (kế hoạch thay đổi dưới chân, thông tin mới khiến nó trở nên lỗi thời), không phù hợp với nhu cầu (hóa ra chúng ta không cần một mạng lưới phân tán, bởi vì thứ sử dụng nó không có giá trị) và giảm giá trị của hàng hóa được vận chuyển (nếu trong năm ngoái, một nửa thời gian của bạn dành cho kế hoạch cho năm tới và hơn thế nữa, bạn có thể đã nhận được gấp đôi số lượng vận chuyển nếu thay vào đó bạn làm việc trên công cụ để sẵn sàng cho bây giờ). Nếu bạn có thể di chuyển kế hoạch gần hơn để thực hiện mà không bị mất (khó khăn!), Bạn có thể giảm hàng tồn kho.

Đó không phải là cách duy nhất để giải quyết những vấn đề này. Bạn dường như đang sử dụng scrum nơi nó cung cấp một luồng công việc cho các nhà phát triển để làm việc trong từng khoảng thời gian, với việc định kỳ thêm công việc mới để làm và kiểm tra tiến trình.

Đây là một cách hữu ích để sử dụng các mẫu scrum-esque. Nó giữ cho công việc trôi chảy, nó tiếp tục lập kế hoạch gần với sản xuất, nó cung cấp một số vòng phản hồi, v.v. , cố gắng hoàn thành mọi thứ và thử nghiệm trong cùng một lần chạy nước rút buộc phần cuối của lần chạy nước rút không liên quan đến sự phát triển mới!)

Việc không đưa chính xác những gì họ sẽ làm vào một cuộc đua nước rút không phải là bằng chứng cho thấy các nhà phát triển của bạn không làm việc tốt. Điều đó có nghĩa là họ không theo SCRUM từ trên cao, thay vào đó sử dụng các phần của khung.

Nếu họ đã giảm một nửa (hoặc một phần tư) số tiền họ đã cam kết cho mỗi lần chạy nước rút, nhưng vẫn giữ mọi thứ khác như cũ, thì họ sẽ hoàn thành nhiều hơn những gì họ đã cam kết cho mỗi lần chạy nước rút! Bạn sẽ có cùng số lượng mã được sản xuất. Rõ ràng "thất bại nước rút" không phải là phần quan trọng, bởi vì đó chỉ là một chi tiết quy trình nội bộ. Mục tiêu của công ty là làm cho shit được thực hiện, và đó là tốt; không tuân theo một số quy trình cụ thể, trừ khi mục tiêu của bạn là một loại chứng nhận quy trình ISO nhất định.

Quá trình tồn tại phụ thuộc vào mục tiêu của các công cụ được thực hiện.

Mặt khác, vì họ không tuân theo các quy tắc của SCRUM, nên bạn không nhận được cùng loại phản hồi. Bạn nên kiểm tra các công cụ thu được để xem loại lỗ hổng được tạo ra có phải là lỗ hổng mà SCRUM được thiết kế để xử lý hay không; Có những câu chuyện sống như thây ma mãi mãi, và chỉ bị giết chết muộn? Có những câu chuyện có vẻ dễ dàng, chúng bùng nổ, và trong một hồi tưởng mà không có giá trị tổng số công việc? Là sản phẩm thực sự có thể vận chuyển tại thời điểm bạn cần / muốn gửi nó?

"Phần mềm được hoàn thành khi nó được thực hiện, không sớm hơn, không muộn hơn" là một công thức cho sự thất bại nếu bạn chưa xác định "hoàn thành" trông như thế nào.

Hầu hết các kỹ sư sẽ cố gắng tạo ra giải pháp tốt nhất có thể, nhưng điều này có thể dễ dàng dẫn đến mạ vàng, đặc biệt là với các kỹ sư ít kinh nghiệm. Các chỉ trách nhiệm của quản lý là để xác định chính xác nơi mục tiêu là và để giữ các kỹ sư của bạn tiến theo hướng đó. Các kỹ sư sẽ thường xuyên cố gắng thay đổi bên để cải thiện các tính năng, và tùy thuộc vào quản lý để quyết định xem việc quay bên đó sẽ tăng tốc mọi thứ trong thời gian dài hay liệu nó chỉ cải thiện cho cùng một cải tiến.

Quan điểm của sự phát triển nhanh là mỗi tác phẩm mới phải tốt như yêu cầu để đáp ứng nước rút đó và KHÔNG TỐT HƠN !!!!!! Vâng, đó là về sự nhấn mạnh nhất mà tôi có thể thêm vào StackOverflow - và nó vẫn chưa đủ nhấn mạnh. Nếu bạn thấy rằng mọi người đang thêm những thứ không bắt buộc ngay lúc này thì họ cần được đào tạo về cách phát triển nhanh một cách chính xác.

Ồ, và vâng, chúng tôi sử dụng quá khứ.

Oh tốt, vậy bạn có biết tại sao đội của bạn thất bại không? Bạn đã có 36 cơ hội để nói về những gì đã làm và không hoạt động, vì vậy các bậc thầy scrum nên hiểu đầy đủ cách giải quyết các vấn đề, phải không?

Tôi có linh cảm, theo mô tả mà bạn đưa ra, rằng công ty của bạn đã rơi vào tâm lý "SCRUM làm cho chúng tôi làm việc hiệu quả". Sự thật là SCRUM không làm cho năng suất của bạn. Thay vào đó, nó là một công cụ giúp bạn làm cho bản thân hiệu quả theo cách xác định thực tế phát triển mà bị quản lý và nhà phát triển bỏ qua.

Điều gì đã làm chủ scrum được xác định là vấn đề tiềm năng với nhóm? Có phải họ liên tục phân công gấp đôi số lượng công việc mà họ có thể xử lý? Nếu vậy, chủ scrum nên nhẹ nhàng đề nghị họ đảm nhận ít công việc hơn, bởi vì chủ scrum có thể nhìn vào vận tốc của đội.

Khi nào công bằng để tìm kiếm vấn đề về chất lượng của các nhà phát triển?

Thời điểm mà một người nên tìm kiếm vấn đề về chất lượng của các nhà phát triển là thời điểm bạn chắc chắn đó là vấn đề. Đây không phải là một vấn đề mới được tạo ra bởi SCRUM. Đây là thực tế của kinh doanh. SCRUM sẽ cho bạn bao la biết thêm thông tin về khả năng của thành viên trong nhóm của bạn hơn các phương pháp truyền thống làm. Bạn nên biết liệu vấn đề là "nhà phát triển phần mềm không đủ tốt" hay "kỳ vọng quản lý là không thực tế" ở mức độ tốt hơn nhiều so với bạn hiểu theo cách tiếp cận truyền thống. Đây là thời gian để quản lý làm những gì quản lý làm tốt nhất: tìm ra những người phù hợp với công việc, để công ty có thể kiếm tiền. Nếu bạn không thể biết vấn đề đang ở đâu, thì hãy tưởng tượng nó sẽ khó đến mức nào nếu không có những hồi tưởng đó!

Nếu bạn nghĩ rằng mọi người có thể đủ tốt (ngụ ý việc tuyển dụng của họ không phải là một lỗi về phía quản lý), thì lời khuyên của tôi sẽ là bắt đầu suy nghĩ bên ngoài. Nếu công việc không hoàn thành, hãy xem xét thay đổi hình dạng công việc cho các nhà phát triển. Một trong những cách dễ nhất mà tôi đã tìm thấy để thực hiện thời hạn hoàn thành nước rút là điều chỉnh tiêu chí DONE để bạn sẽ hài lòng với kết quả, bất kể nó được thực hiện như thế nào. Do đó, được hoàn thành trở thành một tautology.

Điều này đặt trách nhiệm quản lý, đặc biệt là chủ SCRUM. Bí quyết là viết các nhiệm vụ, nếu hoàn thành, rất có giá trị, nhưng nếu không hoàn thành, họ vẫn cung cấp đủ giá trị gia tăng cho công ty để có giá trị tiền lương của họ. Sau 18 tháng, tôi mong đợi những hồi tưởng của bạn sẽ dạy bạn điều gì đó. Nếu họ không, có lẽ bạn nên viết những câu chuyện với mục đích rõ ràng là những câu chuyện thất bại khai quật được điều gì đó không ổn trong công ty của bạn và đưa nó ra ánh sáng. Điều đó sẽ cung cấp cho công ty những dữ liệu quý giá to lớn, cho thấy công ty dường như có bao nhiêu sự thất vọng với đội ngũ phát triển. Vấn đề thực sự có thể là các nhà phát triển, như bạn yêu cầu. Hoặc vấn đề có thể là một bệnh lý trong suy nghĩ của công ty mà bạn không có ý tưởng cho đến bây giờ!

Nếu thực sự vấn đề là ở công ty, không phải nhà phát triển, thông tin bạn thu được từ những câu chuyện chưa hoàn chỉnh này thực sự có thể có giá trị hơn sản phẩm bạn thu thập từ những người thành công! Nó có thể là thông tin cứu toàn bộ công ty của bạn! Đó dường như là thông tin thực sự có giá trị đối với tôi và bạn có thể sử dụng SCRUM làm công cụ để giúp bạn thu thập thông tin.

"Khi nào công bằng để xem xét chất lượng của các nhà phát triển?"

Tất cả thời gian. Rõ ràng một số người có năng suất cao hơn những người khác, bạn không cần một lời bào chữa là chủ nhân của họ để đo lường hiệu suất của họ.

Một chút khó khăn là cách bạn làm điều đó. Lời khuyên của tôi là thuê một số người ký hợp đồng có kinh nghiệm để làm việc cùng với nhân viên perm của bạn trong cùng một nhóm nhiệm vụ được ước tính bởi những người perm của bạn và xem họ có vận tốc cao hơn không.

Điều này sẽ cung cấp cho bạn một so sánh tốt với thị trường hiện tại mà không khóa bạn vào một thuê dài hạn.

Nó cũng có thể cung cấp cho các anh chàng perm một chút đá lên mông.

Ngoài ra, nếu họ phàn nàn các nhà thầu đang bỏ qua chất lượng vv để đạt được vận tốc thì điều đó sẽ thúc đẩy một cuộc trò chuyện về nơi giá trị doanh nghiệp. Bảo trì dài hạn hoặc sản phẩm ngắn hạn vận chuyển.

Nếu đó là công cụ dài hạn thì nó sẽ buộc bạn phải định lượng nó và đưa nó xuống nước rút như những điều cần thiết!

Đã có một số câu trả lời xuất sắc. Cụ thể, ước tính xấu, cam kết quá mức và / hoặc công việc đột xuất là nguyên nhân thường xuyên của sự trượt dốc.

Nhưng tôi tò mò về lý do tại sao "các nhà phát triển [của bạn] chọn các tính năng mà họ muốn đưa vào mỗi lần chạy nước rút". Các nhà phát triển thường nên làm việc trên các tính năng với mức độ ưu tiên cao nhất trước tiên - và ưu tiên là quyết định kinh doanh, nghĩa là phải đến từ chủ sở hữu sản phẩm đóng vai trò ủy quyền cho các bên liên quan kinh doanh.
. )

Mặt khác, ước tính là các quyết định kỹ thuật và không nên được đưa ra (hoặc đoán thứ hai) bởi những người kinh doanh. Bạn không nói bất cứ điều gì về điều này - tôi chỉ nêu quan điểm bởi vì, theo kinh nghiệm của tôi, khi các nhà phát triển đang chọn những gì để làm việc, việc các doanh nhân cố gắng đưa ra quyết định sẽ mất bao lâu.

Có vẻ như bạn có một quá trình rối loạn chức năng. Tôi sẽ khuyên bạn không nên đưa các chuyên gia tư vấn phát triển, ít nhất là vào lúc này, bởi vì điều đó có thể sẽ có ảnh hưởng tiêu cực đến tinh thần. Nhưng có vẻ như tổ chức của bạn có thể sử dụng một số trợ giúp về phía quản lý dự án. Đó là nơi tôi sẽ bắt đầu, bằng cách đưa vào một huấn luyện viên nhanh nhẹn có kinh nghiệm - nếu không phải là để tham gia trung dài hạn, thì ít nhất là để đánh giá hoặc "kiểm tra sức khỏe". Một huấn luyện viên giỏi sẽ cho bạn biết nếu bạn có các nhà phát triển hoạt động kém, nhưng ít nhất theo cách này, đó là toàn bộ đội ngũ (không chỉ các nhà phát triển) đang bị kiểm tra.

Một quan sát khác: theo kinh nghiệm của tôi, rất khó để scrum thành công như một phương pháp quản lý dự án nếu bạn không tuân theo các quy trình phát triển tốt. Bạn đang làm thử nghiệm đơn vị tự động? hoặc thậm chí tốt hơn, thử nghiệm chấp nhận tự động? Là nhà phát triển của bạn ghép nối, hoặc ít nhất bạn có thực hiện đánh giá mã thường xuyên và / hoặc hướng dẫn không? Bạn đang thực hành một số hình thức tích hợp liên tục?