Mô hình SCRUM trong phát triển phần mềm

Ở bài trước mình đã giới thiệu sơ qua về Agile và Scrum. Hôm nay mình sẽ tiếp tục tìm hiểu sâu hơn, chi tiết hơn về mô hình Scrum.

1. Roles (Nhóm Scrum)

Quy trình Scrum có 3 nhóm ứng với 3 vai trò có trách nhiệm rõ ràng để đảm bảo tối ưu hóa các đặc tính của quy trình này. Các nhóm này bao gồm:

a. Product Owner

Product Owner 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.

Product Owner chịu trách nhiệm quản lý product backlog:

• Miêu tả rõ ràng từng product backlog
• Sắp xếp mức độ ưu tiên của product backlog hợp lý để đạt được mục đích và hoàn thành các nhiệm vụ
• Tối ưu hóa giá trị mà Development team thực hiện
• Đảm bảo product backlog rõ ràng, minh bạch và chỉ ra những gì mà nhóm Scrum sẽ làm việc
• Đảm bảo Development team hiểu product backlog với các mức độ cần thiết

Product Owner là người chịu trách nhiệm chính của sản phẩm, vậy nên PO là người duy nhất đưa ra yêu cầu cho Development team, và Development team cũng không được phép làm theo bất kỳ yêu cầu nào khác ngoài yêu cầu từ PO

b. Development team (Nhóm phát triển)

Development team là những người có kỹ năng chuyên sâu trong việc trực tiếp phát triển sản phẩm. Dev team được cấu trúc và trao quyền để tổ chức và quản lý công việc của họ. Sự hợp lực sẽ tối ưu hóa nỗ lực và hiệu quả tổng thể của nhóm này.  Dev team có các đặc trưng sau:

• Đó là nhóm tự tổ chức. Không ai (kể cả Scrum Master) có quyền yêu cầu Dev team làm thế nào để chuyển Product Backlog thành các phần tăng trưởng có thể chuyển giao được
• Đó là nhóm liên chức năng, với tất cả các kĩ năng cần thiết để tạo ra phần tăng trưởng của sản phẩm
• Scrum không ghi nhận một chức danh nào trong Development team ngoài Developer, theo tính chất công việc của người này, không có ngoại lệ cho quy tắc này.
• Các thành viên Development team có thể có các kĩ năng chuyên biệt và các chuyên môn đặc thù, nhưng họ phải chịu trách nhiệm dưới một thể thống nhất là Development team
• Development team không chứa các nhóm con nào khác với các chức năng đặc thù như “nhóm kiểm thử” hay “phân tích nghiệp vụ”.

Một Development team tối ưu nên có từ 3 đến 9 người. Không nên nhỏ hơn 3 hoặc vượt quá 9 thành viên. PO và Scrum master nếu không phải là thành viên của Development team thì sẽ không được tính vào kích thước, quy mô của nhóm này.

c. Scrum Master

Scrum Master chịu trách nhiệm hỗ trợ Scrum team bằng cách giúp mọi người hiểu lý thuyết, thực hành, các quy tắc và những giá trị của Scrum.

Scrum Master giúp tổ chức bên ngoài Scrum team hiểu được những tương tác nào của họ với Scrum team là có ích và tương tác nào thì không. Scrum Master giúp mọi người thay đổi những tương tác đó để tối đa hóa giá trị được tạo bởi Scrum team.

Scrum Master giúp đỡ tất cả mọi người cải tiến các mối tương tác để tối đa hóa giá trị mà Nhóm Scrum tạo ra

2. Scrum Event

Scrum event là các sự kiện được quy định trong scrum tạo ra sự đều đặn, giảm tối đa các cuộc họp không được định nghĩa trong scrum. Tất cả sự kiện đều quy định khung thời gian rõ ràng, tức là đã quy định khoảng thời gian tối đa cho mỗi sự kiện. Khi một sprint bắt đầu, khoảng thời gian của nó đã được cố định sẵn, không thể rút ngắn lại hoặc kéo dài hơn.

