Phiên bản Agile của chúng tôi không hoạt động. Lời khuyên?


12

Tôi làm việc trong một nhóm nhỏ gồm 4 nhà phát triển. Chúng tôi đang triển khai một phiên bản Agile dường như liên tục cung cấp cho chúng tôi những khó khăn tương tự, tuần này qua tuần khác và tôi đang tìm kiếm các đề xuất có thể giúp chúng tôi cải thiện quy trình của mình.

Bối cảnh:

Chúng tôi thường thực hiện chạy nước rút 2 tuần và mỗi lần chạy nước rút chúng tôi có xu hướng đánh giá thấp công việc của chúng tôi và chúng tôi gặp rắc rối với người quản lý của mình vì chúng tôi chậm tiến độ.

Chúng tôi bắt đầu mỗi lần chạy nước rút bằng cách giao nhiệm vụ cho những câu chuyện mà người quản lý của chúng tôi tạo ra cho chúng tôi. Đôi khi anh ấy cũng ném vào các nhiệm vụ và chúng tôi ước tính chúng. Chúng tôi không sử dụng điểm câu chuyện. Chúng tôi sử dụng phần mềm Urban Rùa để "quản lý nước rút", về cơ bản chỉ là những câu chuyện và nhiệm vụ, và sự đốt cháy liên quan. Chúng tôi không có kế hoạch phát hành vào cuối giai đoạn nước rút.

Vấn đề phổ biến nhất xảy ra là chúng tôi lên kế hoạch cho một nhiệm vụ khi bắt đầu chạy nước rút chỉ để phát hiện ra phạm vi lớn hơn nhiều, nhưng vẫn có mức độ ưu tiên cao, vì vậy chúng tôi cần phải làm thêm giờ. Vấn đề phổ biến thứ hai là một trong số chúng ta gặp phải sự cố kỹ thuật làm chậm thời gian bị đốt cháy, gây ra rào cản.

Đề xuất duy nhất được cung cấp cho chúng tôi là chủ động hơn trong việc điều chỉnh các ước tính của chúng tôi và cung cấp các cập nhật trong thời gian chờ vào buổi sáng để chúng tôi có thể điều chỉnh thêm thời gian cần thiết.

Tuy nhiên, dường như có điều gì đó sai về cơ bản với cách chúng ta đang làm. Có lẽ có sự mất kết nối giữa kỳ vọng của người quản lý ở cấp độ dự án và kỳ vọng ở cấp độ nước rút. Bởi vì chúng tôi đang thực hiện các lần lặp lại nước rút này theo một kế hoạch dự án, và do đó mở rộng một lần chạy nước rút hoặc trì hoãn các mục làm hỏng kế hoạch dự án. Vì vậy, khi các nhà phát triển, chúng tôi được khuyến khích thực hiện Agile bằng cách mở rộng các ước tính khi cần thiết nhưng cũng hoàn thành việc chạy nước rút đúng hạn, điều này gây nhầm lẫn.

Đây không phải là một vấn đề hiếm gặp, vì vậy tôi hy vọng những người khôn ngoan hơn tôi có một gợi ý hoặc hai về cách chúng ta có thể ngừng chạy vào cùng một vấn đề này mỗi lần chạy nước rút. Thật là bực bội.


8
không phân bổ 100% thời gian cho các câu chuyện và nhiệm vụ, có thể chỉ 80% thời gian? Và nếu bạn hoàn thành mọi thứ (nghe có vẻ không ổn) hãy mang một câu chuyện khác từ hồ sơ tồn đọng? Hoặc, tạo một số nhân cho ước tính của bạn (your_number * 2)?
Kevin

1
Cảm ơn, tôi nghĩ rằng hệ số nhân là một ý tưởng tốt, cùng với việc tìm ra ít hơn.

Tôi đồng ý với Kevin. Đối với một kịch bản mà bạn phải đưa ra ước tính và bạn không có ý tưởng nào để thực hiện một và sau đó nhân đôi nó và sau đó thêm một chút nữa để có biện pháp tốt. Vì vậy, nếu bạn nói 8 giờ, tôi sẽ tăng gấp đôi lên 16 và có thể làm tròn đến 20 chẳng hạn
dreza

