Scrum: Chạy nước rút ngắn VS dài

8

Chúng tôi đã cố gắng tìm ra chiều dài nước rút tối ưu cho dự án của chúng tôi. Sau khi làm việc trên cơ sở 3 tuần, chúng tôi nghĩ rằng việc cắt nước rút xuống còn 2 tuần sẽ mang lại vận tốc tốt hơn.

Những lợi thế rất rõ ràng - vòng phản hồi ngắn hơn, những câu chuyện nhỏ (có giá trị người dùng), v.v. Mặt khác, có rất nhiều nhược điểm như nghi lễ (lập kế hoạch, hồi tưởng), v.v. chúng tôi không sản xuất và bây giờ xảy ra thường xuyên hơn.

Tôi đã tự hỏi làm thế nào, đối với một đội mới, chúng ta có thể quyết định độ dài nước rút tối ưu không?

— Avi
nguồn

1

Trong khi lập kế hoạch và hồi cứu đến thường xuyên hơn, bạn cũng không có 2/3 nhiều như vậy để nói? Và do đó, bạn có thể không rút ngắn cuộc họp?

— pdr

3

Kinh nghiệm của tôi với scrum cho thấy quá trình hồi cứu sẽ mất nhiều thời gian nhất có thể. Kế hoạch có thể ngắn hơn một chút nhưng tôi không chắc là đủ. Ngoài ra, có bản demo cho cuộc họp khách hàng / po và chạy nước rút.

— Avi

2

Điều đó để lại hai khả năng. 1. Hồi tưởng của bạn là, có lẽ vẫn còn, quá ngắn. Đừng xem đó là thời gian không hiệu quả, bởi vì nó giúp tăng năng suất của bạn trong thời gian còn lại. 2. Hồi tưởng của bạn thiếu cấu trúc và không đạt được nhiều. Trong trường hợp đó là giải pháp rõ ràng.

— pdr

1

Khoảng 1 - Tôi không có xu hướng đồng ý rằng nó ngắn. Mọi người trong nhóm của tôi chỉ thích nói chuyện :) Chúng tôi cố gắng tập trung nhưng thường thì cuộc thảo luận trôi dạt đến một nơi không có kết quả. Đóng khung thời gian hồi cứu giúp cắt giảm các cuộc thảo luận như vậy và trở lại theo dõi một cuộc thảo luận hiệu quả với các kết luận rõ ràng và các mục hành động cho tương lai. Về 2 - Tôi đồng ý và tôi có các cách điều tra để cải thiện quá trình hồi tưởng của chúng tôi gần đây. Mabye tôi sẽ mở một câu hỏi khác để hồi tưởng.

— Avi

1

@pdr: Có một chi phí cố định cho mỗi cuộc họp (ví dụ: trước và sau khi bị gián đoạn, bạn sẽ không làm việc gì nghiêm trọng). Do đó, ít cuộc họp có thể hiệu quả hơn nhiều cuộc họp ngắn.

— Giorgio

8

Tôi nghĩ rằng bạn đang nhìn vào nó một chút ngược. Vận tốc là hậu quả của công việc mà nhóm của bạn đang làm. Nó không phải là một yếu tố nhân quả - tức là. đó là thứ bạn đo lường và nó không phải là thứ bạn có thể điều chỉnh trực tiếp.

Đây giải thích về vận tốc có một miếng ngon có liên quan đến câu hỏi của bạn.

Cách đơn giản nhất để xác định vận tốc là: số lượng hoặc câu chuyện người dùng mà nhóm / dự án có thể thực hiện trong một lần chạy nước rút

Và theo định nghĩa đó, chạy nước rút dài hơn có nghĩa là có nhiều thời gian hơn để phát triển trên mỗi lần chạy nước rút và do đó số vận tốc lớn hơn.

Vận tốc tương đối giữa nước rút 2 tuần hoặc 3 tuần là một câu hỏi hơi khác nhau. Chi phí từ các nghi lễ dự án có thể ảnh hưởng đến số tiền bạn có thể làm được vì có ít thời gian tổng thể có sẵn. Xem xét tính toán này như một cách để xác định giờ phát triển có sẵn trong một lần chạy nước rút.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverheadnói chung là cố định. Giảm của bạn DaysInSprintvà bạn có thể thấy làm thế nào bạn sẽ có ít thời gian hơn để phát triển trong giai đoạn nước rút đó. Sử dụng một ví dụ đơn giản là 1 dev, đây là những con số cho một vài độ dài nước rút.