Tính chất của Scrum cũng bắt nguồn từ tính chất của Scrum Event, đó là:

• Minh bạch
• Kiểm tra
• Định kỳ
• Thích ứng

Scrum Event được chia ra thành 5 event chính là: Sprint, Sprint Planning, Daily Sprint, Sprint Review, Sprint Retrospective.

a. Sprint

Trái tim của Scrum là sprint. Trong mỗi sprint phải đề ra được mục tiêu, cam kết về kết quả và mỗi Sprint có một khung thời gian nhất định kéo dài 1 tháng hoặc ít hơn ( thường từ 2 đến 4 tuần) mà trong đó một phần tăng trưởng của sản phầm đã hoàn thành, có thể sử dụng và bàn giao được, thường là chính mục tiêu và cam kết đã đề ra

Một Sprint mới bắt đầu ngay khi Sprint trước khép lại.

Trong event Sprint chứa 4 event còn lại.

Sprint chỉ được hủy khi mục tiêu, cam kết đề ra từ ban đầu bị thay đổi. Và do sprint tương đối ngắn nên việc hủy sprint không mấy khi có tác dụng gì, mà ngược lại gây lãng phí tài nguyên. Vậy nên

b. Sprint planning

Công việc được thực hiện trong Sprint sẽ được lên kế hoạch trong buổi họp Sprint Planning. Kế hoạch này được tạo ra bởi sự tham gia của toàn bộ thành viên trong Scrum team.

Buổi Họp Kế hoạch Sprint được đóng khung trong tám tiếng cho mỗi Sprint một tháng. Với các Sprint ngắn hơn thì thời gian cho buổi họp được rút ngắn lại. Ví dụ như một Sprint hai tuần có thể chỉ cần họp kế hoạch tới bốn tiếng là đủ.

Buổi Họp Kế hoạch Sprint có hai phần, mỗi phần chiếm một nửa khung thời gian. Hai phần của buổi Họp Kế hoạch Sprint lần lượt trả lời các câu hỏi:

• Mục tiêu của Sprint này là gì?
• Sprint này phải chuyển giao cái gì?
• Làm sao để đạt được điều đó?

c. Daily Scrum meeting

Daily Scrum là sự kiện có khung thời gian 15 phút cho Dev team với mục đích đồng bộ hóa các hoạt động của thành viên và tạo lập kế hoạch cho 24 giờ tiếp theo.

Cuộc họp Scrum hằng ngày được tổ chức tại cùng một địa điểm để giảm thiểu sự phức tạp không cần thiết. Trong suốt cuộc họp, mỗi thành viên Dev team giải thích rõ:

• Tôi đã làm những gì hôm qua cho tới bây giờ?
• Tôi sẽ làm những gì hôm nay?
• Vấn đề tôi gặp phải tới hiện tại là gì?

Dev team sử dụng cuộc họp Scrum hằng ngày để đánh giá tiến độ công việc hướng tới mục tiêu Sprint và đánh giá xu hướng tiến triển của công việc trong Sprint Backlog.

d. Sprint Review

Cuối sprint, PO cùng Dev team sẽ cùng nhau ngồi lại để đánh giá, rà soát những công việc đã hoàn thành trong sprint và đưa ra đề xuất chỉnh sửa, thay đổi cần thiết.

Cũng như sprint planning, thời gian của Sprint review sẽ phụ thuộc vào độ dài của print đó. Thường là sẽ bốn giờ cho sprint một tháng.

Sprint Review có một số đặc điểm sau:

• Product Owner mời mọi người tham dự bao gồm Scrum team và những người liên quan
• Product Owner xác nhận phần nào là “Hoàn thành” và phần nào chưa “Hoàn thành”
• Dev team thảo luận những điều thuận lợi trong Sprint vừa qua, những khó khăn mà nhóm đã trải qua và cách thức giải quyết các vấn đề đó
• Dev team  trình diễn các phần việc đã “Hoàn thành” và trả lời các câu hỏi về gói tăng trưởng
• Product Owner trao đổi về Product Backlog. Dựa trên tiến độ hiện thời, Product Owner đưa ra dự đoán ngày hoàn thành dự án (nếu cần)
• Toàn bộ nhóm thảo luận về những gì sẽ làm, nhờ đó buổi Sprint Review cung cấp các giá trị đầu vào cho Sprint planning tiếp theo
• Xem xét lại thời gian biểu, tài chính, cơ sở vật chất, cũng như các yếu tố thị trường cho bản phát hành dự kiến của sản phẩm.

Kết quả của cuộc họp là một bản Product Backlog đã được cập nhật, với các hạng mục dự định sẽ được triển khai trong Sprint tới. Product Backlog có thể được điều chỉnh toàn diện để thích ứng với các cơ hội mới

d. Sprint Retrospect

Sprint Retrospective là cơ hội để Nhóm Scrum tự thanh tra và đưa ra kế hoạch cho các cải tiến trong Sprint tiếp theo. Cuộc họp này diễn ra sau khi đánh giá Sprint Review và trước buổi lên Sprint planning tiếp theo.

Mục đích của Sprint Retrospective là:

• Kiểm tra xem nhóm đã làm việc như thế nào trong Sprint vừa rồi (con người, mối quan hệ, quy trình và công cụ);
• Xác định và sắp xếp xem nhóm đã làm tốt những gì và những điều gì có khả năng đã được cải thiện;
• Tạo bản kế hoạch để thực hiện các cải tiến cách làm việc của nhóm để đạt kết quả tốt trong các sprint sau.

Kết thúc cuộc họp, Scrum team phải xác định được các cải tiến sẽ được triển khai trong Sprint tới. Việc triển khai các cải tiến này chính là sự thích nghi của Scrum team. Mặc dù các cải tiến có thể được triển khai tại bất kì thời điểm nào đó, cuộc họp Sprint Retrospective cung cấp một phiên làm việc chính thức để tập trung vào việc thanh tra và thích nghi

3. Scrum Artifacts (Tạo tác Scrum)

Các Scrum Artifacts đại diện cho công việc hoặc giá trị để cung cấp sự minh bạch và cơ hội để kiểm tra và điều chỉnh. Các tạo phẩm được định nghĩa bởi Scrum được thiết kế đặc biệt để tối đa hóa tính minh bạch của thông tin quan trọng để mọi người đều có cùng hiểu biết về sản phẩm.

a. Product Backlog

Product Backlog là một danh sách sắp thứ tự tất cả những gì cần thiết của sản phẩm. Nó là nguồn yêu cầu duy nhất thể hiện các thay đổi trong sản phẩm. Product Owner là người chịu trách nhiệm về Product Backlog, nội dung của nó, sự hiện diện và thứ tự các hạng mục trong đó.

Product Backlog có thể không bao giờ hoàn chỉnh. Phiên bản sớm nhất của Product Backlog chỉ cho thấy các yêu cầu được tìm hiểu rõ ràng từ lúc đầu tiên. Product Backlog sẽ tiến hóa cùng với sản phẩm và môi trường mà nó sẽ được sử dụng. Product Backlog là động, nó thay đổi thường xuyên để nhận biết những gì mà sản phẩm cần phải có để có tính cạnh tranh và hữu ích. Chừng nào sản phẩm còn đó, thì Product Backlog cũng hiện diện.

Product Backlog liệt kê tất cả các tính năng (feature), chức năng, yêu cầu, cải thiện, vá lỗi cần thiết để làm nên sản phẩm trong tương lai. Các hạng mục trong Product Backlog được mô tả với các thuộc tính như: mô tả, thứ tự, ước lượng và giá trị.

