Các nguyên tắc và giá trị trong Agile

Phát triển Linh hoạt (Agile Development) làm một thuật ngữ có nguồn gốc từ Tuyên Ngôn Phát triển Phần mềm Linh hoạt (Tuyên ngôn Agile – Manifesto for Agile Software Development), tuyên ngôn này được soạn thảo năm 2001 bởi một nhóm gồm các tác giả của Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM – Phương pháp Phát triển Hệ thống Linh động), và Crystal; đại diện của phát triển hướng-tính-năng (FDD,  Feature-Driven Development); và một vài nhà lãnh đạo khác trong lĩnh vực công nghiệp phần mềm. Tuyên ngôn Agile đã tổng kết ra một số giá trị và nguyên tắc chung, phổ quát cho tất cả các phương pháp luận về linh hoạt đang tồn tại độc lập tại thời điểm đó. Văn bản này đưa ra bốn giá trị cốt lõi cho phép các nhóm đạt được hiệu suất cao gồm:

• Cá nhân và tương tác,
• Cung cấp phần mềm chạy tốt,
• Cộng tác với khách hàng,
• Phản hồi với thay đổi.

Các giá trị cốt lõi này còn được cụ thể hóa với 12 nguyên tắc, bạn có thể tìm thấy các nguyên tắc đó tại: Tuyên ngôn Phát triển Phần mềm Linh hoạt.

Những giá trị đó không chỉ là thứ mà các tác giả của Tuyên ngôn Agile dự định cung cấp ra để phục vụ cho tuyên ngôn để rồi sau đó đi vào quên lãng. Chúng là các giá trị căn cứ vào để làm việc. Bản thân mỗi phương pháp linh hoạt đều tiếp cận các giá trị trên theo các cách thức khác nhau, nhưng tất cả các phương pháp này đều có tiến trình và biện pháp thực hành cụ thể để nuôi dưỡng một hoặc nhiều trong số các giá trị đó.

Cá nhân và tương tác

Cá nhân và sự tương tác giữa họ là cốt yếu để nhóm đạt được hiệu suất cao. Các nghiên cứu về sự “bão hòa giao tiếp” (communication saturation) trong một dự án cho thấy rằng, khi không có vấn đề trong giao tiếp, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Để tạo điều kiện cho giao tiếp, các phương pháp linh hoạt thường xuyên sử dụng chu trình thanh-tra-và-thích-nghi. Chu trình này có thể diễn ra hằng phút với lập trình theo cặp (pair-programming), hằng giờ với tích hợp liên tục (continuous integration), hằng ngày với standup metting (họp đứng), hằng phân đoạn với các buổi họp sơ kết và cải tiến.

Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về giao tiếp. Chu kỳ thanh-tra-và-thích-nghi hoạt động tốt chỉ khi các thành viên trong nhóm thể hiện những hành vi quan trọng sau:

• Tôn trọng giá trị của mỗi cá nhân
• Trung thực trong giao tiếp
• Minh bạch về dữ liệu, hoạt động, và quyết định
• Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm
• Cam kết với nhóm và các mục tiêu của nhóm

Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành viên của nhóm phải thể hiện chúng. Chỉ khi đó nhóm mới có thể phát huy được hết tiềm năng của mình.

Đạt tới các hành vi đó khó khăn hơn rất nhiều so với việc hình thành chúng. Hầu hết các nhóm tránh né sự thật, sự minh bạch, và tin tưởng vào các chuẩn mực văn hóa hoặc có những kinh nghiệm tiêu cực từ các xung đột xuất phát từ truyền thông trung thực trước đây. Để chống lại những khuynh hướng này, ban lãnh đạo và thành viên nhóm phải tạo điều kiện cho những xung đột tích cực. Làm như vậy không chỉ giúp tạo ra hành vi sinh lợi mà còn đem lại các lợi ích khác:

• Cải tiến quy trình phụ thuộc vào nhóm trong việc tạo ra danh sách các trở ngại hoặc vấn đề trong tổ chức, đối mặt với chúng một cách trung thực, và sau đó loại bỏ chúng một cách có hệ thống tùy theo độ ưu tiên.
• Đổi mới chỉ xảy ra với việc tự do trao đổi các ý tưởng mâu thuẫn lẫn nhau, một hiện tượng được nghiên cứu và viết thành tài liệu bởi Takeuchi và Nonaka, những người cha đỡ đầu của Scrum.
• Việc hướng các nhóm tới mục tiêu chung đòi hỏi nhóm phải đối mặt và giải quyết các vấn đề về xung đột.
• Cam kết làm việc cùng nhau sẽ xảy ra chỉ khi mọi người đồng ý với mục tiêu chung và sau đó đấu tranh cho sự tiến bộ của bản thân cũng như nhóm.

Ý cuối cùng ở trên nói về cam kết là đặc biệt quan trọng. Đó là khi mà các cá nhân và các nhóm được cam kết mà họ cảm thấy có trách nhiệm với việc cung cấp các giá trị cao, đó là điểm mấu chốt đối với các nhóm phát triển phần mềm. Các phương pháp linh hoạt tạo điều kiện cho việc cam kết bằng cách khuyến khích các nhóm đưa ra một danh sách các công việc được ưu tiên hóa, để họ tự quản lý công việc của mình, và tập trung vào cải tiến về cách thực hiện các công việc đó. Thực hành là nền tảng của tự-tổ-chức (self-organization), đó là động lực để đạt được kết quả trong một nhóm Agile.

Để tạo ra các nhóm có hiệu suất cao, các phương pháp Agile coi trọng cá nhân và sự tương tác hơn là quy trình và công cụ. Thực tế cho thấy rằng, tất cả các phương pháp Agile tìm kiếm sự gia tăng trong truyền thông và cộng tác thông qua việc kiểm tra thường xuyên các chu trình thanh-tra-và-thích-nghi. Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo Agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm Agile của họ.

Phần mềm chạy tốt hơn là tài liệu đầy đủ

Phần mềm chạy tốt là một trong những khác biệt lớn mà phát triển linh hoạt mang lại. Tất cả các phương pháp linh hoạt thể hiện Tuyên ngôn Agile bằng cách nhấn mạnh việc cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định.

Tất cả các nhóm Agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là định nghĩa hoàn thành. Ở mức độ cao, một phần của chức năng hoàn thành chỉ khi các tính năng của chúng vượt qua tất cả các kiểm thử và có thể được vận hành bởi người dùng cuối. Ở mức thấp nhất, các nhóm phải vượt qua được kiểm thử đơn vị (unit test) và kiểm thử hệ thống. Các nhóm tốt nhất còn bao gồm việc kiểm thử tích hợp, kiểm thử hiệu năng, và kiểm thử chấp nhận của khách hàng trong định nghĩa hoàn thành đối với một phần chức năng. Thông qua nguồn dữ liệu phong phú từ các dự án, một công ty CMMI Cấp độ 5 cho thấy việc xác định kiểm thử chấp nhận cùng với các tính năng, triển khai một loạt các tính năng và theo độ ưu tiên, ngay lập tức chạy các kiểm thử chấp nhận với mỗi tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40%. Điều này có được từ một công ty có tỷ lệ sai sót thấp nhất thế giới.

Tuyên ngôn Agile khuyến nghị các nhóm cung cấp phần mềm chạy tốt sau một khoảng thời gian nhất định. Đồng thuận với định nghĩa hoàn thành là một trong những cách thực tế để nhóm agile mang lại hiệu suất và chất lượng cao, cái cần thiết để hoàn thành mục tiêu này.

Cộng tác với khách hàng hơn là thương thảo Hợp đồng

