Chúng tôi có một nhóm SCRUM "điển hình" và chúng tôi cam kết làm việc cho một lần chạy nước rút, và cũng duy trì tồn đọng. Gần đây, chúng tôi đã gặp phải một vấn đề là cố gắng tích hợp / xử lý công việc của một nhà phát triển quá sức làm việc ngoài ban nhạc (chọn làm việc ngoài giờ làm việc / chạy nước rút thông thường).

Để đưa ra một ví dụ, nếu nhóm thực hiện 50 điểm công việc, hãy nói rằng họ sẽ hoàn thành tất cả các công việc trong khuôn khổ SCRUM vào cuối giai đoạn nước rút và họ và công ty rất vui. Một trong các thành viên trong nhóm quyết định tự làm việc, trên một mục tồn đọng, vào thời gian rảnh của riêng họ. Họ không kiểm tra công việc này mà thay vào đó là lưu nó (chúng tôi sử dụng TFS và nó nằm trong một kệ).

Làm thế nào để xử lý việc này? Một vài vấn đề ..

• Trong lần chạy nước rút tiếp theo, các thành viên trong nhóm này cho biết công việc lập trình đã hoàn thành 99% và chỉ cần xem xét và kiểm tra mã. Làm thế nào để bạn đối phó với điều này trong phương pháp SCRUM và nhanh nhẹn?
• Các nhà phát triển khác phàn nàn về việc không tham gia vào các quyết định thiết kế liên quan đến những câu chuyện này, vì công việc đã được thực hiện ngoài ban nhạc.
• Chủ sở hữu sản phẩm của chúng tôi sẵn sàng thực hiện công việc "miễn phí" này và các thành viên quá cố có thể thực hiện mục đích này để có được nhiều tính năng hơn vào sản phẩm mà nhóm không thể thực hiện được trong lần chạy nước rút. Có quan điểm cho rằng điều này đang phá vỡ "quy trình". Rõ ràng QA, UI và công việc tài liệu vẫn cần phải được thực hiện trên công việc này.

Tôi thấy rất nhiều cuộc thảo luận về việc không buộc một nhóm SCRUM phải làm thêm giờ, nhưng một thành viên của nhóm làm việc ở trên và vượt quá mong đợi trong quá trình lập kế hoạch và thực hiện chạy nước rút thì sao? Tôi sẽ do dự khi trị vì người này và nói rằng bạn không thể làm việc thêm (tất nhiên là hết sức thận trọng), nhưng đồng thời nó dường như gây ra một số vấn đề với một số thành viên trong nhóm (nhưng không phải tất cả).

Làm cách nào để tích hợp công việc được thực hiện bởi một thành viên quá sức vào quy trình SCRUM và nhanh nhẹn để phát triển phần mềm?

Được rồi, vì vậy ai đó nhiệt tình viết mã tuyệt vời cần phải được thực hiện, chỉ là không theo thứ tự. Với tất cả sự nhấn mạnh do:

ĐỂ HỌ

Nó gây ra một số biến chứng trong nước rút scrum của bạn. Liệu nó thực sự quan trọng trong sơ đồ lớn của mọi thứ? Nếu anh ấy hoàn thành những gì anh ấy cần, thì hãy để anh ấy tiếp tục và xây dựng những điều tuyệt vời cho bạn.

Tôi biết một số lập trình viên tuyệt vời đã rời bỏ các công ty vì họ đã không để các lập trình viên vượt ra khỏi những ràng buộc của một hệ thống nhân tạo như Scrum (Bản thân tôi đã rời bỏ công việc cuối cùng của mình sau khi bị đối xử không khác gì QA được tôn vinh). Nếu có khiếu nại từ các nhà phát triển khác về đầu vào (tôi có thể thêm khiếu nại hoàn toàn hợp lệ), tốt nhất nên giới thiệu chương trình "20% thời gian" để cho anh ấy (và những người khác) làm những gì họ làm tốt nhất với sự can thiệp tối thiểu.

Thay vì những câu chuyện trong tương lai (có thể yêu cầu đầu vào từ người khác), hãy để nhà phát triển thử nghiệm công nghệ hoặc tính năng mới. Bạn có thể tìm thấy một cơ hội mới tuyệt vời mà chưa bao giờ được khám phá nếu không. Tôi chắc chắn nhà phát triển này có một vài điều họ muốn thử nếu bạn chỉ để họ.

