Mô hình Agile – Quy trình Scrum trong phần mềm

Vinaspar - Scrum sử dụng cách thực lập kế hoạch từng phần và tăng dần theo thời gian, theo đó việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án phần mềm, đặc biệt mobile app. Mô hình cải tiến scrum linh hoạt để thay đổi các yêu cầu theo nhu cầu của khách hàng

Quy trình scrum được phát triển để đáp ứng cho việc thay đổi yêu cầu của khách hàng 1 cách liên tục và thường xuyên. Trước đó có các mô hình như thác nước waterfall, interation, spiral, các mô hình cổ điển nhưng thế giới và yêu cầu các phần mềm cũng phức tạp hơn và thay đổi nhiều hơn. Nên cần có mô hình cấp tiến để đáp ứng nhu cầu này.,

>> Các mô hình và vòng đời phát triển phần mềm 

1. Khái niệm

Là phương pháp phát triển phần mềm linh hoạt dể làm sao đưa sản phẩm đến tay người dùng càng nhành càng tốt càng sớm càng tố. Scrum là 1 dạng của mô hình Agile và là Framework phổ biến nhất khi thực hiện mô hình agile. Scrum là mô hình phát triển phần mềm lặp đi lặp lại. Những khoảng lặp cố định thường kéo dài 1,2 tuần được gọi lại Sprint hoặc Iteration

2. Quy trình Scrum vận hành như thế nào

Product backlog: đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requiement) của dự án. Produck Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (product backlog item) trong product backlog dựa trên các giá trị do Produck Owner định nghĩa. Sprint backlog: đây là bản kế hoạch cho một sprint, là kết quả của buổi học kế hoạch (sprint planning). Với sự kết hợp của Produck Owner, nhóm sẽ phân tích cá yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong product backlog dưới dạng danh sách công việc. Produck Owner tạo ra product backlog chứa các yêu cầu của dự án với hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Produck Owner với sự lặp đi lặp lại các giai đoàn từ 1 đến 4 tuần làm việc gọi là sprint với đầu vào là các hạng mục trong product backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao. Đội sản xuất cùng họp với Produck Owner để lập kế hoạch cho từng sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là sprint backlog chứa các công việc cần làm trong suốt 1 sprint.

Các sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong product backlog đều được hoàn tất. Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật sprint backlog và thực hiện công việc họp hằng này để chia sẻ tiến đọc công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyên để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong sprint. Khi kết thúc sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao cho khách hàng. Buổi họp sơ kết sprint ở cuối sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến. Sau khi kết thúc đánh giá sprint, scrum master và nhóm cùng tổ chức họp cải tiếng để tìm kiếm các cải tiến trước khi sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng sprint.

3. Đặc trưng Agile

3.1 Tính lặp (Iterative) Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Iteration hoặc Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho ra các phần nhỏ của sản phẩm. Các phương pháp agile thường phân chia mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không thực hiện việc lập kế hoạch dài hạn.

3.2 Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary) Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment of functionality). Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành.

3.3 Tính thích ứng (hay thích nghi – adaptive) Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp . Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo. Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi.

3.4 Nhóm tự tổ chức và liên chức năng Cấu trúc nhóm agile thường là liên chức năng(cross-functionality) và tự tổ chức(self-organizing). Theo đó, các nhóm này tự thực hiện lấy việc phân công công việc mà không dựa trên các mô tả cứng về chức danh (title) hay làm việc dựa trên một sự phân cấp rõ ràng trong tổ chức. Các nhóm này cộng tác với nhau để ra quyết định, theo dõi tiến độ, giải quyết các vấn đề mà không chờ mệnh lệnh của các cấp quản lý. Họ không làm việc theo cơ chế “mệnh lệnh và kiểm soát” (command and control).

3.5 Quản lý tiến trình thực tiễn (Empirical Process Control) Các nhóm agile ra các quyết định dựa trên các dữ liệu thực tiễn thay vì tính toán lý thuyết hay các tiền giả định (prescription). Việc phân nhỏ dự án thành các phân đoạn ngắn góp phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh các chiến lược phát triển của mình. Nói cách khác, Agile rút ngắn vòng đời phản hồi (short feedback life cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chiến lược này sẽ tiến gần đến trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động.

3.6 Giao tiếp trực diện(face-to-face communication) Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc code) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu.

