Tôi là một nhà phát triển làm việc trên một ứng dụng di động mới cho Android và iOS với một thành phần phụ trợ lớn. Chúng tôi đã ở trong ba lần chạy nước rút của dự án này và chúng tôi sử dụng Scrum với tất cả các nghi lễ của nó (sàng lọc, lập kế hoạch, nhật ký, hồi tưởng, v.v.).

Trong hai lần chạy nước rút, nhóm phải làm việc (không trả lương) ngoài giờ và cuối tuần, vì ban quản lý rất hoảng hốt, chúng tôi sẽ không hoàn thành cam kết chạy nước rút đúng hạn. Mọi người đều làm việc chăm chỉ, nhưng một số phụ thuộc bên ngoài và ước tính lạc quan khiến chúng tôi phải vật lộn để hoàn thành tất cả các câu chuyện nước rút.

Theo kinh nghiệm của tôi, có một tỷ lệ nhỏ các câu chuyện chưa hoàn thành trong một số lần chạy nước rút là hơi bình thường và chúng có thể được giải quyết trong phần tiếp theo. Nhưng người quản lý dự án của chúng tôi nói rằng đó là lỗi của chúng tôi khi chúng tôi tự lập dự toán, vì vậy chúng tôi nên hoàn thành tất cả các mục trong giai đoạn nước rút.

1. Đây có phải là một biến thể chấp nhận / phổ biến của Scrum mà tôi không biết?

2. Làm thế nào để bạn đề nghị rằng tôi nên hành động về điều này?

Một vài điều nổi bật với tôi.

Ý tưởng mà ban quản lý đưa ra là nhóm cam kết thực hiện một nhóm công việc không phù hợp với các phiên bản mới nhất của Hướng dẫn Scrum. Từ "cam kết" hoặc "cam kết" chỉ được sử dụng hai lần trong phiên bản gần đây nhất (tháng 11 năm 2017) của Hướng dẫn Scrum - một lần khi liệt kê các Giá trị Scrum và một lần để chỉ ra rằng "mọi người cam kết đạt được các mục tiêu của Nhóm Scrum ".

Ý tưởng về các mục tiêu rất quan trọng đối với Scrum. Không chỉ các tổ chức và nhóm có mục tiêu rộng lớn, mà trong Scrum, mỗi Sprint có Mục tiêu Sprint được xác định tại Sprint Planning là sự hợp tác giữa Chủ sở hữu sản phẩm và Nhóm phát triển. Mục tiêu Sprint được đáp ứng bằng cách triển khai các mục từ Product Backlog, nhưng nó không chỉ đơn giản là "hoàn thành công việc này" và nó thường không đại diện cho Sprint Backlog hoàn chỉnh. Nghĩa là, bạn sẽ có thể đạt được Mục tiêu Sprint mà không cần hoàn thành mọi Mục tồn đọng sản phẩm duy nhất được chọn cho Sprint hoặc mọi mục đơn lẻ trong Sprint Backlog. Suy nghĩ hiện tại của tôi là công việc cần thiết để hoàn thành Mục tiêu Sprint nên ở khoảng 60-70% công suất của nhóm bạn, tuy nhiên bạn chiếm công suất. Các tổ chức khác nhau sẽ khác nhau, mặc dù, nhưng đó '

Làm việc ngoài giờ và cuối tuần cũng là một cách thực hành Phát triển Phần mềm chống Agile. Một trong những nguyên tắc cơ bản là tất cả các bên liên quan của một nỗ lực có thể làm việc với một tốc độ bền vững. Những ngày dài và cuối tuần, ngay cả khi họ được trả tiền, không bền vững cho một đội.

Tại thời điểm này, có một vài bước tiếp theo. Scrum Master của nhóm nên được giáo dục quản lý về các giá trị và nguyên tắc của Phát triển phần mềm Scrum và Agile (như "cam kết" và "tốc độ bền vững"). Nhóm nên làm việc dựa trên khả năng dự báo công việc và đàm phán phạm vi với Chủ sở hữu sản phẩm. Nhóm cũng nên xác định và làm việc để giải quyết hoặc ngăn chặn các trở ngại dẫn đến tình huống này (loại bỏ hoặc giảm tác động của các phụ thuộc bên ngoài).

