0

5 câu hỏi về Agile

Tôi đã được phỏng vấn về phát triển Agile vào mùa hè gần đây với PM*Boulevard. Bài dưới đây được tôi trích ra từ bài phỏng vấn với PM*Boulevard, cập nhật thêm một số câu trả lời và thêm vào một số bình luận của tôi.

5Qs on Agile (5 câu hỏi về Agile) với Steve McConnell

Độc giả của tạp chí Software Development đánh giá Steve McConnell là một trong ba người có ảnh hưởng lớn nhất trong ngành công nghiệp phần mềm. Steve, giám đốc điều hành và giám đốc công nghệ phần mềm tại Construx Software, đã hào phóng đồng ý khởi động “5Qs on Agile” của chúng tôi bằng cách trả lời những câu hỏi thường gặp về phát triển Agile như dưới đây.

 
Câu hỏi 1: Tại sao sử dụng những phương pháp Agile?

Những phương pháp Agile tập trung vào những phân đoạn (iterations) ngắn hơn, trong đó phần mềm thường xuyên được mang tới mức độ chất lượng với “khả năng phát hành” (releasable), thường là hàng tuần đến hàng tháng. Những phân đoạn ngắn cũng cung cấp nhiều lợi ích về mặt công nghệ và quản lý. Về mặt công nghệ, lợi ích chính là giảm thiểu rủi ro tích hợp vì số lượng phần mềm được tích hợp thường được giữ ở mức nhỏ. Những phân đoạn nhỏ cũng giúp việc kiểm soát chất lượng bằng cách thường xuyên hướng tới trạng thái “khả năng phát hành”, và ngăn cản dự án khỏi việc tích luỹ một số lượng lớn công việc sửa lỗi. Về mặt quản lý, những phân đoạn thường xuyên liên tục cung cấp bằng chứng của sự tiến triển, có xu hướng dẫn đến khả năng thể hiện tốt trạng thái, mối quan hệ tốt với khách hàng và tinh thần của nhóm tốt.

Những phương pháp Agile cũng thường xử lý yêu cầu linh động hơn những phương pháp truyền thống. Trong một số môi trường, đó là điểm cộng, và trong một số khác, đó là điểm trừ. Nếu bạn đang làm việc trong một môi trường không cần nhiều khả năng dự báo tầm xa về nhóm chức năng, việc xử lý yêu cầu linh động có thể tiết kiệm rất nhiều công việc đặc tả chi tiết yêu cầu và tránh những “yêu cầu hỏng” (requirements spoilage), thường đi cùng với những công việc tồn đọng kéo dài của những yêu cầu chi tiết.

 
Câu hỏi 2: Thách thức lớn nhất khi thực thi những phương pháp Agile?

Thách thức lớn nhất chúng tôi nhìn thấy qua việc kinh doanh tư vấn và đào tạo của mình là tiến bước. Bạn không thể chỉ nói rằng bạn đang làm Agile. Bạn phải tiếp tục qua những hành động cụ thể. Tất nhiên, đây cũng là vấn đề chúng ta đã thấy nhiều năm trước với phương pháp lập trình hướng đối tượng, và trước nữa là với phương pháp lập trình có cấu trúc, vì thế đây không chỉ là vấn đề của riêng Agile.

Như chúng tôi thấy, thách thức cụ thể lớn nhất chỉ đơn giản là “xoay chuyển chiến hạm” trong một tổ chức lớn để vượt qua những quán tính cố hữu của những công việc thực tế và những kỳ vọng; và, định hướng việc thực hiện những kỳ vọng này theo cách khác. Bạn phải hội tụ được sự quyết tâm để thực sự làm việc với những phân đoạn ngắn. Bạn phải build (dựng thành phần mềm) thường xuyên, ít nhất là hàng ngày, và bạn phải phát triển kỷ luật để đảm bảo bản build tốt. Bạn phải đẩy nhanh mỗi phân đoạn tới mức độ chất lượng với “khả năng phát hành” ngay cả khi điều đó khó thực hiện trong lần đầu tiên. Như tiền lệ, vấn đề này không chỉ của riêng Agile. Nếu chúng ta đang làm việc trong một tổ chức và nhận thấy rằng nhu cầu lớn nhất là thực hiện tốt hơn công việc xác định yêu cầu phía trước (điều này không linh hoạt lắm), “xoay chuyển chiến hạm” để định nghĩa những yêu cầu phía trước tốt hơn sẽ là công việc khó khăn.

 
Câu hỏi 3: Agile sẽ thành công nhất ở những môi trường nào?

Một cách toàn diện, tôi thấy Agile phù hợp nhất với những môi trường có ngân sách cố định hàng năm, quy mô nhóm cố định hàng năm (theo ngân sách), và sứ mệnh của mỗi nhân viên dự án là mang lại những chức năng nghiệp vụ có giá trị nhất, mà họ có thể mang lại trong thời gian của cả năm với quy mô nhóm cố định. Môi trường này thường được mô tả là tổ chức phát triển hệ thống nghiệp vụ nội bộ (in-house).

