Xử lý nước rút thất bại và thời hạn

Nhiều sách và bài viết về Scrum nói rằng việc chạy nước rút thất bại (khi nhóm không hoàn thành một số tính năng từ Sprint Backlog) không phải là điều gì xấu, nó xảy ra theo thời gian và nó thực sự có thể hữu ích nếu nhóm học hỏi từ những sai lầm của họ và cải thiện một cái gì đó trong nước rút sau đây. Và đội không nên bị trừng phạt vì không hoàn thành công việc họ cam kết.

Điều này có vẻ tuyệt vời từ quan điểm của nhà phát triển, tuy nhiên, giả sử chúng ta có một công ty phần mềm " Scrum-Addicts LLC " đang phát triển một thứ gì đó cho các khách hàng nghiêm túc (" Money-Bag Corporation "):

1. Các nhà quản lý Scrum-Addicts đề nghị tạo ra một phần mềm cho Money-Bag
2. Họ đồng ý về danh sách các tính năng và Money-Bag yêu cầu cung cấp ngày giao hàng
3. Người quản lý Scrum-Addicts tham khảo nhóm scrum của họ và nhóm cho biết sẽ mất 3 tuần chạy nước rút để hoàn thành tất cả các tính năng
4. Người quản lý Scrum-Addicts thêm 1 tuần để an toàn, hứa sẽ giao phần mềm trong 1 tháng và ký hợp đồng với Money-Bag
5. Sau 4 lần chạy nước rút (thời hạn vận chuyển) Nhóm Scrum chỉ có thể cung cấp 80% tính năng (do thiếu kinh nghiệm với hệ thống mới, cần phải sửa các lỗi nghiêm trọng trong các tính năng trước đó trong môi trường sản xuất, v.v ...)
6. Như Scrum gợi ý, tại thời điểm này, sản phẩm có khả năng chuyển đổi được, nhưng Money-Bag cần 100% tính năng, như đã đề cập trong hợp đồng. Vì vậy, họ phá vỡ hợp đồng và không trả gì cả.
7. Scrum-Addicts đang trên bờ vực phá sản vì họ không nhận được tiền từ Money-Bag, và các nhà đầu tư đã thất vọng với kết quả này và không sẵn lòng giúp đỡ công ty nữa.

Rõ ràng, không có công ty phần mềm nào muốn ở trong đôi giày của Scrum-Addicts. Điều tôi không hiểu về Agile và Scrum là cách họ đề xuất các nhóm nên giải quyết việc lập kế hoạch và thời hạn để tránh tình huống được mô tả ở trên. Vì vậy, để tóm tắt, tôi có 2 câu hỏi:

Ai là người có lỗi?

1. Các nhà quản lý, vì đó là công việc của họ để lập kế hoạch phù hợp
2. Nhóm, vì họ cam kết thực hiện nhiều công việc hơn họ có thể
3. Một người nào khác

Điều gì sẽ được thực hiện?

1. Người quản lý nên di chuyển thời hạn gấp 2 (hoặc 3x) lần so với ước tính của nhóm ban đầu.
2. Các thành viên trong nhóm nên được khuyến khích thực hiện tất cả các công việc họ cam kết thực hiện bất kể điều gì (bằng cách đưa ra hình phạt cho những lần chạy nước rút thất bại)
3. Nhóm nên bỏ Scrum vì nó không phù hợp với chính sách hạn chót của công ty
4. Tất cả chúng ta nên bỏ phát triển phần mềm và tham gia một tu viện
5. ???

Tôi thấy một số vấn đề quản lý cơ bản trong ví dụ của bạn:

• nếu người quản lý Scrum-Addicts ký hợp đồng "thời hạn cứng", nhưng chỉ thêm một mức an toàn 33% trong tình huống "có một hệ thống mới", điều đó khá liều lĩnh.

• tính khả dụng của việc cung cấp ít nhất x% các tính năng sau một tháng có thể đã được sử dụng để đàm phán hợp đồng trong đó khách hàng trả tiền ít nhất một phần khi anh ta chỉ nhận được 80% các tính năng vào thời hạn. Hợp đồng toàn bộ hoặc không có gì là thứ mà cả nhà cung cấp phần mềm và khách hàng sẽ không được hưởng lợi - điều này có nghĩa là không chỉ 0 tiền cho nhà cung cấp, mà còn 0 tính năng cho khách hàng. Và một phương pháp phát triển hoàn toàn hoặc không có gì như "Thác nước" sẽ chỉ cho phép bạn viết những hợp đồng như vậy, một cách tiếp cận nhanh nhẹn cung cấp các khả năng bổ sung.