3
Chuyển sang thác nước. Thác nước hoạt động tốt hơn rất nhiều với ước tính không chính xác và lịch trình quá chặt chẽ. (Không thể đưa ra câu trả lời vì các lượt tải xuống không thể tránh khỏi sẽ khiến tôi mất khoảng 0,025 điểm danh tiếng)
user281377

1
Làm thế nào bạn chọn bao nhiêu câu chuyện để làm trong một lần chạy nước rút?
jk.

Câu trả lời:


20

bởi vì chúng tôi chậm tiến độ

Kiểu suy nghĩ này là vấn đề của bạn. Bạn không đứng sau lịch trình, lịch trình quá chặt chẽ. Bạn nên bắt đầu ước tính các câu chuyện theo các điểm trừu tượng trái ngược với giờ và sau đó qua 2-3 lần lặp lại để tìm ra vận tốc của bạn. Vận tốc của bạn là có bao nhiêu điểm bạn thường làm mỗi lần lặp chứ không phải bao nhiêu điểm mà người quản lý của bạn muốn phù hợp.

Sau đó, điều đó không thành vấn đề nếu bạn luôn đánh giá thấp các nhiệm vụ - vận tốc của bạn đã chiếm phần đó.

Rõ ràng, điều này là không thể nếu bạn sử dụng hàng giờ thay vì điểm.


Vận tốc dự án +1 là chìa khóa, mặc dù tôi nghĩ bạn có thể làm điều đó với hàng giờ cũng như miễn là bạn sẵn sàng điều chỉnh giờ thô theo hệ số vận tốc
jk.

1
Điều đó giả định rằng các ước tính của bạn luôn được đưa ra bởi cùng một yếu tố. Theo kinh nghiệm của tôi, đó là trường hợp hiếm khi. Ngay cả các nhà phát triển thiếu kinh nghiệm ước tính một số nhiệm vụ rất chính xác. Và các nhà phát triển khá có kinh nghiệm đôi khi tạo ra các ước tính cực kỳ thấp về các nhiệm vụ nhất định. Chén thánh là để biết nhiệm vụ nào có khả năng được ước tính chính xác, và nhiệm vụ nào kém. Áp dụng một số yếu tố fudge chăn sẽ không giúp đỡ này.
Dawood nói phục hồi Monica

4
@DavidWallace Chắc chắn, nó sẽ không tạo ra ước tính chính xác cho mỗi nhiệm vụ , nhưng mục tiêu là ước tính chính xác hơn cho toàn bộ nước rút. Tại các lý thuyết, lý thuyết là sự đa dạng theo từng nhiệm vụ được tính trung bình trên 3+ lần lặp mà vận tốc được tính toán.
Chris Pitman

12

Có vẻ như các vấn đề là nhóm của bạn không có khả năng đưa ra các ước tính chính xác và không có khả năng thấy trước các vấn đề không thể tránh khỏi phát sinh.

Các nhiệm vụ nhỏ dễ dàng hơn nhiều để ước tính chính xác so với các nhiệm vụ lớn, vì vậy hãy thử và chia các nhiệm vụ của bạn thành các phần nhỏ hơn nhiều.

Đừng cho phép bất cứ ai ước tính cho bất kỳ nhiệm vụ nào, trừ khi họ biết CHÍNH XÁC cách họ sẽ thực hiện. Đối với bất kỳ nhiệm vụ nào mà nhà phát triển không biết phải hoàn thành cái gì, hãy dành thời gian cho lịch trình chạy nước rút của NÀY để nhà phát triển thực hiện một số điều tra và thiết kế và đưa ra ước tính chính xác. Không bao giờ dưới nửa ngày. Nhưng chuyển nhiệm vụ sang chạy nước rút TIẾP THEO. Sau đó, khi bạn lên kế hoạch cho lần chạy nước rút tiếp theo, bạn sẽ có một ước tính tốt. Lưu ý rằng thời gian thêm này không bị lãng phí, vì đó là thời gian mà nhà phát triển cuối cùng sẽ chi tiêu trong mọi trường hợp.

Và đừng sợ quay lại người quản lý dự án và nói với anh ấy / cô ấy rằng bạn sẽ cần nhiều lần chạy nước rút hơn để vượt qua danh sách các nhiệm vụ. Tốt hơn là làm điều đó, hơn là dấn thân vào những mục tiêu không thể.


+1 để điều tra các vấn đề khó khăn và hoãn thực hiện để chạy nước rút tiếp theo. Lưu ý rằng điều này thường được gọi là "giải pháp tăng đột biến" (hoặc chỉ "tăng đột biến"); extremeprogramming.org/rules/spike.html .
sleske