1 tuần:
((8 * 5) - 4) * .8 = 28,8 giờ hoặc 5,76 giờ mỗi ngày.
2 tuần:
((8 * 10) - 4) * .8 = 60.8 giờ hoặc 6.08 giờ mỗi ngày.
3 tuần:
((8 * 15) - 4) * .8 = 92,8 giờ hoặc 6,18 giờ mỗi ngày.

Câu trả lời "rõ ràng" là nước rút dài hơn là tốt hơn. Vấn đề với câu trả lời rõ ràng là nó bỏ qua tác động có lợi của các vòng phản hồi. Những suy nghĩ ôn hòa liên quan đến tính toán đó với góc nhìn tổng thể về những gì Agile được cho là sẽ mang lại cho quá trình phát triển.

Tôi nghi ngờ vấn đề cốt lõi của bạn là câu chuyện người dùng của bạn không được xác định như có thể. Sự thiếu hiểu biết những gì cần thiết là trở ngại thực sự để hoàn thành công việc.

1

Đó hoàn toàn không phải là vấn đề. Tôi thực sự cố gắng suy nghĩ, khách quan, làm thế nào để thực hiện một mong muốn như vậy.

— Avi

2

@Avi - suy đoán của tôi sang một bên, bây giờ bạn có thể xem xét các hiệu ứng định lượng của các độ dài nước rút khác nhau. Chỉ cần cắm các số thích hợp cho nhóm của bạn về chi phí hoạt động và hệ số sử dụng của bạn. Từ đó, bạn có một hành động cân bằng giữa độ dài của nước rút so với tác động lên chu kỳ phản hồi. Đối với vấn đề đó, Agile khuyến khích thực hiện những điều khác biệt để thử nghiệm xây dựng và xác định các phương tiện cải tiến. Thay đổi độ dài nước rút của bạn trong một thời gian và xem kết quả là gì.

3

Bạn nói "CeremonyOverhead thường được sửa." Không nên quy mô nghi thức chạy nước rút của bạn với kích thước của nước rút của bạn? Bài viết này tuyên bố "các cuộc họp chạy nước rút quy mô tuyến tính với độ dài của một Sprint. Vì vậy, một tuần Sprint sẽ có 2 giờ Lập kế hoạch Sprint, một Sprint hai tuần có 4 giờ và cứ thế." có thể là một chút lạc quan, nhưng nó phải gần với tuyến tính.

— sgryzko

7

Mặt khác, có rất nhiều nhược điểm như nghi lễ (lập kế hoạch, hồi tưởng), v.v.

Đây là một lá cờ đỏ lớn. Nếu bạn xem nó như một buổi lễ chứ không phải là phương tiện thiết yếu phục vụ quá trình làm việc và cải tiến của nó, có lẽ làm việc trên đó có nhiều lợi ích hơn là loay hoay với chiều dài nước rút.

Quá trình là trong tay của bạn (có nghĩa là nhóm). Bạn nên theo đuổi những ý tưởng đẹp nhất, nếu cần thử nghiệm và điều chỉnh. Chúng tôi đã làm được 2 tuần rồi cuối cùng chuyển sang 3 tuần và nó hoạt động tốt hơn. Nhưng đôi khi chỉ cần đặt độ dài dựa trên ước tính cho phạm vi. Vâng, tôi biết ý tưởng "có độ dài bằng nhau", nhưng nó không phải là một giáo điều, và có thể không thực sự phù hợp với một số dự án thực tế. Và có một mục tiêu nước rút rõ ràng và rõ ràng có thể phục vụ tốt hơn.

Độ dài phù hợp thực sự không phải là thứ có thể suy ra từ bên ngoài. Bạn đang ở đó để biết các yếu tố liên quan. Theo kế hoạch, bạn có thể bắt đầu với "ok, chúng ta có thể làm gì trong X tuần tới". Hoặc thay vào đó "những gì sẽ là sự gia tăng hợp lý tiếp theo". Trong mọi trường hợp lập kế hoạch sau này là tốt, sau đó xem thời gian sẽ mất. Và một phần trong một hoặc nhiều lần chạy nước rút.