• nhìn vào kết quả của một hoặc hai lần chạy nước rút đầu tiên nên có thể thấy rõ với người quản lý rằng đội không thể đáp ứng thời hạn. Vì vậy, anh ta nên có những hành động sớm hơn, và ưu tiên lại các nhiệm vụ và tính năng còn lại, hoặc cố gắng đàm phán lại với khách hàng trước đó. Ví dụ: người quản lý có thể đã cố gắng thu nhỏ phạm vi của một số tính năng còn lại, vì vậy nhóm có thể đã cung cấp tất cả các tính năng được đề cập trong hợp đồng, nhưng mỗi tính năng trong phạm vi giảm.

Nếu một nhiệm vụ hóa ra mất nhiều thời gian hơn bạn nghĩ, không có phương pháp phát triển nào sẽ cứu bạn khỏi điều đó. Nhưng một cách tiếp cận nhanh như Scrum cho phép quản lý có nhiều cơ hội hơn để kiểm soát những gì xảy ra trong tình huống đó. Nếu họ không tận dụng những cơ hội đó, thì rõ ràng đó là lỗi của họ, không phải của nhóm, không phải lỗi của "Scrum" và không phải lỗi của khách hàng vì "anh ta không chấp nhận sự nhanh nhẹn".

Một trong những tuyên bố giá trị của " Tuyên ngôn về phát triển phần mềm linh hoạt " là:

Hợp tác khách hàng qua đàm phán hợp đồng

Việc Scrum-Addicts LLC đàm phán hợp đồng thay vì thiết lập sự hợp tác với khách hàng khiến tôi đặt câu hỏi về sự nhanh nhẹn của họ.

Một điều rõ ràng: Sự nhanh nhẹn cần được MỌI NGƯỜI chấp nhận. Agility không chỉ dành cho các nhà phát triển. Người quản lý và khách hàng cũng cần chấp nhận các giá trị của Tuyên ngôn Agile. Nếu khách hàng không chấp nhận sự nhanh nhẹn và vẫn yêu cầu các hợp đồng cứng nhắc và cộng tác tối thiểu, thì không nên sử dụng nhanh nhẹn hoặc tìm kiếm khách hàng tốt hơn.

Đó là lỗi của khách hàng, họ bị khóa trong bong bóng hợp đồng với sự phát triển theo thời hạn.

Ai là người có lỗi?

Người quản lý, phòng pháp lý, kế toán - hãy lựa chọn ...

Tôi biết ví dụ này có phần khó khăn nhưng thực tế là công ty có thể bỏ đi mà không phải trả tiền nếu họ không hài lòng 100% nên đã gióng lên hồi chuông báo động ngay lập tức khi trộn lẫn thác nước và suy nghĩ nhanh nhẹn.

Khách hàng muốn có bánh của họ và ăn nó - họ rất vui khi chấp nhận thác nước, thác nước nhỏ, nhanh nhẹn, la-la-đất miễn là họ nhận được sản phẩm X với giá $ Y vào ngày Z.

Phát triển Agile hoàn toàn đòi hỏi nhóm phát triển và khách hàng phải ở cùng một trang theo quan điểm phương pháp luận. Suy nghĩ khác biệt trong văn hóa sẽ chỉ xuất hiện trong rửa là mơ tưởng.

Dự án CNTT đối phó với ẩn số ; một số trong những ẩn số thậm chí còn ẩn số chưa biết . Điều đó nghĩa là gì?

Lấy ví dụ một cây cầu đồ chơi cho đường sắt mô hình của bạn. Có tất cả các tham số được biết đến với bạn:

• Bạn biết thung lũng lớn như thế nào

• Bạn biết vật liệu của núi, chiều cao, sự ổn định của họ, vv

• Bạn biết bạn cần bao nhiêu nguyên liệu

• Bạn biết từ các "dự án" trước đó mất bao lâu để bạn xây dựng những thứ tương tự

Có nhiều biến số liên quan đến việc tính toán đầu tư thời gian và tiền bạc của bạn. Nhưng bạn có thể nói mà không cần suy nghĩ, liệu nó đã kết thúc vào cuối tuần tới.

Lấy ví dụ một bước nữa:

• Giả sử bạn không xây dựng cây cầu cho tuyến đường sắt mô hình của riêng mình, thay vào đó bạn xây dựng nó cho một người hoàn toàn xa lạ: công việc của bạn là xây dựng cây cầu đường sắt giữa hai ngọn núi

• Giả sử bạn gần như không có thông tin trước về cảnh quan mô hình

• Thông tin về phong cảnh là, có hai ngọn núi, dường như không quá lớn

• Sự thống nhất của ngọn núi nằm giữa đá và thạch

• Tổng chi phí có tối đa 10 đô la

• Nơi làm việc hoàn toàn tối và không có cơ hội ánh sáng: bạn chỉ có một hộp 8 que diêm

• Hạn chót là 3 giờ

