Lập kế hoạch Poker và nhà phát triển dài dòng [đã đóng]

Nhóm của tôi gồm có 4 nhà phát triển; tất cả dày dạn và lành nghề. Một trong số đó là một chap dài dòng, có chủ đích, người luôn khăng khăng xác định giải pháp kỹ thuật cho câu chuyện của chúng tôi trước khi chúng tôi đưa ra ước tính của mình với Planning Poker. Anh ta từ chối ước tính nếu anh ta không có ý tưởng sơ bộ về giải pháp kỹ thuật đã thỏa thuận (nghe có vẻ hợp lý, phải không?).

Vấn đề là các phiên ước tính của chúng tôi sẽ mất mãi mãi để kết thúc !! Theo kinh nghiệm của bạn, làm thế nào để bạn đối phó với loại tính cách này khi chơi poker lập kế hoạch?

Anh ta có vẻ thích mọi thứ được định nghĩa chính thức, vì vậy một bộ đếm thời gian sẽ là một ý tưởng tốt, vì lập kế hoạch chơi bài xì phé được định nghĩa là đã đặt ra một lượng thời gian để mọi người nói.

Anh ấy cũng có ý tưởng sai về ước tính, mọi người đều ước tính câu chuyện và không thực hiện , đó là lý do tại sao bạn có được phương sai như vậy. Ví dụ, một số người có thể không biết gì về khung hoặc tắt giải pháp trên kệ và bắt đầu viết mọi thứ từ đầu.

Thành viên nhóm của bạn có vẻ là một nhà phân tích cá tính. Các nhà phân tích cần rất nhiều thông tin để đưa ra quyết định. Ý tưởng hẹn giờ là tốt nhất, nhưng lưu ý, anh ta sẽ cảnh báo mọi thứ anh ta đưa ra. Làm việc với anh ta để giải thích rằng đó chỉ là ước tính sớm dựa trên vấn đề KHÔNG phải là giải pháp. Nếu anh ta muốn đặt câu hỏi yêu cầu anh ta giữ nó cho vấn đề không phải là giải pháp. Bạn có thể phải cắt đứt anh ta hoặc làm phiền anh ta một lúc khi anh ta tiếp tục trôi dạt vào các giải pháp.

Hãy chắc chắn rằng bạn giữ những người khác trong đội theo những quy tắc tương tự để anh ta không cảm thấy bị chỉ trích. Các nhà phân tích là một tính cách phổ biến trong lập trình, vì vậy bạn rất có thể gặp phải những người khác như anh ta.

Có vẻ như đồng nghiệp của bạn không hiểu sự khác biệt giữa ước tính và cam kết hoặc nó đã không được truyền đạt cho anh ta trong quá trình đào tạo. Và, vì bạn đã cố gắn vấn đề với tính cách của anh ấy, nên có thể cả nhóm của bạn chưa hiểu về nó. (Nhưng đừng lo lắng! Hầu hết ngành công nghiệp của chúng tôi không hiểu điều đó. Agile rất khó!)

Khi chúng tôi nói kích thước của một câu chuyện là X điểm, chúng tôi thực sự có nghĩa là phân phối xác suất. Nếu ước tính của chúng tôi là chính xác, câu chuyện sẽ mất hơn 50% thời gian (và 50% còn lại sẽ mất ít thời gian hơn). Nếu đồng nghiệp của bạn tin rằng, khi X đơn vị thời gian đã trôi qua, anh ta sẽ được yêu cầu giới thiệu câu chuyện hoặc cách khác, điều đó thay đổi cách tiếp cận của anh ta để ước tính.

Lập kế hoạch chơi bài giới thiệu một lỗi khác: thay vì cố gắng xác định X, chúng tôi khớp nó với một tỷ lệ rời rạc, thang đo Fibonacci (1, 2, 3, 5, 8, v.v.) là phổ biến nhất. Nó đang nói kích thước không nhiều như nó là gì. Khi chúng tôi nói kích thước câu chuyện là 3 điểm, chúng tôi thực sự nói rằng "đó là X cộng trừ một số phương sai và X gần với 3 hơn so với 2 hoặc 5."

Nhóm của bạn có thể được hưởng lợi từ việc hiểu được sự thiếu chính xác của bài tập này và cách ước tính khác với cam kết. Nếu bạn muốn / cần nghiên cứu những khái niệm này một cách sâu sắc, cuốn sách này có điều đó.

Tôi có thể thấy thành viên trong nhóm của bạn đến từ đâu, nhưng rõ ràng anh ta chưa hoàn toàn nắm bắt được khái niệm về Agile và Planning Poker. Bạn nên bắt đầu bằng cách đảm bảo mọi người hiểu các khái niệm và lý do đằng sau chúng, và sau đó họ nên tự mình làm đúng.

Đối với các đội tôi làm việc cùng, vào đầu mỗi phiên lập kế hoạch, tôi đặt đồng hồ cát 3 phút trên bàn. Tôi cho cả nhóm biết rằng nếu tại bất kỳ thời điểm nào, họ cảm thấy cuộc trò chuyện đang trở nên sâu sắc, hoặc không liên quan, hoặc bằng bất kỳ cách nào khác là vượt quá những gì họ cảm thấy cần thiết để ước tính câu chuyện theo điểm câu chuyện, thì bất cứ ai trong nhóm có thể lật bộ hẹn giờ. Khi cát hết, đội lập tức ước tính.

Phương pháp này trao quyền cho mọi cá nhân trong nhóm để hạn chế cuộc trò chuyện, khi họ cảm thấy cuộc trò chuyện không còn hữu ích để ước tính câu chuyện đang được thảo luận. Đồng thời, nó không ngay lập tức cắt đứt cuộc trò chuyện, nhưng sẽ cung cấp cho mọi người một dấu hiệu trực quan rằng cuộc trò chuyện của họ cần kết thúc trong vài phút tới, bởi vì chúng tôi sẽ bỏ phiếu.

Một công cụ khác mà tôi sử dụng để giúp duy trì các phiên lập kế hoạch tập trung, là đảm bảo rằng tất cả mọi người trong nhóm đã xem xét các câu chuyện ở đầu của hồ sơ tồn đọng ít nhất một vài ngày trước khi lập kế hoạch. Ý tưởng là nếu bạn có một danh sách các câu hỏi ngay khi đọc truyện, bạn có thể cho chủ sở hữu sản phẩm biết về các câu hỏi tiềm năng vài ngày trước đó, để họ có thể làm rõ câu chuyện hoặc phê bình chấp nhận để hạn chế thảo luận sau. Điều này cũng cho phép mọi người bắt đầu suy nghĩ về thiết kế tiềm năng của câu chuyện, trước khi lên kế hoạch (và cố gắng thiết kế trong khi lập kế hoạch).