Kurt Cagle gần đây đã viết một bài báo cho Forbes, mang tên The End of Agile (Sự kết thúc của Agile). Mặc dù vài ngày sau đó, Steve Denning, người thường xuyên phản hồi trong các bài viết của Forbes đã đáp trả rất hiệu quả bằng bài viết Why Agile’s Future is Bright (Tại sao Agile có một tương lai tươi sáng) nhưng tôi cũng muốn phụ họa thêm một vài suy nghĩ ngoài những gì Steve đã đưa ra. Như là:

1. Hãy nhìn vượt ra khỏi Scrum. Kurt bắt đầu bài viết của mình với đoạn mô tả khôi hài về một nhóm Agile, nhưng đó thực sự chỉ là đoạn mô tả về một nhóm nhỏ khi mới bắt đầu học Scrum. Đây là lỗi cổ điển mà nhiều người mắc phải khi cho rằng “Scrum = Agile” , và điều này chỉ tốt với những ai đã hiểu rõ cách thức hoạt động của Agile trong thực tế. Chúng tôi khuyên bạn nên xem xét các đội/nhóm đang thành công với mô hình Agile, thay vì các đội/nhóm đang gặp khó khăn trước mắt. Hơn thế nữa, hãy giúp đỡ các đội/nhóm đang gặp khó khăn thay vì xem họ là trò đùa và lấy đó làm niềm vui.
2. Hãy chú ý những người theo chủ nghĩa thuần túy về Agile. Theo như quan sát của Kurt, Agile đã trở thành một tôn giáo không còn xa lạ. Nói chính xác hơn, những người theo chủ nghĩa thuần túy Agile thường được chứng minh chỉ có kinh nghiệm áp dụng Agile trong các tình huống đơn giản – chứ không phải trong các tình huống  phức tạp của doanh nghiệp như Kurt mô tả. Nhưng cũng có những người theo chủ nghĩa thực tế ngoài phạm vi của Agile (chủ nghĩa thực tế là một trong bảy nguyên tắc của Disciplined Agile) đang tích cực tìm cách áp dụng các chiến lược linh hoạt và tinh gọn trong các tình huống kém lý tưởng. Chúng tôi luôn khuyên bạn nên cởi mở và thực tế, làm tốt nhất có thể trong tình huống mà bạn gặp phải và luôn nỗ lực học hỏi để cải thiện.
3. Agile hiệu quả trong nhiều tình huống. Có rất nhiều dữ liệu nghiên cứu và trường hợp thực tế cho thấy Agile hiệu quả trong nhiều tình huống. Ví dụ, trong khảo sát Agility at Scale năm 2016, chúng tôi nhận thấy, trên thực tế các tổ chức đang áp dụng Agile vào các đội/nhóm lớn, trong nhiều lĩnh vực phức tạp, sử dụng các công nghệ đã cũ (kể cả nguồn dữ liệu cũ), trong cả môi trường pháp lý và các tình huống đa tổ chức bao gồm cả thuê ngoài (outsourcing). Ngoài ra, chúng tôi cũng có dữ liệu từ các nghiên cứu khác trong hơn một thập kỷ qua cho thấy, các chiến lược của Agile đã được áp dụng vượt ra ngoài kịch bản của “các đội/nhóm nhỏ với những vấn đề đơn giản” trong một thời gian dài. Chúng tôi thực sự khuyên bạn nên nhìn xung quanh và xem cách thức mà Agile đang được áp dụng trong thực tế.
4. Mở rộng Agile đòi hỏi tính kỷ luật. Bài viết cũng phát biểu rằng Agile không mở rộng quy mô đủ tốt để giải quyết các vấn đề lớn, nhưng thực tế nhiều tổ chức đang thực hiện được điều này. Công bằng mà nói với Kurt, đây là sự hiểu lầm phổ biến do kết quả của tư duy “Scrum = Agile” vì Scrum không dùng để giải quyết vấn đề mô hình (trong số nhiều vấn đề khác). Nhưng các phương pháp Agile khác có thể làm điều này – đặc biệt là Agile Modeling và những công việc tuyệt vời của Jim Coplien xung quanh Lean Architecture – các chiến lược rõ ràng là một phần của Disciplined Agile. Trong Disciplined Agile Delivery (DAD), chúng tôi làm rõ mô hình kiến trúc ban đầu trong dự án thông qua mục tiêu của quá trình Xác định chiến lược kiến trúc (Identify Architecture Strategy), chúng tôi chỉ ra cách giảm thiểu rủi ro thiết kế thông qua mục tiêu của quá trình Thử nghiệm mô hình kiến trúc giai đoạn đầu (Prove Architecture Early) và chúng tôi cũng chỉ cách phát triển mô hình kiến trúc trong suốt quá trình Xây dựng thông qua mục tiêu của quá trình Thiết kế giải pháp sản xuất khối lượng tiêu thụ tiềm năng. Các nhóm DAD cũng phân công rõ, Người chủ sở hữu kiến trúc chịu trách nhiệm hướng dẫn đội/nhóm thông qua các quyết định xây dựng kiến trúc. Hơn nữa, sẽ có riêng một phần quy trình Kiến trúc doanh nghiệp để hỗ trợ các vấn đề kiến trúc cấp tổ chức. Cuối cùng, DA có ý tưởng rằng Chủ sở hữu kiến trúc và Kiến trúc sư doanh nghiệp nên làm việc chặt chẽ với nhau. Chúng tôi đề nghị bạn nên giải quyết vấn đề kiến trúc rõ ràng theo cách làm việc của bạn và đây cũng là điều mà Disciplined Agile cung cấp - những lựa chọn rõ ràng, đã được chứng minh.
5. Dữ liệu của dự án có thể gặp vấn đề. Hay nói cách khác là những dự án không có dữ liệu. Khi độ phức tạp của domain hay kỹ thuật tăng hoặc cả hai đều tăng, bạn cần phải tuân thủ kỷ luật hơn nữa khi tiếp cận với các yêu cầu và mô hình kiến trúc. Như Cagle ngụ ý rằng, dữ liệu của các dự án thường chịu tác động bởi sự phức tạp của domain, điều này đặc biệt đúng với hệ thống dữ liệu của các doanh nghiệp mà ông đề cập. Các dự án có dữ liệu tương tự nhau thường có xu hướng bị tác động bởi sự phức tạp của kỹ thuật - chúng cần tích hợp dữ liệu từ nhiều nguồn khác nhau mà các nguồn này thường sử dụng các công nghệ khác nhau, với các ý nghĩa riêng biệt và được tiếp cận thông qua các chiến lược không giống nhau. Một lần nữa, chiến lược Lựa chọn dựa trên ngữ cảnh mà Disciplined Agile phát triển, chiếm được thế thượng phong thông qua các phương pháp và khuôn khổ đã được quy định mà Cagle dường như đã quá quen thuộc. Một điều có thể gây nhầm lẫn hơn nữa là các khuôn khổ đã được quy định như Scrum và SAFe hầu như không gặp các vấn đề về xử lý dữ liệu. Mặt khác, Disciplined Agile bao gồm cả những chiến lược đã được kiểm chứng trong Phương pháp Agile Data – phương pháp để phân tích dữ liệu dự án thành công. Chúng tôi khuyên bạn nên nắm bắt và đối mặt với sự phức tạp này và bạn sẽ nhận ra mình cần phải điều chỉnh cách làm việc (WoW) để giải quyết nó.
6. Agile áp dụng vào dữ liệu dự án có thể là cách tiếp cận ưu việt. Tôi sẽ đi thẳng vào vấn đề - Kurt Cagle đã hoàn toàn sai khi áp dụng các chiến lược Agile vào dữ liệu dự án. Chiến lược mở rộng mô hình dữ liệu lên phía trước mà các chuyên gia dữ liệu truyền thống thường dùng đã được chứng minh là không hiệu quả trong thực tế. Trong khi đó, chiến lược hiệu quả là, mô hình hóa dữ liệu Agile, khi đó, mô hình hóa tổng quát được thực hiện ngay từ giai đoạn đầu của dự án và mô hình dữ liệu chi tiết được thực hiện trong quá trình xây dựng (khi cần thiết). Bạn có thể rất linh hoạt khi cơ sở dữ liệu Agile có sẵn như cơ sở dữ liệu tái cấu trúc, cơ sở dữ liệu tự động kiểm tra hồi quy và cơ sở dữ liệu tích hợp liên tục. Và ông cho rằng, việc tập trung vào dữ liệu doanh nghiệp rõ ràng là tương đối mới và không phản ánh được sự phong phú của các kỹ thuật xung quanh mô hình dữ liệu doanh nghiệp, quản lý dữ liệu cấp cao và quản lý dữ liệu meta mà cộng đồng dữ liệu đã được theo dõi từ ít nhất là giữa những năm 1990. Và tất nhiên sẽ có những cách tiếp cận Agile cho tất cả những thực tế đó. Ở một khía cạnh khác, tôi bắt đầu viết blog này vào buổi tối khi đang tham dự Hội nghị Vault Dữ liệu Toàn cầu ở Hannover. Hầu hết những người trình bày thảo luận về cách họ lấy, hay tối thiểu là tiếp cận hỗ trợ Agile - và thường là Disciplined Agile - trong các dữ liệu dự án của họ.
7. Nhiều người khác tuyên bố bài báo đã sai rất rõ ràng. Trái ngược với những gì Kurt nhận định, nhiều dự án với nguồn lực lớn và phức tạp áp dụng các chiến lược Agile tinh gọn rất hiệu quả. Ví dụ một số dự án được đặt tên bao gồm Linux (hệ điều hành), Hadoop (xử lý dữ liệu big data), MongoDB (cơ sở dữ liệu), Numenta (máy móc học), Angular (khung ứng dụng web) và Docker (cơ sở hạ tầng phần mềm). Tuy nhiên, không phải công nghệ nào trong số đó cũng là nhiệm vụ quan trọng đối với tổ chức của bạn. Về trao đổi liên quan đến ngành phát triển game? Sau khi tham khảo một số công ty thương mại về game, tôi có thể nói rằng tất cả họ đều làm việc rất nhanh nhẹn và linh hoạt.
8. Bạn phải điều chỉnh cách tiếp cận để giải quyết vấn đề cho phù hợp. Không một quy trình nào có thể phù hợp để áp dụng cho tất cả trường hợp. Hai trong số các nguyên tắc của DA là Context Counts và Choice is Good – các nhóm khác nhau trong các tình huống khác nhau sẽ lựa chọn cách làm việc khác nhau. Nếu bạn muốn nhóm của mình hoạt động hiệu quả thì bạn phải cho phép họ - và tốt hơn nữa là trao quyền – để họ chọn làm việc theo cách riêng (WoW).
9. Để điều chỉnh cách tiếp cận, đòi hỏi phải có kỹ năng và kinh nghiệm. Ở một vài khía cạnh, Kurt đúng - các vấn đề ở cấp độ doanh nghiệp đòi hỏi cách tiếp cận Agile ở mức doanh nghiệp. Nhưng ông ấy đã sai khi cho rằng vì mọi người gặp khó khăn khi áp dụng các chiến lược Undisciplined Agile vào những tình huống mà Agile không hiệu quả; vấn đề thực sự là họ không biết cách làm cho nó hiệu quả. Thực tế là nhiều người đã nhận ra điều này và chúng tôi cũng biết được rất nhiều chiến lược này trong bộ công cụ của PMI’s Disciplined Agile (DA).

Hãy hy vọng đây là sự kết thúc của Undisciplined Agile. Nhưng như Steve Denning chỉ ra, đó chắc chắn không phải là sự kết thúc của Agile. Tôi kiến nghị rằng đây có thể là sự khởi đầu quan trọng của phương pháp Disciplined Agile.

Như Hợp Trần - lược dịch. 

 (Nguồn: The End of Agile? No, the End of Undisciplined Agile)

Xem thêm

Sự kết thúc của Agile? Không, là sự kết thúc của Undisciplined Agile.

Disciplined Agile là gì? Tại sao nên áp dụng Disciplined Agile?

Hệ tư duy của Disciplined Agile - Disciplined Agile Mindset

8 nguyên tắc trong Disciplined Agile

Tổng quan về Disciplined Agile Delivery - Một phần thiết yếu của Disciplined Agile

Vai trò, quyền và trách nhiệm của đội Disciplined Agile Delivery

DASM ONLINE PRO - CHƯƠNG TRÌNH LUYỆN THI DASM HIỆU QUẢ

DASSM ONLINE PRO - CHƯƠNG TRÌNH LUYỆN THI DASSM HIỆU QUẢ