Bạn cần gì để thành công với Agile?

Việc áp dụng Agile có thể thất bại ở một số tổ chức, tôi thậm chí đã làm việc cho một công ty nơi thác nước là cách duy nhất (đúng) nhưng chỉ vì họ đã thử Agile trong một dự án và thất bại.

Khi tôi hỏi những người vẫn còn nhớ rằng (tôi là một thiếu niên) tôi đã im lặng, giống như tôi đang nhắc nhở họ một cơn ác mộng tồi tệ đã thực sự xảy ra.

Tôi không biết tại sao dự án thất bại. Có các tài nguyên được tìm thấy trên web tại sao Agile thất bại là một số công ty nhưng lý do chủ yếu là kinh tế. Vì vậy, tôi nghĩ rằng tôi yêu cầu ở đây trước một số thông tin phản hồi.

Các lý do áp dụng Agile thất bại trong một số tổ chức là gì? Hoặc, một cách khác để đặt nó .. Bạn cần gì để thành công với Agile?

Bạn cần quản lý, khách hàng và nhà phát triển để hiểu và hỗ trợ cách suy nghĩ Agile và phương pháp Agile. Chi tiết hơn:

• Ban quản lý phải thoải mái khi nghe sự thật, trái ngược với những gì họ thường nghe thấy (nghĩa là "vâng, dự án đang đi đúng hướng" trong 11 tháng ... rồi đột nhiên "rất tiếc, chúng tôi cần trì hoãn thời hạn vài tuần ... erm, tháng ... erm ... "cuối cùng). Họ cũng phải thoải mái khi để mỗi bên làm (và chịu trách nhiệm) công việc của họ. Nổi bật nhất là các nhà phát triển phải đưa ra các quyết định và ước tính kỹ thuật. Vì vậy, không kiểm soát chặt chẽ và quản lý vi mô.
• Khách hàng phải hiểu rằng Agile đòi hỏi sự tham gia sâu sắc và liên tục của họ vào quá trình phát triển, không chỉ là "đặt hàng", sau đó nhận giao hàng vài tháng sau đó. Họ cũng phải cảm thấy thoải mái khi thiếu một Đặc tả yêu cầu cố định lớn và sự thiếu cam kết rõ ràng từ nhóm phát triển để cung cấp những gì họ được yêu cầu ban đầu.
• Các nhà phát triển phải thoải mái với việc chịu trách nhiệm, đưa ra quyết định, giao tiếp cởi mở và làm việc theo nhóm. Tức là không có "quyền sở hữu mã", không có "cao bồi cô đơn" và không đổ lỗi cho người khác về những vấn đề có thể được giải quyết bởi chính đội.

Theo kinh nghiệm của tôi, đó là điểm đầu tiên thường nằm sau các dự án Agile thất bại, nhưng hai điểm còn lại cũng có thể gây ra vấn đề.

Cập nhật

"Quản lý" tôi không chỉ có nghĩa là người quản lý dự án trực tiếp, mà cả các cấp cao hơn. Như @Michael lưu ý rất đúng, một số bên ngoài hoặc ít hơn (ví dụ QA hoặc người chuyển nhượng nhiệm vụ bên ngoài) cũng có thể ảnh hưởng đến thành công / thất bại của các dự án Agile, nhưng tôi cho rằng chỉ có thể có thể nếu nhà lãnh đạo tương ứng của họ cho phép họ và / hoặc nếu trách nhiệm và dòng lệnh không rõ ràng trong tổ chức.

Bạn cần:

• Những người sẵn sàng rất cởi mở và trung thực . Tầm nhìn là tất cả mọi thứ bởi vì bạn cần sự tin tưởng trên tất cả các loại ranh giới lớp.
• Khách hàng và người quản lý thực sự muốn nghe sự thật.
• Những người sẵn sàng và có thể xác định lại vai trò của họ cho phù hợp với những gì cần thiết ngay bây giờ .
• Tự do thay đổi các quy trình không hoạt động ngay bây giờ .
• Những người sẵn sàng thừa nhận sai lầm và đảo ngược chúng .
• Khả năng kết hợp xây dựng và kiểm tra môi trường theo ý muốn . (Điều này quan trọng hơn và đắt hơn so với tín dụng của mọi người.)
• Nhiều bảng trắng như bạn có thể lấp đầy các bức tường của bạn với.

Có vẻ đơn giản, nhưng rất nhiều trong số đó là những câu hỏi lớn trong ngành này.

