III. So sánh các phương pháp phát triển phần mềm linh hoạt 1 Giới thiệu
3. Thực hiện theo phương pháp
Trong những phương pháp đã trình bày ở trên,việc thực hiện theo mới đề cập
đến quy trình, vai trò, trách nhiệm và thực hiện theo, rút ra kinh nghiệm, nhưng ngoài ra, việc so sánh còn mở rộng sang cả các vấn đề về quản lí dự án, vấn đề cốt lõi trong việc hiểu phương pháp hỗ trợ thế nào trong chiến lược quản lí. Việc kinh doanh các sản phẩm phần mềm chỉ thu được lợi nhuận khi chúng được sử dụng, tương tự nhhư vậy, lợi nhuận liên quan đến các phương pháp phát triển phần mềm linh hoạt cũng chỉ đạt được khi những phương pháp này được sử dụng trong sản xuất sản phẩm. Việc thực hiện theo 1 phương pháp mới nên đơn giản khi mà tổ
chức không có khả năng tài chính để làm chậm hay dừng việc sản xuất để tái tổ
chức hay tìm ra hướng đi mới trong công việc kinh doanh của họ. Việc làm theo và rút ra kinh nghiệm để đánh giá mỗi phương pháp đã được trình bày ở những phần trên. Một điều khá rõ ràng rằng có không nhiều những báo cáo kinh nghiệm và càng ít hơn những báo cáo khoa học về vấn đề này. Nandhakumar và Avison nhận thấy rằng những phương pháp phát triển phần mềm truyền thống đang được sử dụng hiện nay như là một sự mơ hồ tất yếu để cho ta thấy thực trạng của việc quản lí hoặc là để đưa ra một tình trạng tiêu biểu. Họ cũng khuyến cáo rằng những phương pháp thay thế, cái mà mang đặc điểm đặc biệt của công việc trong nhiều môi trường là rất cần thiết. Nhhững đặc điểm đặc biệt của công việc của công việc mà họđề cập đến ở đây là môi trường kinh doanh sôi động hay thay đổi
theo nền kinh tế. Trong những môi trường này, những thay đổi là rất cần thiết để đạt được dự án hay thậm chí là đạt đến 1 mức rất cao. Nandhakumar và Avison cũng cho rằng công việc thực hiện của những nhà phát triển chỉ bộc lộ rõ nét nhất khi có những yếu tố tương ứng. Một lần nữa, lại có 1 vấn đề là tất cả các phương pháp phát triển phần mềm linh hoạt đều được phân định rõ ràng, thực tế là tất cả
các quan điểm về phương pháp linh hoạt đều bộc lộ đặc trưng khi đặt điểm nhấn vào những khía cạnh sau:
- Việc đem lại 1 vài lợi ích - Tin cậy với con người - Khuyến khích cộng tác
- Thúc đẩy những tiến bộ kĩ thuật
- Khả năng tạo ra những cái đơn giản nhất - Có tính tương thích
Nandhakumar và Avison cũng cho rằng việc phát triển phần mềm hiện nay rất khác so với quan điểm phương pháp luận phổ biến, bảng sau bổ sung thêm những phát hiện của họ với cách tiếp cận linh hoạt,nó trình bày những điều xa hơn ,điều mà phát triển phần mềm linh hoạt đang tiếp cận, kể cả nhiều cách thức phát triển phần mềm hiện nay, do đó, nó giải thích phần nào tại sao, ví dụ như, lập trình gần
đây lại thu hút được nhiều sự chú ý đến vậy, hơn nữa nó cũng tiếp cận đến phát triển phần mềm từ quan điểm của người phát triển
Quan điểm phương pháp
luận
Phát triển phần mềm trong thực hành
Quan điểm biện hộ bởi phương pháp linh hoạt
Các nhiệm vụ riêng rẽ Các kế hoạch cá nhân
liên hệ lẫn nhau
Các kế hoạch cá nhân liên hệ lẫn nhau
Dự đoán được thời gian Không đoán trước
được kết thúc
Đoán được kết quả của bước tiếp theo
Hoạt động
Có thể lặp lại Phụ thuộc vào hoàn
cảnh
Thường phụ thuộc vào hoàn cảnh
Tin cậy Phụ thuộc vào điều
kiện, hoàn cảnh Đáng tin cậy Những tác động qua lại có thể thấy rõ được Có sắn tính tương tác Các tương tác cụ thể làm tăng khả năng tương tác tự nhiên Quy trình thực hiện
Các nhiệm vụ đơn nối tiếp Nhiều nhiệm vụ kết
hợp với nhau
Các nhiệm vụ đơn
theo các điều kiện
Tận tụy với dự án SW Thích ứng với nhiều
việc như dự án,không phải dự án, cá nhân
Người phát triển đánh giá được cố gắng cần thiêt trong công việc
Không có tính phân hóa Phân biệt cá nhân Phân biệt cá nhân
Nỗ lực của người phát triển
Tinh thần sẵn sàng cao Tận dụng triệt để Tận dụng triệt để
Thường xuyên Tận dụng cơ hội, ứng
phó nhanh và gián đoạn
Chỉ chấp nhận việc kiểm soát hiện tai, tôn trọng công việc của người khác
Điều khiển công việc
Kiểm soát những bước tiến quan trọng,những kế hoạch và việc quản lí
Hội thảo cá nhân và thương lượng với nhau
Hội thảo cá nhân và thương lượng với nhau
Mặc dù cách tiếp cận linh hoạt phần nào tương đồng với việc phát triển phần mềm hiện tại nhưng chúng không phải phù hợp hoàn toàn theo các bước trong chu trình phát triển phần mềm. Biểu đồ sau sẽ cho ta thấy những bước phát triển phần mềm được hỗ trợ bởi các phương pháp linh hoạt khác. Mỗi phương pháp lại được chia thành 3 phần, phần đầu biểu diễn phương pháp có đưa ra những hỗ trợ cho việc quản lí dự án hay không., phần tiếp theo xác định xem 1 tiến trình, cái mà
được phương pháp khuyên dùng có được mô tả bởi phương pháp đó hay không, phần cuối cùng chỉ ra là phương pháp có mô tả các hoạt động và sản phẩm công việc cái mà sau đó có thểđược dùng trong nhiều hoàn cảnh khác nhau hay không. Màu nâu biểu thị phương pháp này được áp dụng trong suốt vòng đời của bước còn màu trắng biểu thị phương pháp này không cung cấp những thông tin chi tiết về 1 trong 3 lĩnh vực được đánh giá là quản lí dự án, tiến trình, thực hiện\ hoạt
Biểu đồ trên cho thấy phương pháp linh hoạt tập trung vào các khía cạnh khác nhau của vòng đời phát triển phần mềm. Hơn nữa, một số lại tập trung vào thực hành (như lập trình cực hạn (Extreme Programming), lập trình thực tế, mô hình linh hoạt) trong khi số khác lại tập trung vào quản lí dự án phần mềm (Scrum). Chưa hết, lại có những cách tiếp cận lại được sử dụng trong toàn bộ quá trình phát triển (DSDM,RUP ) trong khi hầu hết chúng chỉ phù hợp trong những bước cụ thể
(FDD). Do đó, có sự khác nhau rõ ràng đa dạng các phương pháp phát triển phần mềm linh hoạt. Trong khi DSDM và RUP không cần bổ sung thêm các cách tiếp cận để hỗ trợ phát triển phần mềm, thì những phương pháp kia phải cần. Tuy nhiên, DSDM lại chỉ phù hợp cho những thành viên của các tập đoàn tài chính DSDM còn RUP thì sau này là môi trường phát triển mang tính thương mại. Cân nhắc làm theo phương pháp nào, quy mô của nhóm phát triển như thế nào hiện nay trở thành một trong những vấn đề quyết định chính. XP, Scrum, AM và PP tập trung vào các nhóm nhỏ, thường là dưới 10 kĩ sư phần mềm. Crystal, FDD , RUP, OSS, ASD và DSDM lại yêu cầu khả năng phát triển lên đến 100 người phát triển. Tuy vậy, những đề xuất linh hoạt thừa nhận rằng khi mà quy mô nhóm phát
triển càng tăng lên thì số lượng tài liệu cũng tăng, do đó,làm cho dự án ít linh hoạt
đi. Khi nhóm phát triển tăng lên đến 20 kĩ sư phần mềm, thì vấn đề nổi cộm ởđây là giải quyết khó khăn trong truyền thông hiệu quả. Mỗi phương pháp lại bao gồm một số lượng các gợi ý làm thế nào để tổ chức các kênh truyền thông với những nhóm kĩ sư nhỏ. Phương pháp tiếp cận linh hoạt xuát hiện đặc biệt phù hợp với những tình huống mà những yêu cầu tiếp theo không được biết. Điều này cho thấy, nếu các yêu cầu tiếp theo như những yêu cầu về hiệu suất, về những xử lí phụ khác, hay những yêu cầu về tính năng … mà được biết hay đã được định rõ thì các cách tiếp cận linh hoạt sẽ không có nhiều ý nghĩa với việc phát triển dự án. Highsmith (2002) đã có những nỗ lực trong việc tìm ra giai đoạn thị truờng phù hợp nhất với phương pháp linh hoạt. Ông cho rằng các cách tiếp cận linh hoạt đặc biệt phù hợp với giai đoạn “ngõ hẻm (bowling alley) “ và “Bão táp (tornado)” (xem phần những đặc điểm của các giai đoạn thị trường khác nhau của Moore 1995). Một ví dụ cho điều này là, trong giai đoạn ngõ hẻm, Highsmith cho rằng, trong giao tiếp khách hàng với sự đáp ứng thay đổi ở cấp độ cao và cường độ lớn thì nên phát triển bằng phương pháp tiếp cận linh hoạt hướng hợp tác. Highsmith cũng gợi ý là kết hợp các phương pháp lại với nhau thành 1 cơ cấu, tổ chức cũng khá quan trọng và những tổ chức có năng lực cao và hợp tác tốt thì sẽ phù hợp cho phương pháp tiếp cận linh hoạt hơn là những tổ chức mà chỉ phụ thuộc vào việc quản lí ,tuy nhiên cũng chưa có sự hỗ trợ về kinh nghiệm nào cho những điều này. Những cái được và những khó khăn của việc chọn làm theo một phương pháp nào
đó rất khó đểđánh giá và cũng có một số rất ít những nhà nghiên cứu nghiên cứu về vấn đề này. Tuy vậy, chúng ta vẫn phải thấy rằng, nếu có một sự chuyển đổi mô hình giữa cách phát triển phần mềm truyền thống và phát triển phần mềm linh hoạt thì nó sẽ rất rộng và việc hỗ trợ để chọn theo một kiểu hoặc theo kĩ thuật nào sẽ bị
bỏ qua, và khi đó, có thể các tổ chức và những nhà phát triển sẽ không tiếp tục áp dụng phương pháp linh hoạt trong công việc hằng ngày nữa. Việc chuyển đổi mô hình này không đặt trọng tâm vào những gì vẫn làm theo truyền thống như lập kế
hoạch, chuẩn bị cho các bước tiếp theo, cho tài liệu, thỏa thuận hợp đồng cùng với những quy trình và công cụ. Các tổ chức và cá nhân hầu như không thể thay đổi 180 độ trong việc thực hiện việc phát triển phần mềm của họ. Hầu hết các phương pháp được nghiên cứu đều nâng cao vai trò, quyền hạn của khách hàng và nhóm phát triển để có được những đánh giá quý báu cho quá trình phát triển. Vì vậy, việc làm theo phương pháp linh hoạt cũng yêu cầu sự thay đổi trong văn hóa, đặc
biệt là trong giai đoạn đầu và giữa của việc phát triển. Rất nhiều cơ chế quản lí truyền thống như báo cáo định kì phải được chuyển đổi theo hướng sản xuất các mã làm việc. Một mặt, điều này đòi hỏi thay đổi cách thức tổ chức, mặt khác nó cũng đặt nhiều niềm tin vào năng lực, khả năng của của nhóm phát triển. Thêm vào đó, cũng có cả rủi ro trong việc thay đổi phương pháp phát triển. Tất cả các cách tiếp cận linh hoạt đều đưa ra việc phát triển các đặc tính phần mềm trong những chu trình nhỏ từ 2 đến 6 tuần, do đó, rủi ro ít nhất, ví dụ như việc sai lịch trình sẽ thấy trước được trong vài tuần. Những đề xuất về phương pháp linh hoạt
được biết đến như của Highsmith hay Schwaber, tin rằng việc triển khai theo 1 phương pháp sẽ đạt được những kết quả tốt hơn nếu nó có 1 sự hậu thuẫn vững chắc, do vậy cần có những sự quan tâm và hỗ trợ chiến lược. Mặc dù cũng có 1 vài luận chứng nhỏ khá hữu ích cho vấn đề này, nhưng những nghiên cứu mang tính kinh nghiêm vẫn cần thiết để quyết định xem bao giờ,như thế nào và trong tình huống nào thì các phương pháp linh hoạt có thểđược áp dụng tốt nhất. Thực hiện theo công nghệ mới không hẳn là công nghệ phát triển phần mềm linh hoạt ấy khác xa so với các công nghệ phần mềm khác hay nó sẽ phủ nhận các thành tựu nghiên cứu, ví dụ như Agarwal và Prasal chỉ ra rằng sự tin tưởng vào công nghệ
mới và việc triển khai theo công nghệ ấy có quan hệ khá mật thiết với nhau, Abrahamsson cũng đã đưa ra một luận điểm tương tự như vậy. Một yếu tố quan trọng khác ảnh hưởng đến việc triển khai công nghệ mới là cách nắm bắt có tổ
chức, có kiến thức kĩ thuật, có sự huấn luyện kinh nghiệm và nhận biết những việc không an toàn. Những phát hiện trên nên được áp dụng trong việc phát triển việc thực hiện theo mô hình nhằm mục đích cung cấp những hướng dẫn trong quá trình tiếp cận các phương pháp phát triển phần mềm linh hoạt.
