Trong lĩnh vực phát triển phần mềm, Agile là tư tưởng tiếp cận yêu cầu và triển khai giải pháp thực thi, thông qua sự phối hợp của khách hàng và đội phát triển. Các đội phát triển được xây dựng gồm nhiều thành phần với các vai trò khác nhau, dựa trên tinh thần tự tổ chức và quản lý.

    Agile hỗ trợ việc lên kế hoạch thích nghi, phát triển có tính tiến hóa, bàn giao sớm và liên tục. Nó khuyến khích sự phản hồi linh hoạt đối với những thay đổi.

    Agile là sự tổng quát hóa của nhiều phương pháp hoặc framework về quy trình phát triển trước đó: Scrum, Extreme Programming,...

    Agile ra đời cũng là để giải quyết các vấn đề của quy trình phát triển Waterfall: nổi bật nhất là việc đối ứng được với sự thay đổi liên tục của phần mềm.

    Các nguyên tắc/tôn chỉ của Agile trong quy trình phát triển phần mềm:

• Sự tương tác và các cá nhân ưu tiên hơn công cụ và quy trình.
• Sản phẩm phần mềm ưu tiên hơn tài liệu đầy đủ (giá trị của sản phẩm hơn là tài liệu xây dựng lên sản phẩm).
• Sự phối hợp với khách hàng ưu tiên hơn những thỏa thuận hợp đồng (khách hàng cần tham gia liên tục vào việc phát triển sản phẩm hơn là chỉ ở trên giấy tờ hợp đồng ban đầu)
• Đối ứng với những thay đổi ưu tiên hơn việc lên kế hoạch.

    Vế bên trái ưu tiên hơn, chứ không có nghĩa là bỏ đi vế bên phải.

    Theo như Scott Ambler, các tuyên ngôn trên có thể được giải thích cụ thể như sau:

•     Công cụ và quy trình là quan trọng, nhưng là quan trọng hơn khi mọi người có liên quan làm việc với nhau hiệu quả.

•     Tài liệu phần mềm đầy đủ giúp hiểu được cách mà phần mềm được tạo và cách sử dụng nó, nhưng điểm mục đích chính của quy trình phát triển là tạo ra phần mềm, chứ không phải tạo tài liệu.

•     Hợp đồng là quan trọng nhưng không thể thay thế được việc phối hợp với khách hàng để khai thác những điều mà họ thực sự cần.

•     Một bản kế hoạch dự án cụ thể là quan trọng, nhưng không được phép quá cứng nhắc để áp dụng những thay đổi về công nghệ hoặc môi trường, độ ưu tiên mà khách hàng/người dùng cuối đưa ra, cũng như việc nhận thức vấn đề và giải pháp của mọi người.

    Nhóm phát triển sản phẩm và những người quản lý dự án cần đánh giá xem nhóm có đang đi theo các nguyên tắc của Agile và những hành động/ứng xử có phù hợp với các giá trị cốt lõi của Agile. Tuyên ngôn Agile được sinh ra từ kinh nghiệm thực tế, chứ không phải từ lý thuyết.

    Bài viết dưới đây sẽ phân tích về bốn giá trị cốt lỗi của tuyên ngôn Agile. Từ đó, giúp người đọc hiểu được ý nghĩa của chúng khi áp dụng vào thực tế. Hiểu được các giá trị này hỗ trợ như thế nào để đạt được những mục tiêu nắm bắt thị trường, đối ứng với thay đổi và nâng cao sự đổi mới về con người.

Cá nhân và sự tương tác hơn là quy trình và các công cụ

    Khi mỗi cá nhân được cống hiến các giá trị riêng biệt của mình cho sản phẩm, kết quả tạo ra có thể vượt hơn mong đợi. Sự tương tác trực tiếp để cùng giải quyết vấn đề sẽ làm sáng tỏ mục đích chung đang hướng đến. Hơn thế nữa, các thỏa thuận thông qua quy trình và công cụ sẽ đơn giản hơn nhiều so với cách thông thường.

    Việc trao đổi trực tiếp về một vấn đề của sản phẩm có thể giải quyết nhiều vấn đề trong khoảng thời gian tương đối ngắn. Cố gắng mô phỏng một cuộc trò chuyện trực tiếp bằng email, văn bản hay tài liệu, có thể dẫn đến những chi phí và sự chậm trễ đáng kể. Thay vì làm tăng tính tường minh, những kiểu liên lạc được quản lý/kiểm soát này thường sẽ không rõ ràng, tốn thời gian và khiến nhóm phát triển mất tập trung vào công việc tạo ra sản phẩm.

    Bảng dưới đây sẽ so sánh về ưu nhược điểm giữa việc đề cao cá nhân/tương tác so với việc đề cao công cụ/tiến trình.

    Nếu các quy trình và công cụ được coi là cách để quản lý việc phát triển sản phẩm và mọi thứ liên quan đến nó, thì con người và cách họ tiếp cận công việc phải phù hợp với các quy trình và công cụ. Sự phù hợp này gây khó khăn trong việc đáp ứng những ý tưởng, yêu cầu và tư duy mới. Tuy nhiên, các phương pháp tiếp cận Agile coi trọng con người hơn quy trình. Việc coi trọng này tập trung vào năng lượng, sự đổi mới và khả năng giải quyết vấn đề của từng cá nhân trong nhóm phát triển. Trong Agile, quy trình và công cụ cũng được sử dụng, nhưng chúng được sắp xếp có chủ ý và hỗ trợ trực tiếp cho việc tạo ra sản phẩm. Quy trình hoặc công cụ càng mạnh mẽ, chi phí về tiền bạc và thời gian để quản lý/chăm sóc càng lớn. Khi lấy con người làm mục tiêu phía trước và trung tâm, kết quả tạo ra sẽ là một bước nhảy vọt về năng suất. Môi trường Agile lấy con người làm trung tâm, sự tham gia của các bên và có thể dễ dàng thích nghi với những ý tưởng và sáng kiến mới.

