Hồi còn đi học, trong môn "Phân tích thiết kế hệ thống thông tin" mà tôi được học có nhắc đến quy trình phát triển phần mềm theo mô hình thác nước (Waterfall). Tên gọi của nó khiến tôi liên tưởng đến hình ảnh một thác nước đang đổ ào ào từ trên xuống dưới rất mạnh mẽ, và dĩ nhiên dòng nước thì chỉ đổ được theo một chiều, hàm ý rằng đây là một quy trình tuần tự và khó có thể quay lui lại bước trước đó.
Nhưng sự thật là khi đi làm, tôi chưa thấy có một công ty nào áp dụng mô hình này để phát triển phần mềm cả. Hoặc là không có, hoặc là một cái tên khác: Agile.
Agile - Scrum là một cái tên mà tôi tin chắc rằng nhiều người biết hoặc đang áp dụng tại nơi làm việc. Một chu trình (sprints) chỉ mất khoảng 2 tuần để phát triển và hoàn thành một số tính năng để tung ra thị trường, đến với người sử dụng. Tư tưởng của Agile là làm sao đưa tính năng ra nhanh nhất cho khách hàng, từ đó khiến họ hài lòng và trả tiền để sử dụng sản phẩm.
Còn gì tuyệt vời hơn Agile, chúng ta quay vòng liên tục trong danh sách tính năng mới, "code" rồi "release"... thi thoảng là một chu trình sửa lỗi, cải thiện tính năng. Cuối mỗi sprint, chúng ta sẽ có một buổi "retrospective" để nhìn lại những gì đã và đang làm tốt hoặc chưa tốt, từ đó rút kinh nghiệm cho lần sau.
Thú thật, đối với một sinh viên mới ra trường lúc đó, Agile như là một phương pháp mà tôi cảm thấy tuyệt vời nhất. Người ta thường nói, con người thường sẽ có cảm xúc mãnh liệt với thứ đầu tiên họ tiếp xúc. Nghĩa là ngay từ đầu được tiếp xúc với Agile, cho dù sau đó được tiếp xúc với mô hình gì đi nữa, Agile vẫn có chỗ đứng đặc biệt trong lòng.
Đã có thời gian tôi đề cao Agile, sẵn sàng vùi dập các phương pháp khác như Waterfall trong các cuộc tranh luận. Rằng Waterfall là đã quá lạc hậu, không thể đáp ứng được nhu cầu phát triển phần mềm mạnh mẽ ngày nay.
Nhưng chỉ mới gần đây thôi, có lẽ tôi đã tích đủ cho mình "chứng cứ" để chỉ ra một sự thật: "Agile không phải là nhất" nếu như không muốn nói là nó quá tệ trong hầu hết trường hợp.
Vậy, tại sao?
Đầu tiên hãy nhắc lại một chút về khái niệm mô hình Waterfall.
Waterfall là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì.
Trong hầu hết thời gian đi làm, phân tích yêu cầu luôn là giai đoạn mà tôi thấy là tốn nhiều thời gian nhất. Vì đó là nơi mà cần phải quyết định xem cần phải làm gì, chiến lược kết hợp với tầm nhìn, kế hoạch và cả những con số thống kê để đi đến tính năng cần phải làm...
Vì vậy, nó phải được thực hiện rất tỉ mỉ và thận trọng trước khi chuyển giao sang giai đoạn tiếp theo, bởi vì một khi đả chuyển thì khó có thể quay lại được. Khi đó bộ phận khác đã tiếp nhận yêu cầu và bắt đầu thiết kế hệ thống, giao diện ứng dụng/phần mềm... Vậy điều gì xảy ra nếu như ngay từ bước đầu tiên đã xuất hiện vấn đề bất thường?
Nếu sai sót là nhỏ, trong tầm kiểm soát, chỉ cần sửa lại câu từ hoặc bổ sung thêm một vài trường hợp không gây ảnh hưởng đến chức năng chính, mọi thứ có thể du di chấp nhận được. Ngược lại, giả sử bộ phận Design tiếp nhận yêu cầu và họ tìm ra một cơ số lỗ hổng nếu không khắc phục thì không thể tiếp tục được. Chu trình thác nước lúc này có thể bị đổ vỡ. Chúng ta không thể cứ mãi một vòng lặp phản hồi từ Requirements đến Design được, vì như thế các bước sau đó sẽ mãi mãi không bao giờ được tiếp tục.
Tôi tin rằng có thể có rất nhiều sai lầm giống như trên đã xảy ra trong quá khứ, cho nên đã đến lúc đội phát triển cần một phương pháp mới: Agile ra đời.
Phát triển phần mềm linh hoạt (Agile) là một phương thức thực hiện các dự án công nghệ phần mềm, phương thức này khuyến khích sự thay đổi khi phát triển dự án và đưa sản phẩm đến tay người dùng sao cho nhanh nhất.
Chúng ta không còn thác nước, không còn từng bước như thác đổ và không sợ bị quay lui nữa. Tất cả giờ đây tập trung vào "đưa sản phẩm đến tay người dùng nhanh nhất".
Chà, nếu thế thì hơi chung chung. Làm thế nào để đưa sản phẩm đến tay người dùng nhanh nhất?
Scrum là một khung cộng tác nhóm linh hoạt thường được áp dụng trong Agile. Theo scrum, chúng ta sẽ có một vòng lặp có hạn thời gian để liên tục phát triển phần mềm, ví dụ là 2 tuần cho đến một tháng. Trong mỗi vòng lặp, phải có tính năng được hoàn thành và đưa đến tay người dùng, và khá nhiều quy tắc nữa nhưng tôi sẽ không nói thêm trong phạm vi bài viết này.
Tôi tin rằng Agile rất phổ biến, khi hỏi 10 người bạn làm trong cùng lĩnh vực, 9 người đều biết Agile, và công ty họ làm đều đang áp dụng phương pháp này, chỉ 1 người còn lại thì bảo "I'm free" - nghĩa là không theo một mô hình nào cả.
Ngày nay sự cạnh tranh trong các sản phẩm công nghệ là rất lớn. Chúng ta không thể chắc chắn ý tưởng của mình là duy nhất vì chỉ cần lơ là một chút, hàng tá sản phẩm có ý tưởng tương tự sẽ xuất hiện ngay sau đó mặc dù chưa từng khoe nó ở bất kỳ đâu.
Như vậy, chúng ta cần Agile để đẩy sản phẩm ra nhanh nhất cho người dùng, từ đó chiếm được thị trường và bước tiếp theo thì chỉ cần ung dung thêm tính năng mới.
Điều đó liệu có đúng? Nếu bạn đã từng ứng dụng Agile và nhận thấy mội vài hạn chế của nó mà chưa tiện nói ra ở đâu, thì hãy tạm dừng lại một chút để nghĩ về những bất cập đó và tiếp theo là...xem những điều đó có giống như tôi?
Dưới đây là những "bằng chứng" đã nhắc đến ở đầu bài để củng cố cho quan điểm "Agile không phải là nhất" trong suốt hơn 5 năm làm việc mà tôi đúc kết được.
Đến lúc này thì mới thấy Waterfall lại khắc phục được hầu hết nhược điểm trên.
Tất cả yêu cầu đã được làm rõ ngay từ bước đầu tiên, chúng ta có đầy đủ tài liệu để làm và không sợ bị thay đổi, vấn đề lúc này chỉ là bản kế hoạch về thời gian hoàn thành tất cả tính năng.
Khảo sát và đánh giá, tất cả đều nằm trong bước đầu tiên. Khảo sát giúp cho chúng ta tránh khỏi cạm bẫy xây dựng và có đủ cơ sở để tin rằng một khi tính năng được ra mắt, nó sẽ đem lại sự hài lòng cho rất nhiều người.
Khi tất cả yêu cầu được giao xuống, tất cả bộ phận đều nắm rõ thông tin sản phẩm, từ đó tạo ra động lực về một tương lai về sản phẩm sắp được làm ra và nó mang lại giá trị gì cho người dùng.
Tuy vậy, ưu điểm của Waterfall cũng là nhược điểm chí mạng khi nó không thể linh hoạt trong các khâu phát triển phần mềm. Hầu hết các công ty mà tôi từng tham gia phát triển đều đang trong quá trình Start-up, họ có chiến lược tạm thời và kế hoạch tung sản phẩm rất nhanh chóng để kịp cho việc chiếm lĩnh thị trường.
Nói đến đây không phải là để chỉ trích phương pháp nào cả, mà một khi đã nhìn ra những bất cập, chúng ta cần phải tìm ra cách để khắc chế lại nó.
Agile khuyến khích mọi người tương tác với nhau nhiều hơn để đẩy nhanh quá trình phát triển. Đừng quá quở trách đội nghiên cứu sản phẩm vì những yêu cầu chưa rõ ràng, tài liệu chậm trễ từ phía họ, vì đôi khi mọi người cũng đang quay cuồng trong danh sách tính năng cần được ưu tiên cho sự sống còn của sản phẩm. Thay vào đó chúng ta có thể chủ động hỏi những câu hỏi để làm sáng tỏ vấn đề, suy nghĩ hay đưa ra các trường hợp mà đội sản phẩm không lường được hết. Hãy nhớ một khi đã chọn Agile, chắc chắn việc làm thế nào để tung sản phẩm ra nhanh nhất cho người dùng mới là điều quan trọng.
Để tránh khỏi cạm bẫy xây dựng, hãy đặt nhiều câu hỏi liên quan đến sản phẩm trong giai đoạn Grooming hoặc Planing. Yêu cầu những con số biết nói và nếu có thể hãy đặt cả câu hỏi tại sao cần làm những tính năng sắp tới. Qua đó giúp cho mọi người có cái nhìn xa hơn về giá trị mà sản phẩm mang lại cho người dùng.
Cuối cùng là, luôn sẵn sàng tâm thế cho việc thay đổi liên tục.
Tóm lại, bài viết này chỉ là sự nhìn nhận mang tính cá nhân về ưu và nhược điểm của 2 phương pháp phát triển phần mềm Waterfall và Agile. Trong khi Waterfall yêu cầu một nền tảng vững chắc thì Agile lại phù hợp với những thay đổi linh hoạt. Chúng phù hợp trong những môi trường làm việc khác nhau và qua bài viết này hy vọng bạn đọc không mắc phải những sai lầm như tôi khi đã quá đề cao một trong hai phương pháp từ đầu.
Bí mật ngăn xếp của Blog
Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!
Đăng ký nhận thông báo bài viết mới
Bình luận (8)
Nếu nhóm của bạn cảm thấy mệt mỏi với sự thay đổi và mông lung khi không có tài liệu, kế hoạch rõ ràng, có lẽ nhóm bạn nên thêm nó vào quy trình của mình, mình nghĩ dù bạn dùng gì thì cũng cần sự rõ ràng và thống nhất. Mình thấy cái này (https://designsprintkit.withgoogle.com/) có thể giúp ích cho nhóm của bạn. Nhân tiện vì comment được sắp xếp theo cái mới nhất, mình thấy đưa ô nhập lên trên thì sẽ tốt hơn
Nếu nhóm của bạn cảm thấy mệt mỏi với sự thay đổi và mông lung khi không có tài liệu, kế hoạch rõ ràng, có lẽ nhóm bạn nên thêm nó vào quy trình của mình, mình nghĩ dù bạn dùng gì thì cũng cần sự rõ ràng và thống nhất. Mình thấy cái này (https://designsprintkit.withgoogle.com/) có thể giúp ích cho nhóm của bạn. Nhân tiện vì comment được sắp xếp theo cái mới nhất, mình thấy đưa ô nhập lên trên thì sẽ tốt hơn
Rất cảm ơn về sự gợi ý. Thực ra cuối các buổi retro, team cũng đã nêu ra rất nhiều lần rồi và... như bạn biết đấy, chỉ khắc phục được một phần... Một quy trình có vấn đề có lẽ cũng phụ thuộc vào nhiều yếu tố, cả khách quan, chủ quan và mình nghĩ nhiều nhất là yếu tố con người. Các công ty mình góp mặt hầu như đều bị một vấn đề như thế, thời gian đầu cảm thấy rất ức chế, chán... nhưng sau đó thì dần hiểu ra và mình không đổ lỗi cho ai cả mà cách tốt hơn là tìm cách để giải quyết những vấn đề đó.
mình hiểu quan điểm của bạn, mình thấy mối phương pháp đều cho thấy sự phù hợp trong các phạm vi, quy mô khác nhau, không nhất thiết mình phải áp dụng chỉ một cho tất cả. Mình thấy dẫn chứng bạn đưa ra có chút thiên kiến về một phương pháp, những vấn đề bạn đề cập cho agile hoàn toàn vẫn gặp trong Waterfall, nên đã đề cập đề mọi người có cái nhìn đa chiều hơn. cảm ơn bạn về bài viết
mình hiểu quan điểm của bạn, mình thấy mối phương pháp đều cho thấy sự phù hợp trong các phạm vi, quy mô khác nhau, không nhất thiết mình phải áp dụng chỉ một cho tất cả. Mình thấy dẫn chứng bạn đưa ra có chút thiên kiến về một phương pháp, những vấn đề bạn đề cập cho agile hoàn toàn vẫn gặp trong Waterfall, nên đã đề cập đề mọi người có cái nhìn đa chiều hơn. cảm ơn bạn về bài viết
Vâng, chắc chắn là mỗi phương pháp luôn tồn tại ưu và nhược điểm, và chúng ta cần là chọn ra được giải pháp phù hợp. Mình cũng không phủ nhận mặt tích cực của Agile, tuy nhiên chúng ta hoàn toàn có thể cóp nhặt được những gì tốt trong mỗi cái để "biến" thành của riêng. Thực ra bài viết nói nhiều về Agile hơn bởi vì hầu hết thời gian làm việc của mình đều dựa trên phương pháp này, rồi từ đó rút ra được những thứ có trong bài viết. Tuy vậy đó không hoàn toàn là quan điểm của cá nhân, mình cũng có hỏi và quan sát đồng nghiệp trong cùng môi trường. Đa phần họ đều cảm thấy mệt mỏi với sự thay đổi và mông lung khi không có tài liệu, kế hoạch rõ ràng. Cảm ơn vì những góp ý của bạn để bài viết được hoàn thiện hơn.
chiến lược thay đổi đâu có phụ thuộc vào phương pháp pháp triển. Khi bạn đang áp dụng Waterfall, nhu cầu người dùng hay chiến lược phát triển vấn có thể thay đổi mà, cái duy nhất khó thay đổi là watefall, lúc đó những gì bạn phân tích xong đã không còn phù hợp với thị trường, nó vấn đảm bảo bạn làm ra sản phẩm như bạn đã xác định, nhưng lúc đó, sản phẩm đó có còn đúng với nhu cầu thị trường. Giá trị của Agile là linh hoạt để thích ứng với sự thay đổi
chiến lược thay đổi đâu có phụ thuộc vào phương pháp pháp triển. Khi bạn đang áp dụng Waterfall, nhu cầu người dùng hay chiến lược phát triển vấn có thể thay đổi mà, cái duy nhất khó thay đổi là watefall, lúc đó những gì bạn phân tích xong đã không còn phù hợp với thị trường, nó vấn đảm bảo bạn làm ra sản phẩm như bạn đã xác định, nhưng lúc đó, sản phẩm đó có còn đúng với nhu cầu thị trường. Giá trị của Agile là linh hoạt để thích ứng với sự thay đổi
Các vấn đề trong bài dường như đến từ việc nhóm đã hiểu sai ý nghĩa của nhanh trong Agile, dẫn đến đã loại bỏ vài bước trong CTPT khi triển khai Agile. Nhanh chuyển giao tới người dùng chứ không phải nhanh là bỏ qua giá giai đoạn khi phát triển
Các vấn đề trong bài dường như đến từ việc nhóm đã hiểu sai ý nghĩa của nhanh trong Agile, dẫn đến đã loại bỏ vài bước trong CTPT khi triển khai Agile. Nhanh chuyển giao tới người dùng chứ không phải nhanh là bỏ qua giá giai đoạn khi phát triển
Mình hiểu ý của bạn đang muốn đề cập đến, dù là phương pháp phát triển phần mềm nào thì mục đích cuối cùng vẫn là đưa sản phẩm đến với người dùng cuối, chỉ có điều là quá trình đó diễn ra như thế nào.
Theo như cách trình bày vấn đề của bạn, "Bản chất Agile vẫn dùng Waterfall để phát triển" thì mình cảm thấy không đồng quan điểm cho lắm.
Hãy đi qua khái niệm của Agile, phương pháp này khuyến khích sự thay đổi và tương tác, hay nói cách khác là tùy cơ ứng biến, trong khi bạn đang thử nghiệm tính năng này thì vì một lý do nào đó mà thay đổi chiến lược thì hoàn toàn có thể tạm gác lại và làm cái mới. Waterfall thì ngược lại, mọi thứ đã được lên kế hoạch từ đầu rất chỉn chu và tất cả quá trình được diễn ra tuần tự mà không có bất kì sự xáo trộn nào cho đến khi sản phẩm được ra mắt.
Qua đó, chúng ta thấy được ưu và nhược điểm của từng phương pháp. Một sprint có thể coi là một waterfall rất nhỏ? Có thể có...hoặc không. Đơn giản vì thời gian diễn ra của nó quá ngắn, chúng ta không có thời gian tổ chức tài liệu, kế hoạch khảo sát cục diện hay thực hiện một chu trình hoàn chỉnh như waterfall được, nơi mà các bước phải được ổn định nhất có thể.
Nói như thế không phải là Agile không chỉn chu mà đó là sự linh hoạt, không cứng nhắc như waterfall. Sự dẻo dai của agile giúp cho đội phát triển phần mềm biến đổi linh hoạt tùy theo nhu cầu thị trường, đổi lại nó sẽ khiến cho các thành viên trong đội phải rèn luyện một tinh thần thích ứng cao độ.
Vì khối lượng công việc và giá trị chuyển giao nhỏ hơn, nên thời gian phát hành tới người dùng sẽ nhanh hơn, nhanh có được phản hồi từ người dùng. đây mới là ý nghĩa của nhanh trong Agile.
Thay vì chỉ có 1 CTPT tại một thời điểm như Waterfall truyền thống, Agile có thể làm nhiều CTPT cùng một thời điểm nên với một phần mềm lớn chúng ta có thể đưa nhiều team vào phát triển độc lập, cái mà Waterfall truyền thống không cho phép
Vì khối lượng công việc và giá trị chuyển giao nhỏ hơn, nên thời gian phát hành tới người dùng sẽ nhanh hơn, nhanh có được phản hồi từ người dùng. đây mới là ý nghĩa của nhanh trong Agile.
Thay vì chỉ có 1 CTPT tại một thời điểm như Waterfall truyền thống, Agile có thể làm nhiều CTPT cùng một thời điểm nên với một phần mềm lớn chúng ta có thể đưa nhiều team vào phát triển độc lập, cái mà Waterfall truyền thống không cho phép
Cả Waterfall truyền thống vs Agile hay Scrum đều thực hiện các CTPT, chúng chỉ khác nhau về khối lượng công việc và giá trị chuyển giao tới khách hàng.
Cả Waterfall truyền thống vs Agile hay Scrum đều thực hiện các CTPT, chúng chỉ khác nhau về khối lượng công việc và giá trị chuyển giao tới khách hàng.
Agile và Scrum: với khối lượng tính năng đồ sộ xác định được, chúng ta xác định một lượng tối thiểu các tính năng cần để có thể phát hành (MVP). Sau đó cứ mối Sprint chúng các xác định vài tính năng rồi thực hiện 1 CTPT lên đó.
Agile và Scrum: với khối lượng tính năng đồ sộ xác định được, chúng ta xác định một lượng tối thiểu các tính năng cần để có thể phát hành (MVP). Sau đó cứ mối Sprint chúng các xác định vài tính năng rồi thực hiện 1 CTPT lên đó.
Bản chất Agile vẫn dùng Waterfall để phát triển, chỉ khác nhau về phạm vi, giá trị chuyển giao tới người dùng.
Chu trình phát triển( CTPT - các bước chính ): Phân tích thị trường, xác định yêu cầu - thiết kế, phát triển - kiểm thử, phát hành
Waterfall truyền thống: chúng ta xác định sản phẩm cần làm và thực hiện chỉ 1 CTPT. Sau đó phần mềm thay đổi, chúng ta tổng hợp lại và thực hiện 1 CTPT mới trong 1 khoảng thời gian (thường theo năm)
Bản chất Agile vẫn dùng Waterfall để phát triển, chỉ khác nhau về phạm vi, giá trị chuyển giao tới người dùng.
Chu trình phát triển( CTPT - các bước chính ): Phân tích thị trường, xác định yêu cầu - thiết kế, phát triển - kiểm thử, phát hành
Waterfall truyền thống: chúng ta xác định sản phẩm cần làm và thực hiện chỉ 1 CTPT. Sau đó phần mềm thay đổi, chúng ta tổng hợp lại và thực hiện 1 CTPT mới trong 1 khoảng thời gian (thường theo năm)