Cái chết chậm chạp và đau đớn của Agile và Jira
(ehandbook.com)"Agile không còn là Agile nữa, nên đã đến lúc Agile cùng với Jira phải cùng biến mất"
- Chu kỳ phát triển phần mềm ngày càng dài hơn, các đội ngũ kỹ thuật ngày càng lớn hơn, quản lý phát triển cần ngày càng nhiều ứng dụng hơn, số người thực sự viết code thì ngày càng ít đi, và trong những khoảng thời gian ngày càng ngắn hơn, mức tiến triển giữa các điểm kiểm tra liên tục lại ngày càng giảm
- Agile đã đi chệch hướng từ đâu?
- Agile là một phương pháp được phát triển vào đầu những năm 2000 như một giải pháp thay thế cho quy trình phát triển phần mềm nặng nề, dựa trên tài liệu của thời trước
- Nhưng hiện nay, Agile đang bị biến chất thành một phương pháp quản lý dự án phức tạp kiểu cũ
Phình to công nghệ (Tech Bloat) là vấn đề chính
- Lý do chính khiến nhiều người từ bỏ hoặc muốn từ bỏ Agile là vì tình trạng phình to công nghệ
- Phình to công nghệ là kẻ thù của mọi công ty công nghệ, và cũng là rủi ro với cả các công ty không phải công nghệ nhưng có đội phát triển nội bộ hoặc thuê ngoài
- Phình to công nghệ khác với technical debt, nhưng lại tạo ra technical debt
- Các triệu chứng của phình to công nghệ gồm có:
- Liên tục trò chuyện với khách hàng nhưng không trở thành chuyên gia về hành vi của khách hàng
- Không ngừng đánh giá và đánh giá lại deadline và ngày bàn giao
- Cực kỳ ngần ngại bắt đầu quy trình phát triển cho đến khi mọi chi tiết đều được tài liệu hóa
- Có động lực bắt đầu từ những việc dễ nhất thay vì những việc rủi ro nhất
Những hệ quả hỗn loạn của phình to công nghệ
- Tăng tài liệu hóa
- Việc tài liệu hóa để theo dõi không chỉ "đã phát triển cái gì và vì sao" mà cả "đã phát triển như thế nào" len lỏi vào toàn bộ quy trình
- Cái "như thế nào" này trở thành trọng tâm của các bản cập nhật trạng thái, khiến đội ngũ liên tục đánh giá lại cách họ đang làm việc
- Các nhóm dành nhiều thời gian để bàn tại sao công việc chưa hoàn thành hơn là để thực sự hoàn thành công việc
- Thiết lập deadline dày đặc
- Nhiều deadline hơn được đặt ra ở các điểm kiểm tra thường xuyên hơn, về bản chất tạo ra vi quản lý ở mọi khúc ngoặt của một quy trình vốn mang tính sáng tạo
- Điều này đi ngược lại việc tạo ra phần mềm chất lượng, vì mọi công việc đều bị buộc phải giao đúng hạn bất kể được thực hiện tốt đến đâu
- Sự hoài nghi không ngừng trong quá trình đánh giá lại
- Sự hoài nghi liên tục trong các giai đoạn đánh giá lại khiến best practice không được xác lập, lãng phí không bị loại bỏ và lợi thế kinh tế theo quy mô không được nhận ra
- Vi quản lý quá trình sản xuất
- Khi khoảng 30% của toàn bộ tính năng đã hoàn thành thì nó đã không còn là ưu tiên nữa
- Tổ chức rơi vào vòng xoáy chết chóc là cứ sản xuất những gì có trong roadmap, bất kể roadmap đó còn định nghĩa việc xây dựng một sản phẩm thành công hay không
- Kết quả cuối cùng
- Sản phẩm phải oằn mình dưới sức nặng của các yêu cầu khách hàng đa dạng và mâu thuẫn
- Các tính năng thường ra thị trường quá muộn, và được cung cấp theo cách và thứ tự phù hợp nhất với đội kỹ thuật chứ không phải với thị trường
- Cuối cùng đội sales/marketing phản ứng dữ dội vì họ không biết mình đang bán cái gì, còn khách hàng cũng không biết mình đang mua cái gì
- Rồi tổ chức bắt đầu một đợt thanh lọc quy mô lớn
Thế giới cần phần mềm gọn nhẹ làm tốt những việc quan trọng, chứ không phải nhiều tính năng hơn
- Đây không phải là một khái niệm mới, nhưng lại là khái niệm mà mọi phương pháp cuối cùng đều rời xa
- Cuối cùng người ta bắt đầu hỏi liệu phương thức Toyota có còn đủ "Toyota" đối với chính Toyota hay không, và điều đó lại trở thành một công việc tạo thêm việc
- Agile giờ đã trở thành một PMP với cái tên dễ thương hơn, các cuộc họp ngắn hơn và nhiều quy tắc hơn
- Vấn đề không nằm ở ý tưởng Agile mà ở việc thực thi và sự thiếu vắng năng lực lãnh đạo để kiểm soát nó
- Đó là vấn đề của tầng lớp quản lý trung gian, những người tập trung vào deadline hơn là tính hữu ích, vào cắt giảm hơn là tăng trưởng, vào tiết kiệm hơn là tiến bộ
Ý kiến của GN⁺
- Trái với ý định ban đầu, Agile đang bị quan liêu hóa và hình thức hóa, trở thành một yếu tố làm chậm phát triển phần mềm
- Phình to công nghệ không chỉ là rủi ro cần cảnh giác trong Agile mà còn trong mọi tổ chức công nghệ
- Tài liệu hóa, đặt deadline, vi quản lý... có thể ngược lại làm giảm cả chất lượng lẫn tốc độ
- Bản chất của Agile nằm ở khách hàng làm trung tâm, hợp tác và tính linh hoạt, vì vậy cần nhớ lại các nguyên tắc thay vì bị trói buộc vào hình thức
- Điều quan trọng trong phát triển phần mềm không phải là có thêm nhiều tính năng, mà là thực hiện tốt các tính năng cốt lõi
- Văn hóa tổ chức và năng lực lãnh đạo quyết định thành bại của Agile, nên các nhà quản lý kỹ thuật cần chú ý đến điều này
- Có lẽ đã đến lúc tìm kiếm những phương pháp mới vượt ra ngoài Agile
17 bình luận
Tôi chưa xem đến hết vì bài gốc là bài trả phí, nhưng có lẽ nên gọt lại cách diễn đạt trong bản dịch một chút. "Vì Agile không còn là Agile nữa, nên giờ đã đến lúc Agile phải cùng Jira biến mất" => "Vì Agile đã ngừng being agile, nên giờ đã đến lúc Agile phải cùng Jira biến mất"
Ở đây có khái niệm phân biệt giữa
Agileviết hoa vàagileviết thường, vàbeing agilevớidoing agiletuy có liên hệ với nhau nhưng vẫn được xem là hai khái niệm riêng.being agile by doing agile.Lý do áp dụng Agile mới là điều quan trọng. Có phải áp dụng để phát triển tốt hơn không? Không, là vì tôi không chịu nổi cảnh các anh ngồi chơi. Để tôi xem các anh chăm chỉ đến mức nào. Người ta áp dụng với kiểu tư duy như vậy đấy. Thế nên nó mới thành địa ngục.
Đến mức này thì có vẻ cần một checklist kiểm tra mức độ tuân thủ Agile rồi.
Trước cả chuyện là agile hay waterfall, nếu con người, văn hóa và môi trường vẫn y nguyên thì dù có áp dụng phương pháp phát triển mới lạ đến đâu cũng chỉ còn con đường bị “Hàn Quốc hóa” kiểu K-OOO.
Nếu (gần như) không có thay đổi về yêu cầu thì đúng là từ góc độ người làm phát triển, Waterfall thực sự là một cách làm rất thoải mái. Miễn là không có thay đổi về yêu cầu mà thôi…
Agile kiểu Hàn thì chẳng thấy được đánh giá lại gì cả.!
Khách hàng: Nút ở màn hình này đặt chỗ này có vẻ tốt đấy
Lập trình viên: (Thế là lại phải thức đêm rồi, còn cả việc mới nữa chứ)
Khách hàng: Ở màn hình khác cũng nên có nút nữa nhỉ
Lập trình viên: (Ai đó làm ơn dùng thuật phân thân giúp tôi với) Vâng haha..
Khách hàng: Vẫn chưa xong à? Theo lịch thì đáng lẽ phải xong hết rồi chứ?
Lập trình viên: (Cứu tôi với) Vâng..;;
Không có nhiều trường hợp Agile được vận dụng đúng chất Agile và duy trì lâu dài,
Có vẻ phần lớn các tổ chức cuối cùng đều hội tụ về công việc kiểu waterfall với thời hạn gấp.
Vấn đề không nằm ở Agile. Vấn đề là ở con người thực hiện nó. Dù mang đến bất kỳ phương pháp luận nào, cuối cùng vẫn là chuyện người thực hiện vận dụng nó ra sao. Tôi cho rằng Agile không phải là một phương pháp luận, mà gần hơn với một tinh thần phát triển sản phẩm theo từng chu kỳ. Nếu bỏ lỡ điều đó và chỉ mù quáng lập kế hoạch rồi hồi tưởng, thì có vẻ chỉ là lãng phí thời gian.
Tôi cứ tưởng chỉ có kiểu Agile kiểu Hàn mới như vậy, hóa ra đây là hiện tượng toàn cầu.
Cảm giác như họ cứ liên tục đánh vào sai chỗ vậy... Lẽ ra phải đánh giá xem nó có phù hợp với Tuyên ngôn Agile hay không chứ...
Ngay cả uncle bob, người tham gia Tuyên ngôn Agile, cũng đã sớm hiểu vấn đề này và xuất bản cuốn Clean Agile vào năm 2019 để sửa chữa Agile bị áp dụng sai, vậy mà đến giờ những vấn đề như thế này vẫn tiếp diễn. Cá nhân tôi cho rằng nguyên nhân là vì Agile không có bộ hướng dẫn tiêu chuẩn và lại sử dụng khái niệm mơ hồ là "văn hóa". Tôi mong sẽ có những hướng dẫn tiêu chuẩn cụ thể được đưa ra.
Có lẽ tác giả sẽ chủ trương rằng bất kỳ phương pháp luận nào, một khi đã trở nên quan liêu, thì nên vứt bỏ.
Tôi đồng ý. Có vẻ như ngày càng nhiều trường hợp làm Agile sai cách rồi lại nói rằng Agile là sai.
Mặt khác, tôi cũng nghĩ rằng dù đã xuất hiện khá lâu, việc xây dựng thực hành cho tốt vẫn khó, và có lẽ đó là điều không thể tránh khỏi.
Rốt cuộc lại quay về như ban đầu sao?
Ý kiến Hacker News
Vấn đề của Agile
Các nguyên tắc của Agile Manifesto
Cốt lõi của Agile
Tính linh hoạt của Agile
Ý kiến về JIRA
Nguồn gốc của Agile
Hiện trạng của Agile
Vấn đề của JIRA
Ứng dụng của Agile