Trong hai thập kỷ qua, tỉ lệ thành công của các dự án tăng hơn hai lần trên toàn thế giới. Điều này được cho là vì các dự án nhỏ hơn và mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn. Các tác giả của bản Tuyên ngôn Agile đã làm sáng tỏ điều này khi họ nhấn mạnh rằng việc để khách hàng tham gia vào quá trình phát triển phần mềm là hết sức cần thiết để dẫn tới thành công.

Các phương pháp phát triển linh hoạt đã thúc đẩy giá trị này bằng cách đưa vào một đồng minh tích cực của khách hàng làm việc sát cánh với đội phát triển. Lấy một ví dụ, một nhóm Scrum đầu tiên có hàng ngàn khách hàng. Sẽ là không khả thi nếu cho phép tất cả khách hàng tham gia vào quá trình phát triển sản phẩm, vì vậy họ chọn ra một vị đại sứ của khách hàng, được gọi là Product Owner (chủ sản phẩm), để đại diện cho không chỉ tất cả khách hàng trong trường hợp này mà còn bao gồm cả quản lý, dịch vụ khách hàng, và các bên liên quan khác. Chủ sản phẩm có trách nhiệm cập nhật danh sách yêu cầu về sản phẩm sau mỗi bốn tuần thời điểm mà nhóm Scrum phát hành phiên bản sản phẩm chạy tốt, có tính đến yếu tố thực tế cùng phản hồi của khách hàng và các bên liên quan. Điều này cho phép khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra.

Một nhóm XP đầu tiên đã bắt đầu với một dự án CNTT nội bộ. Họ có thể có sẵn người sử dụng đầu cuối của công ty trong nhóm làm việc với họ hàng ngày. Khoảng 10% thời gian, các tư vấn viên và nhóm nội bộ có thể tìm được một người dùng cuối có thể làm việc với nhóm từng ngày. 90% thời gian còn lại, họ phải cử ra người đại diện cho khách hàng. Người này, được nhóm XP gọi là Customer (khách hàng), làm việc trực tiếp với người dùng cuối để cung cấp một danh sách các tính năng rõ ràng cùng độ ưu tiên cho phép đội phát triển có thể thực hiện.

Cộng tác với khách hàng (hoặc đại diện của khách hàng) trên cơ sở hàng ngày là một trong những lý do lý giải tại sao các dữ liệu trong ngành công nghiệp cho thấy rằng các dự án linh hoạt có tỉ lệ thành công cao hơn gấp đôi so với các dự án truyền thống tính trung bình trên toàn thế giới. Các phương pháp phát triển linh hoạt đã nhận ra điều đó, và do vậy, chúng đã tạo ra một vị trí đặc biệt trong đội hình phát triển để dành riêng cho vị khách hàng đại diện này.

Phản hồi với thay đổi hơn là bám sát kế hoạch

Phản hồi với thay đổi là điều cần thiết cho việc tạo ra một sản phẩm làm hài lòng khách hàng cũng như mang lại những giá trị kinh doanh. Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với tất cả các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng vì những gì họ thấy không thật sự đúng như những gì họ muốn. Luật Humphrey nói rằng khách hàng không bao giờ biết những gì họ muốn cho đến khi họ thấy phần mềm hoạt động. Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này. Các phương pháp phát triển linh hoạt tìm kiếm sự phản hồi của khách hàng trong suốt dự án để có thể kết hợp thông tin phản hồi và thông tin mới ngay khi sản phẩm đang được phát triển.

