Khi Agile gặp sự cố [đóng]

Tôi đang viết một khóa học Agile cho một số người mới mà chúng tôi đang ở trên tàu gần đây và tôi muốn thêm một câu chuyện cảnh báo để họ hiểu rằng Agile không có nghĩa cho tất cả các dự án.

Vấn đề của tôi là, vì bản chất của các dự án tôi làm việc với Agile đã hoạt động khá tốt cho đến nay, tôi không thể chỉ ra một cách trung thực những gì có thể sai và tại sao khi bạn sử dụng sai loại dự án.

Những điều cần chú ý khi một dự án Agile gặp trục trặc là gì?

Thất bại lớn nhất với các đội "Agile" là kết quả của thứ được gọi là Vận chuyển hàng hóa . Về cơ bản, các đội muốn có hiệu ứng của các đội nhanh nhẹn thành công để họ bắt chước các hành động trực quan

• Standups hàng ngày (chạy trong một giờ hoặc lâu hơn)
• Phá vỡ công việc thành nước rút
• Câu chuyện của người dùng (thường ít hơn một câu nhưng ước tính được dự kiến)

Đó là ba thứ mà bạn sẽ thấy "được áp dụng" một cách nhất quán trong các môi trường này nhưng rất ít cam kết thực sự nhanh nhẹn. Trong thực tế, bạn sẽ nghe quản lý nói rằng chúng tôi "làm việc nhanh nhẹn". (Chạy đi với hai từ đó là một dấu hiệu xấu.)

Bạn cũng sẽ nghe nhiều về nợ kỹ thuật nhưng định nghĩa về nợ kỹ thuật của họ là "làm nhanh và bẩn và có thể chúng ta sẽ xoay quanh để làm cho nó tốt hơn sau này". (Dịch: chúng tôi sẽ làm cho nó có vẻ như chúng tôi quan tâm đến khả năng bảo trì nhưng thực tế chúng tôi sẽ giữ nguyên tâm lý phòng nồi hơi vì đó là những gì làm việc cho chúng tôi trong quá khứ).

Các cụm từ chính khác: "Tôi biết những câu chuyện này không được xác định đầy đủ nhưng chúng tôi đang làm rất nhanh để chúng tôi có thể khắc phục chúng khi chúng tôi đi."

"Chúng tôi đang phát triển nhanh để bạn có thể nhận được những gì tôi cần trong giai đoạn nước rút khi tôi xác định nó."

"Chúng tôi không thể khóa các câu chuyện đã cam kết của chúng tôi khi bắt đầu nước rút vì nhu cầu tiếp tục thay đổi giữa giai đoạn nước rút."

Chỉ số chính về việc một dự án Agile sẽ thành công là nếu người lãnh đạo dự án (chủ scrum hoặc bất kỳ vai trò nào) đã có kinh nghiệm hoặc đào tạo chính thức về lãnh đạo một dự án nhanh. Rất thường xuyên, tôi đã thấy mọi người đọc về Agile trong một cuốn sách hoặc tham gia một khóa học hai ngày về việc trở thành một bậc thầy scrum và nghĩ rằng họ đã có những khúc mắc để thực hiện thành công nó. Xin lỗi nó không xảy ra đội trưởng.

Những người không hiểu Agile là gì (là?) Tất cả về và áp dụng nó vào:

• khách hàng không có bình luận cho đến thời hạn
  ... và đe dọa hành động pháp lý sau đó;

• các nhà quản lý khiến các nhà phát triển tránh xa khách hàng , (có lẽ vì họ bị trả lương thấp và có thể nhảy tàu, làm việc cho khách hàng nói trên) và chơi một trò chơi " điện thoại bị hỏng " trong một nỗ lực tuyệt vọng (thường thành công) nhìn bận rộn và hữu ích,

  Xem thêm: quản lý nấm , còn gọi là "che khuất, cho ăn phân chuồng" và những ông chủ có mái tóc nhọn . :)

• những đội quá lớn để đi bất cứ đâu;

