Đọc được bài báo cũ từ 2011 trên PC World VN, tôi đoán là nhân dịp tổ chức hội thảo kiểm thử và tự động hóa VISTACON, có mấy nhận định của hai “đại ca” mà mình yêu mến khi học testing: GS Kaner và ông Hacket. Đáng tiếc là những nhận định này đều là những ngộ nhận thường gặp khi thảo luận về Agile:
1.”Một trong những yêu cầu tiên quyết trong dự án PTPMLH là các thành viên tham gia phải có trình độ cao và tương đối cân bằng, có tinh thần làm việc tích cực và kỷ luật cá nhân cao để đáp ứng nhu cầu liên tục tự sáng tạo và cải tiến”
— Nhận định kiểu này nếu xuất hiện từ 1995 thì còn được nhiều người ủng hộ, vì thiếu thông tin, cũng vì khi đó XP đang phổ biến, mà tư tưởng XP thì cái gì cũng extreme, nên dễ gây ngộ nhận.
Thực tế là Agile không có khuyến cáo nào cản trở team hỗn tạp, gồm đủ trình độ làm việc tốt với nhau. Không những thế Agile\Lean còn hỗ trợ mạnh mẽ cho việc học tập. Một trong những chính sách bắt buộc mà Joe Justice ở WIKISPEED dùng để phát triển đội ngũ của mình là ghép cặp nhân viên: một nhân viên học việc sẽ cùng làm việc với một nhân viên già nghề hơn, chỉ một thời gian ngắn họ sẽ thạo nghề và bắt đầu có đóng góp vào thành quả chung của nhóm. Một team Agile không cần toàn siêu nhân! Ken Schwaber nói “Scrum is for idiots”. Làm gì mà phải yêu cầu trình độ cao!?
2. “Những hướng phát triển sai sẽ tiêu tốn nguồn lực của dự án, nhất là quỹ thời gian. Theo phương pháp này, thường phải đợi đến khi kết thúc các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp không. Do đó, nếu phải tiêu tốn thời gian liên lạc giữa nhóm phát triển gia công offshore và khách hàng thì dự án kéo lùi tiến độ. Trong thực tế, nếu khách hàng ở nước ngoài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và múi giờ. Khi đó, phương pháp PTPMLH sẽ là không hợp lý”
— Thực tế là phân đoạn trong Agile ngắn nên dễ dàng phát hiện nếu hướng đi có sai và dễ dàng điều chỉnh để quay lại đường đúng đắn. Một phương án hoạch định dài hạn kiểu prescriptive mới rủi ro hơn trong dự đoán. Xem các bài học thất bại nhãn tiền ở đây, và ở đây. Về nỗi lo sợ lệch múi giờ và đa văn hóa, rõ ràng đó là khó khăn. Nhưng làm phương pháp gì thì cũng gặp phải khó khăn kiểu ấy. Điều quan trọng là agile team vẫn có thể vượt qua được để cán đích. Hãy xem đội Xebia, họ có đội phân tán trên bốn châu lục, thực hiện trên quy mô lớn mà vẫn thành công với năng suất cực cao. Trong sprint ngắn 1 tuần mà còn không biết được đúng hay sai, thì làm sao biết được cái đúng sai của 1 năm hay dài hơn? Còn khi phân tích ROI, tôi không dám chắc là những chi phí cho việc liên lạc\giao tiếp lại là lãng phí. Communication là một chương lớn trong lí thuyết quản lí dự án. Chỉ có một nhà quản lí tồi mới không bỏ nỗ lực và chi phí thích đáng cho communication.
3. “Các chuyên gia trong lĩnh vực PM cũng đồng ý rằng PTPMLH thường khó mở rộng quy mô, không phù hợp với các dự án PM lớn có nhiều nhân lực.”
Lời này là của nhà báo “gắp chữ bỏ mồm chuyên gia” rồi. Làm gì có chuyện các chuyên gia đều đồng ý thế. Nếu tính chỉ ba vị trong bài báo là GS Kaner, GS Trần, và Mr. Hacket thì có khi đúng là họ đồng ý thật. Nhưng đó là mới chỉ có 3 người là chuyên gia thôi. Nhưng họ đều có background là testing, perspective của họ còn lâu mới tương đồng với phần nhiều những chuyên gia phát triển phần mềm, phát triển sản phẩm và các “chuyên gia phần mềm” khác.
Thực tế là các ‘sách’ về Scaling Agile (xem Bas Vodde, Mike Cohn, Hendrik Kniberg, Jeff Sutherland và Ken Schwaber ..) đã có từ hơn một thập kỉ, nay không có gì là bí mật cả. Ngay cả cái đội Xebia lấy ví dụ ở trên có lúc lên đến 500 người, dự án như thế đã được gọi là đủ lớn chưa? Hay như team mới nổi WIKISPEED, vận hành theo Agile, đã có ở gần (hay trên, tôi chưa kịp cập nhật) 20 thành phố trên thế giới, vẫn cộng tác tốt với nhau.
Những kĩ thuật scaling nay trở thành cơ bản, để Agile không những phát huy tối đa năng lực cho các nhóm nhỏ, nó còn có thể giúp các nhóm lớn đạt hiệu suất cao hơn nhiều.
Năm 2011, vẫn có những nhận định ngô nghê như vậy, có vẻ như vẫn còn mấy người trong giới software testing vẫn thích đứng từ xa, không cùng hội cùng thuyền với “bọn” development. Là do không chịu học, hay thích nói lấy được, hay nhà báo trích dẫn sai?
Thấy bài này đăng trên mục “Kinh doanh – Giải pháp”. TƯ VẤN KIỂU NÀY THÌ CHẾT!
_____________________________________________
Phát triển phần mềm linh hoạt
Nhật Khang
Bài gốc: http://www.pcworld.com.vn/articles/quan-ly/tu-van/2011/04/1223853/phat-trien-phan-mem-linh-hoat/
Phát triển phần mềm linh hoạt (PTPMLH) – Agile software development – hay Lập trình linh hoạt (Agile programming) bao gồm và khuyến khích các thay đổi mang tính tiến hóa ngay trong vòng đời dự án phát triển phần mềm. PTPMLH cũng có những ưu và khuyết điểm nhất định!
 |