Có hai điều tôi nghĩ bạn nên xem xét ở đây:

1. Đừng cản trở dòng chảy sáng tạo của ai đó.
   • Nếu một nhà phát triển muốn làm việc ngoài giờ, hãy để họ làm.
2. Đừng tạo ra công việc cho người khác.
   • Nếu một nhà phát triển muốn làm việc ngoài giờ, thì chắc chắn không nên tạo thêm công việc cho người khác .

Điểm 2 có thể là điều mà các nhà phát triển khác lo lắng.

Giống như bạn đã đề cập, họ không thích thực tế là mã được viết mà không có toàn bộ đầu vào của nhóm. Điều này có thể là do, về mặt thiết kế, nó kết thúc kém hơn. Và mã với thiết kế kém hơn có cách lây nhiễm các mã khác xung quanh nó.

Vậy, bạn có thể làm gì?

Hãy để mã dev đầy tham vọng vào nội dung trái tim anh ấy, nhưng hãy nói rõ rằng không có lý do gì để cho rằng mã ngoại khóa của anh ấy sẽ được sử dụng .

Rốt cuộc, anh ta là một phần của một nhóm, và vì vậy nhóm nên tham gia vào cách tất cả các mã được phát triển.

Tuy nhiên, nếu công việc của anh ấy hợp lý và phù hợp với thiết kế theo thỏa thuận của nhóm thì anh ấy sẽ có thể sử dụng phần lớn những gì anh ấy đã viết (tiền thưởng!). Nếu không, nó sẽ buộc anh ta phải suy nghĩ nhiều hơn về thiết kế của mình vào lần tới khi anh ta quyết định bắt đầu lại.

Bằng cách này, không ai được nói KHÔNG , và không ai có việc làm thêm được tạo ra cho họ.

Đưa anh ta trở lại đội

Bạn nên tự hỏi mình (hoặc tốt hơn là nhóm, bao gồm cả người vượt quá):

Tại sao hành vi này là một vấn đề?

Vì bạn gắn nhãn cho nhà phát triển là người giám sát, tôi đoán công việc của anh ta có chất lượng tốt, vì vậy tôi sẽ cho rằng đây không phải là vấn đề.

Nhưng dường như có những vấn đề khác:

• Công việc làm thêm không được kiểm tra đúng cách
• nó không được ghi lại
• Phần còn lại của đội không biết điều đó
• nhà phát triển quyết định điều tiếp theo sẽ thực hiện, không phải PO
• nhà phát triển không nhận được bất kỳ phản hồi nào từ các bên liên quan khác nhau để kết hợp trong công việc của mình.

Tại sao tiếp theo tôi sẽ là:

Tại sao nhà phát triển làm điều đó?

• Nếu ở cuối giai đoạn nước rút không còn đủ công việc, cần có một quyết định của nhóm (bao gồm cả PO) về những gì cần giải quyết tiếp theo. Tại sao nhà phát triển tránh quyết định này?

Khi bạn có câu trả lời cho những câu hỏi này, bạn có thể bắt đầu trả lời câu hỏi của riêng mình:

• Nếu đó không phải là vấn đề, hãy để anh ấy làm việc của mình. Mặc dù một số người coi SCRUM như một tôn giáo, nó không nên như thế này.
• Nhiều khả năng bạn có hai vấn đề trong nhóm: một (do) gây ra bởi nhà phát triển giả mạo và một (các) gây ra hành vi của nhà phát triển giả mạo. Tìm cách giải quyết cái sau và cái đầu tiên sẽ biến mất.

Tôi thích ý tưởng rằng thêm công việc miễn phí vào hỗn hợp là một điều tốt, đây không phải là công việc miễn phí - trừ khi nhà phát triển duy nhất đó cũng là người thử nghiệm, QA và anh chàng xây dựng và nhà thiết kế và mọi thứ khác. Nếu tác phẩm của anh ta có thể được đưa vào nước rút tiếp theo mà không có bất kỳ tác động nào, thì .. đi cho nó. Nhưng tôi nghĩ đó không bao giờ là trường hợp. Ít nhất, những người khác, ít nhất, phải hiểu những gì anh ta đã làm và những gì nó có ảnh hưởng đến họ. Họ phải hiểu rằng những thay đổi của anh ấy là trong và để không trùng lặp những nỗ lực của anh ấy - thật khó để nói với ai đó rằng họ đã làm việc chăm chỉ trong một nhiệm vụ chỉ để tìm ra kẻ lừa đảo đã làm điều đó vào tuần trước.