Linh hoạt toàn diện (đặc biệt với những yêu cầu linh động) thường ít phù hợp với những công ty bán phần mềm, vì việc duy trì linh hoạt quá nhiều chức năng đi ngược lại với mục tiêu cung cấp khả năng dự báo trung và dài hạn. Chúng tôi đã thấy nhiều tổ chức đánh giá khả năng dự báo cao hơn những yêu cầu linh động. Nghĩa là, họ đánh giá khả năng thực hiện các cam kết với khách hàng hay thị trường trọng điểm hơn là đánh giá khả năng “phản hồi với thay đổi”.

Tuy nhiên, với những môi trường không linh hoạt toàn diện, chúng tôi cũng thấy nhiều thực hành Agile phù hợp với đại đa số những môi trường. Những phân đoạn phát triển ngắn gần như luôn giá trị, cho dù bạn định nghĩa 5% hay 95% yêu cầu sắp tới. Luôn giữ phần mềm gần tới mức độ chất lượng với “khả năng phát hành” trong tất cả các phần đoạn gần như luôn có giá trị. Scrum dường như được áp dụng rộng rãi như một phong cách quản lý và kỷ luật. Những đội nhỏ và được trao quyền thường luôn hữu ích. Tôi thể hiện chi tiết về những điểm mạnh và điểm yếu chi tiết của những thực hành phát triển linh hoạt trong bài trình bày về điều hành tại Kế thừa của Phát triển Agile.

 
Câu hỏi 4: Tương lai của Agile?

Agile đã trở thành một từ đồng nghĩa với “thực hành phần mềm hiện đại” (“modern software practices that work”) rộng rãi, vì thế tôi nghĩ rằng tương lai của Agile với chữ cái hoa “A” (tác giả phân biệt “agile” – sự linh hoạt, và “Agile” – chỉ phương pháp Agile) cũng giống như Object Oriented hay Structured trước đây. Chúng ta gần như không nói về lập trình Object Oriented nữa; chỉ đơn giản là lập trình. Tương tự, tôi nghĩ Agile cũng theo dòng chảy chung, như trong vài năm tới chúng ta sẽ không nói thêm về Agile nữa, bất cứ khi nào thích hợp, chúng ta chỉ nói lập trình, và giả định rằng mọi người đều hiểu Agile.

 
Câu hỏi 5: Ngay bây giờ, ông có thể giới thiệu với độc giả những sách, blog, podcast, website hay những nguồn thông tin mà ông thấy thú vị hoặc hấp dẫn?

Tôi thấy thú vị nhất với diễn đàn thảo luận Software Development Best Practices (Những bài học thực tiễn về phát triển phần mềm) mà chúng tôi đã triển khai vào tuần trước, tại http://forums.construx.com/ . Gần đây, tôi cũng bắt đầu viết blog, và bạn có thể đọc blog của tôi tại: http://blogs.construx.com/blogs/stevemcc/default.aspx. Hãy liên hệ với tôi qua e-mail This email address is being protected from spambots. You need JavaScript enabled to view it.. 

 

Bình luận bổ sung (Tháng 10, 2007)

Sau khi bài phỏng vấn được đăng vào tháng Tám năm 2007, tôi nhận được một email rất thú vị, nói rằng “Ồ, có vẻ ông thực sự là chuyên gia về Agile. Điều gì đã xảy ra?”

Tôi đã bất ngờ với email đó vì tôi đã không nghĩ những bình luận của mình ở 5Qs đặc biệt “chuyên gia về sự linh hoạt”. Tôi nghĩ họ đã nhấn mạnh sức mạnh của sự linh hoạt và cũng nhấn mạnh một số phương thức thất bại phổ biến. Một lý do khác khiến bình luận này thú vị là gợi ý về việc trước đây tôi đã “chống lại sự linh hoạt”. Tôi chưa bao giờ là “chuyên gia về sự linh hoạt” hay “người chống lại sự linh hoạt” – tôi đã luôn là chuyên gia cho bất cứ (phương pháp) thực-hành-công-việc-tốt-nhất nào. Trong nhiều tình huống thực hành – để làm được tốt nhất – được kết hợp với phát triển linh hoạt. Và trong nhiều tình huống khác, những thực hành cũ lại là tốt nhất.

Vì vậy, tôi không là “chuyên gia về sự linh hoạt” hay “người chống lại sự linh hoạt”. Tôi không là chuyên gia CMM hay người chống lại CMM, chuyên gia về BDUF hay người chống lại BDUF, hay chuyên gia về lập trình theo cặp (pair programming) hay người chống lại (phương pháp) lập trình theo cặp. Về vấn đề này, tôi cũng không là chuyên gia về (phương pháp) thác nước (waterfall) hay người chống lại (phương pháp) thác nước. Tại Construx, sau nhiều năm, chúng tôi đã làm việc với một số lượng lớn những công ty và chúng tôi đã gặp ít nhất một môi trường hoạt động tốt nhất với mỗi thực hành kể trên. Thế giới rộng lớn của dự án phần mềm đa dạng đến đáng ngạc nhiên, và những thứ gọi là thực hành phát triển phần mềm cũng đa dạng đến đáng ngạc nhiên như vậy. Đơn giản là, Agile đã thêm vào những công cụ cho chiếc hộp công cụ cho chúng ta có tập hợp phong phú hơn để lựa chọn công cụ thích hợp với bất cứ công việc cụ thể nào.

 

Tài nguyên

 Nguồn: blogs.construx.com | Người dịch: Nguyễn Văn Hiển