Có giới hạn cam kết trong Scrum dẫn đến sự tự mãn?


8

Trong tổ chức của tôi, các nhóm Scrum gần như không bao giờ hoàn thành tất cả các câu chuyện của mình 100%. Tôi đã đề nghị rằng chúng tôi cam kết ít câu chuyện hơn mỗi Sprint, nhưng người quản lý R & D nói rằng nếu chúng tôi làm điều đó mọi người sẽ vẫn không hoàn thành công việc, nhưng sẽ làm ít hơn vì vậy làm chậm sự phát triển. Ông nói rằng có một Hội chứng sinh viên đang làm việc ở đây.

Bạn đang làm gì trên đó?


Hội chứng học sinh là gì? Họ bỏ cuộc và chờ giáo viên cho họ câu trả lời?
JeffO

@JeffO Hội chứng sinh viên là tên gọi khi mọi người nhìn vào một nhiệm vụ, xác định họ sẽ mất bao lâu (hoặc họ được bảo họ phải làm việc với nó trong bao lâu), và sau đó bắt đầu làm việc vào phút cuối có thể hoàn thành nó đúng hạn Trong lập kế hoạch dự án, đây là vấn đề nếu có bộ đệm được xây dựng trong lịch trình để giải quyết các vấn đề có thể phát sinh trong nhiệm vụ.
Thomas Owens

Xem thêm Luật Parkinson. vi.wikipedia.org/wiki/Parkinson's_law
pdr

Có phải họ thiếu những câu chuyện trên mỗi lần chạy nước rút?
JeffO

Hầu hết các Sprint họ đều bỏ lỡ một câu chuyện hoàn toàn, nhưng trong tất cả các Sprint họ không làm tất cả các câu chuyện 100%.
Eugene

Câu trả lời:


17

Người quản lý của bạn cần hiểu rằng Hội chứng Sinh viên / Luật Parkinson trở thành một vấn đề lớn hơn đáng kể khi không có hy vọng đạt được mục tiêu. Đột nhiên thời gian có sẵn để hoàn thành một nhiệm vụ là vô hạn. Như một đồng nghiệp cũ của tôi đã từng nói, "Hạn chót chỉ là những thứ đi qua đây. Chúng tôi nhớ họ, họ được chuyển trở lại, chúng tôi lại nhớ họ."

Và đó hoàn toàn là kết quả của thời hạn không hợp lý ngay từ đầu. Những người này không tự nhiên lười biếng, họ chỉ thấy không có hy vọng đánh trúng mục tiêu và không có hậu quả của việc không bắn trúng nó, vậy tại sao phải lo lắng về điều đó?

Quan điểm của tôi là người quản lý của bạn có thể đúng. Nhưng anh ta cần phải hiểu rằng anh ta đang tạo ra vấn đề.

Khi một nhóm thực hiện tốt kế hoạch chạy nước rút, họ bắt đầu làm việc như một nhóm để đạt được thời hạn. Bất kỳ ai cũng không giảm cân, họ thất bại như một đội. Nếu điều đó xảy ra liên tục, nhóm giao dịch với người đó.

Có khả năng bạn sẽ cắt giảm vận tốc quá nhiều và đạt được ít hơn bạn có thể có. Nhưng bạn sẽ thành công. Cảm giác trong đội sẽ tích cực. Ai đó có khả năng nói "Thành thật mà nói, tôi nghĩ rằng chúng ta có thể đạt được một vài điểm nữa trong lần chạy nước rút tiếp theo."

Cuối cùng, bạn sẽ tìm thấy điểm cân bằng của mình và bắt đầu dự đoán chính xác số lượng công việc bạn thực sự có thể đạt được trong một lần lặp.


2

Ai quan tâm? Không phải chủ sở hữu sản phẩm sẽ hỏi phần còn lại của các tính năng của tôi ở đâu?