Phần mềm thành phẩm hơn là tài liệu đầy đủ

    Nhóm phát triển nên tập trung vào việc tạo ra những tính năng thực tế của sản phẩm. Trong agile, cách duy nhất để xác định đã thực sự hoàn thành một yêu cầu của sản phẩm là việc tạo ra tính năng chạy được mà đáp ứng với yêu cầu đó. Đối với sản phẩm phần mềm, phần mềm thành phẩm có nghĩa là phần mềm đáp ứng được định nghĩa về sự hoàn thành: ít nhất là đã phát triển, kiểm thử, tích hợp và tạo tài liệu xong. Sau cùng, sản phẩm chạy được là lý do chính cho việc đầu tư.

    Bạn đã bao giờ từng ở trong một cuộc họp tiến độ mà chỉ báo cáo hoàn thành được 75 phần trăm dự án ? Sẽ ra sao nếu khách hàng nói rằng "Chúng tôi cạn vốn rồi. Giờ chúng tôi có thể nghiệm thu 75 phần trăm sản phẩm không ?". Đối với một dự án truyền thống, bạn sẽ không có bất cứ phần mềm hoạt động nào để bàn giao cho khách hàng. 75 phần trăm hoàn thành có nghĩa là đang làm dở 75 phần trăm và 0 phần trăm hoàn thành. Tuy nhiên, trong Agile, bằng việc sử dụng định nghĩa hoàn thành, bạn có thể bàn giao chức năng của 75 phần trăm yêu cầu của sẳn phẩm - 75 phần trăm yêu cầu có độ ưu tiên cao nhất.

    Mặc dù cách tiếp cận của agile có nguồn gốc từ lĩnh vực phát triển phần mềm, nhưng có thể áp dụng cho cả những loại sản phẩm khác. Giá trị agile này có thể phát biểu là "Chức năng chạy được hơn là tài liệu đầy đủ".

    Các công việc ngoài lề cần được đánh giá xem có hỗ trợ hay gây ảnh hưởng đến việc tạo ra sản phẩm cuối cùng hay không. Bảng dưới đây đưa ra một vài ví dụ về tài liệu dự án truyền thống và tính hữu dụng của chúng. Hãy nghĩ xem liệu các tài liệu được tạo ra trong một dự án gần đây mà bạn tham gia có mang lại giá trị gia tăng cho chức năng cần bàn giao tới khách hàng hay không.

    Xác định tài liệu hữu dụng

    Trong Agile, vừa đủ mang hàm ý tích cực, nghĩa là một công việc, văn bản, cuộc họp hay bất cứ thứ gì khác được tạo ra chỉ nên bao gồm những gì cần thiết nhất để đạt được mục tiêu. Vừa đủ có tính thực tiễn và hiệu quả. Trái ngược với vừa đủ là kỹ lưỡng, hay có thể hiểu là thêm thắt những thứ không cần thiết và tốn công đối với một công việc, văn bản, cuộc họp hay bất cứ thứ gì khác.

    Quá trình phát triển nào cũng yêu cầu có tài liệu nào đó. Trong Agile, tài liệu hữu dụng chỉ khi chúng hỗ trợ việc phát triển và vừa đủ để cung cấp thiết kế, bàn giao và triển khai một sản phẩm chạy được theo cách trực tiếp, không cầu kỳ nhất có thể. Cách tiếp cận hướng Agile đơn giản hóa đáng kể các thủ tục hành chính liên quan đến kiểm soát thời gian, chi phí, kiểm soát phạm vi hay việc báo cáo.

    Nhóm phát triển theo tư tưởng Agile tạo ra tài liệu ít hơn nhưng sắp hợp hợp lý hơn để giảm thời gian bảo trì tài liệu và có cái nhìn rõ hơn đối với các vấn đề tiềm tàng. Với cách tiếp cận này, nhóm phát triển dành nhiều thời gian hơn cho việc phát triển và ít thời gian hơn cho tài liệu, tạo ra cách bàn giao sản phẩm hiệu quả hơn.

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

    Khách hàng thực sự không phải kẻ thù.

    Các tiếp cận quản lý dự án truyền thống thường giới hạn sự tham gia của khách hàng vào một số giai đoạn phát triển.

