Scrum vs Water fall

Bài này nhằm mục đích so sánh giữa hai quy trình scrum và water fall. Bạn có thể dễ dàng đoán được cái nào ưu việt hơn nhưng mình muốn đi sâu hơn, đánh giá xem ưu nhược điểm của quy trình và tính áp dụng của quy trình có khả thi trong thực tế không.

Water fall là quy trình truyền thống. Trong đó, mọi thứ được diễn ra theo một tuần tự duy nhất xuyên suốt toàn bộ dự án. 

Về cơ bản thì water fall bao gồm: thu thập yêu cầu, phân tích yêu cầu, thiết kế, phát triển, kiểm thử, phát hành rồi duy trì. Bước thu thập yêu cầu và phân tích yêu cầu thường do một đội có chức danh BA - Business Analysist đảm nhiệm. Khâu phân tích có thể có thêm các nhân sự bên thiết kế và phát triển. Kết quả của khâu này là  một tập tài liệu và đảm bảo mọi thành viên trong đội dự án từ BA, designer, developer, tester đều nắm được. Nhưng vấn đề ở chỗ việc hiểu cũng có nhiều mức. Nhiều khi mình cứ tưởng mình hiểu khách hàng nhưng hóa ra là mình lại chẳng hiểu gì về họ. Sai sót trong sự hiểu có thể đến từ chính khách hàng. Khách hàng hầu hết là dân kinh doanh, chẳng biết gì về kỹ thuật. Ở đây chúng ta có hai nhóm khách hàng và developer, designer có cách nhìn về một vấn đề rất khác nhau. Để ngăn ngừa sự hiểu lầm này mà ra đời BA là cầu nối giữa hai nhóm. BA do đó thường là một dân chuyên làm kỹ thuật, có hiểu biết về kinh doanh. Với các dự án onsite, BA cũng thường là BrSE - Bridge System Engineer. Trắc trở nữa là khách hàng đôi khi còn không hiểu họ cần gì. Họ hay nhầm lẫn giữa cái họ cần và cái họ muốn. Cái họ muốn thường xa vời, không đem lại lợi ích trực tiếp cho kinh doanh của họ. Một BA giỏi thì cần loại bỏ suy nghĩ về ham muốn này của khách hàng. 

Kể cả BA đã làm tốt vai trò của họ thì mọi chuyện cũng không đơn giản. Vì water fall chỉ diễn ra tuần tự một lần có nghĩa là bạn không thể dành hẳn thời gian để phân tích yêu cầu khi có sự thay đổi từ khách hàng. Tệ thay, điều này diễn ra thường xuyên. Vô hình chung, trong dự án xuất hiện những khoảng thời gian không được quản lý mà ở đó developer, designer phải họp bàn để tìm hiểu yêu cầu và tìm phương án. Nó không chỉ khiến độ tập trung của developer và designer suy giảm vì không biết lúc nào thì yêu cầu lại thay đổi lần nữa mà còn khiến cho project plan trở nên vô dụng vì đánh mất vai trò quản lý của nó. Dự án do đó dễ bị sa lầy. 

Một đặc điểm nữa của water fall là vai trò trách nhiệm trong đội dự án phân chia rất rạch ròi. Dự án water fall gồm các bước tuần tự, chưa xong bước này thì bước tiếp không làm được. Bạn có thể hình dung: designer chưa thiết kế xong thì developer cũng không code, tester viết test case xong thì đợi cho developer code xong thì test. Dù dự án rất gấp nhưng đặc thù này khiến nhân lực trong đội không hoạt động 100% trong suốt dự án.

Cuối cùng, ác mộng của nhiều developer là viết tài liệu bàn giao lại xuất hiện rất nhiều vào cuối dự án. Dự án water fall đòi hỏi khá nhiều tài liệu. Mình lúc đầu cùng sùng bái tài liệu nhưng sau này mình thấy tài liệu chỉ là công cụ để trao đổi thông tin, ý tưởng và cách này không hiệu quả bằng giao tiếp trực quan giữa người với người. Có một số dự án sử dụng framework chặt chẽ thì việc viết tài liệu mô tả là thừa thãi. Khi làm theo framework, các class đã có vai trò nào, thuộc tầng nào đã rõ hết rồi. 

