2010-09-18 38 views
6

Công ty tôi làm việc cho hiện đang tìm cách chuyển từ thác nước truyền thống sang Scrum để phát triển. Chúng tôi đang trong quá trình áp dụng từ từ những gì chúng ta có thể thực hiện mà không cần hoàn toàn di chuyển (chúng ta vẫn còn nhiều điều để học trước khi chúng ta hoàn toàn có thể chuyển sang!).Scrum Taskboard - các tác vụ có thể thay đổi không?

Một trong những điều chúng tôi muốn triển khai ngay bây giờ, trước khi thực hiện chuyển đổi đầy đủ, là bảng tác vụ. Tất cả chúng ta đều cảm thấy đó là một công cụ tuyệt vời có thể giúp phát triển và giúp giữ cho những người dùng doanh nghiệp đó khỏi lưng của chúng tôi với "những gì bạn đang làm?" và "nó thế nào?" câu hỏi và cuộc họp.

Vì vậy, với tất cả những gì đã nói, một điều tôi đã tự hỏi là các nhiệm vụ có thể thay đổi trên taskboard không? Tôi biết bạn không muốn thay đổi Câu chuyện, nhưng còn về nhiệm vụ trong một câu chuyện thì sao? Điều gì sẽ xảy ra nếu một nhiệm vụ mới xuất hiện, hoặc một nhiệm vụ cũ không còn hợp lệ nữa? Chúng có thể được thêm vào và/hoặc loại bỏ giữa chạy nước rút (mặc dù chúng tôi không thực sự sử dụng chạy nước rút, giống như chu kỳ phát triển ngắn).

Cảm ơn!

+0

Điều này có vẻ giống như ứng cử viên tốt cho http://area51.stackexchange.com/proposals/6922/software-engineering sẽ sớm tham gia vào phiên bản beta riêng tư ... –

+4

Tôi đang bỏ phiếu để đóng câu hỏi này là không có chủ đề vì nó không phải là về lập trình. –

Trả lời

10

Tôi biết bạn không muốn thay đổi Câu chuyện, nhưng còn về nhiệm vụ trong một câu chuyện thì sao? Điều gì sẽ xảy ra nếu một nhiệm vụ mới xuất hiện, hoặc một nhiệm vụ cũ không còn hợp lệ nữa? Chúng có thể được thêm vào và/hoặc loại bỏ giữa chạy nước rút (...).

Có, họ có thể. Trong một lần lặp lại, một nhóm thường tập hợp kiến ​​thức và hiểu rõ hơn về những gì phải được thực hiện, hay không. Kết quả là, một nhóm có thể phát hiện ra rằng một nhiệm vụ không thực sự có liên quan, một Item Backlog đã cho đòi hỏi nhiều công việc hơn dự kiến, rằng ước lượng ban đầu là sai. Trong những trường hợp như vậy, bạn chắc chắn muốn cập nhật Sprint Backlog của mình và Burndown Chart để bám sát thực tế và giữ cho những gì phải được thực hiện: bạn thực sự muốn biết nếu lặp lại vẫn đang đi đúng hướng, nếu bạn có thể lấy thêm một mục nữa , v.v.

Vì vậy, có, đừng ngần ngại cập nhật, xóa, thêm nhiệm vụ ngay sau khi bạn phát hiện ra nó phải được thực hiện. Và càng sớm càng tốt.

Trong nhóm chúng tôi, chúng tôi sử dụng một bảng nhiệm vụ lấy cảm hứng từ Scrum and XP from the Trenches từ Henrik Kniberg và chúng tôi có một vị trí đặc biệt cho "mặt hàng không có kế hoạch" như minh họa dưới đây:

Scrum Task Board

Chúng tôi thích phương pháp này vì nó làm dễ phát hiện nếu các mục không có kế hoạch đang giết chết một sự lặp lại. Và chúng tôi cũng "xem xét" các nhiệm vụ đó trong quá trình hồi cứu để xem cách chúng tôi có thể cải thiện cuộc họp lập kế hoạch, ước tính của chúng tôi, cách chúng tôi chia nhỏ các mục, v.v.

