Scrum: Làm thế nào để làm việc trên một câu chuyện tại một thời điểm

Tôi đã được đề cử làm chủ scrum trong một nhóm scrum mới thành lập. Chúng tôi đã thực hiện một số nước rút. Lúc đầu, tôi đã cố gắng làm cho nhóm của mình làm việc trên một câu chuyện tại một thời điểm. Nhưng nó không hoạt động. Nhóm của tôi gặp khó khăn khi phân phối các nhiệm vụ theo cách mà họ có thể làm việc đồng thời trên một câu chuyện. Có lẽ chúng ta đang làm gì đó sai?

Ví dụ: chúng tôi có một câu chuyện để tạo một hộp thoại mới. Chúng tôi tạo ra các nhiệm vụ sau:

• Tạo các lớp Model
• Đọc dữ liệu mô hình từ cơ sở dữ liệu
• Kết nối các lớp mô hình với khung nhìn
• Thực hiện xử lý hộp thoại
• Lưu dữ liệu khi đóng
• Tài liệu kiểm tra
• Mô tả giải pháp

Các nhiệm vụ này có thể được thực hiện bởi nhiều người cùng một lúc không? Các nhiệm vụ - ít nhiều - xây dựng lẫn nhau. Hay chúng ta thiết kế các nhiệm vụ một cách sai lầm?

Tại sao tất cả các nhóm làm việc trên một câu chuyện duy nhất?

Tại sao không làm cho câu chuyện đủ nhỏ (và đủ độc lập) để một người (hoặc tốt hơn, một cặp làm lập trình cặp) có thể làm việc trên một câu chuyện duy nhất. Quá trình này cũng giúp xác định tốt hơn các yêu cầu và suy nghĩ nhiều hơn về vấn đề và việc thực hiện. Ước tính cũng có thể trở nên chính xác hơn, nhưng không có bảo đảm ở đây.

Mặc dù điều này phụ thuộc rất nhiều vào kích thước của câu chuyện người dùng, nhưng trong nhiều trường hợp, chỉ có một nhà phát triển nên được chỉ định cho một câu chuyện để tránh việc các nhà phát triển của bạn bước lên từng ngón chân khác. Mặc dù những câu chuyện lớn hơn hoặc rất phức tạp có thể cần nhiều nhà phát triển hơn, nhưng cũng có thể chia những câu chuyện đó thành nhiều câu chuyện nhỏ hơn có thể được chỉ định riêng.

Những gì chúng ta thường làm là chia các câu chuyện thành các nhiệm vụ dev / infra / phân tích.

1. Nói chung, bất cứ điều gì hơn một ngày làm việc là một câu chuyện.

2. Khi các tác vụ được chia nhỏ, một hoặc tối đa hai nhà phát triển làm việc trên một câu chuyện, tùy thuộc vào không: của các nhiệm vụ trong tay. Thường là một.

3. Chúng tôi ghi lại thời gian sử dụng và cập nhật ước tính còn lại vào cuối ngày trước khi chúng tôi rời đi hoặc trước khi hàng ngày đứng lên.

4. Nhiệm vụ được tạo cho bất kỳ vấn đề mới nào xảy ra trong khi làm việc.

5. Câu chuyện kéo dài hơn 2 tuần được coi là một sử thi.

6. Một sử thi có thể được tạo thành từ nhiều câu chuyện

Những gì bạn muốn nhóm của bạn làm được gọi là swarming , nhưng không phải tất cả các mục tồn đọng có thể được tràn ngập xung quanh bởi toàn đội. Suy nghĩ phổ biến là swarming đòi hỏi một số điều kiện trước:

• một nhóm chức năng chéo, collocated
• một câu chuyện không tầm thường
• một định nghĩa về "thực hiện" ngụ ý sự tham gia của cả nhóm

Khi chia một câu chuyện thành các nhiệm vụ, nhóm phải ở chế độ tràn lan để các tác vụ được tạo tương thích với tràn ngập và có thể liên quan đến toàn đội.

Nhưng hãy cẩn thận khi sử dụng swarming quá thường xuyên hoặc có quá nhiều người cùng một lúc, vì bạn có thể gặp phải vấn đề quá sức, khi một số xung đột có thể xuất hiện giữa các thành viên trong nhóm vì họ có quá nhiều hoạt động trên cùng một mặt hàng.

Bạn có thể muốn đọc Mike Cohn's Một đội có nên tập trung vào một mục tồn đọng một lúc không? hoặc bài viết này tôi đã viết (ngày hôm qua) trong đó đề cập cụ thể hơn đến các lỗi: Bầy hay không vung

Một phần lớn của SCRUM là nhóm nên đưa ra các loại quyết định này. Backlog nên có các câu chuyện của người dùng với hy vọng đủ thông tin cho các tác vụ được tạo.

Mặc dù có thể ép buộc một câu chuyện của người dùng vào một mục mà cả nhóm có thể làm việc cùng một lúc, nhưng điều quan trọng hơn là nhóm chọn các mục để làm việc, xác định các nhiệm vụ để hoàn thành câu chuyện của người dùng và sử dụng giá trị hàng ngày để xem nếu bạn đang đi đúng hướng với công việc đã hứa.

Nỗi đau mà bạn đang cảm thấy khi cố gắng thực hiện chỉ một câu chuyện tại một thời điểm cần phải được nhóm thừa nhận và trong các cuộc đua hồi cứu các giải pháp tiềm năng cần phải được đưa ra. Chỉ ra những gì bạn đang làm đúng và những gì cần phải được cải thiện.

Sử dụng ví dụ của bạn về khó khăn trong việc phân phối các nhiệm vụ có thể được thực hiện đồng thời, một giải pháp khả thi là đảm nhận nhiều câu chuyện và phân định 3 hoặc 4 mục trong một lần chạy nước rút. Vì các tác vụ cho câu chuyện người dùng này được xây dựng chồng chéo lên nhau nên sẽ rất khó để phân phối công việc. Vì vậy, thay vì chiến đấu mà nắm lấy nó.

Các tác vụ của bạn, như được chỉ ra, dường như 'nhỏ' đủ để được phân phối, nhưng có một số khớp nối giữa các tác vụ như một nhiệm vụ về mô hình hóa dữ liệu và lấy nó từ cơ sở dữ liệu.

Điều có thể là chia nó thành ba điều chính mà mọi người có thể làm việc đồng thời, với một số công việc / thiết lập bổ sung:

• Back-end (cơ sở dữ liệu, mô hình, v.v.)
• Front-end (sử dụng dữ liệu giả)
• Các thử nghiệm (thiết lập kỳ vọng, kịch bản, v.v.)

Các nhiệm vụ không thể phân chia có thể được thực hiện theo cặp. Và tất nhiên, không có gì sai trái với nhiều hơn một câu chuyện đang diễn ra tại bất kỳ thời điểm nào; miễn là mọi thành viên trong nhóm biết những gì người khác đang làm và họ có thể giúp đỡ bất cứ khi nào cần thiết (như trong 'quyền sở hữu mã được chia sẻ').

Bạn nên giữ cho nhóm của bạn tập trung, vâng, nhưng đồng thời bạn cần giữ cho tất cả mọi người bận rộn, và tất cả mọi người tham gia.

Ngoài ra, đội của bạn lớn như thế nào? Đây cũng là một yếu tố; thật khó để có mười người làm việc trên một câu chuyện và nếu bạn có thể, câu chuyện của bạn rất xa, quá lớn và nên được chia ra (nhóm của bạn cũng vậy).