Đó sẽ là sự tương tự với một dự án CNTT. Bạn có kinh nghiệm trong việc xây dựng những cây cầu và thật dễ dàng để đi bộ trên địa hình đã biết. Những gì nó làm cho khó khăn là bóng tối . Có rất nhiều điều bạn khó có thể dự đoán: Các biện pháp của những ngọn núi chỉ được biết đến sau khi chọc vào một thời gian trong bóng tối. Vậy là sự nhất quán của những ngọn núi. Từ đó bạn có thể ước tính thời gian bạn sẽ mất và chi phí bao nhiêu. Ở đây, những điều chưa biết là những điều mà bạn không biết khi bắt đầu dự án như địa hình cụ thể, v.v. Nhưng có những điều bạn không thể thấy trước, ngay cả với những ước tính kinh nghiệm nhất và bảo thủ nhất. Những điều này là những ẩn số chưa biết mang một chút hỗn loạn.

Mọi công ty CNTT nên biết điều đó. Họ phải đối phó với rủi ro dự án.

1) Có một số cách để giảm thiểu rủi ro (tài chính): thỏa thuận có thể bao gồm tha khách hàng trả cho mỗi lần tăng công việc. Vì vậy, sau khi tăng 1 được phân phối, một tỷ lệ một phần phải được thanh toán. Miễn là Scrum-Addicts LLC cung cấp, có rủi ro tài chính tối thiểu. Các mục tiêu chạy nước rút càng được lên kế hoạch, tổng rủi ro của mỗi lần chạy nước rút càng thấp. Điều đó có nghĩa là, nếu Tập đoàn Money-Túi nhận được 80% hợp đồng, ít nhất họ phải trả 80% giá trị hợp đồng. Nếu họ từ chối thanh toán sau khi nước rút thất bại, rủi ro sẽ không cao bằng việc từ chối thanh toán 100%.

2) Scrum-Addicts LLC có vấn đề với các nhà phát triển của họ

Người quản lý Scrum-Addicts tham khảo nhóm scrum của họ và nhóm cho biết sẽ mất 3 tuần chạy nước rút để hoàn thành tất cả các tính năng mà người quản lý Scrum-Addicts thêm 1 tuần để an toàn, hứa sẽ gửi phần mềm trong 1 tháng và ký hợp đồng với túi tiền

Điều đó cho thấy rằng, a) các nhà phát triển không có kinh nghiệm với scrum hoặc b) họ đang làm scrum sai Các nhóm càng làm việc với scrum, ước tính của họ càng tốt. Nếu các nhóm đưa ra ước tính và người quản lý thêm "bộ đệm" là "an toàn", thì người quản lý dường như biết rõ hơn nhóm, đó là một dấu hiệu xấu . Nếu bạn có một nhóm có kinh nghiệm, không cần phải có "người quản lý", nhóm đã bao gồm điều đó trong dự toán. Ý tưởng là, càng chạy nước rút, nhóm càng làm việc với nhau thì nhóm càng biết điểm mạnh và điểm yếu của mình và có một số số liệu để đưa ra ước tính thực tế. Tất nhiên là có - như đã đề cập - những ẩn số chưa biếtmà có xu hướng làm cho ước tính khó khăn; hoặc ít nhất là không chính xác. Nhưng về lâu dài, các ước tính sẽ ngày càng tốt hơn.

Ai là người có lỗi?

1) Quản lý

Như đã nói ở trên: rõ ràng có một thất bại trong quản lý rủi ro. Nếu công ty đang trên bờ vực phá sản, công ty xứng đáng. Nếu bạn làm việc tại một công ty như vậy: rời đi!

2) Đội

Ngay cả khi quản lý là hoàn toàn ngu ngốc, nhóm nên đã lên tiếng chống lại một dự án như vậy. Một người quản lý tốt nên biết những rủi ro; nhưng một nhà phát triển tốt nên chỉ ra rủi ro. Và hơn hết: Nhóm nên báo cáo sớm nếu có sự cố.

Điều gì sẽ được thực hiện?

Bây giờ: Mang tiền-túi ra tòa

Vì tương lai: Đừng làm những hợp đồng như vậy

Scrum không thể đổ lỗi cho thất bại trong quản lý. Scrum được phát triển dựa trên kinh nghiệm của nhiều dự án CNTT thất bại. Nó không thể ngăn chặn sự thất bại, nó cũng không thể chữa khỏi sự bất tài của các đội hoặc quản lý. Ý tưởng cơ bản là:

• cấu trúc các cách giao tiếp (ai nói chuyện với ai khi về vấn đề gì)

• để khuyến khích nhà phát triển báo cáo thất bại sớm

• phân chia vấn đề trong nhiệm vụ và nhiệm vụ

