Scrum – Quy trình phát triển phần mềm

Nếu trước kia nói đến dự án phần mềm bạn nghĩ ngay đến quy trình gồm nhiều giai đoạn khá phức tạp với thời gian hoàn thành thường vài tháng đến vài năm. Bây giờ mọi chuyện đã khác. Sự ra đời và phát triển của Phương pháp phát triển phần mềm linh hoạt Agile đã mang lại những thành công nhất định trong phát triển phần mềm. Có vài phương pháp trong Agile nhưng phổ biến nhất là “Scrum” một qui trình được xác định để giám sát và kiểm soát các hoạt động phát triển phần mềm. Scrum chia dự án thành các vòng phát triển lặp 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.

Khía cạnh then chốt của Scrum là vai trò, trách nhiệm của mọi người trong tổ như sau:

Người chủ sản phẩm (Product Owner) chịu trách nhiệm cho những điều sau:
Xác định tính năng của sản phẩm;
Quyết định về ngày đưa ra và nội dung;
Ưu tiên hoá các tính năng tương ứng với nhu cầu của khách hàng;
Điều chỉnh các tính năng và ưu tiên cứ sau 30 ngày, khi cần; và
Chấp nhận hay bác bỏ kết quả công việc.

Người chủ Scrum (Scrum Master) là người lãnh đạo tổ làm việc chặt chẽ với người chủ sản phẩm:
Đảm bảo rằng tổ hoạt động và có năng suất đầy đủ;
Tạo khả năng cho hợp tác chặt chẽ qua tất cả các vai trò và chức năng;
Che chắn cho tổ khỏi bị can nhiễu bên ngoài; và
Đảm bảo rằng qui trình được tuân theo,

Tổ (Team):
Xuyên chéo chức năng, với các thành viên có kinh nghiệm;
Lựa chọn mục đích việc chạy nước rút (Sprint) và xác định kết quả công việc;
Có quyền tự tổ chức bên trong biên giới của hướng dẫn để đạt tới mục đích của Sprint;
Đề mô kết quả công việc cho người chủ sản phẩm.

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.


Sự khác nhau giữa 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.

Mô hình thác nước (waterfall) 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 (spiral) 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.



Cách thức triển khai cài đặt Scrum:

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

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, 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ụ.


2. Ước lượng đầy các yêu cầu về sản phẩm đầu ra. Chia sản phẩm thành số lượng các danh mục backlog. 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.


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.


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.


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á.


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.


7. Mọi người báo cáo kết quả; 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.


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.


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.


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.

Ưu điểm

• Đ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.

Nhược điểm

• Quy mô đội ngũ: Trung bình giới hạn từ 7 đến 10 người, quy mô đội ngũ có thể là một trở ngại nếu nó vượt quá số lượng đề xuất này. Việc tổ chức các cuộc họp sẽ không khả thi và nền tảng của phương pháp này trở nền suy yếu.


• Số lượng yêu cầu nhiều: Số yêu cầu có thể đến từ nhiều kênh của dự án và đôi khi có thể khó quản lý vì các khía cạnh khác nhau của chúng. Ở mức độ nhận giao hàng, những mâu thuẫn này có thể làm chậm quá trình xác nhận.


• Chất lượng phát triển: Số lượng đội ngũ càng tăng, chất lượng càng khó kiểm soát. Điều này hoàn toàn đúng khi dự án được triển khai tại nhiều chi nhánh. Các rủi ro đặc biệt liên quan đến chất lượng code và số lượng khiếm khuyết được xác định tại thời điểm tích hợp.