Bạn đã thấy sai lầm gì khi giới thiệu SCRUM?

Điểm thất bại duy nhất gặp phải khi công ty của bạn quyết định thay thế các quy trình hiện tại bằng SCRUM là gì?

Bạn có thể cho tôi một số ví dụ về những điều đã thực sự sai khi một công ty cố gắng giới thiệu SCRUM? Tôi muốn nghe những giai thoại của bạn, một vài điều bạn tự trải nghiệm, thất bại lớn mà bạn thấy sắp tới nhưng không thể ngăn chặn.

Tôi nghe thấy rất nhiều mối quan tâm về việc thiếu tài liệu về các quyết định về chi tiết thực hiện, và về quy mô câu chuyện và mức độ chi tiết của câu chuyện.

Vấn đề lớn nhất là sự hiểu lầm. Thất bại thường gặp là:

• Chỉ có một nhóm làm Scrum nhưng phần còn lại của công ty (bao gồm bán hàng, quản lý, nhân sự) vẫn nghĩ theo cách cũ. Ví dụ:

  Tương tác liên tục với sự tham gia của khách hàng và khách hàng là rất quan trọng.

  Nhân sự phải hiểu rằng hiệu suất nhóm quan trọng hơn hiệu suất của các cá nhân. KPI phải thay đổi điều đó.

  Định nghĩa tính năng là quá trình liên tục. Định nghĩa dự án sẽ phát triển trong quá trình phát triển bởi phản hồi của khách hàng. Do thời hạn dự án đó, ngân sách yêu cầu hoặc bộ tính năng kết quả có thể thay đổi (sau khi được các bên liên quan chấp thuận).

  Thay đổi là một phần của quá trình.

  Ước tính là quá trình liên tục, bạn không thể nói khi bắt đầu dự án rằng bạn sẽ được thực hiện với tất cả các tính năng (nhiều trong số chúng chưa biết lúc đầu) trong vòng 5 tháng.

  Đội ngũ được trao quyền để đưa ra quyết định. Nhóm thực hiện cam kết về số lượng tính năng được phân phối trong lần chạy nước rút tiếp theo. Điều này không thể được yêu cầu hoặc chỉ huy.

  Sprint là vùng an toàn cho đội. Khi nhóm cam kết với một số câu chuyện người dùng đã xác định, cam kết không thể được sửa đổi bên ngoài nhóm.

  Một phần của cấu trúc tổ chức cũ không có ý nghĩa khi chuyển sang Scrum. Scrum xác định ba vai trò: Scrum master, Chủ sở hữu sản phẩm, nhóm. Có các vai trò khác nhưng ba vai trò này thường đủ để cung cấp ứng dụng. Ý nghĩa thông thường là có Scrum master, trưởng nhóm, chủ sở hữu sản phẩm và một hoặc nhiều người quản lý dự án. Quản lý dự án và trưởng nhóm là những vai trò dư thừa trong Scrum.

• Guy giao Scrum master vai trò không làm Scrum master. Scrum master giải quyết các trở ngại. Bất cứ điều gì làm phiền nhóm là trở ngại phải được giải quyết càng sớm càng tốt. Thất bại phổ biến nhất là gán vai trò này cho nhà phát triển mà không có bất kỳ kinh nghiệm nào trước đây với Scrum. Vai trò này một phần thay thế người quản lý dự án chung nhưng Scrum master không có quyền lực đối với nhóm và Scrum master không yêu cầu bất kỳ tính năng nào được triển khai. Scrum master bảo vệ nhóm thậm chí chống lại chủ sở hữu Sản phẩm với các yêu cầu không thể thực hiện được.

