Làm thế nào chúng ta có thể giảm thời gian chết khi kết thúc một lần lặp?

Nơi tôi làm việc, chúng tôi thực hành nhanh nhẹn theo hướng scrum với các vòng lặp 3 tuần. Vâng, thật tuyệt nếu các lần lặp lại ngắn hơn, nhưng thay đổi đó không phải là một lựa chọn vào lúc này.

Vào cuối vòng lặp, tôi thường thấy rằng ngày cuối cùng trôi qua rất chậm. Công việc thực tế đã được hoàn thành và chấp nhận. Có một vài cuộc họp (hồi tưởng và lập kế hoạch lặp lại tiếp theo), nhưng khác hơn là không có nhiều điều đang diễn ra.

Nhóm kỹ thuật nào chúng ta có thể sử dụng để duy trì động lực cho đến ngày cuối cùng? Chúng ta có nên giải quyết khuyết điểm? Hãy bắt đầu sớm với công việc lặp lại tiếp theo nào? Thứ gì khác?

Gần đây tôi đã đấu tranh với cùng một câu hỏi. Chúng tôi đang bắt đầu vào lần lặp tiếp theo, nhưng tôi cảm thấy rằng điều này loại bỏ sự hài lòng của một lần lặp được thực hiện tốt.

Tôi đang suy nghĩ về tùy chọn để lại cho các nhà phát triển, với lời cảnh báo "miễn là mục đích là có lợi cho công ty."

Ví dụ:

• Dành cả ngày để học một cái gì đó
• Chi tiêu nó cho một dự án thời gian đổi mới
• Chi tiêu nó để dọn dẹp đoạn mã phiền phức mà bạn không bao giờ có được để tái cấu trúc
• Có một hoạt động tốt thông qua ứng dụng với tầm nhìn đến UX (mà chúng ta dường như không bao giờ tìm thấy thời gian để làm khác)

Bất cứ điều gì thúc đẩy lập trình viên, cung cấp cho họ một động lực để cung cấp bản phát hành đúng thời gian.

Ngày nghỉ. Bạn đã làm công việc mà bạn cần phải hoàn thành, vậy tại sao bạn vẫn làm việc?

Nếu thay đổi quy trình là có thể, hãy xem xét bỏ các lần lặp, phát hành liên tục và chỉ cần tiếp tục kéo các câu chuyện ra khỏi hồ sơ tồn đọng. Nhưng bạn không xứng đáng với một chút thời gian?

Tôi đã nhận thấy vấn đề tương tự (và đôi khi chúng tôi sử dụng nước rút 2 tuần, điều này làm trầm trọng thêm nó). Những gì tôi cố gắng làm cho những ngày đó (ngày xem xét nước rút và ngày lập kế hoạch chạy nước rút) là tiết kiệm một số công việc mà tôi biết tôi sẽ muốn làm nhưng không yêu cầu nhiều kế hoạch hoặc giao tiếp intrateam, như lỗi ưu tiên thấp, đánh bóng, hoặc cải tiến công cụ. Đôi khi điều này thực sự trở nên tích cực, vì nó tạo ra một thời điểm tốt để làm những công việc quan trọng nhưng không gợi cảm mà nếu không thì khó có thể dành thời gian cho nó.

Ngay cả khi các câu chuyện người dùng của chúng tôi hầu như luôn luôn kết thúc vào cuối vòng lặp, chúng tôi luôn có một danh sách dài các "câu chuyện hay" ở cuối, cùng với một danh sách các lỗi đã biết. Vì vậy, khi mọi người kết thúc câu chuyện của họ, luôn có nhiều việc phải làm.

Tôi nghĩ rằng thực hiện cuộc họp hồi cứu là vua, ngay cả khi chủ yếu là những vấn đề tương tự được nêu ra, điều rất quan trọng là dành một chút thời gian để suy nghĩ về cách lặp đi lặp lại, bạn học như thế nào, nếu bạn không nhận ra sai lầm của mình và những điều đã diễn ra tốt đẹp