— Balog Pal
nguồn

1

Tôi đồng ý với chẩn đoán của bạn. Các cuộc họp sẽ được tổ chức ngắn gọn, đơn giản và hiệu quả bởi một đội ngũ giàu kinh nghiệm. Các cuộc họp dài mà nhóm cố gắng tránh là một dấu hiệu chắc chắn về việc thực hiện nhanh chóng bị hỏng.

— Sklivvz

2

Tùy bạn Hãy thử cả hai, xem những gì hoạt động. Sử dụng nó.

Nhanh nhất 'chạy nước rút' tôi từng sử dụng là 6 tuần. Chúng tôi đã hoàn thành rất nhiều việc - nhưng chúng tôi chỉ cần giao cho khách hàng theo lịch trình đó. Chúng tôi đã không sử dụng các tác vụ, thích làm việc theo phong cách làm việc theo câu chuyện của người dùng.

— gbjbaanb
nguồn

Tôi biết điều đó tùy thuộc vào tôi và mỗi đội có sở thích của mình. Tuy nhiên, tôi muốn thu thập một số dos và không nên đưa ra quyết định tốt ngay từ đầu. Btw. Trong dự án nước rút 6 tuần này - bạn đã có nhiều hơn một lần chạy nước rút?

— Avi

6 tuần dường như rất nhiều cho một lần chạy nước rút, có thể là quá nhiều. Tôi nghĩ rằng, trong hầu hết các tình huống, nếu bạn vượt quá 4 tuần với một lần chạy nước rút, có lẽ bạn đã làm sai ...

— Radu Murzea

Tôi nghĩ rằng gbjbaanb chỉ có 6 tuần cho dự án. Hay nói cách khác - dự án chỉ là 1 lần chạy nước rút. Tất nhiên, ngay cả một dự án 6 tuần có thể được chia thành 1-2-3 tuần nước rút.

— Avi

chúng tôi đã có khoảng 6-8 tháng làm việc. Nó đã xảy ra như vậy rằng 6 tuần là tốt cho chúng tôi và khách hàng đã xem xét việc giao hàng của chúng tôi, và đó là điểm quan trọng - bỏ qua bất cứ ai nói rằng nước rút nên là gì. Đó là những gì làm cho bạn năng suất nhất. Hãy nhớ rằng, agile nói rằng phân phối phần mềm làm việc thường xuyên, nó không nói là 2 tuần. Tôi đã làm việc trong những lần chạy nước rút trong 2 tuần, nơi chúng tôi phải thực hiện rất nhiều nghiên cứu để thực hiện việc giao hàng, ở mỗi đầu, các bản demo đều lúng túng trong sự ngắn gọn của họ, và phản hồi từ họ là không quan trọng. Vì vậy, chúng tôi đã có rất nhiều chi phí cho kết quả nhỏ. YMMV

— gbjbaanb

1

Nó phụ thuộc vào những gì bạn mô tả về một "nhóm mới".

Thật vậy, vận tốc của các đội phụ thuộc vào rất nhiều thông số giữa nhiều người (ví dụ: đàn em?, Người cao niên?, Người mới?, Căng thẳng giữa các thành viên trong đội?, V.v.).

Do đó, chiều dài nước rút "lý tưởng" cũng bị ràng buộc với các tham số này.

Dù sao, không có giải pháp nào phù hợp cho điều đó, cách duy nhất là thử nghiệm nó với chính đội và cũng tính đến mức phù hợp trung bình tốt nhất cho tất cả các thành viên trong nhóm.

— Vincent
nguồn

1

Tôi nghi ngờ đề xuất của bạn về một "vòng phản hồi ngắn hơn". Nhóm của bạn nên làm việc với khách hàng hàng ngày - phản hồi không nên chờ Đánh giá và Hồi cứu của Sprint. Kiểm tra, mã, thiết kế, và nhận phản hồi ngay lập tức .