Bạn đang làm việc trong một môi trường nhanh nhẹn và một điều tôi biết về nhanh nhẹn là nó được thiết kế để làm việc cho bạn chứ không phải chống lại bạn. Vì vậy, bạn cần thay đổi cách bạn làm việc để cho phép loại hoạt động ngoại khóa này xảy ra. Điều đó có nghĩa là nhận được đầu vào và thỏa thuận của mọi người, bạn không thể làm điều này mà không cần mua. Nó quan trọng. Nếu đội không thích nó, thì kẻ lừa đảo sẽ ngừng làm việc đó. Cuối của. Đó không phải là một chàng trai làm những gì anh ta thích, cho dù công việc của anh ta có tốt đến đâu, đó là nỗ lực của cả đội. Đội đến trước.

Vì vậy, bạn cần phải ngồi lại mọi người trong cuộc họp lập kế hoạch tiếp theo và thảo luận về vấn đề này, tất cả các thành viên trong nhóm cần quyết định cho phép hoặc thay đổi quy trình của bạn để quản lý loại hoạt động này tốt hơn.

Có thể bạn sẽ nhận được một giải pháp trong đó mọi người làm việc trong các dự án yêu thích của họ và đưa họ đến bàn (bạn có thể tưởng tượng sự hỗn loạn trong giao hàng của mình sẽ gây ra :) trong đó nêu rõ vấn đề với nó ngay từ đầu) hoặc bạn có thể ủy thác khu vực nơi mỗi nhà phát triển tự động hóa để phát triển bất kỳ giải pháp nào họ thích đó là 'đóng góp' tương tự như có bao nhiêu dự án nguồn mở hoạt động hoặc bạn có thể cho mọi người có thời gian rảnh để thử nghiệm (20% thời gian cũ).

Có phải nhà phát triển này viết các bài kiểm tra và mã sạch / rắn hoặc anh ta / cô ta chỉ cần đưa ra bất cứ điều gì anh ta có thể hoàn thành nhanh chóng? Cá nhân tôi sẽ không cho phép bất cứ ai làm việc ngoài giờ đã xác định vì điều đó sẽ làm xáo trộn các ước tính của bạn và như bạn đã chỉ ra các vấn đề khác xảy ra.

Tuy nhiên, bạn không bao giờ nên cứng nhắc trong quá trình của bạn. Scrum chỉ là một khung để bạn luôn có thể điều chỉnh quy trình để bao gồm thêm thời gian (nhưng một lần nữa rất khó để lập kế hoạch cho những gì ai đó có thể làm).

Bạn cũng có thể yêu cầu anh ta làm việc trên những thứ khác ngoài dự án. Nhìn vào công nghệ mới hoặc tạo ra đào tạo về những thứ anh ấy làm khác đi. Điểm mấu chốt là mọi thứ được thực hiện ngoài lịch trình dự kiến ​​của bạn sẽ phá hủy ước tính của bạn và tôi sẽ không để điều đó xảy ra.

Chúng tôi cũng phải đối mặt với điều tương tự, về cơ bản chúng tôi đã cam kết khoảng 20 điểm nhưng vào tuần trước hoặc thậm chí giữa giai đoạn nước rút, chúng tôi đã hết nhiệm vụ mã hóa, tuy nhiên vì Thử nghiệm và phần còn lại của quá trình, chúng tôi đã không mạo hiểm để chọn PBI khác, vậy thì sao các lập trình viên đã làm là xem xét các hồ sơ tồn đọng và bắt đầu phát triển các PBI trong tương lai (âm thầm!) và thông báo cho các thành viên còn lại trong kế hoạch rằng PBI đã sẵn sàng để xem xét và kiểm tra mã! như bạn đã nói.