Tình huống mà bạn mô tả, nơi quản lý yêu cầu nhóm làm việc ngoài giờ để hoàn thành tất cả các câu chuyện được lên kế hoạch, là một trong những lý do khiến tài liệu Scrum đã ngừng sử dụng thuật ngữ "cam kết". Một cam kết thực sự chỉ có thể được đưa ra khi tất cả sự không chắc chắn được đưa ra, bao gồm cả sự không chắc chắn về sự phụ thuộc của bên thứ 3, mỗi mục là bao nhiêu công việc, mọi người sẽ có bao nhiêu thời gian để nhận bệnh, v.v.

Một trong những ý tưởng cơ bản của Scrum là nhóm làm việc với tốc độ bền vững, về cơ bản có nghĩa là làm việc nhiều giờ bình thường mà không phải làm thêm giờ (trả hoặc không trả). Điều này trực tiếp có nghĩa là bạn không gặp phải biến thể chấp nhận được của Scrum.

Những gì bạn có thể làm về nó phụ thuộc vào vai trò của bạn.

Nếu bạn là một nhà phát triển, thì điều tốt nhất bạn có thể làm là

• (gọi chung là nhóm phát triển) từ chối "cam kết" với nhiều công việc hơn bạn hoàn toàn chắc chắn bạn có thể cung cấp trong một lần chạy nước rút. Điều này có thể sẽ ít hơn những gì quản lý muốn bạn làm.
• tập trung vào việc hoàn thành công việc, thay vì bắt đầu vào các nhiệm vụ mới. Nếu bạn thấy rằng một số công việc không thể hoàn thành, hãy chỉ ra điều này càng sớm càng tốt để các kế hoạch có thể được điều chỉnh.

Nếu bạn là một bậc thầy Scrum, thì bạn thực sự có thể chứng minh giá trị của mình bằng cách giáo dục quản lý về Scrum. Một số điểm nổi bật với tôi:

• Như đã nêu trong đoạn đầu tiên, nhóm không đưa ra cam kết trong quá trình lập kế hoạch nước rút, nhưng họ đưa ra dự báo về công việc mà họ mong đợi đã hoàn thành.
• Mặc dù nhóm nên tránh có những công việc còn dang dở khi kết thúc cuộc chạy nước rút, tình huống này gần như không thể tránh khỏi khi bắt đầu một dự án (hoặc sau khi thay đổi thành phần của đội). Làm thế nào nhiều công việc mà nhóm có thể thực hiện thực tế trong một lần chạy nước rút chỉ có thể được xác định dựa trên các nhân vật lịch sử của một vài lần chạy nước rút cuối cùng của nhóm trong tác phẩm này. Đầu dự án, những nhân vật lịch sử như vậy không tồn tại, vì vậy một nhóm hoàn thành trong 3 lần chạy nước rút đầu tiên chính xác những gì kế hoạch cho mỗi lần chạy nước rút là tai nạn hơn là lập kế hoạch tốt. Sau khoảng 5 lần chạy nước rút với tốc độ bền vững, có đủ dữ liệu để có được ý tưởng hợp lý về việc nhóm có thể hoàn thành thực tế bao nhiêu trong một lần chạy nước rút.

PM của bạn không có kinh doanh liên quan đến scrum của bạn.

PM của bạn không có doanh nghiệp yêu cầu bạn làm thêm giờ không được trả lương.

Điều rõ ràng cần làm là ước tính tất cả các nhiệm vụ theo cách mà bạn có thể đảm bảo chúng sẽ được hoàn thành đúng lúc. Sau đó, bạn sẽ có thể đi đến quán rượu theo cách thứ hai, vì rõ ràng nếu đánh giá thấp một nhiệm vụ có nghĩa là bạn hoàn thành nó miễn phí, sau đó đánh giá quá cao có nghĩa là bạn có thời gian mà không làm việc.

Có một số khía cạnh về vấn đề này, nhưng ở mức độ cao, vâng - Thủ tướng sẽ hoàn toàn muốn hiểu rõ lý do tại sao công việc theo kế hoạch chưa được hoàn thành. Tuy nhiên, điều này nên được đưa lên (và giải quyết) trong quá trình hồi cứu. Từ phía nhà phát triển, có nhiều yếu tố có thể góp phần vào thất bại nước rút.

Một số điều bạn có thể muốn xem xét:

Quá nhiều trong nước rút

Nếu bạn thường xuyên cam kết với quá nhiều công việc, thì chạy nước rút sẽ thất bại. Vận tốc nước rút nên được theo dõi theo thời gian để tìm ra số điểm (hoặc ngày) tối ưu là bao nhiêu.