Tất cả các phương pháp phát triển linh hoạt đều được tích hợp sẵn những tiến trình thay đổi các kế hoạch trong một khoảng thời gian đều đặn dựa trên những thông tin phản hồi từ phía khách hàng cũng như bên đại diện của khách hàng. Các kế hoạch được thiết kế để sao cho luôn cung cấp giá trị kinh doanh cao nhất trước hết. Bởi vì 80% giá trị nằm trong 20% các tính năng, một dự án phát triển linh hoạt chạy tốt có xu hướng kết thúc sớm, trong khi hầu hết các dự án truyền thống thường kết thúc trễ. Kết quả là, khách hàng thì vui vẻ hơn, và các nhà phát triển thì thích thú với công việc của họ hơn. Các phương pháp phát triển linh hoạt dựa trên những hiểu biết đó, để thành công hơn chúng phải có kế hoạch để thay đổi. Đó là lý do tại sao chúng thiết lập các quy trình, chẳng hạn như Sơ kết và Cải tiến, được thiết kế đặc biệt để thay đổi các ưu tiên thường xuyên dựa trên thông tin phản hồi của khách hàng và giá trị kinh doanh.

Agile là chiếc ô – Các phương pháp được triển khai dưới chiếc ô này

Phát triển linh hoạt bản thân nó không phải là một phương pháp. Nó là một thuật ngữ chung mô tả rất nhiều các phương pháp linh hoạt. Tại thời điểm ký kết Tuyên ngôn Agile năm 2001, những phương pháp này bao gồm: Scrum, XP, Crystal, FDD, và DSDM. Kể từ thời điểm đó, Lean cũng đã nổi lên như là một phương pháp linh hoạt có giá trị do vậy cũng được đưa vào trong chiếc ô của các phương pháp Agile trong hình minh họa dưới đây.

Mỗi phương pháp phát triển linh hoạt có một cách tiếp cận hơi khác nhau để thực hiện các giá trị cốt lõi trong tuyên ngôn Agile, cũng giống như các ngôn ngữ máy tính có các biểu hiện tính năng cốt lõi trong lập trình hướng đối tượng theo những cách khác nhau. Một cuộc khảo sát gần đây cho thấy rằng, khoảng 50% học viên theo học phương pháp phát triển linh hoạt nói rằng đội của họ đang làm Scrum, 20% khác nói rằng họ đang làm Scrum với các thành phần của XP. Khoảng 12% nói rằng họ chỉ áp dụng XP. Do có hơn 80% áp dụng phát triển linh hoạt trên toàn thế giới là sử dụng Scrum và XP, nên bản MSF cho phát triển phần mềm linh hoạt phiên bản 5.0 tập trung vào quy trình cốt lõi và thực tiễn áp dụng của Scrum và XP.

Scrum là một khung làm việc (framework) cho các quy trình phát triển linh hoạt. Nó không bao gồm các vấn đề thực hành, kỹ thuật cụ thể. Ngược lại, XP lại tập trung vào các kỹ thuật thực hành cụ thể nhưng không có một bộ khung làm việc tổng thể cho quá trình phát triển. Điều đó không có nghĩa rằng Scrum khuyên bạn không nên áp dụng các phương pháp thực hành cụ thể hay là XP thì không có quy trình. Ví dụ, ban đầu Scrum áp dụng tất cả các phương pháp thực hành mà bây giờ được biết đến như là XP. Tuy nhiên, khung làm việc Scrum cho việc phát triển phần mềm được thiết kế để có được một nhóm nghiên cứu bắt đầu trong hai ba ngày, trong khi thực hành kỹ thuật phải mất nhiều tháng để thực hiện. Vì vậy, nó để lại câu hỏi khi nào (hay không) để thực hiện các thực hành cụ thể đối với mỗi đội. Hai đồng tác giả của Scrum là Jeff Sutherland và Ken Schwaber khuyến nghị rằng Nhóm Scrum bắt đầu ngay lập tức và tạo ra danh sách các trở ngại và kế hoạch cải tiến quy trình. Khi việc thực hành về kỹ thuật được xác định là trở ngại, nhóm nên xem xét các phương pháp thực hành của XP như là một cách để cải tiến. Các nhóm tốt nhất sử dụng Scrum bổ sung với thực hành XP. Scrum giúp XP về mặt quy mô, XP giúp Scrum làm việc tốt hơn.

Bảng sau cho thấy những thuật ngữ quan trọng tương ứng giữa Scrum và XP.

Nguồn: MSDN