Nó thực sự gây ra một số lo ngại từ các PO của chúng tôi rằng có vẻ như chúng tôi có khả năng nhiều hơn nhưng chúng tôi không tận dụng hết tiềm năng của nhóm chúng tôi, điều đó đúng một phần nhưng có thể, các lập trình viên của chúng tôi có thể làm được nhiều hơn nhưng những người thử nghiệm của chúng tôi không thể theo kịp tốc độ đó có nguy cơ thất bại nước rút. Sau khi suy nghĩ về vấn đề này, chúng tôi phát hiện ra rằng chúng tôi cần thay đổi quan điểm về scrum và vấn đề chính là mọi người không muốn chấp nhận rủi ro đó là vì chúng tôi cam kết PBI nên nhóm không cảm thấy tốt khi chấp nhận rủi ro đó. PBI mới trong trường hợp chúng tôi có lập trình viên miễn phí.

Đơn giản là chúng tôi bắt đầu Dự báo PBI thay vì cam kết. Về cơ bản dự báo có nghĩa là chúng tôi chọn 25 điểm khi lập kế hoạch và bắt đầu chạy nước rút, và khi lập trình viên được tự do ở giữa nước rút, vì không còn nhiệm vụ mã hóa nữa nên anh ấy chọn một trong những PBI tương lai và đưa nó vào Sprint hiện tại và bắt đầu làm việc trên đó, nếu PBI có thể vượt qua tất cả quá trình (thử nghiệm, sáp nhập và v.v.) trong cùng một lần chạy nước rút, thì đó là điểm thưởng cho đội nếu KHÔNG chúng ta không thất bại trong cuộc đua nước rút vì PBI đó và chỉ tiếp tục công việc còn lại ( thử nghiệm hoặc meging hoặc vv) để chạy nước rút tiếp theo và chơi bài xì phé cho công việc còn lại. Vì vậy, nó có thể được thực hiện trong hai lần chạy nước rút khác nhau trong trường hợp xấu hơn. Tôi biết nó có vẻ giống như Scrumbut nhưng nó thực sự cải thiện cách chúng ta làm việc. Tôi chỉ có thể tóm tắt lợi ích của nó như dưới đây:

• Nó đánh bại nỗi ám ảnh về việc chạy nước rút thất bại vì chấp nhận rủi ro lấy thêm PBI
• Nó làm cho công việc thêm của các lập trình viên và nhóm của bạn hiển thị
• Nó làm tăng vận tốc nhóm của bạn

Tuy nhiên, có thể đối với một nhóm có ít kinh nghiệm hơn, có thể điều đó làm giảm sự thúc đẩy mà cam kết mang lại cho nhóm để hoàn thành PBIs

Một số câu trả lời khác cho rằng nhà phát triển "quá sức" là "bất hảo" hoặc "vi phạm các nguyên tắc của Scrum". Điều này là không chính xác và nhà phát triển này nên được khuyến khích (mặc dù bạn không nên yêu cầu mọi người làm việc trên bất cứ điều gì cụ thể trong thời gian thêm này, nhưng bạn có thể đưa ra đề xuất và giúp thúc đẩy ý tưởng).

Scrum không có gì để quy định cách mọi người làm việc và bất cứ điều gì anh ta làm thêm sẽ tự nhiên được kết hợp vào vận tốc của đội.

Công việc của anh ta nên được đưa vào tồn đọng sản phẩm và ước tính trong cuộc họp lập kế hoạch tiếp theo. Nếu bạn không thể dự đoán được những nỗ lực còn lại là gì ngay lập tức, bạn nên dành thời gian chạy nước rút để tìm ra nó (đó là Spike).

Thật thú vị khi bạn mô tả nhà phát triển là "quá sức", tôi cho rằng điều này có nghĩa là anh ta đang tăng thêm nhiều giá trị hơn các thành viên khác trong nhóm.

Những khó khăn khi làm thêm làm việc ngụ ý có một cái gì đó không tối ưu (hoặc thậm chí là rối loạn chức năng) trong nhóm của bạn.

Nếu đây là trường hợp, bạn nên tự hỏi tại sao anh ta đạt được nhiều hơn nữa, với có lẽ chỉ cần một chút nỗ lực thêm?

Bạn có thể cho phép các thành viên còn lại trong nhóm đạt được nhiều hơn không?