Phân bổ tài nguyên

Đảm bảo rằng lập kế hoạch chạy nước rút chiếm đủ tài khoản cho các hoạt động không phát triển như các nghi lễ, ngày lễ, đào tạo, quản trị viên, hỗ trợ và các dự án khác, v.v. đưa bạn vào chân sau từ đi.

Ước tính biến đổi

Bạn đang thực hiện sàng lọc, nhưng có một số loại nhiệm vụ luôn luôn tràn ngập? Thông thường đây là những yêu cầu còn thiếu hoặc mơ hồ. Nếu các yêu cầu là khó khăn, câu chuyện thậm chí không được đưa vào giai đoạn nước rút trừ khi nó đã được tinh chỉnh đầy đủ hoặc tăng đột biến đã được lên kế hoạch.

Vận tốc

Nếu vận tốc đang được theo dõi chính xác, số lượng câu chuyện thực sự sẽ trở nên rõ ràng. Điều đó không có nghĩa là chúng sẽ luôn được hoàn thành kịp thời nhưng nó sẽ giúp mọi việc dễ dàng hơn rất nhiều.

Thiện chí

Trên bất kỳ dự án, ý chí tốt là hạn chế. Nếu bạn liên tục làm việc ngoài giờ để giao hàng, tinh thần sẽ bị ảnh hưởng và các nhà phát triển sẽ kiệt sức - đây là một thất bại trong quản lý dự án . Như tôi đã vạch ra, hãy đảm bảo lập kế hoạch chạy nước rút chỉ lên lịch cho một số lượng thực tế các câu chuyện bằng cách sử dụng vận tốc và gai để giúp bạn trên đường đi.

Gai

Nếu một mặt hàng được tinh chế kém hoặc chỉ đơn giản là len, đừng ngại đặt một cành vào để cung cấp ước tính tốt hơn cho các lần chạy nước rút sau này. Vâng, một số người chỉ kém về ước tính nhưng hầu hết thời gian, các sự kiện đầy đủ chỉ không được biết đến vào thời điểm đó. Lý tưởng nhất, điều này đáng lẽ phải được đề cập trong sàng lọc hoặc được PO chọn sớm, nhưng đôi khi chúng có thể trượt qua một cuộc đua nước rút. Các nhà phát triển nên đẩy lùi những khó khăn này vì chúng có thể dễ dàng phóng ngư lôi một cuộc chạy nước rút đang diễn ra tốt đẹp.

Không, đây không phải là một dạng Agile được công nhận , vì một lý do rất quan trọng: nếu bạn cam kết cung cấp mọi thứ , bạn không làm Agile, bạn đang làm Waterfall - và nếu bạn nghĩ rằng bạn đang làm Agile , có lẽ bạn đang làm thác nước kém , tại đó. Tôi chắc rằng bạn đã nghe thấy câu nói cũ "tốt, nhanh, rẻ, chọn bất kỳ hai", phải không? Với sự phát triển phần mềm, nó giống như "tất cả các tính năng được phân phối, đúng thời gian, theo ngân sách, chọn đầu tiên hoặc hai tính năng khác". Thác chọn cái thứ nhất và Agile chọn cái thứ hai.

Nếu bạn sẽ nhanh nhẹn, bạn cần linh hoạt để bỏ Câu chuyện khỏi Sprint mà bạn không thể hoàn thành đúng hạn. Một cách có thể để làm điều này là yêu cầu Chủ sở hữu sản phẩm của bạn đánh giá các câu chuyện bằng cách sử dụng mức độ ưu tiên của MoSCoW. Điều này sẽ liên quan đến việc chọn không quá 60% Câu chuyện (tính theo tổng số Điểm Câu chuyện) là Phải có các làn sóng phải hoàn thành, 20% là các Sóng nên được hoàn thành bởi dự án và Sản phẩm khả thi tối thiểu được phát hành, 20% là Có thể Haves có thể được hoàn thành nếu bạn có thời gian và bất cứ điều gì nằm ngoài phạm vi của bản phát hành hiện tại là Waves Haves. Cũng cần lưu ý rằng khi kết hợp, Must Haves phải có đủ thịt cho xương của chúng để tạo ra Sản phẩm khả thi tối thiểu mà không cần bao gồm bất kỳ mục nào từ các danh mục khác.

