Scrum-software development

"Scrum cách tiếp cận rất mới mẻ và sáng tạo giúp giải quyết các khó khăn và phức tạp" Scrum là 1 phương pháp phổ biến nhất trong các phương pháp phát triển phần mềm theo tư tưởng agile, nó thường là phương pháp đầu tiên được các doanh nghiệp lựa chọn để áp dụng khi quyết định chuyển đổi từ mô hình truyền thống sang hướng Agile. Cách làm trong mô hình scrum được minh họa như hình dưới đây

• Nhóm bắt đầu với những chức năng cần có trong sản phẩm gọi là product backlog
• Nhóm Scrum sẽ phát triển sản phẩm thông qua nhiều sprint, hoàn thành chức năng, bàn giao đến tay người dùng sớm nhất
• Cách làm việc theo Sprint được lặp đi lặp lại đến khi mọi việc trong Prod backlog được hoàn thành hoặc khi PO quyết định dừng dự án theo tình hình thực tế
• Chiến thuật của Scrum:
• Có giá trị cao làm trước --> Scrum luôn mang lại giá trị cao nhất về mặt kinh doanh
• Tập trung vào việc chuyển giao chức năng --> tối ưu hóa quá trình phát triển, phản hồi
• Cải tiến quy trình sau mỗi sprint --> năng suất lao động tăng

Vai trò trong mô hình Scrum

Scrum team gồm 7-9 thành viên Đây là nhóm tự tổ chức: tự chọn quy trình, kĩ thuật để thực hiện và đạt mục tiêu, ko chịu ảnh hưởng từ người ngoài nhóm Cũng là nhóm liên chức năng: nhóm có đầy đủ kiến thức và kĩ năng cần thiết

• Product Owner (PO) là người duy nhất chịu trách nhiệm về quản lý sản phẩm, quản lý backlog, PO là 1 người, không phải 1 nhóm để đảm bảo thông tin đưa đến nhóm là duy nhất, không gây hiểu lầm
• Scrum master: giảm thiểu trở ngại, định hướng và hỗ trợ team

Product backlog

Bao gồm mọi thứ để hoàn thiện sản phẩm (bug, task..) Giai đoạn đầu của dự án Product backlog chỉ gồm các chức năng chính của sản phẩm, trong quá trình làm thì danh sách này có thể được bổ sung để làm rõ hơn hoặc bổ sung thêm các chức năng khác. Danh sách được sắp theo thứ tự ưu tiên Việc thực hiện dự án chỉ kết thúc khi toàn bộ các task trong product backlog được hoàn thành hoặc khi PO quyết định dừng. Product backlog không phải một danh sách cố định, nó thường xuyên được thay đổi để đáp ứng mong muốn của khách hàng, ở mỗi sprint độ ưu tiên sẽ được thiết lập lại PO cần đảm bảo những task trên cùng của Prod backlog đạt trạng thái sẵn sàng khi bắt đầu Sprint

Sprint

Một Sprint có time box kéo dài từ 1 đến 4 tuần. Sprint thường phải đủ ngắn để phần (tăng trưởng) bàn giao nhận được phản hồi nhanh, đủ dài để hoàn thành ít nhất 1 phần tăng trưởng. Các sprint nên có chung 1 khoảng thời gian để duy trì sự ổn định, tạo thành chu kì cải thiện quy trình và hiệu suất làm việc Mục đích việc chia nhỏ giai đoạn phát triển thành các Sprint là để có thể bàn giao được liên tục và nhận phản hồi sớm nhất từ phía khách hàng cũng như kịp thời đáp ứng với thay đổi. Sprint sau sẽ được bắt đầu ngay sau khi sprint trước kết thúc. Kết thúc khi timebox hết hoặc PO quyết định dừng Sprint. Tuy nhiên việc dừng sprint thường ít xảy ra và cần được cân nhắc kĩ vì việc này ảnh hưởng đến tinh thần của nhóm. Nhưng nếu Sprint Goal ko còn được đảm bảo hoặc lỗi thời thì Sprint nên được dừng lại do mục tiêu là hướng tới giá trị

Sprint Planning

Là cuộc họp đầu tiên trong Sprint, có time box là 8h cho sprint 4 tuần Thành phần tham dự gồm có: Scrum Master, Product Owner, Scrum Team Các công việc thực hiện trong buổi Sprint planning Trong các sprint đầu thì cần phân tích kĩ khả năng của nhóm: nhóm có bao nhiêu thành viên, mỗi người có bao nhiêu thời gian, kiến thức của member đủ chưa hay cần thêm thời gian để tìm hiểu. Đánh giá hiệu suất làm việc trước đây để ước lượng xem nhóm có thể thực hiện bao nhiêu công việc với năng lực hiện tại.

• Phân tích & đánh giá product backlog từ đó đưa ra Sprint Goal
• Dựa trên Sprint Goal lựa chọn các task trong Product backlog theo thứ tự ưu tiên để đưa vào Sprint backlog.

Sprint Backlog

Là danh sách các task lựa chọn từ Product backlog và được sắp xếp theo thứ tự ưu tiên. Danh sách này được cập nhật trong suốt Sprint và được quản lý bởi Scrum team, các thành viên tự ước lượng cho task của mình. Kết thúc sprint, các task còn lại có thể scope out

Define of Done (DoD)

Là các mô tả cho biết khi nào công việc được hoàn thành. DoD cần diễn đạt đầy đủ, rõ ràng, không gây hiểu lầm và được thống nhất trong Scrum team Có thể tạo các DoD khác nhau cho các công việc khác nhau nhưng nên có DoD chung cho các công việc Ví dụ về DoD cho task chức năng

Daily Scrum

Là cuộc họp hàng ngày, có time box là 15 phút và nên diễn ra vào cùng một thời điểm trong ngày để tạo thành thói quen cho team Thành phần: Scrum team, SCM

Trả lời 3 câu hỏi:

• Tôi đã làm gì trong ngày hôm qua?
• Tôi sẽ làm gì hôm nay?
• Có trở ngại nào không?

Mục đích:

• Đồng bộ các hoạt động
• Kịp thời thay đổi kế hoạch
• Bám sát Sprint Goal
• Không cố gắng bàn luận, giải quyết vấn đề trong daily scrum

Sprint Review

Cuộc họp ở gần cuối Sprint, thời lượng cho cuộc họp là 4h- sprint 4 tuần

Thành phần: Scrum team, PO, SCM, và các bên liên quan

Mục đích:

• Demo những phần đã được bàn giao
• Điều chỉnh Product Backlog cho sprint tiếp theo

Kết quả của Sprint Review là một Product Backlog được sửa đổi

Sprint Retrospective

Đây là một cuộc họp mang tính cải tiến của Scrum so với các mô hình truyền thống, thời lượng là 3h cho sprint 4 tuần

Thành phần: Scrum team, SCM, PO

Mục đích:

• Cải tiến quy trình Trong buổi họp, cả team cùng nhìn lại Sprint:
• Con người, cộng tác, quy trình, công cụ
• Việc thực hiện tốt
• Việc gì có thể làm tốt hơn

--> Đề ra hành động nhằm cải tiến Buổi họp không mang tính chỉ trích mà là không gian mở để nhận ra vấn đề trong hoàn cảnh cụ thể của nhóm

Tham khảo: Agile Y