Scrum cho các nhóm chuyên gia

Scrum là tốt nhất cho các đội có thành viên tổng quát, đó là các đội ít nhất 2 người có thể làm các nhiệm vụ tương tự. Mối quan tâm chính của tôi là tìm giải pháp tốt để điều chỉnh scrum (những gì cần giữ, những gì cần loại bỏ, những gì cần cải thiện) cho các nhóm làm từ các chuyên gia?

Giả sử bạn có một nhóm gồm 5 nhà phát triển (không có thực, chỉ là ví dụ):

1. Một nhà toán học có kỹ năng mạnh về C;
2. Một nhà phát triển DB;
3. Một nhà phát triển web;
4. Một nhà phát triển UX / GUI;
5. Một kiến ​​trúc sư phần mềm;

Ở đây, tất cả đều là chuyên gia và không ai có thể thay thế người khác (Tôi không quan tâm đến những rủi ro khi xây dựng một đội ngũ như vậy, tôi muốn tập trung vào scrum). Vì vậy, trong một bối cảnh scrum, đây là suy nghĩ của tôi:

1. Quy hoạch mùa xuân vô dụng: thực sự, khi nhà toán học nói rằng một nhiệm vụ cụ thể có giá trị 2 điểm, không ai có thể bỏ phiếu chống lại anh ta;
2. Chỉ số vận tốc nhóm vô dụng: vì mọi người có thể phân bổ bất kỳ số điểm nào cho các nhiệm vụ của riêng mình, tốc độ tính toán không có ý nghĩa;
3. Thay thế các cuộc họp scrum hàng ngày bằng các cuộc họp scrum hàng tuần (dài hơn): vì mỗi thành viên trong nhóm đang thực hiện các nhiệm vụ của riêng mình, các cuộc họp scrum hàng ngày nên thực sự quan trọng để giữ "tinh thần đồng đội". Tuy nhiên, các cuộc họp scrum hàng ngày được cho là kéo dài khoảng 15 phút. Điều này rõ ràng là không đủ để hiểu những gì người khác đang làm và sẽ làm. Hơn nữa, nhà toán học sẽ hầu hết trả lời những điều tương tự: "Tôi vẫn đang làm % & Lo (+? $$ + &)" ... Các cuộc họp hàng tuần sẽ cho nhiều thời gian hơn. Để giữ cùng thời gian cuộc họp giữa các cuộc họp scrum "ban đầu" và cuộc họp scrum "hàng tuần", mỗi cuộc họp scrum hàng tuần nên kéo dài (5 ngày một tuần, với 4 tuần nước rút, với các cuộc họp nước rút kéo dài 4 giờ và các cuộc họp hàng ngày kéo dài 15 phút): (4 * 60 + 20 * 15) / 4 =>

Hoặc là scrum vẫn có thể sử dụng? Có lẽ nên sử dụng một kỹ thuật nhanh nhẹn khác?

Scrum không phải là viên đạn bạc. Không phải mọi dự án đều phải sử dụng Scrum để thành công. Tuy nhiên, tình huống bạn đang mô tả nghe có vẻ phù hợp với Lean / Kanban. Bạn có thể muốn kiểm tra xem nó ra.

Kanban về cơ bản yêu cầu bạn chỉ làm một vài điều, không ai trong số đó là mâu thuẫn với loại đội bạn đang mô tả:

• Hình dung dòng chảy của giá trị, tức là bảng Kanban. Bảng Scrum là một ứng dụng cụ thể của bảng Kanban; Có thể điều chỉnh nó để cho phép chuyên môn hóa.
• Hạn chế tiến độ công việc (WIP), sao cho khối lượng công việc được giao cho nhóm vừa đủ để giữ cho công việc liên tục trôi chảy - tức là không "tắc nghẽn" khi bắt đầu luồng (thiết kế) hoặc kết thúc (triển khai) .

Bạn có thể muốn xem một số tài liệu tham khảo về Kanban:

• Một ngày ở Kanban Land
• Kanban mồi ( Sách điện tử miễn phí)