Nếu tất cả các lỗi đã được thực hiện, một danh sách dài các việc cần làm tốt hơn, đã được thực hiện, cùng với các điểm hành động, tôi nghĩ thật tuyệt khi kết hợp đội trước một màn hình lớn và cố gắng chơi xung quanh với phần mềm đã được xây dựng, cùng với một số loại bia. Nó không thực sự hiệu quả, nhưng thật tuyệt khi nói về những gì đã được thực hiện và cách nó thực sự hoạt động.

Nếu bạn có ngày, sau đó tôi sẽ cố gắng tìm một cái gì đó mới để học, và cố gắng chơi xung quanh nó, có thể đó là điều lớn tiếp theo. Nhưng sau đó một lần nữa nếu có ngày, thì có lẽ có một câu chuyện người dùng tồn đọng để làm

Lặp lại của chúng tôi kết thúc vào thứ năm, để có thể khắc phục bất kỳ vấn đề vào phút cuối vào thứ Sáu. Nhưng những thứ Sáu đó (cứ sau 2 tuần) lại trùng với Thứ Sáu Bia của chúng tôi, vì vậy chúng tôi cố gắng thực hiện nó một cách khá bình tĩnh. Khắc phục một số lỗi nhỏ, dành thời gian đọc nội dung (sách, StackExchange, blog, v.v.) và thư giãn với một cốc bia vào cuối ngày. Nếu không, bạn không đạt được cảm giác hoàn thành hoặc đóng cửa, và thay vào đó cảm giác như một con chuột đồng quay tròn trong một bánh xe không ngừng.

Tôi không chắc bạn muốn luôn hoàn thành chính xác thời gian. Hoàn thành công việc sớm một chút cho phép bạn suy nghĩ về những câu chuyện, khả năng và tính năng trong tương lai. Nó cung cấp cho bạn một chút tạm dừng sau khi hoàn thành tốt công việc có thể bổ ích hơn là bắt đầu sớm hoặc cam kết nhiều câu chuyện hơn và luôn luôn có công việc tiếp tục.

Ken Schwaber tuyên bố trong blog của mình http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"Chúa giúp chúng tôi. Mọi người tìm mọi cách để nghỉ ngơi trong thác nước, nghỉ ngơi và sáng tạo. Với Lean và Kanban, những nơi ẩn náu đó đã được gỡ bỏ.

Trong các dự án của tôi, trong quá trình lập kế hoạch lặp lại, chúng tôi luôn chọn một số nhiệm vụ bổ sung và gắn nhãn cho chúng là "nhiệm vụ thưởng" được thực hiện nếu mọi thứ trong vòng lặp kết thúc. Về mặt thực tế, những "nhiệm vụ thưởng" này nói chung là những gì sẽ được thực hiện đầu tiên trong lần lặp tiếp theo, nhưng về mặt sinh lý học gọi chúng là "nhiệm vụ thưởng" hoạt động tốt hơn nhiều thì đơn giản là luôn có kế hoạch hoàn thành nhiều công việc hơn.

Đối với những thứ khác như thời gian học tập hoặc đổi mới, chúng tôi chỉ cần để mỗi nhà phát triển dành tối đa một ngày một tuần cho những thứ đó như một điều bình thường mong đợi. Nó có thể là bất kỳ ngày nào trong tuần (nghĩa là không phải vào cuối mỗi tuần).

Tất cả các nhà phát triển trong nhóm của tôi sử dụng thời gian rảnh vào cuối giai đoạn nước rút (với điều kiện là tất cả các nhiệm vụ chạy nước rút đã kết thúc) là 'thời gian của Google'.

Đây là nơi mỗi nhà phát triển làm việc theo ý tưởng / dự án của riêng mình miễn là nó mang lại lợi ích cho công ty. Tôi thực sự khuyên bạn nên đặt một hệ thống như thế này, điều này thực sự đã tăng mức độ hài lòng công việc trong nhóm của chúng tôi.