• công ty đang giữ trên bảng lương của họ một lần nổi tiếng nhà thiết kế kiến trúc hệ thống được một cách tuyệt vọng chuyển hướng sự chú ý từ thực tế, họ hoàn toàn mất phương hướng về nghề mã hóa thực tế, bởi overdesigning tuyệt vời, không thực tế, khó nhận ra, UML familias Sagrada .

Agile không phù hợp với các hợp đồng có thời hạn hoặc giá cố định. Khi bạn đã đăng ký cho một con thú như vậy, bạn phải cung cấp. Agile rất giỏi trong việc tiếp tục phát triển mãi mãi, khi khách hàng thay đổi quyết định và 'làm rõ' các yêu cầu của họ. Điều đó không giúp bạn vào ngày hết tiền, nhưng vẫn phải hoàn thành công việc.

Agile rất tốt cho giai đoạn hậu dự án khi bạn đang thực hiện các bản cập nhật gia tăng và sửa lỗi.

Khía cạnh khác mà Agile thất bại không phải là lỗi của Agile, đó là lỗi của những người khăng khăng với tất cả những thứ cũ như tài liệu dự án đầy đủ, thiết kế trước và đường truyền thông kém. (Bản tuyên ngôn nhanh nhẹn một nửa ).

Dưới đây là một vài câu hỏi có thể hữu ích để tìm câu trả lời về mặt tìm kiếm một ví dụ trong đó nỗ lực tại Agile có thể trở nên kém:

• Agile có phải là quản lý vi mô mới không?
• Quy trình Agile: làm thế nào và những gì cần được ghi lại?
• Kết hợp đúng kế hoạch và lập trình cho một dự án mới

Bạn đã bao giờ nghe nói về "giả Agile" chưa? Dưới đây là một vài mục blog về nó:

• Từ Pseudo-Agile đến Waterfall - Con đường của một công ty phần mềm nhỏ và mới
• Giả nhanh nhẹn!

Có một điều gì đó để nói cho các công ty có thể có quan điểm riêng của họ về Agile là gì và bán nó thành một thứ khác.

Tôi đã làm việc trong một nhóm Agile rất thành công, cũng như một vài người đã cố gắng Agile, nhưng không thể làm cho nó hoạt động được.

Người thành công có các yếu tố sau:

• Yêu cầu thực sự "nhanh nhẹn". Có những câu chuyện của người dùng và chúng tôi đã mã hóa chúng.
• Chủ sở hữu sản phẩm có sẵn. Nếu một câu chuyện người dùng mà tôi đã mã hóa chưa hoàn chỉnh, tôi có thể dễ dàng đi đến chủ sở hữu sản phẩm, hỏi anh ta những gì nên có, thêm nó và hoàn thành mã.
• Cam kết về quy trình và nhận ra rằng đó là một đường cong học tập.
• Đội tập trung.
• Các nhà quản lý đã biết và hiểu cách Agile làm những việc đã cam kết làm cho nó hoạt động.

Nhóm thành công đã làm Agile, và làm điều đó thực sự tốt. Tôi nghĩ rằng nếu bạn không có bất kỳ điểm nào ở trên, bạn có thể thất bại khá dễ dàng. Điều đầu tiên và thứ hai song hành với nhau, và nếu bạn không có điều đó, thì Agile sẽ không hoạt động.

Đội tôi tham gia mà Agile không làm tốt cũng có một vài yếu tố:

• Thiếu sự cam kết từ ban quản lý. Ban quản lý đã không tin vào triết lý này và do dự không cam kết.
• Yêu cầu tài liệu ở những nơi khác ngoài câu chuyện của người dùng. Xem ở trên về cam kết quản lý. Ngoài ra, chúng tôi đã có các nhà phân tích yêu cầu được trả lương cao và các công cụ yêu cầu đắt tiền lớn mà ai đó cần để biện minh cho việc sử dụng.

Tôi sẽ thêm vào những câu trả lời tuyệt vời đã được đăng tải rằng, theo kinh nghiệm của tôi, Scrum nhanh nhẹn và cụ thể sẽ chỉ hoạt động nếu đội ngũ quản lý VÀ sẵn sàng đưa ra nhiều tầm nhìn về những gì đang diễn ra.

