tester49
13-01-2011, 10:30 AM
Phát triển phần mềm linh hoạt Agile Sofrware development – hay Lập Trình linh hoạt (Agile programining) bao gồm và khuyến khích các thay đổi mang tính tiến hóa ngay tróng vòng đời dự án ph1t triền phần mềm. cũng có những ưu và khuyết điểm nhất định.
Nhật Khang
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,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 sang tạo cao trong từng bước lặp, kết qủa 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 đượcp hía khách hang 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 đổ - water fall) các yêu cầu ban đầu thường ít thay đổo so trong sướ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 interenet – thì các yêu cầu thay đổ thường 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ộ yêu cầu cấu trúc cho PM cho phù hợp với yêu cầu mới. Ở giai đoạn Web 2.0 các ứng dụng Interent 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ử phần mềm 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ốm kiểm thử PM tự động. Từ đó thời gian và công sức thực hiện dự án kiểm thử sẽ giảm bớt…
Nhưng sễ 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ó trinh độ 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ác nhân cao để đáp ứng nhu cầu liên tục tự sang tạo cà 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 hang có mặt trong cùng một địa điểm với nhóm phát triển. Ngườu này có thể trực tiếp trả lời các câu hỏi phát sinh trong khi có vấn đề và duy trì đúng hướng phát triển cho PM. Nếu tốc độ sáng tạo nhanh nhưng phản hồi chậm có thể dẫn tới phí phạm tài nguyen dự án và có thể chuyển sang những phí phạm tài nguyen dự àn và có thể chuyển sang hướng phát triển không phù hợp.
Ông Cem Kanner, giáo sư ngành công nghệ PM – Học viện kỹ thuật Florda ở 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 đợ đến khi kết thu171c các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp hô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 và khách hang thì dự án sẽ kéo dài dẫn đ61n lùi tiến độ. Trong thực tế nếu khách hang ở nước ngài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và my1i giờ. Khi đó, phương pháp PTPMLH sẽ 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 chua làm nhiều phần nhỏ, cấu trúc tương đối chặt chẽ và không có chó chỗ cho sai sót. Các nhóm phát riể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 sang tạo, dù nó cũng cần qua nhiều thảo luận để đưa và ứ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ẽ của khách hang.
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 áo dụng chủ yếu cho các dự án trung binh trở xuống ở các mảng ứng dụng web, ứng dụng trên di động 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ớit nhóm phát triển PM là khá cao. Đâu 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.
Trong mô hình offshore, nếu đại diện dự án không thể theo sát tại chỗ với nhóm phát triển thì cần trực trong một khỏang thời gian ấn định trong ngày, giao tiếp qua mail, chat, VoIP(thọai trên nền Iternet), điện thoại… để giải đáp thắc mắc tức thì”.
link (http://www.logigear.vn/vi/about-us/news/349-agile.html)
Nhật Khang
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,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 sang tạo cao trong từng bước lặp, kết qủa 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 đượcp hía khách hang 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 đổ - water fall) các yêu cầu ban đầu thường ít thay đổo so trong sướ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 interenet – thì các yêu cầu thay đổ thường 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ộ yêu cầu cấu trúc cho PM cho phù hợp với yêu cầu mới. Ở giai đoạn Web 2.0 các ứng dụng Interent 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ử phần mềm 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ốm kiểm thử PM tự động. Từ đó thời gian và công sức thực hiện dự án kiểm thử sẽ giảm bớt…
Nhưng sễ 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ó trinh độ 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ác nhân cao để đáp ứng nhu cầu liên tục tự sang tạo cà 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 hang có mặt trong cùng một địa điểm với nhóm phát triển. Ngườu này có thể trực tiếp trả lời các câu hỏi phát sinh trong khi có vấn đề và duy trì đúng hướng phát triển cho PM. Nếu tốc độ sáng tạo nhanh nhưng phản hồi chậm có thể dẫn tới phí phạm tài nguyen dự án và có thể chuyển sang những phí phạm tài nguyen dự àn và có thể chuyển sang hướng phát triển không phù hợp.
Ông Cem Kanner, giáo sư ngành công nghệ PM – Học viện kỹ thuật Florda ở 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 đợ đến khi kết thu171c các chu kỳ nhỏ mới xác định được hướng phát triển có phù hợp hô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 và khách hang thì dự án sẽ kéo dài dẫn đ61n lùi tiến độ. Trong thực tế nếu khách hang ở nước ngài thì quá trình liên lạc rất khó khăn do khác biệt địa lý và my1i giờ. Khi đó, phương pháp PTPMLH sẽ 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 chua làm nhiều phần nhỏ, cấu trúc tương đối chặt chẽ và không có chó chỗ cho sai sót. Các nhóm phát riể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 sang tạo, dù nó cũng cần qua nhiều thảo luận để đưa và ứ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ẽ của khách hang.
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 áo dụng chủ yếu cho các dự án trung binh trở xuống ở các mảng ứng dụng web, ứng dụng trên di động 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ớit nhóm phát triển PM là khá cao. Đâu 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.
Trong mô hình offshore, nếu đại diện dự án không thể theo sát tại chỗ với nhóm phát triển thì cần trực trong một khỏang thời gian ấn định trong ngày, giao tiếp qua mail, chat, VoIP(thọai trên nền Iternet), điện thoại… để giải đáp thắc mắc tức thì”.
link (http://www.logigear.vn/vi/about-us/news/349-agile.html)