• để cấu trúc thời gian và năng lực (ai làm việc khi nào

• để phân phối các nhiệm vụ theo các khe thời gian

• làm cho không thể đoán trước được một chút dự đoán hơn (lập kế hoạch poker)

hoặc tổng thể: để giảm thiểu rủi ro.

Scrum là một công cụ như một cái búa. Cho dù đó là một công cụ tốt phụ thuộc vào kiến ​​thức của bạn làm thế nào để sử dụng nó. Nhưng đôi khi một tuốc nơ vít phù hợp hơn. Tuỳ bạn.

Trước hết, "Ai là người có lỗi?" là câu hỏi sai. Chỉ định đổ lỗi là niềm vui và tất cả, và có lẽ sẽ khiến tất cả mọi người ngoại trừ người bị đổ lỗi cảm thấy nhẹ nhõm (theo nghĩa "này, đó không phải là lỗi của tôi, ông chủ đã nói như vậy!"), Nhưng đó không phải là cách sử dụng hiệu quả thời gian của bạn , và thực sự có thể phản tác dụng và làm giảm tinh thần nhân viên.

Một cách tốt hơn để xem xét nó là "Điều gì gây ra sự chậm trễ?". Có phải nó thiếu kinh nghiệm trong công nghệ? Các lỗi nghiêm trọng không được phát hiện trong thử nghiệm / QA? Thiếu kiểm tra / QA? Quá lạc quan trong dự toán? Không tính đến các ước tính không lạc quan của nhóm? Ai đó bị xe buýt đâm phải? Dù nguyên nhân là gì, câu hỏi tiếp theo là "Làm thế nào để chúng tôi đảm bảo điều này không xảy ra nữa?". Trong một số trường hợp (hy vọng là hiếm), câu trả lời cho điều đó có thể là "loại bỏ những thứ tương tự", nhưng nếu bạn bắt đầu từ "Tôi cần trừng phạt bất cứ ai chịu trách nhiệm", bạn sẽ không thể thấy phần lớn các trường hợp nơi mà nó không phải là giải pháp đúng

Trong dự án, bạn đã bị chìm. Hạn chót đến và đi, bạn đã cảnh báo khách hàng ngay khi rõ ràng là nó sẽ bị trượt (vì bạn đã làm điều đó, phải không? Nếu không, đó là một phần của vấn đề), và bây giờ nó phải được xử lý trong hợp đồng (nó thực sự được đánh vần trong hợp đồng, phải không?). Nói chung, điều đó sẽ liên quan đến việc đàm phán với khách hàng về cách bạn sẽ cung cấp những gì còn thiếu. Rất nhiều người thích nghĩ về hợp đồng là một thứ không thể thay đổi, nhưng phải đối mặt với việc a) bỏ hợp đồng và không có những gì bạn đã mua, b) kiện công ty vi phạm hợp đồng và tiêu tốn rất nhiều tiền vào tòa án, và c) đàm phán làm thế nào để có được sản phẩm của họ với ít rắc rối nhất có thể, hầu hết các công ty chọn c.

Nhìn về phía trước, trước khi trích dẫn giá / thời hạn cho khách hàng, bạn nên phân tích các rủi ro liên quan đến thời hạn bị trượt hoặc vượt chi phí (nguyên nhân có thể gây ra điều đó là gì? Nguyên nhân nào bạn có thể giảm thiểu bằng cách nào đó và bạn không thể và chỉ là phải lập kế hoạch cho) và sử dụng thông tin đó để giúp quyết định những gì bạn sẽ hứa. Nếu đó là trường hợp 100% hoặc không có gì, rõ ràng bạn sẽ báo giá cao hơn và thời hạn dài hơn, vì rủi ro cao hơn.

Bạn sẽ nhận thấy tôi đã không nói về Agile trong toàn bộ câu trả lời này. Đó là bởi vì (tôi sẽ quên đi sự tham gia của khách hàng vào Scrum trong một giây, mặc dù điều đó rất, rất quan trọng) vào thời điểm này nó không thực sự quan trọng. Bạn sẽ phải đối mặt với vấn đề này trong Agile, Waterfall hoặc bất kỳ quy trình phát triển nào bạn sử dụng. Có, Agile có nhiệm vụ giúp bạn quản lý rủi ro tốt hơn, bằng cách cho bạn biết liệu họ có trở thành vấn đề thực sự sớm hơn không và liên quan đến khách hàng trong chính quy trình để họ luôn được thông báo, nhưng đó không phải là thuốc chữa bách bệnh.

Thứ nhất, đây là một vấn đề với bất kỳ phương pháp phát triển. Ít nhất là với một hệ thống phát triển lặp đi lặp lại, bạn có một cái gì đó để hiển thị cho khách hàng vào cuối thời hạn, có thể đủ để có một phần mở rộng để hoàn thành sản phẩm (ngay cả khi khách hàng không trả thêm tiền nữa!).