3.7 Phát triển dựa trên giá trị (value-based development) Một trong các nguyên tắc cơ bản của agile là “phần mềm chạy tốt chính là thước đo của tiến độ”. Nguyên tắc này giúp nhóm dám loại bỏ đi các công việc dư thừa không trực tiếp mang lại giá trị cho sản phẩm.

4. Quy trình Scrum: 4 cuộc họp

1. Sprint Panning(họp kế hoạch Sprint): nhóm phát triển họp với product owner để lên kế hoạch làm việc cho 1 sprint. Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiets để hoàn tất các tacs vụ. Scrum sử dụng cách thực lập kế hoạch từng phần và tăng dần theo thời gian, theo đó việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.
2. Daily Scrum (họp scrum hằng ngày): scrum master tổ chức cho đội sản xuất họp hằng ngày trong khoảng 15p để nhóm hát triển chia sẻ tiến độc công việc, trong cuộc họp này từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi: Hôm qua đã làm gì? Hôm nay sẽ làm gì? Có khó khăn trở ngại gì không?
3. Sprint review (họp sơ keert sprint): cuối sprint nhóm phát triển cũng với product owner sẽ rà soát lại các công việc đã hoàn tất trong sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm
4. Sprint Retrospective (họp cải tiến sprint): dưới sự trợ giúp của scrum master nhóm phát triển sẽ rà soát lại toàn diền sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

5. Quy trình Scrum: 3 vai trò

Trong scrum đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để dảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm:

• Product Owner(GĐ dự án): là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm
• Scrum Master(Quản lý dự án): 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.
• Development Team(Dev, Test...): thường 5-9 người, tùy theo quy mô dự án nó có thể có rất nhiều, nhiều người tham gia.

NỘI DUNG CẦN NHỚ CỦA QUY TRÌNH SCRUM

Không thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ hệ thống vào code và testing cùng 1 lúc mà sẽ chia các yêu cầu làm theo từng giai đoạn. Mỗi giai đoạn chỉ làm 1 số lượng yêu cầu nhất định

• Chi thành nhiều giai đoạn nhỏ để thực hiện hay còn gọi lại sprint
• Mỗi 1 sprint thường kéo dài từ 1 đến 4 tuần (không dài hơn 1 tháng)
• Đầu sprint sẽ lên kế hoạch làm những yêu cầu nào, sau đó sẽ thực hiện code và test. Cuối sprint là 1sp hoàn hiện cả code lẫn test có thể demo và chạy được
• Hoàn thành sprint 1, tiếp tục làm sprint 2,.... cho đến khi hoàn thành hết các yêu cầu
• Trong mỗi 2 sprint thì sẽ có họp hàng – daily meeting. Cả team sẽ đứng họp thành 1 vòng tròn thường chỉ hopjc 15-20p. Mỗi thành viên sẽ báo cáo: hôm qua đã làm gì? Hôm nay sẽ làm gì? Có gặp khó khăn gì không?
• Trong mỗi 1 sprint thì các thành viên của dự án phải tạo task cho code và test, một tast code xong là phải có task test liền ngay đó. Do thời gian làm ngắn nên hiệu quả làm việc cao, đúng tiến độ đảm bảo cuối sprint là hoàn thành được cả test
• Ưu điểm phù hợp với những yêu cầu nghiệp vụ hay thay đổi hoặc hệ thống nghiên cứu do làm theo từng giai đoạn ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù hợp để thay đổi
• Điều hành đội dự án sẽ là ông scrum maste, còn có product owner là người đánh giá phần mềm làm đã đúng nghiệp vụ/ yêu cầu chưa

6. Ba chân (hay giá trị cốt lõi) của Scrum

Có 3 yếu tố cốt lõi của Scrum là:

Minh bạch: Mọi kế hoạch và công việc của các thành viên tất cả mọi người đều phải biết và công khai kể cả PO.

Thanh tra: Phải thường xuyên thanh tra kiểm soát tiến độ công việc của mình xem đã hoàn thành đến đâu rồi có phát hiện điều gì bất thường không để kịp thời xử lý, đảm bảo tiến độ công việc.

Thích nghi: Là đảm bảo rằng khi có một vấn đề mới hay có sự thay đổi nào từ phía khách hàng thì mọi người trong team sẽ có thể xử lý và đáp ứng theo cách thích hợp. Luôn phải thích nghi trọng mọi hoàn cảnh.

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt.

>> Các mô hình và vòng đời phát triển phần mềm