• Guy được giao vai trò chủ sở hữu sản phẩm không làm chủ sở hữu sản phẩm. Chủ sở hữu sản phẩm có trách nhiệm tài chính cho sản phẩm. Nó rất cụ thể và là một vai trò quan trọng để thành công. Vai trò này có điểm chung với phân tích, quản lý dự án và quản lý sản phẩm. Chủ sở hữu sản phẩm thu thập và duy trì các yêu cầu (thường ở dạng câu chuyện của người dùng). Trách nhiệm của anh là cung cấp thông tin cho nhóm và xác định mức độ ưu tiên của các câu chuyện của người dùng. Anh ta nên có mặt tại chỗ với đội vì sự hợp tác giữa PO và nhóm là liên tục.
• Thay đổi tên quy trình thành Scrum nhưng để lại hầu hết quy trình như cách cũ. Kịch bản phổ biến nhất là bạn sẽ thay đổi từ thác nước sang Scrum và thay đổi quan trọng nhất là bạn không thực hiện phân tích và tài liệu nữa và bạn nói rằng bạn là Scrum.
• Yêu cầu / câu chuyện người dùng bị thiếu định nghĩa thực hiện - rất phổ biến. Nếu bạn không có định nghĩa về việc thực hiện (tiêu chí chấp nhận), bạn không thể đưa ra bất kỳ giả định nào về sự phức tạp của câu chuyện người dùng trong quá trình lập kế hoạch nước rút. Nếu bạn không có chúng trong khi chạy nước rút, bạn không thể đánh dấu câu chuyện của người dùng là đã hoàn thành vì bạn không thể xác thực nó.
• Chất lượng được coi là tùy chọn. Chất lượng trong Scrum là công dân hạng nhất. Chúng tôi có thể nói rằng mỗi tiêu chí chấp nhận nên được bao phủ bởi thử nghiệm đầu cuối tự động. Khi bạn bắt đầu giảm chất lượng và thêm các tính năng chưa được kiểm tra, bạn sẽ mất quyền kiểm soát sản phẩm vì các tính năng được coi là hoàn thành có thể ngừng hoạt động bất cứ lúc nào do hồi quy.
• Kết quả của lần chạy nước rút phải là mức tăng có thể chuyển được (= làm việc và được kiểm tra) cho sản phẩm.

Chỉnh sửa:

Tôi đang thêm ghi chú quan trọng. Khi sử dụng phương pháp nhanh, điểm chính là cung cấp lượng giá trị doanh nghiệp cao nhất cho khách hàng nhanh nhất có thể. Nhưng khách hàng (đại diện bởi Chủ sở hữu sản phẩm) mô tả giá trị doanh nghiệp là gì. Vì vậy, nói chung không đúng khi bạn không có phân tích hoặc tài liệu khi sử dụng Scrum. Nếu khách hàng yêu cầu phân tích hoặc tài liệu và đánh dấu nó là giá trị kinh doanh (ví dụ vì dự án quy mô lớn hoặc dài hạn cần được cải thiện trong vài năm tới), bạn cũng sẽ tạo ra nó. Cách tiếp cận cơ bản nhất là bao gồm phân tích và tài liệu trong các tiêu chí chấp nhận cho các câu chuyện của người dùng. Phân tích trong trường hợp như vậy là tài liệu giao tiếp với chủ sở hữu sản phẩm theo một cách tiêu chuẩn hóa.

Vấn đề lớn nhất tôi nhận thấy trong hơn 10 năm xp và scrum, là khi các đội chưa hoàn toàn "nhanh nhẹn", quyết định "linh hoạt về nhanh nhẹn" và bắt đầu tùy chỉnh nó, bỏ một số phần, v.v. một sự hiểu biết rõ ràng về những gì mỗi phần làm và tại sao nó ở đó.

Lúc đầu, tôi đã thấy các đội thành công hơn với scrum khi họ làm mọi thứ bằng cuốn sách, hơn là các đội thay đổi những gì họ chưa "có được".

Đó là khi bạn nhận được những thứ như "lần chạy nước rút đầu tiên, chúng tôi sẽ thực hiện tất cả các yêu cầu. Lần chạy nước rút thứ hai tất cả các thiết kế, v.v., lần chạy nước rút cuối cùng trong tất cả các thử nghiệm". Còn được gọi là thác nước. Hoặc thậm chí những điều đơn giản như "dù sao đi nữa, những gì với doanh nghiệp nổi bật này?".

Một cái gì đó để làm với Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

Vấn đề lớn nhất là luôn luôn mua. Nếu bất kỳ nhóm hoặc cá nhân quan trọng nào không mua (quản lý dự án, QA, phát triển, v.v.) thì thất bại gần như được đảm bảo.

Một vấn đề khác có liên quan là thực sự làm cho tất cả mọi người tham gia nhận thức được scrum thực sự là gì và không phải là gì.

Tôi đã thấy các môi trường nơi quản lý dự án thực sự coi đây là một tấm vé đến trực tiếp với các nhà phát triển với những thay đổi và hy vọng nó sẽ được thực hiện vào ngày mai, vì chúng tôi đang sử dụng quy trình mới tuyệt vời. Bất cứ ai đã ở trong tình huống này hoặc trong những nỗ lực thất bại khác trong việc thực hiện Scrum và có vị đắng trong miệng. Những người này đôi khi cũng sẽ cố gắng khử đường sắt của dự án.

Một vấn đề khác tôi đã thấy là đứng lên các cuộc họp. Bạn sẽ luôn khiến anh chàng muốn ngồi xuống trong một cuộc họp thường trực .... "Tôi đã bị đau lưng" hoặc bất cứ điều gì. Dường như luôn luôn là một anh chàng không biết mục tiêu đằng sau sự nổi bật là gì và sẽ không im lặng về chính trị hay những gì anh ta đã làm vào cuối tuần đó. Đứng lên các cuộc họp, tôi đã tìm thấy, là chìa khóa để giao tiếp hiệu quả. Điều quan trọng là không để ai đầu độc những cuộc họp này.

