Làm cách nào để dừng / tránh theo thời gian trên Nhóm Scrum?

Trên thực tế, tôi đang giúp một cửa hàng phần mềm nhỏ trên Triển khai Scrum của họ. Gần đây, Scrum Master đã báo cáo với tôi rằng anh ta có vấn đề vì Nhóm đang làm việc theo thời gian để đạt được Phạm vi (Đã cam kết tồn đọng). Vì vậy, họ có một vận tốc không thực .

Câu hỏi chính thức của tôi là / là:

1. Ngoài việc nói về Cuộc họp Hồi cứu; Bạn có nghĩ rằng đó là một ý tưởng tốt để thực hiện một số khối cứng để tránh theo thời gian?

2. Nếu vậy, những kỹ thuật / công cụ nào bạn đề nghị?

   • Hệ thống kiểm soát sửa đổi (SVN, GIT, HG, v.v.), khối theo giờ (8 đến 5)
   • Khối trạm làm việc theo giờ (8 đến 5) hoặc giờ tích lũy (tối đa 8 giờ / ngày)?
   • Khác)...

3. Hoặc, có thể, không khó ngăn chặn những thứ này; nhưng thực hiện một số "Hệ thống hình phạt" cho những giờ làm thêm không chính đáng?

@Baqueta (và những người khác có câu hỏi tương tự): Không họ không được trả thêm giờ. Lời khuyên đầu tiên của tôi cho họ là xem xét ước tính của họ vì có thể họ đang đánh giá thấp. Đây là lời khuyên yêu thích của tôi:

Nếu họ có hứng thú làm việc ngoài giờ, hãy loại bỏ nó. Phát triển không phải là thứ bạn có thể làm trong 60 giờ một tuần và duy trì hiệu quả, và có rất nhiều nghiên cứu ngoài đó chứng minh điều này. Nếu trả lương ngoài giờ là vấn đề, hãy loại bỏ nó và cải thiện mức lương cơ bản của họ để họ nhận được những gì họ đáng giá.

Ngoài ra, tôi nghĩ rằng vấn đề gốc (đối với nhóm này), là sự kết hợp của các vấn đề sau:

1. Các nhà phát triển đang được cho biết những gì họ phải đạt được trong giai đoạn nước rút / không được hỏi ý kiến ​​về những gì có thể đạt được / đang bị bỏ qua khi họ nói rằng có quá nhiều công việc.
2. Các nhà phát triển luôn đánh giá thấp các nhiệm vụ sẽ mất bao nhiêu thời gian / bao nhiêu đơn vị công việc có liên quan đến mỗi nhiệm vụ.

Tóm tắt: Tôi sẽ nói chuyện với Nhóm để xem xét ước tính của họ và với PO vì tôi cảm thấy rằng họ không được hỏi ý kiến về phạm vi, như bạn đã đề cập.

Thành thật mà nói, những "khối cứng" mà bạn đề cập trong # 2 là ý tưởng tồi tệ nhất mà tôi đã nghe trong một thời gian dài. Điều gì xảy ra nếu một lỗi ưu tiên hàng đầu được tìm thấy vào lúc 4h45 chiều và anh chàng có khả năng ghi đè các khối của bạn bị bệnh? Đối với số 3 - bạn đang đề nghị trừng phạt mọi người vì đã làm công việc của họ .

Nếu nhóm liên tục làm việc ngoài giờ để hoàn thành các lần chạy nước rút, thì họ có hứng thú làm việc ngoài giờ - ví dụ như trả lương ngoài giờ hoặc trở lại làm thêm giờ trong kỳ nghỉ - hoặc họ cam kết thực hiện quá nhiều công việc trong các lần chạy nước rút.

Nếu họ có hứng thú làm việc ngoài giờ, hãy loại bỏ nó . Phát triển không phải là thứ bạn có thể làm trong 60 giờ một tuần và duy trì hiệu quả, và có rất nhiều nghiên cứu ngoài đó chứng minh điều này. Nếu trả lương ngoài giờ là vấn đề, hãy loại bỏ nó và cải thiện mức lương cơ bản của họ để họ nhận được những gì họ đáng giá.