Một dự án nhanh thường sẽ thất bại khi một người chơi chính từ chối nhanh nhẹn, hoặc (tệ hơn) khi ai đó không thực sự quan tâm đến thành công của dự án hoặc phá hoại hoàn toàn dự án. Cái sau có thể giết chết bất kỳ dự án nào (như một số thứ khác), nhưng các quy trình nhanh nhẹn giúp mọi người linh hoạt hơn, và điều đó bao gồm sự linh hoạt để chơi chính trị phá hoại.

Ví dụ:

• QA khẳng định rằng khách hàng không thể xem phần mềm trừ khi nó đã qua chu kỳ kiểm tra thủ công kéo dài một tháng
• Quản lý áp đặt thời hạn không thực tế
• Khách hàng từ chối ưu tiên các yêu cầu (" tất cả đều có mức ưu tiên cao nhất!")
• Một người không phải là một bên liên quan ngay lập tức nhưng có đầu mối chính trị liên tục giao các nhiệm vụ dài dòng, không liên quan cho một thành viên chủ chốt và người quản lý dự án không thể ngăn chặn điều này.

Tôi chỉ có thể đưa ra lời khuyên từ kinh nghiệm cá nhân của riêng tôi.

Một nhà tuyển dụng tôi đã hoàn toàn thất bại tại Agile. Công việc được thực hiện trên cơ sở đặc biệt, thử nghiệm là không tồn tại và các yêu cầu được ghi lại trong email và biên bản cuộc họp. Phương pháp phát triển duy nhất được sử dụng là vô chính phủ, hoặc 'mã hóa và quên'. Việc thực hiện một số loại phương pháp kỹ thuật phần mềm sẽ là không thể vì các nhà phát triển đã làm việc quá sức để thiết lập một số loại phần mềm quản lý dự án theo dõi câu chuyện.

Tại một chủ nhân khác, nhóm của chúng tôi có một thành viên anh hùng đã cố gắng thiết lập một số thực tiễn tốt nhất về Agile - chúng tôi có một bảng Kanban, theo dõi vấn đề, chúng tôi đã sử dụng TDD và BDD (trong khi không phải là Agile, họ có xu hướng hiện diện trong các nhóm Agile) . Thật không may, chúng tôi thiếu những thứ như điểm câu chuyện, phiên ước tính, lập kế hoạch năng lực, biểu đồ chi tiết, biểu đồ vận tốc - loại công cụ quản lý dự án Agile hữu ích cho phép công việc trôi chảy. Như một triệu chứng kinh điển của Agile gặp trục trặc, khi bảng Kanban của chúng tôi quá đầy, chúng tôi đã mua một bảng lớn hơn: /

Nơi tôi hiện đang sử dụng các điểm câu chuyện như một cách lập kế hoạch năng lực với các vòng lặp hai tuần, TDD, các cảnh báo hàng ngày, các lần hồi tưởng theo thời gian lặp lại và lập trình cặp trên hầu hết mọi thứ. Đây là kết quả của tổng số quản lý mua và quản lý khách hàng.

Nó nghĩ rằng để Agile thành công tại một công ty, bạn cần có những điều sau đây:

• Người quản lý dự án hiểu Agile và người sẽ sử dụng các công cụ phù hợp.
• Các nhà phát triển hiểu Agile, cởi mở và trung thực, với kỷ luật Agile yêu cầu
• Mua từ khách hàng. Họ cần nhận ra lợi ích của Agile và sẵn sàng lắng nghe lời khuyên từ các nhà phát triển của họ liên quan đến những gì có thể được phát triển trong một khung thời gian nhất định.

EDIT: Điều quan trọng nữa là đảm bảo bạn hiểu rõ về - những thứ như đứng lên hàng ngày và lặp đi lặp lại ngắn đều hữu ích.

Kinh nghiệm của tôi với thất bại Agile không liên quan gì đến kinh tế mà là với chính trị doanh nghiệp / phòng ban / cá nhân.

Ở cấp độ cá nhân, đơn giản là một số người mà tính cách của họ sẽ đụng độ. Buộc họ vào một nhóm Agile, hoặc thậm chí tệ hơn là một nhóm lập trình được ghép nối, sẽ leo thang sự không thích nhau của họ đến điểm sôi. Điều này có thể trở nên rất khó chịu, rất nhanh chóng và dẫn đến những thứ như hành động phá hoại xứng đáng với một chương trình thực tế, biến các cuộc họp scrum thành một đội bắn súng tròn đổ lỗi hoặc thậm chí tệ hơn.

Trên đó, có quản lý phát triển. Tôi đã thấy điều này đi sai theo hai cách khác nhau.