Dễ cải tiến…
Đa số các phương pháp PTPMLH đều nhắm đến tối thiểu rủi ro bằng cách phát triển phần mềm (PM) trong thời gian ngắn, gọi là các bước lặp. Mỗi bước lặp giống như một dự án PM thu nhỏ, bao gồm tất cả các tác vụ cần thiết để cho ra nâng cấp. Do mức độ tự do sáng tạo cao trong từng bước lặp, kết quả thu được có thể rất khác biệt. Điều này tùy thuộc vào định hướng phát triển xác định tại đầu mỗi bước lặp, và những chuẩn mực yêu cầu (requirements) nhất định được phía khách hàng hoặc chính nhóm phát triển đặt ra tại thời điểm thành lập dự án.
Theo giả thiết trong các phương pháp phát triển PM truyền thống (mà tiêu biểu là mô hình thác đổ – waterfall), các yêu cầu ban đầu thường ít thay đổi so trong suốt quá trình phát triển và sử dụng. Tuy nhiên, trên thực tế – nhất là môi trường ứng dụng Internet – thì các yêu cầu thay đổi rất thường xuyên. Từ đó có thể ảnh hưởng đến chất lượng và tiến độ công việc, thậm chí có khi phải thiết kế lại toàn bộ cấu trúc PM cho phù hợp với yêu cầu mới. Ở giai đoạn Web 2.0, các ứng dụng Internet cũng phải liên tục thay đổi để thích ứng với nhu cầu chia sẻ thông tin đa dạng của cộng đồng sử dụng. Đó cũng chính là lý do khiến mô hình PTPMLH đang ngày một phổ biến, do khả năng thay đổi yêu cầu mang tính tiến hóa.
Một lĩnh vực khác cũng có tiềm năng rất lớn để ứng dụng cách quản lý dự án PTPMLH là ngành kiểm thử. Dự án kiểm thử thường được thiết kế làm nhiều cấp hay nhiều giai đoạn khác nhau. Cấu trúc dự án gắn liền với cấu trúc thiết kế của PM được kiểm thử. Việc ứng dụng khái niệm “linh hoạt” trong từng giai đoạn sẽ cho phép đơn vị kiểm thử tự kiểm tra và cải tiến tính năng của hệ thống kiểm thử nhanh chóng. Xa hơn nữa, quá trình cải tiến liên tục qua các bước lặp giúp các công ty thiết lập hệ thống PM kiểm thử tự động với cơ sở dữ liệu đa dạng. Từ đó, thời gian và công sức thực hiện dự án kiểm thử sẽ giảm bớt….
| “Phương pháp PTPMLH chỉ phát huy tác dụng tốt nhất đối với các dự án yêu cầu nhóm nhân lực không lớn, và đặc biệt thích hợp để phát triển ứng dụng trên Internet”. |
… nhưng dễ phí phạm tài nguyên
Không có phương pháp nào luôn tối ưu. Một trong những yêu cầu tiên quyết trong dự án PTPMLH là các thành viên tham gia phải có trình độ cao và tương đối cân bằng, có tinh thần làm việc tích cực và kỷ luật cá nhân cao để đáp ứng nhu cầu liên tục tự sáng tạo và cải tiến. Ngoài ra, mô hình nhóm gia công không cùng vị trí địa lý với chủ dự án (offshore) thường yêu cầu phải có một đại diện khách hàng có mặt cùng địa điểm với nhóm phát triển. Người này có thể kịp thời giải đáp các thắc mắc ngay khi có vấn đề phát sinh và duy trì PM phát triển đúng hướng. Nếu tốc độ sáng tạo nhanh nhưng phản hồi chậm cũng dẫn tới phí phạm tài nguyên dự án và có thể chuyển sang hướng phát triển không phù hợp.
Ông Cem Kaner, Giáo sư ngành Công nghệ PM – Học viện Kỹ thuật Florida ở Mỹ, cho rằng ưu điểm lớn nhất của phương pháp PTPMLH là khả năng đưa ra và theo đuổi nhiều hướng đi trong quá trình phát triển. Nhưng đây cũng chính là khuyết điểm của nó. “Những hướng phát triển sai sẽ tiêu tốn nguồn lực của dự án, nhất là quỹ thời gian. Theo phương pháp này, thường phải đợi đến khi kết thúc các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp không. Do đó, nếu phải tiêu tốn thời gian liên lạc giữa nhóm phát triển gia công offshore và khách hàng thì dự án kéo lùi tiến độ. Trong thực tế, nếu khách hàng ở nước ngoài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và múi giờ. Khi đó, phương pháp PTPMLH sẽ là không hợp lý”.
|
Khó áp dụng trong dự án lớn?
Các chuyên gia trong lĩnh vực PM cũng đồng ý rằng PTPMLH thường khó mở rộng quy mô, không phù hợp với các dự án PM lớn có nhiều nhân lực. Các dự án lớn thường được chia làm nhiều phần nhỏ, cấu trúc tương đối chặt chẽ và không có chỗ cho sai sót. Các nhóm phát triển cần thống nhất rất cao về định hướng và hầu như không còn nhiều chỗ cho sáng tạo, dù nó cũng cần qua nhiều thảo luận để đưa vào ứng dụng thực tế. Với các dự án này, các nhóm gia công nếu có sẽ là một phần của kiến trúc lớn, dưới sự kiểm soát chặt chẽ khách hàng.
Những điểm nói trên đi ngược với bản chất của PTPMLH. Sẽ rất khó quản lý khi dự án đạt quy mô vài ngàn nhân lực. Do đó, hiện tại phương pháp PTPMLH được áp dụng chủ yếu cho các dự án tầm trung trở xuống, ở các mảng ứng dụng web, ứng dụng trên di động (web applications, phone applications) và các dự án gia công kiểm thử trong và ngoài nước.
Khắc phục điểm yếu của PTPMLH
Michael Hackett, Phó tổng Giám đốc Công ty Kiểm thử LogiGear: “Các nhóm gia công từ xa (offshore) muốn áp dụng PTPMLH cần có chuyên môn, kinh nghiệm, khả năng giao tiếp tốt, sự hiểu biết liên văn hóa, sự tin tưởng thông hiểu lẫn nhau giữa các thành viên và giữa các nhóm với nhau”.
Quang Trần, Giáo sư CNTT, Đại học Quốc tế RMIT Việt Nam: “Yêu cầu đối với đại diện khách hàng làm việc chung với nhóm phát triển PM là khá cao. Đây phải là một người có đầy đủ kiến thức chuyên môn, hiểu rõ định hướng ban đầu của dự án, và quan trọng nhất là phải có đủ thẩm quyền đưa ra quyết định. |