+1 để điều tra sớm. Cá nhân, khi tôi bối rối bởi thư viện hoặc nguyên tắc lập trình, nếu tôi nghiền ngẫm nó trong một hoặc hai tuần, khi tôi trở lại chủ đề, nó có ý nghĩa hơn rất nhiều.
Nút840

6

Bạn đang cố gắng phân bổ 100% thời gian của bạn? Nếu vậy, hãy ngừng làm điều đó. Bắt đầu bằng cách thêm tất cả số giờ mà nhóm của bạn phải đóng góp trong giai đoạn nước rút. Làm điều này bằng cách giả sử mỗi công nhân sẽ tốt nhất đặt 6 giờ một ngày cho dự án. Đây được coi là một "ngày lý tưởng". Hai giờ kia? Bị cuốn hút bởi các cuộc họp, giờ giải lao, các nhiệm vụ hành chính, vào thời điểm đó vào buổi sáng khi bạn đọc email và lên kế hoạch cho ngày của bạn, v.v ... Đây không phải là "phòng ngừa các vụ cá cược của bạn" hay "bao cát", điều đó là thực tế.

Thứ hai, nhân 6 giờ / ngày với 80% . Tại sao? Bởi vì như con người chúng ta dự đoán sẽ mất bao nhiêu thời gian cho một nhiệm vụ. Điều này cho các lỗi trong đánh giá của chúng tôi. Một lần nữa, không bao cát, đó là thực tế.

Bây giờ bạn có một số đại diện cho số giờ thực tế mà bạn mong đợi sẽ áp dụng trực tiếp cho các nhiệm vụ của mình. Khi bạn đang ước tính, ngừng thêm câu chuyện khi câu chuyện tiếp theo sẽ đưa bạn qua.

Cuối cùng, đừng để chủ sở hữu sản phẩm thêm nhiệm vụ. Lập kế hoạch Scrum là dành cho nhóm , PO không phải là một phần của nhóm thực hiện công việc. Tất nhiên, trong thế giới thực, nếu PO hiểu biết hơn bất kỳ ai trong nhóm, đầu vào của cô ấy có thể rất hữu ích. Tuy nhiên, nếu đội đang mất nhiệt vì đứng sau, đội cần có quyền sở hữu chính xác những nhiệm vụ họ sẽ làm. Mục tiêu của bạn là có thể đáp ứng các tiêu chí chấp nhận; nếu một nhiệm vụ không dẫn trực tiếp đến điều đó, đừng thực hiện nó.

Hãy nhớ rằng, Scrum không phải là về năng suất cao hơn. Đó là về việc cởi mở và giao tiếp hơn. Công việc sẽ mất bất cứ điều gì cần thiết để hoàn thành. Scrum có mặt để giúp ước tính dễ dàng hơn, dễ dàng giao tiếp với các bên liên quan hơn và nhóm của bạn thực hiện cam kết dễ dàng hơn.


5

Tiêu chí chấp nhận được xác định kém khi bắt đầu nước rút?

Ước tính ban đầu thường quá thấp vì thẻ câu chuyện có tiêu chí chấp nhận kém (nếu có) khi chúng được ước tính. Điều gì về việc chuyển sang Phát triển chấp nhận thử nghiệm (ATDD) hay còn gọi là kể chuyện để giúp nhóm thực sự hiểu rõ về thẻ là gì?

Chuyện quá lớn?

Một lý do khác khiến bạn phát hiện ra giữa cuộc đua nước rút rằng những câu chuyện của bạn mất nhiều thời gian hơn dự kiến ​​có thể là vì chúng quá lớn. Bạn đã thấy Agile trong bộ bài Flashcard chưa? Họ có một thẻ từ được gọi là "Shrink XL to Fit". Nó đưa ra các chiến lược để phân tách các câu chuyện như trì hoãn các trường hợp cạnh, tác dụng phụ, các khía cạnh không chức năng hoặc xử lý lỗi cho các câu chuyện sau này.

Không thể ước tính vì bạn không có đủ thông tin?