Nếu có quá nhiều công việc đi vào nước rút, điều này thường là vì một trong ba lý do:

1. Các nhà phát triển đang được cho biết những gì họ phải đạt được trong giai đoạn nước rút / không được hỏi ý kiến ​​về những gì có thể đạt được / đang bị bỏ qua khi họ nói rằng có quá nhiều công việc.
2. Các nhà phát triển luôn đánh giá thấp các nhiệm vụ sẽ mất bao nhiêu thời gian / bao nhiêu đơn vị công việc có liên quan đến mỗi nhiệm vụ.
3. Các nhà phát triển tiếp tục bị kéo vào các nhiệm vụ không phải là một phần của scrum.

Nếu đó là số 1, bạn đang làm sai . Không có hai cách về nó!

Nếu đó là số 2, nguyên nhân thông thường là thiếu kinh nghiệm - hoặc là thực hiện ước tính thời gian hoặc với hệ thống đang được phát triển. Một cách tốt để giải quyết vấn đề này là ngừng thực hiện ước tính thời gian và bắt đầu ước tính 'đơn vị công việc'. Sử dụng một số đơn vị trừu tượng, chỉ cần đảm bảo rằng đó không phải là giờ thời gian thực (cuối cùng bạn vẫn đại diện cho một khoảng thời gian, nhưng sự trừu tượng là quan trọng!). Sau đó, bạn có thể bắt đầu tính toán có bao nhiêu đơn vị công việc thực sự được thực hiện trong một tuần, sau đó thiết lập chạy nước rút bằng dữ liệu đó.