Tôi đã thấy tình huống trong đó các nhóm được quản lý vi mô, có khả năng vượt qua các câu chuyện người dùng giả định, định nghĩa về việc đã hoàn thành, cuối cùng trở nên ngột ngạt đối với các nhà phát triển. Là nhà phát triển này đang làm công việc mà anh ta muốn? Tôi cho rằng anh ấy đang đưa ra quyết định tốt. Làm việc theo cách này trong tuần làm việc cũng sẽ giúp phần còn lại của nhóm chứ?

Có họ cũng là một giáo viên

Thật tuyệt khi bạn có một nhà phát triển ngôi sao với các kỹ năng tốt nhất và tiên tiến nhất trong nhóm. Tôi sẽ khen ngợi và khen ngợi điều này. Thông thường những người như vậy là "chất keo" giữ các tổ chức lại với nhau.

Tôi sẽ xem thử thách là 'làm thế nào để đưa các nhà phát triển ít kinh nghiệm đến gần hơn với năng suất của nhà phát triển tiên tiến nhất'.

Một cách tuyệt vời để làm điều này là tập trung vào việc khiến nhà phát triển ngôi sao dành nhiều thời gian hơn cho việc giảng dạy, đào tạo và hướng dẫn các thành viên nhóm ít kinh nghiệm và chậm hơn. Trước tiên tôi sẽ thảo luận điều này trong 1-1 với nhà phát triển ngôi sao để họ biết bạn đang làm gì và tại sao. Thông thái khác, nó có thể được xem với sự nghi ngờ như một chương trình nghị sự / quản lý kém

Khi bạn đứng lên, một hoặc hai lần một ngày, nếu người này hết việc và những người khác vẫn đang làm nhiệm vụ, hãy tìm đến lập trình cặp để cô ấy có thể ghép đôi với các thành viên cơ sở và truyền đạt kiến ​​thức và kinh nghiệm tuyệt vời của cô ấy. Hãy chắc chắn để đặt câu hỏi "có ai cần giúp đỡ không? Có ai đang tìm kiếm một cặp không?"

Bạn cũng có thể tìm thấy một số công việc phụ cho nhà phát triển tốt nhất khi họ không làm việc, chẳng hạn như tăng cường bộ công cụ đang được sử dụng, điều hành một nhóm thảo luận câu lạc bộ sách kỹ thuật hoặc tham gia vào các dự án tổ chức khác.

Tôi sẽ trả lời một câu hỏi khác. Tôi nghĩ làm thế nào để đối phó với tình huống này trong Scrum thực sự không quan trọng. Scrum giống như một hướng dẫn hơn. Nếu bạn muốn điều này xảy ra, hãy tìm một cách đơn giản để điều chỉnh quy trình của bạn như đơn giản là giả sử công việc đã hoàn thành.

Câu hỏi thực sự là liệu bạn có muốn nhà phát triển này làm những gì anh ta đang làm không. Tôi nghĩ rằng một số khía cạnh đóng một vai trò quan trọng trong câu trả lời cho câu hỏi đó:

1. Là lập trình viên làm việc tốt.
2. Mọi người có ổn không khi anh ấy tự mình làm việc (dù tốt hay xấu). Rốt cuộc anh ta đang né tránh quá trình thiết kế!
3. Là những giờ làm thêm được trả hay không.

Tất cả những ảnh hưởng này cho dù nó có ý nghĩa cho sản phẩm của bạn rằng anh ấy đang làm những gì anh ấy đang làm. Một lần nữa, kết hợp quyết định của bạn trong quá trình thiết kế không thực sự là một vấn đề. Chỉ cần linh hoạt.

Điều này vi phạm một người thuê Scrum vì nhóm không quyết định công việc trong giai đoạn nước rút. Đây là một nhóm scrum . Nhóm cần kỷ luật lập trình viên này nếu kỷ luật được đưa ra.

Một vấn đề khác mà điều này tạo ra là nó vặn với vận tốc của đội. Làm việc ngoài ban nhạc không được tính vào vận tốc và đốt cháy. Vì vậy, điều này ngoài công việc ban nhạc được thực hiện, nhóm đang đạt trung bình 50 điểm vận tốc, nhưng hơn 50 điểm được thực hiện. Chủ sở hữu sản phẩm sẽ thấy điều này và yêu cầu vận tốc cao hơn trong lần chạy nước rút tiếp theo. Vận tốc có thể không thể.

Nhóm (không phải PO hoặc ScrumMaster) cần giải quyết vấn đề này với lập trình viên lừa đảo.