Bạn có thể cần phải giới hạn độ dài nước rút của bạn. Cách này tiến bộ hơn phải được hiển thị cùng với cách. Sử dụng phản hồi về những gì đang được thực hiện để xác định bao nhiêu có thể được thực hiện trong các lần chạy nước rút tiếp theo.

Bạn không thể có khung thời gian cố định cho dự án và danh sách cửa hàng / tính năng cố định mà không phân bổ đủ tài nguyên. Nếu có một ngày đáo hạn cố định, bạn có thể không hoàn thành tất cả các câu chuyện. Bạn muốn cắt ra một số câu chuyện? Những cái nào? Bạn có thể thực sự xác định rằng lúc đầu? Hy vọng, nếu bạn ưu tiên đúng, chủ sở hữu sản phẩm sẽ nhận được những gì quan trọng nhất. Đó là ưu tiên của họ sau tất cả.

Người quản lý đang chơi trò chơi trí tuệ. Nếu bạn là một đứa trẻ muốn một con chó, hãy yêu cầu một con ngựa.


2

Trong tổ chức của tôi, các nhóm Scrum gần như không bao giờ hoàn thành tất cả các câu chuyện của mình 100%. Tôi đã đề nghị rằng chúng tôi cam kết ít câu chuyện hơn mỗi Sprint, nhưng người quản lý R & D nói rằng nếu chúng tôi làm điều đó mọi người sẽ vẫn không hoàn thành công việc, nhưng sẽ làm ít hơn vì vậy làm chậm sự phát triển. Ông nói rằng có một Hội chứng sinh viên đang làm việc ở đây.

Từ kinh nghiệm hạn chế của tôi với [những gì đặt ra] Agile, tôi không ngạc nhiên. Tất cả mọi thứ tôi đã đọc về Agile cho thấy rằng mọi người cần có tổ chức hơn nhiều so với kỹ thuật phát triển khác, nhưng cũng giống như bạn, tôi thấy rất ít, nếu có, bằng chứng về nó.

Ước tính Điểm Câu chuyện không phải là một môn khoa học chính xác, đặc biệt là trong các lĩnh vực "tiên tiến" như R & D. Có thể dễ dàng là các Nhà phát triển của bạn đang ước tính sai Điểm Điểm của họ (IME, thường đánh giá quá cao khả năng của chính họ) hoặc có thể có một số Điểm "mục tiêu" mà họ sẽ tạo ra trong mỗi Sprint (IMHO , một cách hoàn hảo để quản lý, đưa tôi đến ...).

Người quản lý của bạn cần nghiên cứu vấn đề này và tìm hiểu những gì không hoạt động. Trách nhiệm của họ là giao đồ cho khách hàng (hoặc đáng lẽ phải như vậy), và do đó, "cổ trên khối" của họ khi người dùng bắt đầu phàn nàn.
[hoài nghi] Tất nhiên là không , bởi vì họ có tất cả các khóa đào tạo / kỹ năng cần thiết để đảm bảo không ai đổ lỗi cho họ. [/ hoài nghi]

Và xúc phạm công nhân của họ, xây dựng thương hiệu cho họ bằng bất kỳ loại "hội chứng" nào, không bao giờ là hành vi có thể chấp nhận được - điều đó chỉ cho thấy sự thiếu cam kết của ban quản lý đối với Đội và mong muốn "xa cách" với họ.

Sự phát triển đang bị chậm lại, nhưng thực hiện công việc một cách chậm rãi và tận tâm hơn (nghĩa là thực sự làm cho công cụ hoạt động) là rất xa, tốt hơn nhiều so với việc không cung cấp bất cứ điều gì cả.


Làm thế nào để bạn ước tính sai khi sử dụng điểm câu chuyện?
Dave Hillier

Điểm câu chuyện là chủ quan cho một nhóm. Bạn không thể hơn, dưới hoặc ước tính sai chúng. "2" trong tâm trí tập thể của một đội có thể là "13" trong nhóm khác, ngay cả khi các đội trùng nhau! Đó là một biện pháp chống lại hiệu suất lịch sử của riêng bạn.
Heliac
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.