Bạn đang tập trung quá nhiều vào các cơ chế của scrum / agile mà không nhìn vào những gì nhanh được cho là sẽ cung cấp. Bạn nói rằng nếu anh chàng toán học ước tính 2 điểm thì không ai có thể nói anh ta sai. Đây không phải là mục tiêu. Mục tiêu là để thống nhất một bộ mục tiêu có thể đạt được cho lần chạy nước rút sắp tới. Là chuyên gia về nhiệm vụ đó, anh ta sẽ biết rõ nhất sẽ mất bao lâu.

"Vậy điều gì sẽ xảy ra nếu anh ta nói dối hoặc chỉ hiểu sai?" bạn nói. Theo kinh nghiệm của tôi, mọi người ước tính nhiều hơn bởi vì họ sợ họ sẽ bị bắn vì đưa ra dự đoán chính xác. Những người khác theo ước tính sau đó thêm một giới hạn an toàn để cân bằng mọi thứ và người lười biếng kỳ quặc sẽ ước tính quá mức để họ không phải vội vàng. Trong số ba cái đầu tiên sẽ được chọn trên theo dõi vận tốc, cái thứ hai trong khi nghe sai, đang hoạt động và thứ ba là thứ bạn phải xử lý bên ngoài scrum.

Cuộc họp hàng ngày vẫn cung cấp lợi ích. Có sự phụ thuộc giữa các thành viên trong nhóm ngay cả khi họ là từng chuyên gia. Anh chàng UI có thể đang đợi anh chàng máy chủ sửa lỗi thông báo. Anh chàng máy chủ có thể đang chờ đợi anh chàng toán học để tìm ra lý do tại sao một phép tính sai. Nó cũng không chỉ là về cách công việc của họ ảnh hưởng đến bạn. Nếu một thành viên trong nhóm liên tục bị trì hoãn vì "Lý do X" nhưng họ đã không dành thời gian để giảm thiểu các sự cố "Lý do X" trong tương lai, điều đó có thể bị thách thức.

Nếu bạn có chuyên gia có trình độ như những gì bạn mô tả, thì giả định của bạn rằng mỗi người đang làm việc theo nhiệm vụ riêng của mình, hiếm khi cần giao tiếp với người khác, là IMHO sai. Trên thực tế, để nhận ra một tính năng mới ("câu chuyện người dùng"), bạn thường sẽ phải

• thay đổi cơ sở dữ liệu của bạn
• thêm hoặc thay đổi GUI hoặc giao diện Web
• kết hợp điều này với logic kinh doanh chính xác (trong đó, có lẽ, bạn là "nhà toán học" đi vào)
• đảm bảo rằng tất cả những thay đổi đó hoạt động tốt với nhau

Vì vậy, tôi đoán họ sẽ phải giao tiếp nhiều hơn như trong một nhóm tổng quát, nơi mọi người có thể làm việc trên một câu chuyện ứng dụng / người dùng khác nhau, tự mình thực hiện tất cả các thay đổi cần thiết cho tất cả các lớp ứng dụng. Do đó, tất cả các hoạt động nhóm từ Scrum bạn liệt kê ở trên có ý nghĩa rất lớn đối với một nhóm như vậy.

Scrum chắc chắn vẫn phù hợp với hoàn cảnh của bạn, nhưng các khung khác cũng vậy.

Để cung cấp các tính năng mới, bạn có thể cần tất cả hoặc nhiều kỹ năng này. Để nhóm đưa ra quyết định tác động lẫn nhau và làm việc cùng nhau, họ sẽ cần liên lạc. Thời gian giữa các cuộc họp Scrum càng dài, kế hoạch tiêu cực có thể khiến nhóm đi lạc càng lâu. Bằng cách gặp gỡ hàng ngày, nhóm có thể giải quyết các tình huống này một cách nhanh chóng và đưa ra một kế hoạch mới.

Tôi cũng muốn giải quyết một số chủ đề cụ thể mà bạn đưa ra:

Các nhóm chức năng chéo Một nhóm sẽ được coi là đa chức năng nếu có tất cả các kỹ năng cần thiết để cung cấp cho mục tiêu chạy nước rút và / hoặc mục tồn đọng sản phẩm. Điều này không có nghĩa là có 2 người cho mọi công việc.