Nếu bạn liên tục hoàn thành sớm ba ngày, điều đó cho tôi thấy rằng bạn không lên kế hoạch đủ cho câu chuyện nước rút.

Một trong những mục tiêu của scrum là tăng năng suất - bạn sẽ không làm điều này nếu bạn đang thực hiện mỗi lần chạy nước rút.

Để giải quyết điều này, hãy lên kế hoạch cho nhiều câu chuyện hơn bạn đã từng. Chỉ cam kết với vận tốc trước đó của bạn, nhưng nếu bạn hoàn thành những câu chuyện đó hãy bắt đầu làm việc với những câu chuyện thêm. Nếu bạn hoàn thành nhiều hơn, tăng tốc độ của bạn cho lần chạy nước rút tiếp theo. Luôn lập kế hoạch cho một chút nhiều hơn bạn sẽ cam kết, hoặc ít nhất là có một số câu chuyện xếp hàng, chỉ trong trường hợp.

Đây là một trong những lý do chúng tôi chuyển sang Kanban. Tất cả những lợi ích của scrum mà không cần phải tiếp tục phá vỡ khỏi dự án.

Tôi thích câu trả lời của Todd về việc nghỉ ngày, tuy nhiên tôi sẽ nói rằng hãy thử và thực hiện kế hoạch chạy nước rút và hồi tưởng vào buổi sáng và đặt ra một kế hoạch hoàn thành đúng giờ cho bữa trưa và sau đó ăn trưa dài với tư cách là một đội. Trong bữa ăn trưa khuyến khích thảo luận về nước rút để bạn có được một hồi cứu không chính thức miễn phí.

Nếu sau đó bạn không thể đưa ra dư luận (và ý tôi là như về nhà vào đầu giờ chiều không phải là mục tiêu của riêng bạn vào buổi chiều) thì hãy giải quyết nợ kỹ thuật vì đó là điều khiến nhà phát triển chán nản hơn bất cứ điều gì khác (nguồn : ý kiến ​​của tôi) phải làm việc xung quanh nợ kỹ thuật khi họ biết chính xác cách giải quyết và làm cho cuộc sống của họ dễ dàng hơn.

Cá nhân tôi thấy rằng các quá trình hồi tưởng không thực sự đáng để dành thời gian, thường có một vài chủ đề định kỳ phổ biến (câu chuyện người dùng kém, ước tính xấu, v.v.) và bạn chỉ chấp nhận chúng là những vấn đề và tiếp tục. Chúng tôi cũng cố gắng và xử lý các vấn đề khi chúng phát sinh, thay vì chờ hồi cứu (điều mà chúng tôi có xu hướng làm trong giai đoạn đầu áp dụng Scrum).

Bây giờ thay vì có một hồi cứu, mỗi cặp nhà phát triển chọn một mục nổi bật từ tồn đọng hồi cứu hiện có và hoạt động trên đó.

Chúng tôi cũng giữ một tồn đọng nợ kỹ thuật đang diễn ra, hoạt động như các phần thưởng cho nước rút (nếu doanh nghiệp không sẵn sàng thực hiện một cái gì đó từ hồ sơ tồn đọng của họ trước thời hạn).

Điều này đã được chứng minh khá tích cực, trong đó tất cả các mặt hàng nhỏ bé nghịch ngợm chỉ tiếp tục sủi bọt dưới sự chú ý của một ngày mỗi lần chạy nước rút.

Có một phiên thiết kế bảng trắng và chia sẻ ý tưởng thực hiện cho những câu chuyện thú vị trên đường nước rút sắp tới. Thực hiện việc này sau và tách khỏi phiên lập kế hoạch, trong đó các câu chuyện vẫn nhẹ về các chi tiết và được đánh giá bằng các ước tính kích thước điểm truyện hoặc áo phông. Giữ phiên không chính thức và khuyến khích sự sáng tạo.