Bạn thấy đấy, water fall là quy trình rất cực nhọc. Có lẽ nó chỉ phù hợp cho các dự án dài hơi, thiết kế phức tạp, ổn định về yêu cầu và được thực hiện bởi một đám developer designer giàu kinh nghiệm. Scrum một quy trình phát triển phần mềm nhanh khắc phục hầu hết nhược điểm của water fall. Sức mạnh của scrum đến từ một lối tiếp cận và thực hiện dự án mới mẻ.

Sơ lược về cách scrum thực hiện:

Khách hàng viết product backlog - yêu cầu chính. Đội dự án sẽ họp để phân tích product backlog. Sau đó đội dự án sẽ họp tiếp để phân tích và chẻ nhỏ yêu cầu thành các sprint backlog - Tương tự kick off dự án trong water fall nhưng đây là kick off một sprint. Đóng băng backlog và thực hiện sprint. Trong quá trình chạy sprint, đội dự án có họp sprint hàng ngày khoảng 15 phút để mỗi người tự thông báo tiến độ. Kết thúc sprint sẽ trình bày sản phẩm chạy được phù hợp với sprint backlog. Trước khi chuyển sang sprint kế tiếp sẽ tiến hàng sơ kết sprint để rút kinh nghiệm.

Scrum là tập hợp nhiều vòng phát triển phần mềm liên tục. Mỗi vòng gọi là một sprint. Kết quả mỗi vòng là một sản phẩm chạy được, chưa phải sản phẩm hoàn thiện nhưng nó hơn hẳn một bản demo. Vì có nhiều vòng phát triển nên developer và designer có thêm cơ hội để hiểu sâu hơn yêu cầu, tối ưu hóa các giải pháp, nâng cao chất lượng sản phẩm, nghiên cứu công nghệ. 

Các bước thực hiện mỗi vòng tương tự một water fall. Nhưng khác ở chỗ, trong mỗi sprint, khách hàng không được thay đổi yêu cầu. Đây là chi tiết rất đáng giá, đội dự án giờ đây sẽ toàn tâm toàn ý với công việc hơn. Đội dự án sẽ được bảo vệ bởi scrum master khi đang hoạt động trong một sprint. Kết quả mỗi sprint lại là một sản phẩm chạy được nên giữ được nhịp độ cho đội phát triển.

Một điểm đáng lưu ý nữa là scrum không phân nhiệm rõ ràng vai trò từng cá nhân trong đội. Một cá nhân có thể có đa trách nhiệm. Anh hay cô ta có thể là developer với backlog này nhưng lại có thể là designer với backlog khác hay thậm chí là tester với một backlog khác nữa. Cải tiến này sẽ nâng cao năng suất của đội dự án, giờ đây thì chẳng có sự chờ đợi giữa các cá nhân làm các công việc chuyên biệt như trước nữa.

Đội dự án trong scrum là tập hợp các cá nhân có động lực. Họ không nhận việc mà đăng ký để thực hiện việc. Khái niệm gán việc bị loại bỏ hoàn toàn. Vai trò quản lý nắm đầu của PM cũng biến mất thay vào đó là scrum master nhưng scrum master chỉ có vai trò hỗ trợ và bảo vệ đội. Đôi khi anh hay cô ta cũng có thể là một phát triển viên trong đội.

Cuối cùng, scrum không yêu cầu tài liệu kinh khủng như water fall. Scrum khuyến khích trao đổi trực tiếp để giữ cho luồng thông tin thông suốt giữa các cá nhân trong đội.

Một số ngoại lệ: 

Nếu khách hàng thay đổi sprint backlog giữa lúc sprint đang hoạt động ?

Nếu khách hàng hủy sprint backlog ?

Tính thực tiễn trong ứng dụng scrum ?