@sleske đưa ra một gợi ý tốt về gai . Hãy thử và xác định những ẩn số kỹ thuật tại thời điểm ước tính. Nếu có, hãy xem liệu bạn có thể trì hoãn câu chuyện vào lần chạy nước rút sau đó hay không và thực hiện một cuộc điều tra theo thời gian (tăng đột biến) lần chạy nước rút này để thử và tìm hiểu xem điều gì sẽ có thể ước tính. Đừng mang đi và giải quyết câu chuyện gốc - việc tăng đột biến được thực hiện khi bạn biết đủ để ước tính câu chuyện.

Thất bại nhanh hơn

Và tôi đồng ý với @Patrick Hughes - xem xét chuyển sang chạy nước rút 1 tuần để bạn có thể thấy vấn đề nhanh hơn.


3

Ngoài những gợi ý hay của @Kevin và @Patrick ...

Cách tiếp cận nhanh nhẹn không phải là "một kích thước phù hợp với tất cả" nhưng nhận xét này đã thu hút sự chú ý của tôi:

Chúng tôi đang triển khai một phiên bản Agile dường như liên tục cung cấp cho chúng tôi những khó khăn tương tự

Bạn nên bắt đầu với một phương pháp "bằng cuốn sách" (Scrum có vẻ chiếm ưu thế ngày nay) - và thực hiện chính xác những gì một nhóm thành công khác đã làm ... Làm điều đó trong một vài lần chạy nước rút ... Và chỉ sau đó mới bắt đầu xem xét thay đổi cần thiết để tối ưu hóa cho các điều kiện địa phương.

Thuê một huấn luyện viên Scrum có kinh nghiệm (cho một vài lần lặp) có thể là một nhà sản xuất khác biệt thực sự. Có sự tinh tế trong việc nhanh nhẹn ngay.


3

Đầu tiên tôi khuyên bạn nên theo cuốn sách scrum-xp-from-the-trenches . Nhìn vào trang 26 điểm về tính toán Vận tốc. Ý tưởng là xác định một yếu tố trọng tâm và để nói rằng cho Sprint tiếp theo:

ngày có sẵn * hệ số tập trung = vận tốc ước tính

vận tốc ước tính là tổng số ước tính của những câu chuyện bạn dự định thực hiện trong Sprint tiếp theo.

Và sau một Sprint, bạn tính hệ số tiêu điểm Sprint kéo dài là:

hệ số tập trung = vận tốc thực tế / ngày có sẵn

trong đó vận tốc thực tế là tổng của các ước tính của những câu chuyện bạn đã thực hiện trong giai đoạn nước rút.

Sau đó, bạn sử dụng lại yếu tố tập trung thực tế này cho Sprint tiếp theo và sau một vài Sprint bạn sẽ có thể chính xác hơn với số tiền bạn thực sự có thể đạt được trong một Sprint ...


+1 để đề cập đến scrum từ các chiến hào. Câu hỏi và câu trả lời khiến tôi nghĩ về cuốn sách đó.
Nút840

1

Cho đến khi bạn có được ước tính của mình để rút ngắn thời gian chạy nước rút của bạn xuống còn một tuần, bằng cách này, bạn sẽ nhận ra tình trạng quá tải nhanh hơn và có thể phản ứng theo từng bước nhỏ hơn.

Dành nhiều thời gian hơn lên phía trước khi thiết kế các nhiệm vụ để có được một số phòng thở để nhận ra các tác dụng phụ có lẽ là nguyên nhân khiến phạm vi bị chảy máu khắp nơi. Nó cũng có thể là bản thân các nhiệm vụ quá dài cho một ước tính nhanh nhẹn thích hợp, xem nếu các nhiệm vụ có thể được chia thành các bước ngắn hơn sẽ dễ nuốt hơn.

Giúp mọi người thoải mái với việc gửi một lá cờ đỏ ngay khi họ gặp phải sự cố thay vì bị mắc kẹt trong một vài giờ. Hãy thử và tách cái tôi ra và đổ lỗi cho quá trình này, điều đó dễ dàng hơn đối với một số người khác =)

Và giống như @Kevin đưa ra, bạn không bao giờ thực sự lên lịch trực tiếp 100% cho các nhiệm vụ vì luôn có chi phí như các cuộc họp và do đó bạn có thể không nhận ra mình là người ăn thời gian.

Khi mọi thứ đều tuyệt vời trên mặt trận lên lịch sau đó quay trở lại hai tuần, bạn sẽ kỳ diệu lấy lại một ít thời gian từ ít cuộc họp hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.