Việc xác định có nên bỏ các mục từ Sprint Backlog hay không là trách nhiệm của Chủ sở hữu sản phẩm, sau khi Nhóm đã yêu cầu và bất kỳ mục nào bị rơi từ Sprint Backlog đều được Chủ sở hữu sản phẩm đánh giá, và sau đó bỏ hoàn toàn dự án hoặc đặt vào Project Backlog ở vị trí được xếp hạng thích hợp.

Trong trường hợp này, tôi đoán rằng Chủ sở hữu sản phẩm của bạn là Người quản lý dự án của bạn, phải không? Công việc của anh ấy là xác định những nhiệm vụ nào sẽ bị bỏ, vì vậy anh ấy chắc chắn không nên đổ lỗi cho bạn vì đã quá cố gắng, vì đó là công việc của anh ấy để bỏ các nhiệm vụ để bù đắp cho điều đó, và có vẻ như anh ấy không làm như vậy.

Anh ta đúng, rằng không nên có bất kỳ sự chuyển đổi nào giữa các lần chạy nước rút. Các nhóm Scrum có sự tiến hành giữa các lần chạy nước rút là một mô hình chống và không phải là điều mà Scrum chính quy chấp nhận là kết quả hợp lệ.

Nhưng, cách tiếp cận của anh ta không phải là một cách tốt.

Trong giai đoạn nước rút, nhóm phải liên tục theo dõi công việc đang được thực hiện và nếu họ có thể giữ cam kết về kế hoạch chạy nước rút về việc hoàn thành các câu chuyện đã chọn. Nếu nhóm xác định, rằng nó không thể hoàn thành tất cả các câu chuyện, nó sẽ gặp PO và chọn một câu chuyện để loại bỏ khỏi nước rút. Bằng cách đó, mọi người HÃY LÀM VIỆC TRÊN CÂU CHUYỆN, và tập trung vào việc hoàn thành những câu chuyện còn lại. Hãy nhớ rằng: luôn luôn tốt hơn để hoàn thành một câu chuyện đầy đủ hơn là hoàn thành hai câu chuyện.

Các vấn đề của sự phụ thuộc bên ngoài và ước tính không chính xác là chính xác lý do tại sao Retrospectives tồn tại. Trong quá trình Retro, nhóm nên phản ánh và xác định những vấn đề này. Và nhóm nên tìm và thực hiện các giải pháp cho những vấn đề đó. Ước tính có thể được thực hiện chính xác hơn bằng cách biết rõ hơn về hệ thống và kinh nghiệm đơn giản. Phụ thuộc bên ngoài là khó khăn hơn, nhưng không phải là không thể sửa chữa.

PM của bạn ( thậm chí PM đang làm gì trong nhóm Scrum ?? ) không được Scrum Master cho phép để buộc bạn hoàn thành tất cả các câu chuyện. Thay vào đó, nếu anh ta phàn nàn, anh ta nên giữ chúng để Hồi cứu. Và thậm chí tốt hơn, nên là một phần của việc giải quyết các vấn đề ngăn chặn những câu chuyện được hoàn thành đúng hạn.

Đây có phải là một biến thể chấp nhận / phổ biến của Scrum mà tôi không biết?

Không . Điều đó hoàn toàn sai. Tôi có thể có thể thông cảm với trả tiền làm thêm giờ, nếu PO đã sai lầm khi đưa ra dự toán như sự thật trước khi kết thúc chạy nước rút, nhưng chưa được thanh toán làm thêm giờ là hoàn toàn vô lý và sẽ làm cho tôi tìm kiếm một công việc khác càng sớm càng tốt.

Làm thế nào để bạn đề nghị rằng tôi nên hành động về điều này?

Theo kinh nghiệm của tôi, những người ở phần lớn đường sắt sẽ không lắng nghe những lập luận logic. Cách duy nhất để họ thấy nó bị hỏng như thế nào là hiển thị , không nói. Vì vậy, lần tới khi bạn ước tính và cam kết, hãy cam kết với số tiền nhỏ nhất có thể . Cam kết hoàn thành một vé nhỏ vào cuối nước rút. Một trong những bạn có thể làm trong một ngày. Xem cách PM của bạn phản ứng. Sau đó bắt đầu một cuộc thảo luận từ đó về việc hệ thống được sử dụng để làm gì và hệ thống nên được sử dụng cho mục đích gì.