Điều này có nghĩa là trong các công ty đại chúng (ví dụ chính phủ), sẽ rất khó để làm cho nó hoạt động đúng.

Agile theo tôi là tất cả về văn hóa của đội đang luyện tập. Nếu văn hóa tệ, các thành viên trong nhóm không hòa đồng và mọi người không hợp tác để đáp ứng các ủy ban nước rút thì văn hóa hoặc nhóm bị thiếu.

Tuy nhiên, tôi không nhất thiết phải nói rằng Thác nước sẽ nhất thiết phải hoạt động trong một môi trường như vậy, đó không phải là một tình huống đen trắng, rất ít thực sự là đen và trắng.

Một nhóm Agile tốt là cộng đồng. Họ có một tinh thần cộng đồng bộ lạc nơi tất cả các thành viên đang làm việc hướng tới cùng một mục tiêu. Nhóm thành công hoặc thất bại cùng nhau. Họ cùng nhau giải quyết vấn đề. Một thành viên trong nhóm sẽ ngăn chặn những gì anh ta đang làm với nhiệm vụ của mình để giúp đỡ một thành viên trong nhóm đang gặp khó khăn. Tất cả mọi thứ là chìm hoặc bơi.

Khi đây không phải là trường hợp sau đó nó nhanh chóng trở nên rõ ràng những gì sai. Nếu các thành viên trong nhóm đang ngồi xuống, gõ máy tính xách tay của họ hoặc nhắn tin hoặc khoanh vùng trong lúc đứng lên hàng ngày thì bạn không có một nhóm Agile tốt. Nếu các nhà quản lý dự án của bạn đang thực thi tất cả các quy trình, định nghĩa và thuật ngữ Scrum nhưng mọi người chỉ giữ nhịp và trả tiền cho dịch vụ môi, thì đây chỉ là một trò hề khá trắng trợn về Agile thực sự là gì, và điều này theo nhiều cách dẫn đến rối loạn chức năng nhóm, không hiệu quả , bỏ lỡ thời hạn và các dự án thất bại.

Thất bại Agile về nhiều mặt còn tệ hơn cả một nhóm Waterfall thành công vừa phải và có thể có tỷ lệ thành công dự án thấp hơn.

Tôi không biết điều này từ kinh nghiệm cá nhân, nhưng theo giả thuyết, có nhiều trường hợp khi nhanh nhẹn không phải là lựa chọn tốt nhất.

• Các dự án có sản phẩm quan trọng về tính mạng hoặc tài sản - Ví dụ: bạn không muốn sử dụng nhanh để phát triển phần mềm chạy máy tạo nhịp tim. Tại sao? Bởi vì bạn có dung sai gần như bằng không đối với các lỗi. Hãy xem xét một ví dụ kinh điển về lỗi lập trình trong y học liên quan đến Therac 25 . Cấp, nó không được xây dựng với sự nhanh nhẹn, nhưng vấn đề là: Phát triển cuộc sống hoặc tài sản quan trọng không phải là nơi để nói, "chúng tôi sẽ làm sạch điều đó trong lần chạy nước rút tiếp theo" hoặc "chúng tôi không cần tuyệt vời, chỉ là tốt đủ."

• Các dự án có quá nhiều nhà phát triển cơ sở - Agile mong đợi một sự tự chủ nhất định trong nhóm tham gia. Nếu không có đủ kinh nghiệm trong nhóm, thì quyền tự chủ đó có thể chống lại bạn.

• Các dự án đòi hỏi mức độ kiểm soát hoặc lập kế hoạch cao hơn so với những gì được cung cấp theo truyền thống với Agile.

Tôi giả sử ai đó sẽ nhảy vào và giúp đỡ với những ví dụ tốt hơn, hoặc hạ thấp phần nhỏ này của tôi đã viết ;-).

Chỉ cần nhớ rằng khi công cụ duy nhất bạn có là một cái búa, mọi vấn đề trông giống như một cái đinh. Không phải tất cả các dự án là móng tay.