+0

Cảm ơn bạn rất nhiều vì cái nhìn sâu sắc của bạn Pascal. Hình ảnh đó thực sự hữu ích và tôi khá thích ý tưởng có một khu vực được chỉ định cho "Các mục chưa được lập". Nghĩ rằng hội đồng quản trị của chúng tôi không đủ lớn cho một phần khác, tôi nghĩ chúng tôi có thể sử dụng một lưu ý dính màu khác nhau (vì chúng tôi chỉ sử dụng hai màu bây giờ - Màu xanh lá cây cho các nhiệm vụ câu chuyện và màu cam cho các khuyết tật). –

3

Đội cam kết về câu chuyện của người dùng, không nhiệm vụ

Nó không phải là một vấn đề để có một số nhiệm vụ thay đổi khi bạn đang phải đối mặt vấn đề hoặc có những ý tưởng thực hiện tốt hơn.

Thực tế, rất hiếm khi kết thúc chạy nước rút với mọi công việc 100% "được dự đoán" chính xác trong cuộc họp lập kế hoạch chạy nước rút.

+0

Cảm ơn bạn rất nhiều vì điều này. "Đội ngũ cam kết về những câu chuyện của người dùng, chứ không phải nhiệm vụ" là một thứ có vẻ rất hữu ích để chúng ta nhớ! –

2

Họ có thể và nên thay đổi. Ban nên được cập nhật ít nhất mỗi ngày.

Nhưng Pascal đã trả lời điều đó - Tôi muốn đưa ra một điểm khác: từ kinh nghiệm 'cố gắng áp dụng' Agile thông qua những thay đổi nhỏ sẽ không hoạt động.Scrum là một khuôn khổ hoàn chỉnh - bởi điều này có nghĩa là có rất ít Scrum (tôi không nói gì cả) có thể bị bỏ mà không làm hại đến quá trình và thúc đẩy rối loạn chức năng hoặc ít nhất là cho phép rối loạn chức năng tiếp tục (wrote about it). Đi chậm có thể là cách duy nhất để đi vào một số công ty/hoàn cảnh, nhưng nó có nguy cơ rối loạn chức năng kéo dài sẽ thổi quá trình thay đổi/cải tiến trước khi nó có thể đạt được lợi ích cuối cùng và lợi nhuận của nó.

+0

+1 cho điểm bổ sung, cá nhân tôi chia sẻ quan điểm này. –

1

Tôi đã thích câu trả lời của Pascal và Andy nên không lặp lại.

Cách thay thế hữu ích là bắt đầu Hội đồng Kanban. Henrik Kniberg cũng có một 'cuốn sách' tốt về nó, có sẵn tại đây: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

Nó cho phép bạn tổ chức công việc của mình và suy nghĩ một cách nhanh nhẹn vào công ty. Như Andy đã nói, Scrum là một All-in, nếu không bạn sẽ thấy rằng 'Nó không hoạt động'.

1

Tại sao không? Để lại không gian cho nhóm để hoàn thành công việc theo cách họ muốn làm.

Câu chuyện là 'hợp đồng' giữa khách hàng, chủ sở hữu sản phẩm và nhóm, do đó bạn không nên thay đổi, thêm, xóa câu chuyện mà không cho họ biết. Nhưng nhiệm vụ chỉ dành cho đội.

Nhóm nghiên cứu sẽ có thể theo dõi nỗ lực theo cách họ cần để hiển thị.

Có thể nghi ngờ là một sự thay đổi về số giờ mà nhóm cam kết hoàn thành trong lần chạy nước rút, nhưng đội ngũ chuyên gia giỏi và đội ngũ giàu kinh nghiệm có thể tự tổ chức điều đó.

Các vấn đề liên quan