Tuyên ngôn Agile: 4 Giá trị cốt lõi và 12 Nguyên tắc được giải thích

Hình ảnh bên dưới được lấy từtrang web Tuyên ngôn Agile và thể hiện bốn tuyên bố giá trị Agile.

Agile Manifesto and the 4 Agile Values answer what agility is

Như bạn có thể thấy trong phần mở đầu về các giá trị, các tác giả nêu rằng họ đang khám phá những cách tốt hơn để phát triển phần mềm và giúp đỡ người khác. Tất cả các giá trị đều quan trọng, nhưng những giá trị ở bên trái được ưu tiên hơn những giá trị ở bên phải.

Con người và tương tác hơn là quy trình và công cụ

Như đã đề cập trước đó, khi Tuyên ngôn Agile được công bố, nó đã thách thức các phương pháp nặng nề. Mô hình chín độ năng lực (CMM) và ITIL là những xu hướng phổ biến hướng đến các tiếp cận dựa trên quy trình vào thời điểm đó.

Do đó, điều đáng ngạc nhiên là những người tiên phong này lại chọn bắt đầu từ con người. Họ tin rằng việc tìm ra những người phù hợp (con người) trong một nhóm và giúp họ hợp tác hiệu quả (tương tác) là điều quan trọng hơn nhiều so với việc tuân theo bất kỳ quy trình cụ thể nào và/hoặc sử dụng các công cụ nhất định. Đó là lý do tại sao họ đặt trọng tâm vào bên trái: con người và tương tác.

Phần mềm hoạt động hơn là tài liệu toàn diện

Trong phát triển phần mềm truyền thống hoặc theo mô hình nước chảy, các đội sẽ dành nhiều thời gian thu thập yêu cầu và phát triển thiết kế và đặc tả, chỉ xây dựng một sản phẩm cụ thể vào cuối vòng đời. Các tác giả của tuyên ngôn tin rằng việc có một giải pháp hoạt động là có giá trị hơn nhiều so với việc sở hữu một bộ sưu tập lớn các tài liệu mô tả cách giải pháp hoạt động.

Hợp tác với khách hàng hơn là đàm phán hợp đồng

Giá trị thứ ba là hợp tác với khách hàng hơn là đàm phán hợp đồng—trong đó đàm phán hợp đồng có nghĩa là tranh cãi về những gì được bao gồm trong phạm vi. Ví dụ, bạn có thể nghe thấy những cụm từ như “Điều đó không có trong tài liệu yêu cầu của bạn.” Những người tiên phong này tin rằng việc hợp tác với khách hàng để cung cấp giải pháp mà họ thực sự cần là điều quan trọng hơn nhiều.

Phản ứng với thay đổi hơn là tuân theo một kế hoạch

Giá trị Agile thứ tư và cuối cùng là phản ứng với thay đổi hơn là tuân theo một kế hoạch. Các tác giả đồng ý rằng lập kế hoạch là quan trọng—thậm chí các đội Agile thực hiện rất nhiều công việc lập kế hoạch. Nhưng những người tiên phong này tin rằng khả năng phản ứng với những thay đổi tất yếu là quan trọng hơn nhiều so với việc bám vào một kế hoạch được xây dựng vào đầu dự án, khi thông tin vẫn còn hạn chế.

Tất cả các giá trị trong tuyên ngôn này đều quan trọng, nhưng những giá trị ở bên trái được ưu tiên cao hơn những giá trị ở bên phải.

12 Nguyên tắc Agile

Bên cạnh 4 giá trị Agile này, các tác giả của Tuyên ngôn Agile đã đồng ý với một bộ12 Nguyên tắc Agile, tạo nên nền tảng cho các cách làm việc Agile. Mặc dù ít được biết đến hơn so với 4 giá trị Agile, tôi thấy 12 nguyên tắc Agile thực tế hơn và cung cấp hướng dẫn rõ ràng hơn cho các thực hành Agile.

12 Agile Principles behind the Agile Manifesto

