(Bài chia sẻ của tác giả Ryo Amano)
Trong bài viết số này, tôi muốn viết về dự án phát triển phần mềm có áp dụng nguyên tắc phát triển Agile mà tôi cho là thành công nhất. Chúng ta hãy tạm gọi là dự án S nhé.
Khái quát về dự án
Đầu tiên tôi xin giải thích về bối cảnh của dự án.
Dự án S thực hiện phát triển Mmiddleware có chức năng là engine thực hiện edit video file định dạng mpeg. Thực ra, khi đó đã có sẵn Mmiddleware edit video file định dạng mpeg rồi nhưng đó là sản phẩm được tạo ra trong dự án R. Tóm lại, dự án S đã được khởi đầu với mục đích là tạo lại từ đầu Mmiddleware của dự án R để thay thế middleware này.
Middleware phát triển trong dự an R là một phần mềm có lịch sử sử dụng khá dài tính đến thời điểm đó. Những phần mềm như vậy thường ẩn chứa vấn đề mang tính maintain vô cùng tệ do design đã bị phức tạp hóa trên mức cần thiết vì version up và thêm chức năng nhiều lần. Do đó, khi đó chúng tôi đã cấu trúc lại phần mềm này từ một đống hỗn tạp bằng thiết kế hiện đại.
Một phần cũng do tình hình như vậy nên leader của dự án S là người có kinh nghiệm phát triển dự án R. Ngoài ra, dự án S cũng được tiến hành với tổ chức với nhiều thành viên là những người đã có kinh nghiệm với dự án R. Dự án tập trung nhiều member có kinh nghiệm đa dạng nên cho đến bây giờ, việc có thể thực hiện pair programming với những member lúc đó vẫn là một trong những niềm tự hào của tôi.
Dự án S từ khi đó được thực hiện theo XP style nhưng khoảng một tháng rưỡi kể từ sau khi bắt đầu dự án, tôi đã giới thiệu ví dụ về dự án ở XP Fiesta 2006, một sự kiện quan trọng trong cộng đồng Agile ở Nhật (Figure 1). Tuy nói là giới thiệu nhưng thực ra nội dung cũng chỉ mới đến iteration (sprint) thứ 3 nhưng và tôi đã phát biểu về tình hình ở thời điểm khởi đầu khi đó của dự án.
Vậy dự án đó diễn ra như thế nào?
Tôi đã giới thiệu về dự án ở sự kiện XP fiesta vào đầu tháng 9 năm 2006 nhưng kết cục thì khoảng 5 tháng sau tức là thời điểm tháng 1 năm 2007, dự án S đã bị dừng phát triển. Không phải dừng do đã hoàn tất việc phát triển mà là bị dừng khi đang làm dở. Đó là do dù có tiếp tục phát triển với nhịp độ như lúc đó thì cũng không thể release sản phẩm đúng thời điểm có giá trị về mặt kinh doanh được,. tTóm lại ở thời điểm đó chúng tôi đã nhận định dự án đã dùng effort và thời gian phát triển vượt quá kế hoạch ban đầu. Kết quả là cho đến nay, deliverables của dự án R vẫn tiếp tục được sử dụng.
Trong 7 tháng kể từ ngày start bắt đầu dự án, hàng ngày chúng tôi đều làm stand up meeting, thực hiện phát triển bằng pair programming, update burndown chart, tổ chức look back (Restropective), lập kế hoạch cho iteration trong planning game. Thỉnh thoảng member dự án cũng có conflict về phương châm thiết kế, phương châm vận hành dự án. Đôi khi mọi người cũng cùng đi nhậu vui vẻ với nhau. Chúng tôi đã tích lũy được những kinh nghiệm thực tế như vậy. Tuy đây chỉ là nhận định cá nhân của tôi nhưng tôi cho rằng hoàn toàn có thể kết luận dự án S là dự án đã được thực hiện theo XP style.
Vậy tại sao dự án được đánh giá là thành công?
Ở phần đầu bài báo này, tôi đã viết rằng đây là dự án “thành công”. Vậy tại sao dù dự án đã làm đến vậy nhưng vẫn không đạt được mục tiêu ban đầu đề ra, kết quả là còn bị dừng giữa chừng nhưng tôi vẫn cho rằng dự án đã “thành công”?
Bản thân tôi cho rằng chính vì thực hiện dự án theo XP style nên ở thời điểm đó chúng tôi mới đưa ra được kết luận là sẽ dừng phát triển. Việc tiếp tục đưa ra estimation về tiến độ một cách thực tế, đúng đắn, không quá lớn cũng không quá nhỏ đối với bản thân chúng ta tuyệt đối không phải là việc dễ dàng gì. Tuy nhiên, tôi cho rằng chính vì có việc này mà chúng tôi đã có thể thực hiện phán đoán nghiệp vụ mà không gây băn khoăn về sunk cost (restropective cost, chi phí chìm), giống kiểu như “Vì đã làm đến mức này rồi nên…”. Đối với manager và tất nhiên với tất cả member của dự án thì đây là một quyết định đầy cay đắng nhưng đến tận bây giờ tôi vẫn thấy đó là một quyết định đúng đắn. Cho nên tôi cho rằng dự án đã “thành công”.
Về việc làm lại
Rất nhiều người đi trước đã từng cảnh báo những kỹ sư thường mơ tưởng về việc “Sửa lại những phần mềm liên quan từ một đống hỗn độn sao cho đẹp đẽ”. Ví dụ như điều này đã được nêu trong bài viết "Things You Should Never Do, Part I" đăng tải trên báo ”Joel on Software” của Joel Spolsky – người sáng lập ra site trao đổi về lập trình Stack Overflow – website giúp ích rất nhiều cho công việc của mọi người. Đây là bài viết vô cùng có ích, các bạn hãy đọc thử nhé.
http://www.joelonsoftware.com/articles/fog0000000069.html Tất nhiên, khi đó tôi cũng biết đến điều này. Song dù cho có biết được nội dung nhưng việc tư thân trải nghiệm và thực sự hiểu được lại là chuyện khác. Nếu so sánh với cuộc đời của một kỹ sư sau này thì tôi không nghĩ mấy tháng làm dự án S là một “khoản học phí” quá cao. Ngoài ra, tôi thấy rằng việc có thể cảm nhận được sức mạnh của việc phát triển dự án dựa trên Agile bằng hình thức đó là một trải nghiệm không thể thay thế, góp phần tạo nên “tôi” của ngày hôm nay.
Joel on Software là tài liệu tổng hợp một số bài báo đăng tải trên Web.
Đây là ảnh bìa của "Joel on Software" và "More Joel on Software".
Lời kết
Ở phần trên tôi có viết là “có thể thực hiện phán đoán nghiệp vụ” nhưng vai trò của những business manager chấp nhận (hơn nữa là khuyến khích) development team thực hiện phát triển theo XP style cũng rất quan trọng. Những năm gần đây, ở Nhật, việc phát triển bằng Agile đã dễ dàng lấy được sự đồng tình của mọi người hơn nhưng ở thời điểm năm 2006, khi chúng tôi thực hiện dự án đó, chúng tôi đã rất khó khăn mới có được sự chấp thuận của bộ phận kinh doanh và các Senior Manager về việc phát triển Agile. Trong khi đó, cần đi theo cách tiếp cận (approach) đã có kinh nghiệm từ trước và đưa các member của dự án R-đối tượng thay thế lần này vào tham gia. Lý do là những member này là những người hiểu rõ nhất hiện trạng lúc đó,: phần nào là phần không tốt, phần nào là thế mạnh để sale. Đó chính là điểm cần rút kinh nghiệm.
Tôi xin kể một chuyện hậu trường. Lúc đầu đã quyết định là sẽ thực hiện dự án S với mục tiêu là thay thế hoàn toàn sản phẩm của dự án R nhưng thực ra sau đó một dự án khác với mục tiêu design lại riêng phần phức tạp nhất của dự án R đã được thực hiện và dự án đó đã đạt được mục tiêu đề ra và kết thúc. Có nghĩa là không phải làm lại toàn bộ mà chỉ thực hiện cải thiện thôi. Tôi là leader của dự án cải thiện mới đó nhưng tôi có thể tự hào mà nói rằng chính vì có những kinh nghiệm khi thực hiện dự án S mà tôi mới có thể thành công trong dự án mới đó cải thiện phần phức tạp nhất của dự án R. Tôi nghĩ rằng ở Việt Nam hiện nay cũng đang chuyển hướng sang phát triển theo Agile nhưng dù kết quả phát triển có như thế nào đi chăng nữa, các bạn cũng hãy suy nghĩ là có thể tích lũy kinh nghiệm, bài học gì đó cho bản thân từ kết quả ấy nhé. Chính vì có được suy nghĩ như vậy nên lần này tôi mới giới thiệu về dự án có kết quả như thế này. Dù dự án có bị dừng thì chúng ta cũng có thành quả là xây dựng được mối quan hệ tín nhiệm khiến mọi người đều có thể nghĩ được rằng “Dừng ở thời điểm này là tốt”.Trong những bài viết của tôi giới thiệu về Agile mind hay Project Facilitation trong tạp chí Geek & Tech cũng đề cập đến rất nhiều cách suy nghĩ hiệu quả để thực hiện mục tiêu đó nên các bạn hãy tìm đọc lại nhé.
Ryo Amano
