Tháng 2 năm 2021 tròn đúng kỷ niệm 20 năm Tuyên ngôn phát triển Phần mềm Agile – một cuộc cách mạng trên thị trường phần mềm và có tầm ảnh hưởng trên nhiều ngành nghề.
Ngay cả khi bản tuyên ngôn không thay đổi, việc áp dụng cách hiểu của nó cũng khác nhau ở mỗi nơi.
Trong bài viết này, chúng ta sẽ xem xét khái niệm về Agile, những thực tiễn đã thay đổi theo thời gian và hướng đi của nó trong một thế giới đang thay đổi.
Tuyên ngôn Agile
Chúng tôi đã tìm ra được những cách thức phát triển phần mềm tốt hơn bằng cách thực hiện và giúp đỡ người khác áp dụng chúng. Qua đó, chúng tôi đánh giá cao:
- Cá nhân và sự tương tác hơn là quy trình và công cụ
- Phần mềm hoạt động tốt hơn là tài liệu đầy đủ
- Sự cộng tác với khách hàng hơn là đàm phán hợp đồng
- Phản hồi trước thay đổi hơn là bám sát kế hoạch.
Mặc dù những hạng mục bên phải có giá trị của chúng, chúng tôi vẫn đánh giá cao những hạng mục ở bên trái hơn.
12 Nguyên tắc Agile
- Làm hài lòng khách hàng thông qua việc chuyển giao sớm và liên tục phần mềm có giá trị là ưu tiên cao nhất.
- Đón nhận những thay đổi trong yêu cầu, thậm chí thay đổi muộn trong quá trình phát triển. Các quy trình Agile khai thác những thay đổi vì lợi thế cạnh tranh của khách hàng.
- Thường xuyên chuyển giao phần mềm hoạt động tốt tới khách hàng, từ vài tuần đến vài tháng, khoảng thời gian càng ngắn càng tốt.
- Đội ngũ business và đội ngũ lập trình phải cùng làm việc hàng ngày xuyên suốt dự án.
- Xây dựng dự án với những cá nhân có động lực cao. Mang đến cho họ môi trường và sự hỗ trợ cần thiết, đồng thời tin tưởng họ có thể hoàn thành tốt công việc.
- Phương pháp hiệu quả nhất để truyền đạt thông tin là đối thoại trực tiếp.
- Phần mềm hoạt động tốt là thước đo chính của tiến độ dự án.
- Các quy trình Agile thúc đẩy phát triển bền vững. Các nhà đầu tư, lập trình viên, và người dùng nên luôn duy trì nhịp độ phát triển liên tục.
- Liên tục quan tâm đến các công nghệ và thiết kế tiên tiến để gia tăng tính linh hoạt.
- Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành – là vô cùng quan trọng.
- Các kiến trúc, yêu cầu, và thiết kế tốt nhất được tạo ra bởi các team tự quản.
- Theo định kỳ, đội ngũ phát triển cùng nghiệm lại cách làm việc hiệu quả hơn, sau đó sẽ điều chỉnh và thay đổi hành vi cho phù hợp.
Những thay đổi trong quy trình phát triển phần mềm Agile
Trong một thế giới đang thay đổi, kỳ vọng về phần mềm ngày càng tăng và lập trình viên độc lập nay đã được thay thế bằng nguyên một đội ngũ lập trình.
Trong bài “20 Jahre Agiles Manifest – Deftiv den Kinderschuhen entwachsen”, Jutta Eckstein (business coach, change manager) đưa ra danh sách những thay đổi về phát triển phần mềm theo Agile. Trích đoạn:
- Nếu team đảm bảo rằng các story luôn có cùng size thì việc estimate từng story sẽ không cần thiết nữa.
- Trong một thời gian dài, các story chỉ được công nhận nếu chúng tương ứng với format Connextra (“As a …, I want …, so …”). Thay vào đó, giờ đây, các story chỉ đóng vai trò như một loại ghi nhớ cho một cuộc hội thoại về nội dung của story (và không có format cho các bản ghi nhớ hội thoại).
- Flow ngày càng trở nên quan trọng. Điều này bao gồm thực tế là các sprint hay iteration thường không còn đóng vai trò quan trọng nữa. Điều này có nghĩa là các team không lập kế hoạch hai tuần một lần, mà phối hợp hàng ngày theo Kanban những gì có thể hoàn thành và những gì được bổ sung sau từ backlog. Như vậy, việc lập kế hoạch, phản ánh và điều chỉnh có tính liên tục hơn.
- Với sự gia tăng của tốc độ phát triển phần mềm, những trào lưu mới như DevOps đã góp phần tạo ra một cách nhìn tốt hơn về phát triển phần mềm trong một bối cảnh rộng hơn. Tuy nhiên, không phải lúc nào người ta cũng hiểu được ý tưởng cơ bản của DevOps. Ngày càng có nhiều công ty đặt đội ngũ DevOps bên cạnh đội ngũ phát triển hoặc đảm nhiệm vai trò kỹ sư DevOps. Họ bỏ qua thực tế rằng DevOps là một thái độ, một văn hóa chứ không phải một chức năng, vai trò hay nhiệm vụ đặc biệt.
Jutta Eckstein bổ sung rằng một vài phương pháp vốn là cơ sở của bản tuyên ngôn vẫn còn đóng một vai trò nhất định ở thời điểm hiện tại.
Ví dụ: crystal method (tập trung vào cá nhân và sự tương tác) hoặc phát triển phần mềm mang tính thích ứng.
Extreme Programming (XP) phát triển trong những năm gần đây vì người sáng lập Kent Beck đã quay trở lại sau khi ông vắng bóng trong nhiều năm vì lý do cá nhân.
Cũng cần lưu ý rằng có một sự thiển cận trong nguyên tắc thứ 3 của Tuyên ngôn Agile khi giới hạn tần suất chuyển giao phần mềm xuống còn “một vài tuần” nhưng DevOps và chu kỳ continuous delivery ngày nay cho phép chúng ta release nhiều phần mềm trong một ngày.
Uncle Bob (Robert Cecil Martin) trả lời cho điểm này như sau:
“Vào thời điểm năm 2001, chúng tôi không thể tưởng tượng sẽ làm được gì nhanh hơn vài tuần. Tom Gilb là người duy nhất trong cộng đồng có thể làm được, nhưng ông ấy không có mặt tại cuộc họp. Chúng tôi nghĩ rằng hai tuần là giới hạn thấp hơn và không ai bận tâm đến việc chất vấn điều này, và rõ ràng đây là điểm thiển cận”.
Tương lai của Agile
Agile không còn chỉ được hiểu trong bối cảnh phát triển phần mềm nữa.
Chúng ta có “Scaling Agile” với niềm tin rằng toàn bộ tổ chức cần hoạt động theo các nguyên tắc Agile.
Agile trong doanh nghiệp hiện là một chủ đề ngày càng nhận được nhiều quan tâm và động lực.
Để áp dụng Agile vào các quy trình truyền thống của doanh nghiệp, Bjarte Bogsnes nhấn mạnh một thách thức lớn trong bài “Chuyển đổi Agile và hiện tượng con voi trong phòng” (tựa gốc: Agile Transformation and the Elephant in the Room).
“Thật khó để mở rộng quy mô Agile bằng cách sử dụng cùng một framework và cùng một ngôn ngữ đã hoạt động rất tốt để chuyển đổi phát triển phần mềm. Đối với các giám đốc điều hành, “Scrum” nghe có vẻ giống như một căn bệnh ngoài da, “Sprint” không chỉ việc chạy nhanh hơn, “Slack” không phải nói về sự lười biếng, còn “continuous delivery” không phải là chỉ đến một dây chuyền lắp ráp hiệu quả.
Chúng ta cần một bản dịch, một thứ giúp ban điều hành doanh nghiệp hiểu rõ hơn ý nghĩa của Agile ở cấp độ kinh doanh. Agile trong doanh nghiệp thực sự có ý nghĩa gì trong thực tế?”
Theo Bogsnes, “con voi trong phòng” (một điều hiển nhiên nhưng ai cũng lờ đi) chính là quy trình lập ngân sách.
Vì trước giờ đây được coi là quy luật kinh doanh rồi, nên khó mà thay đổi nó. Nếu nó không được thay đổi, bất kỳ sự chuyển đổi theo hướng Agile nào cũng sẽ gặp khó khăn.
“Quy trình lập ngân sách có lẽ là rào cản cơ bản nhất đối với sự chuyển đổi Agile. Ngân sách hàng năm, quá trình lập ngân sách, và tư duy đằng sau nó đều là phản đề của Agile theo nhiều khía cạnh. Lập ngân sách được xây dựng dựa trên hai giả định cơ bản: tương lai có thể dự đoán được và không thể tin ai được. Còn gì ngược với Agile hơn chứ?”
Nhiều tổ chức trên khắp thế giới đã giải quyết vấn đề này và bổ sung nguyên lý Agile cho các quy trình trong doanh nghiệp bằng cách tuân theo 12 nguyên tắc bên cạnh việc lập ngân sách theo Bjarte Bogsnes.
Thay vì được sử dụng theo nghĩa hẹp của nó là lập kế hoạch và kiểm soát, “ngân sách” có thể là văn hóa lãnh đạo và hệ thống quản lý hiệu suất.