Cá nhân tôi thích chạy nước rút ba tuần vì tuần giữa cho phép nhóm có thời gian "chảy". Đó là, luôn luôn có thời gian quay vòng trong tuần đầu tiên (tìm hiểu ý nghĩa của những câu chuyện mới này) và một số kết thúc cuối cùng (chuẩn bị cho đánh giá). Một tuần giữa để đơn giản sản xuất phần mềm làm việc là một điều thực sự tốt đẹp để có.

Đưa logic này đi xa hơn, nước rút bốn tuần sẽ có ý nghĩa hơn nữa. Tuy nhiên, cảm giác cấp bách có thể bị mất nếu bạn bắt đầu mở rộng nước rút. Hơn nữa, thực sự có một khối thông tin tương đối nhỏ mà một người hoặc nhóm có thể nắm bắt và giữ trong đầu suy nghĩ có ý thức của họ - chạy nước rút càng lâu, bạn càng cố gắng tập trung vào, điều này có thể khiến mọi việc khó khăn hơn thay vì dễ dàng hơn Ngoài ra, thật khó để đánh giá những yếu tố bên ngoài nào sẽ xuất hiện nếu bạn mở rộng mọi thứ ra quá xa.

— Matthew Flynn
nguồn

1

Vì bạn đã hỏi về một đội mới , tôi muốn thêm một vài suy nghĩ. Tôi đã làm việc với Scrum và các phương pháp Agile khác trong hơn 15 năm và bây giờ tôi luôn khuyên các nhóm mới bắt đầu với Sprints dài 1 tuần. Có ba lý do quan trọng cho việc này:

Sprints ngắn hơn giúp các đội có được trạng thái hiệu suất cao nhanh hơn. Sprint dài thường có nghĩa là phải mất 18 tháng đến hai năm để đến trạng thái đó. Sprint ngắn một tuần giúp một nhóm đạt được trạng thái hiệu suất cao đó chỉ trong hai hoặc ba tháng. Tất nhiên, những thứ khác cũng cần phải có để đạt được hiệu suất cao (xem "Trí tuệ của các đội" của Katzenbach và Smith).
Như những người khác đã đề cập, một Sprint ngắn hơn làm tăng chu kỳ phản hồi. Một Sprint dài một tuần dường như là tối ưu cho hầu hết các nhóm thực hiện phát triển phần mềm hoặc phát triển sản phẩm. Các phản hồi chủ yếu nên có trong Đánh giá Sprint sẽ thay thế quy trình UAT truyền thống của bạn.
Cuối cùng, Sprint ngắn hơn gây áp lực lên nhóm của bạn để đối phó với những trở ngại của tổ chức đối với việc giao hàng thường xuyên. Áp lực đó ban đầu rất khó chịu, nhưng là điều cần thiết để cải thiện các quy trình phát triển tổng thể của bạn bao gồm lập kế hoạch, tuân thủ, phát hành, v.v.

Tôi đã viết một bài báo có tên 21 Mẹo để chọn Độ dài Sprint có thể được quan tâm.

— Mishkin Berteig - Huấn luyện viên nhanh nhẹn
nguồn

0

Các nghi lễ có một mục đích - khi chúng tôi nhận ra mục đích chúng tôi nhận ra chúng không phải là chi phí mà là giá trị gia tăng.

Lập kế hoạch - không chỉ là cam kết làm việc, mà còn hiểu cách làm việc với các đồng đội của bạn. Khi mọi người phàn nàn về việc thiếu sự hợp tác trong Nhóm Scrum của họ, tôi muốn xem Kế hoạch Sprint của họ như là một phần của vấn đề

Đánh giá - thu thập phản hồi từ khách hàng về những gì chúng tôi đang xây dựng và vẫn có liên quan, v.v. Cũng hoạt động như một kiểm tra chất lượng.

Hồi tưởng - cải thiện cách chúng ta làm việc cùng nhau như một đội.

Khi chúng ta nỗ lực để tôn vinh mục đích sâu xa hơn, vấn đề trên cao thường biến mất. Như đã lưu ý trong các ý kiến ban đầu cho câu hỏi, các nghi lễ thường quy mô tuyến tính.

Nếu bạn cần thêm về chủ đề tôi có một bài viết: Chọn Độ dài Sprint

— Đánh dấu Levison
nguồn