Nếu đó là số 3, bạn cần bắt đầu bao thanh toán trong các nhiệm vụ khác bằng cách nào đó. Nếu nó phù hợp, nó sẽ dễ dàng chiếm được (xem # 2 ở trên). Nếu nó thường xuyên nhưng không thể đoán trước thì sẽ rất khó xử lý. Bạn sẽ muốn xem lý do tại sao điều đó xảy ra (ví dụ: lỗi nghiêm trọng trong mã 'sống' => thử nghiệm của bạn có đủ kỹ lưỡng không?) Nhưng nếu điều đó không thể được khắc phục thì cuối cùng scrum có thể không phải là phương pháp phù hợp với bạn. Nhóm của tôi gần đây đã chuyển sang Kanban vì lý do này ...

Chỉnh sửa: Làm rõ sự chỉ trích của tôi về các ý tưởng được trình bày trong câu hỏi.

Trước hết, có vẻ như họ đã làm việc quá nhiều trong một lần chạy nước rút nếu họ phải làm thêm giờ để hoàn thành công việc. Có phải tất cả các giờ đăng nhập? Nếu vậy thì bạn có thể đếm được bao nhiêu công việc thực tế là một điểm câu chuyện và sử dụng số đó để tính toán công việc cho lần chạy nước rút tiếp theo.

Điều quan trọng nữa là đảm bảo nhóm hiểu rằng họ chỉ làm hại chính mình bằng cách làm quá nhiều việc. Ngay cả bản tuyên ngôn nhanh nhẹn cũng nói về tốc độ bền vững: "Các quy trình nhanh nhẹn thúc đẩy sự phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng nên có thể duy trì tốc độ không đổi vô thời hạn." Làm việc ngoài giờ mọi lúc không bền vững.

Nói chung, tôi đề nghị giao tiếp thay vì ép buộc và phạt. Tôi tưởng tượng rằng điều đó sẽ chỉ dẫn đến việc mất tinh thần của đội.

Các nhà phát triển làm việc quá giờ có khả năng đáp ứng một số ưu đãi, thực tế hoặc được cảm nhận. Điều này là để loại bỏ ưu đãi nếu nó là thực tế hoặc để thông báo rằng một khuyến khích nhận thức không hoạt động.

Mỗi giới hạn cứng được đề xuất có một số cách giải quyết hoặc các vấn đề khác. Các khối kiểm soát nguồn sẽ chỉ dẫn đến các nhà phát triển giữ cam kết của họ cho đến khi cửa sổ mở lại. Các khối máy trạm sẽ phải đi ngay khi có một số vấn đề hỗ trợ hoặc một trong những nhà phát triển cần thiết để thay đổi giờ của mình vì một số lý do. Hệ thống hình phạt sẽ chỉ dẫn đến việc che giấu hoặc chôn vùi giờ làm thêm.

Tôi nghĩ vấn đề là cơ bản hơn - nhóm có một số động lực (hoặc tin rằng họ có động lực) để làm thêm giờ.

Đây là những gì cần được giải quyết. Là đánh giá hiệu suất của họ gắn liền với số vận tốc của họ? Có phải quản lý làm thêm giờ? Được khuyến mãi và giải thưởng được trao cho những người làm việc nhiều giờ? Họ có phải là nhà thầu được trả tiền làm thêm giờ không?

Đơn giản chỉ cần nói với nhóm không làm thêm giờ. Giai đoạn = Stage.

Điều này có thể khiến họ không thể hoàn thành một số công việc. Đó không phải là một vấn đề, đó là một điểm dữ liệu. Sau đó, họ có thể sử dụng điểm dữ liệu đó trong kế hoạch chạy nước rút tiếp theo. Một lần nữa, đừng để họ làm thêm giờ. Cho dù họ kết thúc hay không, họ có một điểm dữ liệu khác. Lót, rửa sạch, lặp lại.

Không có số lượng các thủ thuật hoặc giới hạn là cần thiết. Đừng làm thêm giờ. Tìm hiểu bao nhiêu công việc bạn có thể hoàn thành và điều chỉnh kế hoạch chạy nước rút của bạn cho phù hợp.

Có thể có một vấn đề không phải là họ "làm việc" bao nhiêu mà là khi nào. Đây có thể là một vấn đề khi có một ngày làm việc theo lịch trình, nhưng phần lớn các giờ bình thường được tạo thành từ các cuộc họp và các phiền nhiễu xã hội và cá nhân khác. Có phải họ làm việc trong thời gian dài vì họ cảm thấy năng suất hơn.

Cắt giảm số lượng công việc trong nước rút và bắt đầu làm việc với thời gian flex. Cho phép họ đến sau. Người phụ trách chỉ cần bảo mọi người về nhà; không sao đâu Có một số nền văn hóa doanh nghiệp tạo ra một môi trường mà việc rời đi sớm có thể mang lại một số cau mày.

Tôi đã vật lộn với điều này khi lần đầu tiên chuyển sang scrum. Thật tự nhiên khi muốn nỗ lực thêm gần thời hạn, nhưng scrum có thời hạn hai tuần một lần nên đó là một sự điều chỉnh. Ngoài đề xuất mà những người khác đã đưa ra để cắt giảm các điểm câu chuyện đã cam kết mỗi lần lặp, tôi cũng đề nghị đảm bảo các câu chuyện được chia nhỏ đủ để mỗi nhà phát triển có thể hoàn thành ít nhất hai hoặc ba lần lặp.

Điều đó không chỉ đảm bảo mỗi nhà phát triển cảm thấy như họ đã hoàn thành một cái gì đó mỗi lần lặp, nó còn cung cấp cho bạn một chút chậm chạp trong phạm vi của bạn. Khi kết quả của bạn cho thấy bạn sẽ không thể hoàn thành một câu chuyện, bạn có thể kéo nó ra và phân bổ lại cho mọi người những câu chuyện có thể kết thúc. Khi mọi người thấy phạm vi đó có thể được điều chỉnh, họ sẽ ít có khả năng nhấn mạnh về thời hạn không thực tế. Nếu bạn bắt đầu một vòng lặp với mỗi câu chuyện đang diễn ra, bạn không có chỗ để điều chỉnh.

Một biểu đồ luồng tích lũy lý tưởng sẽ trông giống như thế này nếu mọi người đang hoàn thành hai câu chuyện trên mỗi lần lặp:

Nó không bao giờ giống như vậy bởi vì trong thực tế, rất khó để thời gian kết thúc tất cả các câu chuyện vào ngày cuối cùng trong khi vẫn khiến mọi người bận rộn, nhưng đó là một quy tắc tốt. Nếu bạn quá quan tâm, vùng màu đỏ sẽ lớn hơn và bạn có thể xóa câu chuyện. Nếu bạn không đủ điều kiện, khu vực màu xanh sẽ lớn hơn và bạn có thể thêm câu chuyện. Nếu câu chuyện của bạn quá lớn, khu vực màu xanh lá cây sẽ lớn hơn và bạn nên chia câu chuyện.

Để tránh làm thêm giờ, bạn phải cắt phạm vi của dự án.

Biểu đồ sau đây cho thấy sự không chắc chắn nằm trong một dự án:

Nếu bạn nhận thấy, ở giai đoạn định nghĩa sản phẩm và yêu cầu, bạn có sự chênh lệch lớn trong ước tính nỗ lực. Bạn không thể chắc chắn liệu sẽ mất một tháng hay một ngày để thực hiện tính năng này.

Tôi cá rằng không có nhiệm vụ nào được thực hiện bởi vì chúng đơn giản là quá lớn và không xác định và có quá nhiều trong số chúng.

Nếu nhóm của bạn có thể xử lý 10 vé trong 5 ngày và họ được chỉ định 20 vé, hãy cắt số đó xuống, gửi cho chủ sở hữu sản phẩm / người quản lý dự án / người quản lý / khách hàng và bảo họ ưu tiên.

Tại thời điểm này, đó là cách duy nhất để cứu đội khỏi làm thêm giờ. Bạn không thể cung cấp tất cả mọi thứ, nhưng bất cứ điều gì bạn cung cấp sẽ ít có khả năng có lỗi.

Tôi cũng sẽ khuyên bạn nên tìm một công việc mới và giúp các đồng đội của bạn làm điều tương tự và sửa chữa sơ yếu lý lịch và danh mục đầu tư chuyên nghiệp của họ. Một công ty mong đợi làm thêm giờ là không ai nên làm việc và phần mềm được sản xuất sẽ có lỗi như địa ngục.

Tôi khuyên mạnh mẽ chống lại "khối cứng". Các kiểm soát như vậy có thể được coi là quản lý vi mô và có thể không giải quyết được vấn đề tiềm ẩn.

Tôi đề nghị bạn tìm hiểu tại sao lập trình viên làm việc ngoài giờ. Câu trả lời có thế làm bạn ngạc nhiên. Nghe có vẻ như bạn là "người ngoài cuộc" (không phải là nhân viên của công ty) và các lập trình viên có thể sẵn sàng thẳng thắn với bạn nếu bạn gặp riêng họ (một đối một).

Là lý do để làm việc ngoài giờ thực sự là khối lượng công việc, hay là lý do nhiều hơn để làm với văn hóa hoặc kỳ vọng?

Lý do khối lượng công việc có thể là

• Backlog cam kết quá lớn
• Lập trình viên hoặc chủ sở hữu sản phẩm là "mạ vàng" (làm cho các tính năng phức tạp hơn mức cần thiết)

Kỳ vọng có thể là

• Một số loại phần thưởng tài chính hoặc công nhận khi làm thêm giờ
• Nỗi sợ thất bại. Các lập trình viên sợ rằng họ sẽ trông xấu hoặc bị trừng phạt nếu không đáp ứng được thời hạn
• Các lập trình viên đang đánh giá thấp những tác động lâu dài có hại của việc làm thêm giờ.