Đầu tiên là "tôn sùng hàng hóa Agile" nơi người quản lý khăng khăng tuân theo bản tuyên ngôn và bất kỳ lớp / sách / trang web nào họ đọc chính xác mà không hiểu lý do tại sao và khi nào nên sử dụng chúng và khi nào nên ứng biến. Như thể người quản lý Agile đang chờ phép màu xảy ra bởi vì họ đang theo đúng câu thần chú. Việc triển khai Agile chần chừ này có thể dẫn đến một số vấn đề sẽ dẫn đến thất bại của dự án.

Cái còn lại là 'Agile In Name Only' trong đó các thuật ngữ như chạy nước rút và scrum được sử dụng nhưng thực sự chỉ là nhãn hiệu cho các hoạt động cũ như quản lý vi mô, không trung thực đi lên và xuống chuỗi lệnh, các cuộc họp trạng thái vô dụng kéo dài và các thứ khác như vậy . Các dự án thất bại giống như trước đây nhưng giờ Agile có thể đổ lỗi cho nó thay vì quản lý kém.

Trên đó là sự thiếu mua của khách hàng / khách hàng của dự án. Những người này sẽ có các ưu tiên bộ phận riêng và có thể chống lại việc hợp tác với nhóm phát triển trừ khi họ nói rõ rằng đó là một phần thiết yếu trong công việc của họ bởi ban quản lý của họ. Điều này có thể được làm tồi tệ hơn bởi chính trị bộ phận hoặc chính sách của công ty. Ví dụ, cả hoạt động và tiếp thị đều có đầu vào vào một dự án và nhóm của bạn cuối cùng quay vòng bánh xe vì hai bên không thể đồng ý về bất cứ điều gì. Một ví dụ khác là khi chính sách của công ty về quản lý thời gian và thanh toán gây ra xung đột. Tôi thực sự thấy rằng khách hàng bên ngoài dễ đối phó hơn so với khách hàng nội bộ. Họ thích sự chú ý mà họ nhận được từ quá trình và biết rằng họ đang nhận được giá trị tiền của họ.

IMO "Agile" thất bại khi không có hoạt động mua bán thực hành. Ý tôi là Agile dựa vào "khách hàng" (thường là bộ phận hoặc người quản lý khác) hiểu rằng:

1. Họ không biết 100% họ muốn phần mềm làm gì, ngay cả khi họ nghĩ họ làm
2. Họ không biết sẽ mất bao lâu để hoàn thành, ngay cả khi họ nghĩ rằng họ làm
3. Họ sẽ được cho biết sẽ mất bao lâu và phải chấp nhận hoặc giảm các tính năng để đáp ứng thời hạn
4. Họ sẽ phải chọn các tính năng cho mỗi lần lặp và sẽ không nhận được ứng dụng đầy đủ, hoàn thành 100% trong một lần chụp.

Tất cả những điều đó là những điều rất khó để hầu hết các nhà quản lý nuốt, và IMO là lý do số 1 tại sao Agile khó thực hiện - các nhà quản lý thường nói "Nó sẽ được thực hiện trước ngày x" và thực hiện "Kỳ diệu" vào ngày đó (sau khi các nhà phát triển thực hiện trong 80 giờ một tuần) và đó là 180 để nhận ra rằng nhóm phát triển sẽ nói với bạn rằng dự án này sẽ được thực hiện trong 3 tháng và lựa chọn duy nhất bạn có là chấp nhận hoặc giảm các yêu cầu để có được nó được thực hiện sớm hơn

Thứ hai, phải có sự tin tưởng vào đội ngũ phát triển. Đi đôi với số 1 ở trên, rất ít nhà quản lý thực sự có vẻ tin tưởng vào ý kiến ​​của những người được thuê làm chuyên gia; nếu một nhà phát triển nói rằng một dự án sẽ mất x lượng thời gian và x nhiều hơn quản lý nghĩ, thì đó không phải là trường hợp "Tôi không biết cách viết phần mềm, vì vậy nhà phát triển có lẽ đúng" hơn " Những nhà phát triển tốt chẳng vì điều gì muốn làm hỏng việc nên họ nói sẽ mất 3 tháng ".

Thứ ba, nhóm phát triển của bạn cần đứng sau Agile; điều đó có nghĩa là không cắt góc và không bỏ qua phản hồi và câu hỏi liên tục về "Điều này có đúng không? Khi x xảy ra, Y nên làm gì?". Ngay cả khi bạn không tuân theo TDD hoặc Lập trình cặp, nhóm phát triển của bạn cần đủ năng lực để tuân theo các quy trình nhanh (ví dụ như chạy nước rút, lặp lại). Điều này liên quan đến việc có một người lãnh đạo / người quản lý có thể ước tính chính xác các nhiệm vụ và hiểu rằng bạn không cần phải ưu tiên mọi tính năng, không có vấn đề tồn đọng trong công việc và bạn không nên làm việc quá sức.