Nói chung, khi bắt đầu dự án, khi chúng tôi quyết định vận tốc của đội, chúng tôi đi theo một con số bảo thủ (thấp hơn bình thường) khi xem xét thực tế rằng đó là một đội mới, sẽ mất một ít thời gian để nhóm ổn định , hiểu nhau, hiểu các yêu cầu về chức năng và NFR, v.v ... Về cơ bản, sau vài lần chạy nước rút đầu tiên, chúng tôi tối ưu hóa vận tốc đội và rõ ràng vận tốc sẽ chỉ cải thiện từ thời điểm đó.

Không có điểm nào trong việc cam kết vận tốc cao hơn lúc ban đầu và kéo dài đội để đạt được nó.

Một điều nữa là, trong một kịch bản một lần, trong đó có một cam kết giao hàng không thể bỏ qua, các nhà quản lý dự án có thể gây áp lực cho nhóm để kéo dài, làm việc muộn và làm việc vào cuối tuần. Nhưng sau đó phải được coi là một ngoại lệ và không phải là tiêu chuẩn làm việc. Làm việc như vậy có thể làm tăng vận tốc trong một thời gian ngắn, nhưng về lâu dài nó sẽ phản tác dụng, vì nó có thể dẫn đến các vấn đề về chất lượng mã, các vấn đề kiệt sức của nhóm, nhóm không hài lòng với động lực thấp, v.v.

Cam kết FAQ

Hành vi này có bình thường không?

Tôi không chắc.

Có đáng ngạc nhiên không?

Không. Một số người sẽ luôn hiểu "cam kết" có nghĩa là mọi thứ trong cam kết phải được hoàn thành.

Nó là một ý tưởng tốt?

Không. Phát triển Agile có tính bền vững như một chủ đề trung tâm: Chỉ làm việc nhiều / lâu / chăm chỉ như bạn có thể làm vô thời hạn. Đó là một ý tưởng hợp lý tại hầu hết các thời điểm. (Nếu quản lý của bạn không chấp nhận điều này, họ không nên gọi tổ chức của họ nhanh nhẹn.)

Chúng ta nên làm gì?

• Giải thích rằng nội dung chạy nước rút dựa trên ước tính . "Ước tính" có nghĩa là đôi khi nó sẽ chỉ đúng - và thường là sai. Khi nó sai, đôi khi quá thấp và đôi khi quá cao.
• Giải thích việc thay đổi hành vi ước tính dễ dàng hơn nhiều so với tốc độ làm việc.
• Giải thích rằng khi nhóm bị trừng phạt vì ước tính quá cao, họ sẽ chỉ ước tính thấp hơn và quản lý sẽ mất nhiều tiến bộ hơn bằng cách đẩy một số nội dung từ lần chạy nước rút này sang lần chạy tiếp theo.

Điều tốt đẹp là: Người quản lý dự án của bạn sẽ biết tất cả những điều này và nhận ra chúng là đúng. Chỉ là trong ngắn hạn, người ta có thể thích bỏ qua chúng.

Tôi không đồng ý với đội ngũ quản lý của bạn. Họ không nên bắt bạn làm thêm giờ để hoàn thành cuộc chạy nước rút.

Tuy nhiên, ý tưởng rằng các cam kết là không thể xuất phát từ sự hiểu lầm về phát triển phần mềm. Tôi đã thấy nhiều đội cố gắng dự đoán những câu chuyện họ có thể hoàn thành trong một lần chạy nước rút bằng số điểm câu chuyện họ đã hoàn thành trong các lần chạy nước rút trước đó. Nếu điều đó là có thể thì nó sẽ nói rằng sự phát triển phần mềm là tuyến tính, tức là nếu tôi làm việc hai giờ, tôi sẽ hoàn thành gấp đôi so với trong một giờ.

Phát triển phần mềm là sáng tạo, và do đó, không tuyến tính. Đó là một thực tiễn tốt hơn cho nhóm để nói với quản lý những gì họ có thể làm trong một lần chạy nước rút và sau đó cung cấp những câu chuyện. Nếu bạn luôn thiếu các cam kết của mình, bạn sẽ không biết phạm vi câu chuyện sẽ bắt đầu hoặc bạn đang bị chủ sở hữu sản phẩm của mình gây áp lực để tiếp tục thực hiện.

Trong trường hợp trước, bạn phải chắc chắn rằng bạn hiểu phạm vi của câu chuyện trước khi bạn đồng ý tiếp tục. Nếu đó là vấn đề thứ hai, bạn có một vấn đề về văn hóa và có rất ít việc có thể làm được.