Định cỡ Điều quan trọng cần nhớ là chúng tôi đang định cỡ một vấn đề hoặc nhu cầu kinh doanh, không phải là giải pháp hay một phần của giải pháp. Chẳng hạn, Tích hợp phương tiện truyền thông xã hội / Twitter vào trang web thương mại điện tử của chúng tôi là một vấn đề đòi hỏi UX, Thiết kế giao diện người dùng, Lập trình, Cơ sở dữ liệu và kiến ​​thức về API Twitter. Một nhóm nên định cỡ rằng là một đơn vị vì họ là một nhóm sẽ cung cấp chức năng này. Kích thước này sẽ không chính xác 100%, nhưng chúng tôi thấy rằng, tổng hợp, các dự báo dựa trên kích thước tương đối chính xác hơn. Điều này có nghĩa là một số sẽ cao, một số sẽ thấp và kết hợp với nhau, dự báo được tính toán sẽ chính xác hơn thời lượng ước tính.

Các quy hoạch mùa xuân vô dụng Lập kế hoạch Sprint là thời gian để hợp tác với tư cách là Nhóm Scrum (Nhóm phát triển + Chủ sở hữu sản phẩm + Scrum Master) để xác định những gì nên được sản xuất và đưa ra kế hoạch bắt đầu. Một số nhóm sẽ phá vỡ các Mục tồn đọng sản phẩm này được chọn trong các nhiệm vụ trong khi các nhóm khác sẽ đưa ra cách tiến bộ của riêng họ, như các bài kiểm tra phải vượt qua (nghĩ XP).

Đây là một sự hợp tác hai chiều. Chỉ định nhóm một nhóm PBI và nói "đi" là vai trò của nhà độc tài. Nhóm đang đàm phán với Chủ sở hữu sản phẩm để tối đa hóa thời gian trong giai đoạn nước rút.

Số liệu vận tốc nhóm vô dụng Với các nhóm định cỡ các vấn đề và nhu cầu của doanh nghiệp cắt ngang kiến ​​trúc / hệ thống và kinh nghiệm trong quá khứ cho chúng tôi biết có bao nhiêu trong số đó đã được phân phối trong một hộp thời gian nhất quán (chạy nước rút), giờ đây chúng tôi có thể cung cấp dự báo nhóm cho phần còn lại của tồn đọng.

Một lần nữa, sẽ không có hai lần chạy nước rút nào giống nhau và tập hợp các mẫu sản phẩm Backlog sản phẩm bạn sử dụng càng nhỏ, lỗi càng ít lan truyền trong các ước tính. Hãy nghĩ về nó giống như thị trường chứng khoán; nó luôn luôn tăng lên, nhưng điều đó không có nghĩa là chúng ta không có nhiều năm. Tổng hợp bạn có thể kiếm tiền, nhưng vào bất kỳ tháng, quý, năm nào bạn sẽ đoán sai.

Thay thế các cuộc họp scrum hàng ngày bằng các cuộc họp scrum hàng tuần (dài hơn) Scrum hàng ngày có mặt để cung cấp cho nhóm một chu kỳ phản hồi 24 giờ và cơ hội để lên kế hoạch cho 24 giờ tiếp theo. Không hơn không kém. "Ba câu hỏi" có nghĩa là để giúp tạo điều kiện cho nỗ lực đó.

Nếu bạn không có bất kỳ phản hồi nào trong 5 ngày, tôi tin rằng nhiệm vụ của bạn không đủ tốt. Đây chỉ đơn giản là ý kiến ​​của tôi, nhưng nó dựa trên kinh nghiệm của tôi với tư cách là một huấn luyện viên và thành viên trong đội. Các nhóm nên nói chuyện, lập kế hoạch và tích hợp các nỗ lực của họ FAR thường xuyên hơn.

Kết luận Scrum có nghĩa là tạo điều kiện thuận lợi cho việc học và cân bằng việc học với phân phối (nơi học tập thực sự xảy ra). Thử nghiệm với các quy trình và công cụ của bạn theo thời gian và sử dụng Scrum để kiểm tra tác động. Hãy thử chuyển từ Scrum hàng ngày sang hàng tuần và xem liệu nó có giúp hoặc làm tổn thương khả năng của các đội để cung cấp chức năng phù hợp hay không. Điều đó có thể làm việc cho bạn.