Product Backlog thường được sắp xếp theo các giá trị, độ rủi ro, độ ưu tiên và sự cần thiết. Các hạng mục đứng đầu danh sách sẽ trực tiếp điều khiển các hoạt động phát triển. Càng ở thứ tự cao hơn, các hạng mục càng được quan tâm nhiều hơn và được tập trung nỗ lực nhiều hơn vì chính giá trị của chúng.

Dev team chịu trách nhiệm việc ước lượng các hạng mục Product Backlog. Product Owner có thể gây ảnh hưởng lên Nhóm bằng cách giúp họ hiểu và lựa chọn trong các tình huống khó, nhưng người trực tiếp làm việc sẽ đưa ra con số ước lượng cuối cùng.

Product backlog nên được quản lý bằng những công cụ chuyên dụng và phải được update thường xuyên.

b. Sprint backlog

Sprint Backlog là tập hợp các mục Product Backlog được chọn cho Sprint, cộng với một bản kế hoạch bàn giao sản phẩm và thực hiện Mục tiêu Sprint. Sprint backlog chính là kết quả của event Sprint planning

Sprint Backlog cho thấy tất cả những việc Dev tem cần phải làm để tiến tới Mục tiêu Sprint.

Với sự kết hợp của PO, nhóm sẽ phân tích cá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 (TODO list).Increment

c. Increment (Sự tăng trưởng)

Increment là tập hợp tất cả các hạng mục Product Backlog đã được hoàn thành trong suốt Sprint hiện tại và những Sprint trước đó. Cuối Sprint, Increment mới phải thỏa mãn điều kiện “Hoàn thành”, có nghĩa là nó phải ở trạng thái sử dụng được và thỏa mãn định nghĩa của Nhóm Scrum về “Hoàn thành”. Increment phải ở trạng thái dùng được để Product Owner có thể quyết định phát hành (release) nó

d. Burndown / Burn up chart

Rất nhiều phương pháp có thể được sử dụng để biểu thị tiến độ công việc, như các biểu đồ burndown, biểu đồ burnup hay các phương pháp dự báo khác. Các biện pháp này đã được chứng minh là rất hữu ích. Tuy nhiên, những thứ này không thay thế được tầm quan trọng của tính thực nghiệm trong quá trình phát triển. Trong các môi trường phức tạp, ta không thể biết được những điều sắp xảy ra. Chỉ có thể dựa trên những điều đã xảy ra để đưa ra các quyết định cho tương lai

Biểu đồ không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

4. Artifact Transparency (Minh bạch các tạo tác)

Scrum vận hành dựa trên sự minh bạch. Các quyết định để tối ưu hóa giá trị và kiểm soát rủi ro dựa nhiều vào việc quan sát trạng thái của các đồ tạo tác Scrum (artifact). Nếu sự minh bạch là đầy đủ, các quyết định sẽ trở nên dễ dàng. Nếu các tạo tác không minh bạch, các quyết định có thể thiếu sót hoặc tiềm ẩn rủi ro.

Scrum Master phải làm việc với Product Owner, Dev team và các đối tượng khác để hiểu rõ tại sao các tạo tác này không hoàn toàn minh bạch. Có nhiều cách để xử lý việc này Scrum Master phải giúp đỡ mọi người áp dụng cách thức phù hợp trong tình thuống thiếu vắng sự minh bạch đầy đủ. Scrum Master có thể phát hiện sự minh bạch không đầy đủ bằng việc thanh tra các tạo tác, các mẫu thăm dò, lắng nghe những gì được nói và phát hiện những sự khác biệt giữa những gì dự kiến và kết quả thực tế.

Nhiệm vụ của Scrum Master là làm việc với Nhóm Scrum và tổ chức để gia tăng tính minh bạch cho các tạo tác này. Công việc này đòi hỏi sự học hỏi, thuyết phục và thay đổi. Minh bạch không phải là việc ngày một ngày hai, mà là cả một quá trình

5. Tham khảo

Wikipedia: Scrum (mô hình phát triển phần mềm)

Học việnn agile: https://hocvienagile.com/