Tuy nhiên, có những trường hợp thời hạn là hạn chót, tuy nhiên, hãy tưởng tượng bạn đang viết một trò chơi và nó hoàn toàn phải được phát hành đúng vào dịp lễ Giáng sinh. Nhận sai mà đã phá sản nhiều công ty!

Đối với các phương thức nhanh phải hoàn thành một số tính năng nhất định vào một ngày nhất định, scrum có thể không phải là phương pháp tốt nhất để sử dụng (vì tôi luôn thấy rằng scrum làm cho dev chậm hơn và không cho phép đủ nhanh để thay đổi quy trình khi cần thiết

Những gì bạn cần, bất kể phương pháp nào, là thiết lập một hồ sơ tồn đọng các tính năng cần thiết để cung cấp khả năng hiển thị tiến trình. Tiến bộ trên cơ sở mỗi lần chạy nước rút là không đủ, bạn sẽ không biết liệu mình có đạt được mục tiêu cuối cùng hay không. Vì vậy, một phương pháp theo kiểu kanban sẽ tốt hơn: đặt tất cả các tính năng ở bên trái và làm việc với chúng thông qua hệ thống để hiển thị tiến trình hoàn thành.

Điều đó tập trung vào suy nghĩ của mọi người về những gì vẫn cần phải được thực hiện theo cách mà Scrum không xử lý và cho phép những người khác ngoài nhóm nhà phát triển thấy những gì còn lại và liệu bạn có thể đáp ứng mục tiêu hay không (và do đó quản lý sớm mong đợi của khách hàng hoặc sắp xếp những phần thưởng ngoài giờ trước khi chúng cần thiết).

Scrum là một hệ thống làm việc mãi mãi, liên tục xác định và tinh chỉnh một cái gì đó. Nó chỉ đơn giản là không phù hợp cho loại phát triển này. Những người khác có thể quản lý sự tinh tế này và vẫn giữ khái niệm phát triển lặp lại, Kanban là một người như thế, Crystal khác. Nhưng điều cần thiết phải hiểu là nếu bạn theo dõi Scrum một cách tôn giáo, bạn sẽ không nhanh nhẹn. Bất kỳ hệ thống Agile thực sự nào cũng có thể biến đổi để đối phó với các vấn đề cụ thể này, đó là lý do tại sao nó được gọi là nhanh nhẹn, đó là về việc hoàn thành những gì cần phải làm và nếu thời hạn cố định là một phần của điều đó, thì bạn nên được bao thanh toán vào cách bạn làm việc.

Mô hình phát triển không đồng bộ với mô hình hợp đồng. Lý tưởng nhất là cách các hợp đồng được viết sẽ thay đổi, nhưng điều đó khó có thể thực sự xảy ra. Tuy nhiên, ngay cả khi bạn đã bỏ scrum, bạn vẫn sẽ có những bất ngờ và bỏ lỡ thời hạn (chỉ có thể bạn sẽ muộn hơn nhiều vì bạn đã làm tất cả những thiết kế đó ở phía trước và tất cả đều sai !!).

Có hoặc không có thay đổi về cách viết hợp đồng, bạn gửi những gì bạn đã làm việc . Sau đó hoàn thành hợp đồng bằng cách ăn một chu kỳ thời gian phát triển để hoàn thành các tính năng bạn chưa hoàn thành.

Có tốt không khi bạn thất bại trong việc cung cấp mọi thứ bạn đã hứa vào ngày bạn đã hứa? Không, nhưng khách hàng của bạn sẽ hạnh phúc hơn nhiều nếu bạn có thể giao một thứ gì đó đúng giờ, sau đó sẽ giao phần còn lại nhanh hơn sau khi bạn đơn giản là chạy muộn và không có gì để cung cấp cho họ.

Nhiều sách và bài viết về Scrum nói rằng việc chạy nước rút thất bại (khi nhóm không hoàn thành một số tính năng từ Sprint Backlog) không phải là điều gì xấu, nó xảy ra theo thời gian và nó thực sự có thể hữu ích nếu nhóm học hỏi từ những sai lầm của họ và cải thiện một cái gì đó trong nước rút sau đây. Và đội không nên bị trừng phạt vì không hoàn thành công việc họ cam kết.

Cách bạn "trừng phạt" loại hành vi này là bằng cách giới hạn số lượng công việc mà những người không hoàn thành có thể thực hiện lần chạy nước rút tiếp theo. Cơ hội để làm việc trên những thứ mát mẻ đang biến mất. Phần thưởng cho việc làm tốt là công việc nhiều hơn.

Điều này có vẻ tuyệt vời từ quan điểm của nhà phát triển, tuy nhiên, giả sử chúng ta có một công ty phần mềm "Scrum-Addicts LLC" đang phát triển một thứ gì đó cho các khách hàng nghiêm túc ("Money-Bag Corporation"):

Các nhà quản lý Scrum-Addicts đề nghị tạo một phần mềm cho Túi đựng tiền Họ đồng ý về danh sách các tính năng và Money-Bag yêu cầu cung cấp ngày giao hàng Các nhà quản lý Scrum-Addicts tham khảo nhóm scrum của họ và nhóm cho biết sẽ mất 3 tuần - chạy nước rút dài để hoàn thành tất cả các tính năng Người quản lý Scrum-Addicts thêm 1 tuần để an toàn, hứa sẽ gửi phần mềm trong 1 tháng và ký hợp đồng với Money-Bag Sau 4 lần chạy nước rút (thời hạn vận chuyển) Nhóm Scrum chỉ có thể cung cấp 80% về các tính năng (vì thiếu kinh nghiệm với hệ thống mới, cần sửa các lỗi nghiêm trọng trong các tính năng trước đây trong môi trường sản xuất, v.v ...) Như Scrum gợi ý, tại thời điểm này, sản phẩm có khả năng chuyển đổi được, nhưng Money-Bag cần 100% của các tính năng, như được đề cập trong hợp đồng. Vì vậy, họ phá vỡ hợp đồng và không trả gì cả.

Scrum-Addicts đang trên bờ vực phá sản vì họ không nhận được tiền từ Money-Bag, và các nhà đầu tư đã thất vọng với kết quả này và không sẵn lòng giúp đỡ công ty nữa.

Nếu vào thứ Hai, tôi đặt cược cho bạn 100 đô la rằng trời sẽ mưa vào thứ năm và trời không mưa cho đến thứ Sáu, bạn có quyền lấy tiền của tôi. Nếu, thay vì một cơ hội để đánh bạc, điều bạn muốn là dự báo thời tiết thì chúng tôi cần một hợp đồng cho phép tôi đưa ra dự báo cập nhật vào thứ ba.

Rõ ràng, không có công ty phần mềm nào muốn ở trong đôi giày của Scrum-Addicts. Điều tôi không hiểu về Agile và Scrum là cách họ đề xuất các nhóm nên giải quyết việc lập kế hoạch và thời hạn để tránh tình huống được mô tả ở trên.

Hãy suy nghĩ về lý do tại sao MB muốn lấy bóng của họ và về nhà. MB đã không yêu cầu công việc được thực hiện trong một tháng ngay từ đầu. SA hứa 100% các tính năng quan trọng trong một tháng và không cung cấp. SA đặt thời hạn không MB. SA thậm chí còn tự ý thêm một tuần vào hạn chót. Vậy tại sao đây là thời hạn?

Thỉnh thoảng khi cạnh tranh cho các công ty phần mềm làm việc chịu thua cám dỗ để thể hiện và hứa hẹn mặt trăng. Các chuyên gia cẩn thận thiết lập cho dù một mặt trăng thậm chí là cần thiết. Đâu là nhu cầu quan trọng hơn đối với MoneyBags? 100% tính năng hoặc một sản phẩm hoạt động trong thời gian một tháng? Họ thậm chí có biết những gì thực sự quan trọng? Có một số sự kiện sắp tới thiết lập một thời hạn khó khăn?

Nếu tôi là người nghiện Scrum đàm phán hợp đồng này, tôi muốn biết nhiều hơn về nhu cầu kinh doanh của Money-Bag và cấu trúc hợp đồng để có được sự linh hoạt như Money-Bag thoải mái. Tôi sẽ dạy họ cách quy trình nhanh hoạt động để họ biết những gì mong đợi từ chúng tôi.

Bằng cách này, thay vì mong đợi mọi thứ sẽ đột nhiên hoạt động hoàn hảo trong một tháng, họ sẽ mong đợi được đánh giá khả năng giao hàng đầu tiên sau 1 đến 2 tuần.

Vì vậy, để tóm tắt, tôi có 2 câu hỏi:

Ai là người có lỗi? Cán bộ quản lý, bởi vì đó là công việc của họ để thực hiện kế hoạch phù hợp
Nhóm nghiên cứu, bởi vì họ cam kết sẽ làm việc nhiều hơn họ có thể
người khác

Bất cứ ai cũng có thể dừng chuyến đi này trước khi chúng tôi xuống đường một tháng.

Tôi có thể đổ lỗi cho Money-Bags Corp khi thuê một đội rõ ràng là đại diện cho một quá trình thác nước là nhanh nhẹn. Bản thân hợp đồng cho thấy rõ điều này không nhanh nhẹn. Kế hoạch được thực hiện trong một tháng không làm cho nó nhanh nhẹn.

Nếu bạn khăng khăng rằng nó nhanh nhẹn, thì nó nhanh nhẹn chỉ với một lần chạy nước rút kéo dài một tháng. Mà, vâng, tôi không khuyên bạn vì điều đó, một lần nữa, giống như thác nước.

Điều gì sẽ được thực hiện?

Nhanh như thế nào? Cung cấp một cái gì đó mỗi lần chạy nước rút? Nhận phản hồi trước thời hạn? Tuần nước rút dài? Làm thế nào về việc đàm phán lại hợp đồng hà khắc ngay lúc bạn nghi ngờ thời hạn đang gặp nguy hiểm thay vì trốn tránh và cầu nguyện? Ít nhất bạn có thể ngừng lãng phí thời gian cho một dự án cam chịu và tìm kiếm một khách hàng hợp lý hơn.

Người quản lý nên di chuyển thời hạn gấp 2 (hoặc 3x) lần so với ước tính của nhóm ban đầu.

Hệ số nhân thời hạn cũng hữu ích như đặt đồng hồ sớm 15 phút để bạn không bao giờ bị trễ. Bạn chỉ có thể tự đánh lừa mình rất lâu trước khi bạn nhận ra mình đang làm gì.

Ước tính sớm là sai. Cố nắm bắt thế nào là sai. 5 tuần, cho hoặc mất một vài tuần là một biểu thức đơn giản cho phép bạn thể hiện mức độ không chắc chắn của ngày hoàn thành. Thay vì cố gắng đoán chính xác, bạn đoán dự đoán của bạn hoang dã đến mức nào. Làm một số công việc thực tế và nhận được một số dữ liệu thực sự. Sau đó, bạn có thể bắt đầu thực hiện ước tính với phạm vi hẹp hơn. Một đến hai tuần là nhiều thời gian để làm điều này.

Các thành viên trong nhóm nên được khuyến khích thực hiện tất cả các công việc họ cam kết thực hiện bất kể điều gì (bằng cách đưa ra hình phạt cho những lần chạy nước rút thất bại)

Các thành viên trong nhóm nên được khuyến khích. Thất bại, cam kết, hoặc cách khác. Thay vì xây dựng bất kỳ hậu quả nhân tạo nào như các hình phạt hay thậm chí tiền thưởng (cà rốt và cây gậy) đã chỉ ra rằng những người làm công việc sáng tạo như lập trình đáp ứng tốt nhất nếu được cung cấp ba điều: Tự chủ, Làm chủ và Mục đích.

Daniel Pink đã nói về TED về điều này. Cuộc nói chuyện là về động lực không nhanh nhẹn nhưng tôi dễ dàng thấy cách ánh xạ những điểm này thành nhanh nhẹn:

Tự chủ - Tôi muốn chỉ đạo cuộc sống của chính mình - Hãy để tôi chọn công việc từ hồ sơ tồn đọng.
Làm chủ - Tôi muốn cải thiện điều gì đó quan trọng - Phản hồi của khách hàng.
Mục đích - Tôi muốn trở thành một phần của một cái gì đó lớn hơn bản thân mình - Một nhóm hợp tác.

Nhóm nên bỏ Scrum vì nó không phù hợp với chính sách hạn chót của công ty Scrum có thể đạt thời hạn chính xác hơn thác nước. Đưa ra một scrum thời hạn có thể đáp ứng nó. Nó có thể đáp ứng nó chỉ với 1 trong 47 tính năng tùy thuộc vào thời gian, tính năng và kỹ năng nhưng nó có thể đáp ứng nó.

Một dự án nhanh nhẹn có thể được tạo kiểu vô cùng tuyệt vời đến nỗi mỗi đêm khi nhóm về nhà, nó đã sẵn sàng để xuất xưởng. Điều này có vẻ ngớ ngẩn trừ khi bạn nghĩ về việc vận chuyển như yêu cầu khách hàng kiểm tra và cung cấp phản hồi. Càng sớm xảy ra, bạn càng có thể điều chỉnh sớm. Điều này đánh vào mọi thời hạn có thể. Chỉ là không phải mọi tính năng. Nhưng nó chỉ cho bạn các tính năng quan trọng.

Tất cả chúng ta nên bỏ phát triển phần mềm và tham gia một tu viện

Phải, giống như nhốt tôi trong một căn phòng cách xa cuộc sống thực sẽ khiến tôi viết mã LESS.

Tôi đã chỉnh sửa câu trả lời này xuống kích thước. Nếu bạn tò mò đọc lịch sử chỉnh sửa.

Mọi người phải nhanh nhẹn. Bất cứ điều gì bạn quyết định sẽ là, trông như thế nào, ai làm gì, như thế nào, khi nào, ở đâu và tại sao bởi tất cả các bên. Agile khách hàng, quản lý và phát triển.

Bạn không thể đưa ra một ngày vận chuyển quá xa trong tương lai. Bạn đưa ra một ước tính.

Ai đó cần để quản lý kỳ vọng của khách hàng. Lý do bạn không lo lắng quá nhiều về việc có một vài lần chạy nước rút bị tụt lại là vì bạn điều chỉnh để ngăn chặn toàn bộ dự án bị tụt lại phía sau. Nếu bạn đi đến kết luận sau một hoặc hai lần chạy nước rút mà bạn sẽ không hoàn thành sẽ đáp ứng "ngày giao hàng", đó là khi bạn nói với khách hàng.

Bây giờ bạn muốn làm gì? Loại bỏ các tính năng bạn không cần hoặc di chuyển ngày. Nếu bạn có thể giao hàng đúng thời gian, bạn sẽ làm được. Đừng ngần ngại mang tin xấu.

Ai biết được, trên một số dự án, bạn có thể giao hàng sớm hơn.

Bạn không thể nhanh nhẹn nếu khách hàng không muốn.

Mục tiêu

Tôi tin rằng hai "số liệu" sau đây sẽ là cơ sở cho mọi quyết định kinh doanh:

• là công việc có lợi nhuận (cho khách hàng)
• chúng ta có làm việc hiệu quả nhất có thể không

Đây là khá phổ quát. Tất nhiên, nó trở nên phức tạp hơn rất nhanh, ví dụ, công việc mang lại lợi nhuận là về sản phẩm làm đúng, người dùng có thể sử dụng sản phẩm, sản phẩm được bán trên thị trường một cách chính xác, v.v. - cho rất nhiều " Người nghiện Scrum " LLC "không chịu trách nhiệm.

Vấn đề

Hợp đồng không tập trung vào các mục tiêu đã nêu ở trên. Có một điều khoản "tất cả hoặc không có gì" - hoàn thành mọi thứ và được trả tiền, hoặc không làm gì cả và không được trả tiền. Tuy nhiên, điều này không liên quan trực tiếp đến giá trị được tạo ra. Một nhược điểm khác sau: bây giờ chúng ta cần dành thời gian và tiền bạc để đảm bảo và xác minh rằng hợp đồng đang được tuân theo. Tại sao chúng ta lại muốn tiêu số tiền này? Làm thế nào để đảm bảo một hợp đồng được thực hiện giúp đỡ khi các yêu cầu đã thay đổi trong thời gian đó và chúng tôi đã phát hiện ra rằng phần mềm được đặt hàng không tạo ra bất kỳ giá trị nào? Có nhiều tiền hơn đi xuống cống! Bây giờ, tất nhiên, có một lý do cho hành vi này:

• Văn hóa chúng ta được sử dụng để mua sắm cho những thứ như vậy. Chúng tôi hy vọng mua sắm phần mềm như chúng ta sẽ làm cho một chiếc xe hơi: chọn một cấu hình, được đưa ra một mức giá và thời hạn, và sẽ rất không vui nếu hai điều đó không được đáp ứng.
• chúng tôi muốn giảm tải rủi ro và trách nhiệm
• chúng tôi muốn sự ổn định, nó giúp lập kế hoạch và làm cho chúng tôi cảm thấy tốt hơn (và cũng là khách hàng của chúng tôi, đó là một khía cạnh quan trọng!)

Vào cuối ngày, chúng ta sẽ phải chọn một sự thỏa hiệp cho phép chúng ta thỏa mãn mục tiêu của mình tốt nhất có thể.

Đây là cách nó nên hoạt động

• có hợp đồng dịch vụ & công việc thay vì sản phẩm
  • cần phải chấm dứt trong thông báo tương đối ngắn
• phối hợp chặt chẽ để đảm bảo hiệu quả tối ưu
• liên quan đến tất cả các bên cần thiết, cả từ " Scrum-Addits LLC " và " Money-Bag Corporation " - một "điểm liên lạc duy nhất", tất cả thông tin sẽ không hoạt động ở đây

Vâng, về cơ bản tôi chỉ nói "nhanh nhẹn". Bây giờ đây là lý do:

• quy trình & hợp đồng được tối ưu hóa để chi tiêu càng nhiều tiền cho Mục tiêu càng tốt
• bạn sẽ phải tin tưởng nhà thầu thực hiện công việc của mình và không cần đầu tư nhiều tiền để xác minh rằng anh ta hoàn thành công việc.
• khả năng kiện nhà thầu của bạn nếu kỳ vọng / hợp đồng của bạn không được đáp ứng thường không có ích, bởi vì làm như vậy sẽ tốn nhiều chi phí hơn là chỉ bỏ nó. Một số mối quan tâm chính ở đây là thời gian để thị trường. Bạn rất có thể sẽ mất nhiều tiền / doanh nghiệp bằng cách ra tòa hơn bạn sẽ nhận được.
  • vào cuối ngày, bạn sẽ phải tự chịu một số rủi ro.