Tìm hiểu về mô hình Agile và quy trình Scrum

Tìm hiểu về mô hình Agile và quy trình Scrum trong phát triển phần mềm

Trong bài viết này Stanford sẽ giải thích các khái niệm cơ bản nhất cũng như những giá trị cốt lõi về Agile và quy trình Scrum trong phát triển phần mềm để bạn có thể nắm chắc được.

1. AGILE VÀ SCRUM LÀ GÌ ?

Agile là 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 khách hàng càng nhanh càng tốt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm. 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 TRÌNH SCRUM VẬN HÀNH NHƯ THẾ NÀO ?

Product backlog: Là 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 Product Owner định nghĩa.
Sprint backlog: Là bản kế hoạch cho một sprint, là kết quả của buổi họp kế hoạch (sprint planning). Với sự kết hợp của ProductOwner, 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 Product 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 Product 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ự quản lý 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ến để 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ừ 1-4 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, 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

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 thiết để 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.
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 phá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?
Sprint review (họp sơ kết sprint): Sau cuối mỗ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.
Sprint Retrospective (họp cải tiến sprint): Scrum master hỗ trợ cùng 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-10 người, tùy theo quy mô dự án nó có thể có nhiều người tham gia.

6. BA 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.

LỢI ÍCH MÀ SCRUM MANG LẠI

Sau đây là những lý do tại sao nên dùng Scrum.

Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.
Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn.
Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.
Gia tăng tỷ suất hoàn vốn đầu tư (ROI)
Tăng mức độ hài lòng của khách hàng
Kiểm soát dự án tốt, cải tiến liên tục
Giảm thiểu rủi ro khi xây dựng sản phẩm

8. Các công cụ quản lý dự án theo Agile mà bạn nên biết

TRELLO

Đây là một trong những ứng dụng quản lý dự án nổi tiếng và được sử dụng nhiều nhất. Nó có cả tài khoản miễn phí và cao cấp mang đến cho bạn cơ hội tuyệt vời để sử dụng hầu hết các chức năng phổ biến. Cấu trúc của Trello dựa trên phương pháp kanban. Tất cả các dự án được đại diện bởi các bảng, có chứa danh sách. Mọi danh sách đều có các thẻ lũy tiến mà bạn được tạo dưới dạng kéo và thả. Người dùng có liên quan đến bảng, có thể được gán cho thẻ.

Health