Quy trình SCRUM: Thành công mới trong phát triển phần mềm

Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.

Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống. Các tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và đánh giá lại sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra.

Thành phần chính quan trọng của scrum là các role (vai trò) và các cuộc trao đổi đánh giá. Có các role chính là: 

+ Product Owner: là người làm những công việc bắt đầu cho dự án, tạo ra các yêu cầu trong quá trình phát triển dự án. Phân tích mục tiêu, giải phóng các kế hoạch.

+ Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại.

+ Đội làm việc ở scrum: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất nhiều đội, nhiều người tham gia. Sẽ không có những lập trình viên (programmer), người thiết kế (designer), kiểm thử viên (tester),… thường thấy ở các dự án phần mềm truyền thống. Các đội làm việc sẽ tiến hành cài đặt các chức năng được mô tả trong bản yêu cầu. Họ tự quản lý, tổ chức và điều chỉnh đội làm việc của mình sao cho hiệu quả lớn nhất. Tất cả các thành viên có ảnh hưởng như nhau đến sự thành công hoặc thất bại của toàn bộ hệ thống hoặc các hệ thống nhỏ hơn trong đó.

Có 2 pha là lập kế hoạch và kết thúc sẽ xác định các tiến trình cần thiết gồm các dữ liệu đầu vào đầu ra thật đầy đủ. Có một số vòng lặp phát triển trong pha kế hoạch. Kế hoạch lập ra ban đầu chỉ là tương đối và sẽ có sự điều chỉnh.

2. So sánh scrum và các quy trình phần mềm truyền thống

Với các phương pháp truyền thống, việc lập kế hoạch dự án (xác định những việc cần làm và thời gian kế thúc) dựa trên kinh nghiệm chứ không phải là môi trường làm trực tiếp. Và so với kế hoạch đó khi bắt tay vào xây dựng thì thường có độ trễ nhất định.

Scrum và quy trình thác nước (waterfall), xoắn ốc (spiral)

Mô hình thác nước chia dự án phần mềm gồm các giai đoạn: đặc tả yêu cầu, thiết kế hệ thống, cài đặt (lập trình), kiểm thử và bảo trì. Quy trình này dễ quản lý nhưng lại kém linh hoạt và không hiệu quả bởi nếu có sự thay đổi ở các giai đoạn sau sẽ ảnh hưởng rất lớn đến các giai đoạn trước.

Quy trình xoắn ốc chia dự án thành các giai đoạn: lập kế hoạch, phân tích rủi ro, giao tiếp khách hàng, đánh giá lại, sản xuất và phân phối. Nó vẫn chưa được sử dụng rộng rãi.

Các quy trình phần mềm truyền thống thường có quá khá nhiều giai đoạn, nhiều thành phần, yếu tố trong suốt thời gian phát triển sản phẩm. Phương pháp scrum tránh điều này. (Xem bảng)

3. Cách thức cài đặt để sử dụng scrum 

Có nhiều cách để triển khai, có thể sử dụng 10 bước sau:

– Bước 1: Thu nhập các đặc điểm của sản phẩm (backlog) trong đơn đặt hàng. Đây là bước quan trọng nhất. Lập nên các đội làm việc, có thể tách thành các đội nếu cần thiết và thảo luận với nhau về nghiệp vụ cần làm. Sau đó bổ nhiệm một người vào vị trí Product owner, người này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp ưu tiên đúng thứ tự các nhiệm vụ. Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ưu tiên. 

• Bước 2: Ước lượng đầy các yêu cầu về sản phẩm đầu ra. Có ước lượng ở mức độ cao, chia sản phẩm thành số lượng các danh mục backlog. Tuy nhiên số lượng sẽ không chính xác được, về sau chúng sẽ được bổ sung. Tiếp đến là ước lượng chi tiết từng backlog, ước lượng số lượng các đội làm việc.

• Bước 3: Lên kế hoạch phát triển các vòng lặp sprint. Sử dụng các cuộc trao đổi kế hoạch phát triển sprint với tất cả các thành viên. Xác định khoảng thời gian sẽ phát triển một sprint (thường là 30 ngày), mục tiêu của sprint là gì, sẽ đạt được gì, phân tích các yêu cầu của sprint một cách rõ ràng.

• Bước 4: Lên kế hoạch phát triển các nhiệm vụ của sprint. Tất cả mọi người sẽ xác định ngân sách của sprint đó, chia các đặc điểm thành các tác vụ nhỏ hơn, ước lượng số thời gian sẽ làm từng task (giờ), hoàn tất các yêu cầu và nhận dạng task quan trọng.

• Bước 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi người. Thường sử dụng bảng trắng để vẽ nên những vấn đề cần thiết cho tất cả mọi người cùng đánh giá.

• Bước 6: Các thành viên bắt tay xây dựng từng sprint. Lập trình, kiểm thử và điều chỉnh thời gian để có hiệu quả tốt nhất. Đôi khi có thể hủy bỏ một sprint và quay lại với việc lập kế hoạch khác.

• Bước 7: Mọi người báo cáo kết quả để tiếp tục làm việc. Các báo cáo tập trung vào các vấn đề: đạt được những gì so với lần trao đổi trước; sẽ hoàn thành những gì trong lần trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc v.v. 

• Bước 8: Tổng hợp kết quả trên biểu đồ. Đây là bức tranh tổng quát về những việc đã làm được, những việc chưa làm được, thời gian ước lượng còn lại và có thể điều chỉnh lại. 

• Bước 9: Xem xét để hoàn tất. Khi các thành viên nói công việc đã hoàn thành có nghĩa là mọi thay đổi sẽ bị từ chối, đẩy lại cho vòng lặp sau.

• Bước 10: Đánh giá, phản ánh và lặp lại. Có các cuộc họp đánh giá lại sprint của các thành viên. Sẽ trình bày những gì đạt được, phản hồi của khách hàng, xét thời hạn của sprint. Nhìn lại biểu đồ ở bước 8 để xác định lại toàn bộ hệ thống và tiếp nhận những đóng góp, bổ sung để đưa tiếp vào các vòng lặp sprint tiếp theo.

4. Các điểm mạnh

Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế. 

Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt theo môi trường sử dụng thực tế.
Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu.

Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao.

Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá lại ở những vòng lặp phát triển.

Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất nhanh. Và khi đi sai hướng, có thể hủy ngay sprint đó để quay lại với bản kế hoạch.

Đây là bài sử dụng nguồn trích dẫn tài liệu từ http://www.pcworld.com.vn/articles/cong-nghe/cong-nghe/2009/12/1195134/quy-trinh-scrum-thanh-cong-moi-trong-phat-trien-phan-mem/