Để tiện lợi, tôi đã đánh số 12 nguyên tắc này, mặc dù chúng không được đánh số trêntrang web chính thức.

  1. Nguyên tắc đầu tiên làưu tiên cao nhấtlà thỏa mãn khách hàng thông qua việc cung cấp phần mềm có giá trị một cách sớm và liên tục. Cụm từ “phần mềm có giá trị” khiến một số người nhầm lẫn. Hãy nhớ rằng, vào năm 2001, khi những người tiên phong này giới thiệu các giá trị và nguyên tắc Agile, họ chỉ tập trung vào phát triển phần mềm. Kể từ đó, Agile đã được áp dụng rộng rãi trong gần như mọi ngành—kiến trúc, sản xuất ô tô, thậm chí cả sản xuất máy bay chiến đấu. Nếu bạn thấy hợp lý hơn, hãy thay thế “giải pháp có giá trị” cho “phần mềm có giá trị”.
  2. Nguyên tắc thứ hai làchào đón các yêu cầu thay đổi, ngay cả ở giai đoạn cuối của quá trình phát triển. Trong khi phần lớn mọi người ngày nay tập trung vào kiểm soát thay đổi hoặc quản lý “sự lan rộng phạm vi”, thực tế là thay đổi là điều không thể tránh khỏi. Các quy trình Agile trì hoãn việc ra quyết định, rút ngắn chu kỳ phát triển và hỗ trợ phân tích kịp thời các yêu cầu. Điều này giúp các đội Agile thích nghi nhanh chóng và với chi phí thấp. Điều này mang lại lợi thế cạnh tranh và là một trong những trụ cột chính của làm việc theo Agile.
  3. Nguyên tắc thứ ba là thường xuyên cung cấp phần mềm hoạt động, từ vài tuần đến vài tháng, ưu tiên các khoảng thời gian ngắn hơn. Một trong những lợi ích chính của việc giao hàng thường xuyên là thu thập phản hồi để đảm bảo bạn đang đi đúng hướng và thực sự đang xây dựng những gì khách hàng cần.
  4. Nguyên tắc Agile thứ tư là về những người kinh doanh và nhà phát triển làm việc cùng nhau mỗi ngàytrong suốt dự án. Ngày nay, các bên liên quan về kinh doanh thường tạo tài liệu yêu cầu và “ném qua bức tường” cho các nhà phát triển. Vài tháng hoặc thậm chí vài năm sau, các nhà phát triển giao giải pháp cho người yêu cầu để kiểm thử cuối cùng—chỉ để phát hiện ra giải pháp bị hiểu nhầm, được xây dựng sai hoặc đã không còn cần thiết. Trọng tâm của nguyên tắc này là hợp tác giữa những người xây dựng giải pháp và những người sử dụng nó, nhằm tránh những kết quả như vậy.
  5. Nguyên tắc Agile thứ năm là xây dựng dự án xung quanh những cá nhân có động lực, cung cấp cho họ môi trường và hỗ trợ cần thiết, và tin tưởng họ hoàn thành công việc. Về cơ bản, đây là một cách tiếp cận ba phần: trao quyền cho con người, trao quyền tự chủ và tin tưởng họ.
  6. Nguyên tắc Agile thứ sáu đề cao phát triển bền vững. Các nhà tài trợ, nhà phát triển và người dùng nên có thể duy trì nhịp độ ổn định vô thời hạn. Khi tôi mới bắt đầu làm việc trên các dự án công nghệ, chúng thường kéo dài 6 tháng, 12 tháng hoặc lâu hơn. Rất phổ biến khi không đạt được nhiều tiến độ trong tháng đầu hoặc hai tháng đầu. Không ngạc nhiên khi điều này dẫn đến các giai đoạn căng thẳng cực độ ở cuối dự án, khi phải hoàn thành khối lượng công việc khổng lồ. Các thành viên đội phải làm việc vào buổi tối hoặc cuối tuần để đáp ứng các mốc thời gian cố định và phạm vi cố định. Điều này được gọi là dự án “đi đến cái chết”. Agile không nói rằng bạn sẽ không bao giờ làm việc buổi tối hay cuối tuần—nhưng nó nhấn mạnh việc làm việc ở nhịp độ bền vững cho mọi người.
  7. Nguyên tắc thứ bảy là phần mềm hoạt độnglà thước đo chính của tiến độ. Truyền thống, phần trăm hoàn thành được dùng để theo dõi tiến độ dự án. Phần trăm hoàn thành rất không đáng tin cậy vì rất khó đánh giá, đặc biệt khi đạt đến 80% hoặc 90%. Một mức hoàn thành 90% thường có nghĩa chỉ còn 10% công sức hoặc thời gian nữa. Các đội Agile tránh dùng phần trăm hoàn thành bằng cách chia công việc thành các tính năng hoặc chức năng, chia nhỏ thành các mảnh nhỏ và theo dõi xem các mảnh này đã hoàn thành hay chưa. Cách tiếp cận này tránh được các chỉ số tiến độ gây hiểu lầm.
  8. Nguyên tắc thứ tám là cách hiệu quả và hiệu suất cao nhất để truyền đạt thông tin đến đội phát triển và trong đội là thông qua cuộc trò chuyện trực tiếp. Ngày nay, công cụ giao tiếp phổ biến nhất có thể là email. Nó hiệu quả với người gửi—tất nhiên, họ có thể gửi tin nhắn đến hàng trăm hoặc hàng ngàn người cùng lúc. Nhưng đó không phải là giao tiếp thực sự. Nghiên cứu cho thấy việc đọc văn bản của người khác để lại nhiều khoảng trống cho sự hiểu lầm. Các nhà ủng hộ Agile đã học được rằng sự hiểu biết chung thực sự đòi hỏi phải đưa mọi người lại gần nhau. Nếu không thể gặp trực tiếp, hãy sử dụng kênh giao tiếp có băng thông cao nhất—đó có thể là cuộc gọi video hoặc điện thoại. Điều này tốt hơn rất nhiều so với việc đăng tài liệu lên SharePoint! Bài học ở đây là hãy sử dụng kênh giao tiếp có băng thông cao nhất có thể. Một hệ quả phụ của việc ưu tiên giao tiếp trực tiếp là việc đặt các thành viên trong cùng một đội Agile làm việc cùng nhau là hợp lý. Ngày nay, nhiều tổ chức bỏ qua điểm hiển nhiên này.
  9. Nguyên tắc thứ chín là tập trung liên tục vào sự xuất sắc về kỹ thuật và thiết kế tốtđể nâng cao tính linh hoạt. Trọng tâm là tránh các cách làm tắt hoặc nợ kỹ thuật. Đừng làm điều gì khiến việc nhanh hơn trong ngắn hạn nhưng tốn kém hơn trong dài hạn. Nếu bạn tiếp tục tích lũy nợ kỹ thuật, bạn sẽ mất đi tính linh hoạt. Điều này phổ biến trong các dự án waterfall với thời hạn cố định. Để đáp ứng các mốc thời gian cam kết, các chi tiết bị bỏ qua. Các chu kỳ kiểm thử có thể bị rút ngắn hoặc loại bỏ để tiết kiệm thời gian, dẫn đến nhiều vấn đề hơn trong môi trường sản xuất sau khi ra mắt. Điều này dẫn đến việc xử lý sự cố liên tục và mã nguồn khó duy trì.
  10. Nguyên tắc thứ mười là về việc giữ đơn giản và loại bỏ công việc không cần thiết. Simplicity—nghệ thuật tối đa hóa lượng công việc không làm—là điều thiết yếu. Nói cách khác, chúng ta nên xem xét lại quy trình của mình và loại bỏ bất cứ thứ gì không tạo ra giá trị cho khách hàng, từ đó tối đa hóa lượng công việc chưa hoàn thành nhưng vẫn đảm bảo cung cấp những gì cần thiết.
  11. Nguyên tắc thứ mười cũng nói về các đội tự tổ chức. Những kiến trúc, yêu cầu và thiết kế tốt nhất đến từ các đội tự tổ chức. Chúng ta nên để những người gần công việc nhất quyết định cách thức thực hiện tốt nhất—đây chính là cốt lõi của nguyên tắc này.
  12. Nguyên tắc cuối cùng, số 12, là về việc tổng kết. Các đội thường xuyên phản tư về cách trở nên hiệu quả hơn và sau đó điều chỉnh và thích nghihành vi của họ phù hợp theo đó.

Các giá trị và nguyên tắc Agile có thể không còn trông có vẻ cách mạng ngày nay, nhưng khi chúng được công bố vào năm 2001, chúng thực sự mang tính cách mạng. Chính vì vậy mà gọi là “Tuyên ngôn”. Chúng đã nêu rõ một phương pháp làm việc hoàn toàn khác biệt so với cách các tổ chức đã hoạt động trong thế kỷ trước. Trước đó, phát triển phần mềm chủ yếu phản ánh các phương pháp làm việc thời kỳ công nghiệp. Hiểu rõ bối cảnh lịch sử này là điều rất quan trọng, như đã thảo luận bên dưới.

 

 

Leave a Reply