Cố gắng thực hiện tất cả các phân tích cho mã mà chúng tôi đã phát triển trong cùng một lần chạy nước rút, chúng tôi thực sự đang mã hóa nó.

Chúng tôi đã chuyển đến scrum một thời gian trước đây và thẳng thắn quản lý điều hành nó đã coi mỗi scrum là một quá trình thác nước kéo dài 2 tuần. Có một sự tuân thủ các quy tắc của scrum đã trở thành một quá trình trong chính nó!

Đây là vấn đề tôi tìm thấy, tất cả các phương pháp nhanh nên là về sự linh hoạt để làm việc hiệu quả theo cách làm việc cho bạn. Không phải là cách được quy định bởi các quy trình. Ví dụ: chúng tôi có 2 tuần scrum và một nhóm cho biết họ cảm thấy 2 tuần không đủ để làm việc tốt (không phải với thời gian chết do kết thúc bản demo scrum và đánh giá yêu cầu ban đầu) nên họ muốn đi đến 3 tuần. Sốc kinh hoàng! Ban quản lý đã từ chối vì họ đã quyết định 2 tuần cho mỗi scrum là lý tưởng và điều này hiện đã được ghi nhận trong các quy trình chất lượng.

Scrum là phương pháp nhanh nhất trong các phương thức nhanh, có lẽ đó là lý do tại sao nó rất phổ biến - dễ bán hơn cho người bảo vệ cũ. bạn có nghĩa vụ phải loại bỏ những thứ bạn không thích, nhưng tôi không nghĩ điều đó xảy ra. Lời khuyên của tôi là đi với một quy tắc linh hoạt hơn, ít dựa trên một quy tắc và thêm các quy tắc mà bạn cần thay thế. Tôi thích Crystal vì điều này.

Cuối cùng, chỉ cần nhớ bản tuyên ngôn nhanh nhẹn một nửa .

Vấn đề lớn nhất là khách hàng của bạn cũng cần chấp nhận quy trình SCRUM và trở nên nhanh nhẹn. Hầu hết các khách hàng muốn nghe điều này khi bắt đầu dự án:

• Nó sẽ tốn bao nhiêu tiền
• Nó sẽ trông như thế nào
• Khi nào xong

Nghe có vẻ hợp lý, nhưng nó hoàn toàn không tương thích với nhanh nhẹn. Bạn cần giải thích cho khách hàng của mình tại sao nhanh nhẹn tốt cho anh ta thay vì thác nước.

Chúng tôi đã có hai vấn đề lớn trong lần đầu tiên của tôi tại SCRUM:

1) Chúng tôi không thực sự có chủ sở hữu sản phẩm. Ông chủ của chúng tôi đã phải đóng vai trò bởi vì không ai là chủ sở hữu sản phẩm sẽ đồng ý làm như vậy. Kiểu này khiến mọi thứ trở nên khó khăn vì anh không thực sự biết câu trả lời.

2) Chúng tôi rất tệ trong việc hạch toán các thành phần bên ngoài. Một vài lần chạy nước rút đầu tiên của chúng tôi liên quan đến việc kiểm tra và chạy hoàn toàn tự động, và chúng tôi liên tục gặp rắc rối khi tự động hóa các trình giả lập mà chúng tôi đang sử dụng. Bằng cách nào đó chúng ta không bao giờ có thể tốt hơn khi nhận ra rằng điều này sẽ xảy ra.

Vấn đề chính tôi gặp phải trong dự án của mình là việc thu thập yêu cầu diễn ra sau khi chúng tôi ước tính cho lần chạy nước rút tiếp theo. Chúng tôi ước tính dựa trên các tiêu chí chấp nhận. Trong quá trình thu thập yêu cầu, chúng tôi thấy rằng AC tinh chỉnh lớn hơn rất nhiều vì vậy nhiệm vụ được ước tính trong 8 giờ thực sự là 24 giờ! Vì vậy, tôi có thể thay đổi tồn đọng nước rút của tôi và sửa đổi các ước tính adn giảm câu chuyện của tôi? Không, thưa ngài! Yêu cầu nhanh nhẹn mà bạn không thể thay đổi tồn đọng nước rút! Đó là những gì TL của tôi nói. Vì vậy, tôi cũng không nên mã hóa theo tiêu chí chấp nhận ban đầu mà tôi đã ước tính thời gian là 8 giờ! Thượng Đế! Không! Bạn không thể làm điều đó! Đó sẽ không phải là Agile, phải không!