•     Bắt đầu dự án: Khi khách hàng và nhóm dự án đàm phán chi tiết hợp đồng.

•     Bất cứ khi nào phạm vi của dự án thay đổi: Khi khác hàng và nhóm dự án đàm phán những thay đổi trong hợp đồng.

•     Kết thúc dự án: Khi nhóm phát triển bàn giao một sản phẩm hoàn thiện cho khách hàng. Nếu sản phẩm không đáp ứng được đúng kỳ vọng của khách hàng, nhóm dự án và khách hàng đàm phán những thay đổi bổ sung trong hợp đồng.

    Sự chú trọng vào hợp đồng, tránh thay đổi phạm vi và hạn chế sự tham gia trực tiếp của khách hàng không khuyến khích những ý kiến đóng góp có giá trị của khách hàng và thậm chí có thể tạo ra mối quan hệ đối nghịch giữa khách hàng và nhóm dự án.

    Lúc bắt đầu dự án là thời điểm nhận thức về sản phẩm là ít nhất. Việc đóng khung những chi tiết về sản phẩm trong hợp đồng ban đầu đồng nghĩa với việc các quyết định được tạo ra dựa trên nhận thức không đầy đủ. Nếu linh hoạt khi tìm hiểu về sản phẩm và khách hàng mà sản phẩm hướng tới, kết quả cuối cùng sẽ là một sản phẩm có giá trị hơn.

    Những người tiên phong theo agile hiểu rằng sự hợp tác, thay vì đối đầu, đã tạo ra những sản phẩm tốt hơn, gọn gàng hơn, hữu ích hơn. Kết quả của sự hiểu biết này là các phương pháp agile biến khách hàng trở thành một phần của quá trình phát triển sản phẩm liên tục.

    Sử dụng phương pháp tiếp cận agile trong thực tế sẽ giúp các cá nhân trải nghiệm mối quan hệ đối tác giữa khách hàng và nhóm phát triển. Trong đó, việc khám phá, đặt câu hỏi, tìm tòi và điều chỉnh trong quá trình phát triển sản phẩm diễn ra thường xuyên, chấp nhận được và có hệ thống.

Đáp ứng với các thay đổi hơn là làm theo kế hoạch đã định

    Thay đổi là công cụ có giá trị để tạo ra những sản phẩm chất lượng. Nhóm dự án có thể đáp ứng nhanh chong đối với khách hàng, người dùng sản phẩm và thị trường có thể phát triển các sản phẩm hữu ích, phù hợp mà mọi người muốn sử dụng.

    Tuy nhiên, các phương pháp quản lý dự án truyền thống lại cố gắng vật lộn và né tránh thay đổi. Các quy trình quản lý thay đổi nghiêm ngặt và cấu trúc ngân sách không thể đáp ứng các yêu cầu sản phẩm mới khiến việc thay đổi trở nên khó khăn. Các nhóm dự án truyền thống thường tuân theo kế hoạch một cách mù quáng, bỏ lỡ các cơ hội để tạo ra các sản phẩm có giá trị hơn hoặc thậm chí tệ hơn là không thể phản ứng kịp thời với các điều kiện thay đổi của thị trường.

    Biểu đồ dưới đây cho thấy mối quan hệ giữa thời gian, cơ hội thay đổi và chi phí thay đổi đối với một dự án truyền thống. Khi thời gian - và kiến thức về sản phẩm - tăng lên, khả năng thực hiện thay đổi giảm và chi phí cao hơn.

    Trái ngược lại, quy trình phát triển hướng Agile có khả năng thay đổi một cách hệ thống. Tính linh hoạt của hướng tiếp cận agile làm gia tăng độ ổn định vì các thay đổi về sản phẩm là có thể dự đoán và quản lý được. Nói cách khác, thay đổi được chờ đón và không làm gián đoạn đối với một nhóm agile.

    Khi các thay đổi mới diễn ra, nhóm dự án kết hợp những điều thực tế này vào công việc đang diễn ra. Bất kỳ thứ mới mẻ nào cũng trở thành cơ hội để tạo ra giá trị gia tăng thay vì trở ngại cần tránh, mang lại cho các nhóm phát triển cơ hội thành công lớn hơn.

    Lược dịch và tham khảo:

    Georgette C. Beatty, 4 Values of the Agile Manifesto

    Wikipedia, Agile software development

    Wikipedia, Phát triển phần mềm linh hoạt