Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.27 MB, 23 trang )
HƯỚNG DẪN
Thực hiện phát triển sản phẩm
theo phương pháp Agile Scrum
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
MỤC LỤC
1.
2.
GIỚI THIỆU ............................................................................................................................ 3
1.1.
Mục đích ......................................................................................................................... 3
1.2.
Phạm vi .......................................................................................................................... 3
1.3.
Tài liệu tham khảo .......................................................................................................... 3
1.4.
Thuật ngữ ....................................................................................................................... 3
NỘI DUNG HƯỚNG DẪN...................................................................................................... 5
2.1.
Tổng quan về Agile scrum ............................................................................................. 5
2.2.
Khung làm việc của agile scrum .................................................................................... 6
2.3.
Mô hình phát triển trong agile scrum ............................................................................. 6
2.4.
Trình tự các công việc trong một Sprint ......................................................................... 7
2.5.
Các vai trò và trách nhiệm của đội ngũ trong agile Scrum ............................................ 9
2.6.
Vai trò của “Gà” trong mô hình Scrum ......................................................................... 10
2.7.
Các hoạt động trong Agile ........................................................................................... 10
2.8.
Các tạo tác (Artifact) trong Scrum................................................................................ 13
2.9.
Những lưu ý khi chạy sprint ......................................................................................... 22
2/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
1. GIỚI THIỆU
1.1. Mục đích
Tài liệu này có mục đích hướng dẫn IT có cái nhìn khái quát về việc phát triển phần mềm theo
phướng pháp Agile Scrum, nêu rõ vai trò trách nhiệm của mỗi member trong dự án phát triển
phần mềm theo phương pháp Agile Scrum
1.2. Phạm vi
Tài liệu này được áp dụng cho toàn bộ nhân viên của IT có tham gia vào dự án phần
mềm mô hình Agile scrum (PM, BA,DEV, Tester, QA…)
1.3. Tài liệu tham khảo
Tên tài liệu
STT
1
SCRUMstudy-SBOK-Guide-2013.pdf
2
Scrum-Guide-VI_3.pdf
Giải thích
1.4. Thuật ngữ
Viết tắt và thuật ngữ
STT
1
Product Backlog
Giải thích
Được gọi là High Level Document, chỉ ghi mô tả các tình năng cấn
có của hệ thống ở mức tổng quan
2
Sprint Backlog
Danh sách các nhiệm vụ xác định công việc của nhóm trong một
Sprint
3
Sprint
Một phân đoạn (iteration), là một chu kỳ lặp đi lặp lại công việc
tương tự nhằm tạo ra các phần tăng trưởng (increment) cho hệ
thống. Sprint thường kéo dài từ một tuần tới một tháng.Trong suốt
dự án, thời gian cho một Sprint là cố định. Từ “sprint” có nghĩa là
giai đoạn nước rút, ám chỉ sự gấp gáp và tập trung cao độ trong
khoảng thời gian ngắn để làm việc
4
Release
Là sản phẩm đầy đủ các chức năng theo yêu cầu của chủ sản
phẩm, có khả năng bán ra thị trường hay chuyển tới người dùng
5
Team (hay Development Team)
Đội phát triển
6
User Story
Là một bản tóm tắt nhu cầu người dùng. Đây là công cụ được sử
dụng phổ biến trong Scrum và các phương pháp Agile khác để thể
3/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
hiện nhu cầu người dùng. Thông thường, user story do khách
hàng, hoặc đại diện của khách hàng, người thực sự hiểu nghiệp vụ
và nắm bắt được chính xác yêu cầu của mình đối với nhóm phát
triển
7
Product Backlog Item
Một yêu cầu chức năng hay phi chức năng và các vấn đề được
sắp độ ưu tiên trong product backlog. Độ chính xác của ước lượng
phụ thuộc vào tầm quan trọng và độ chi tiết của hạng mục đó.
Phần có độ ưu tiên cao nhất sẽ được chọn trong Sprint tiếp theo
để làm việc
8
Burndown Chart
Là biểu đồ thể hiện xu hướng của công việc còn lại theo thời gian
trong một Sprint, một bản phát hành (Release), hoặc sản phẩm.
Dữ liệu cho Biểu đồ Burndown được lấy từ Sprint Backlog và
Product Backlog, với công việc còn lại được theo dõi trên trục tung
và khoảng thời gian (các ngày trong một Sprint, hoặc nhiều Sprint)
theo dõi trên trục hoành. Biểu đồ Burndown được dùng cho Bản
phát hành (khi đó gọi là Release Burndown) hoặc cho Sprint (gọi là
Sprint Burndown).
9
Scrum Team
Đây là một nhóm liên chức năng gồm Product Owner, Scrum
Master và Development Team (Nhóm Phát triển). Nhóm Scrum sẽ
cộng tác với nhau theo khung làm việc Scrum để hiện thực hóa
mục tiêu của Product Owner
10
Velocity
Là nâng suất xử lý của đội Scrum trong một Sprint
4/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
2. NỘI DUNG HƯỚNG DẪN
2.1. Tổng quan về Agile scrum
Scrum là khung làm việc được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm
(empirical process control). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết
định được dựa trên những gì đã biết. Khung làm việc Scrum đã được sử dụng để quản lý quá
trình phát triển các sản phẩm phức tạp từ đầu những năm 1990.
Scrum hoạt động dựa trên những giai đoạn nước rút (Sprint), thông thường kéo dài trong
khoảng 2 – 4 tuần để nhanh chóng đưa dần những yêu cầu của khách hàng vào hệ thống
phần mềm thực tế có thể sử dụng được.
Scrum là mô hình thúc đẩy sự tương tác và gia tăng cho hoạt động quản lý dự án dựa trên
việc tổ chức một nhóm nhỏ khoảng 5 – 9 người có khả năng chuyên sâu làm việc phụ thuộc
lẫn nhau trong một khoảng thời gian cố định.
Scrum được phát triển bởi Ken Schwaber
và Jeff Sutherland
với mục
tiêu là cung cấp một sản phẩm có gia trị ngày càng gia tăng trong những khoảng thời gian cố
định được gọi là Sprint
2.1.1 Bốn tuyên ngôn của (Agile Agile Manifesto)
1.
2.
3.
4.
Con người và sự tương tác hơn là Quy trình và công cụ
Phần mềm chạy tốt hơn là tài liệu đầy đủ
Công tác với khách hàng hơn là đàm phán hợp đồng
Phản hồi với các thay đổi hơn là bám sát kế hoạch
2.1.2 Mười hai nguyên lý của Agile
1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao
sớm và liên tục các phần mềm có giá trị.
2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các
quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
3. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ
vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự
án.
5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi
trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội
bộ nhóm phát triển là hội thoại trực tiếp.
7. Phần mềm chạy tốt là thước đo chính của tiến độ.
8. Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát
triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
11. Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các
nhóm tự tổ chức.
12. Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu
quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.
5/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
2.1.3 Giá trị của Scrum
1. Commitment: Tính cam kết cao trong công việc.
2. Focus: Tập trung vào đúng mục tiêu, chiến lược trong một thời điểm nhất định.
3. Openness: Giá trị mở đối với cả trong và ngoài dự án, mọi thông tin đều minh bạch
và công khai.
4. Respect: Giá trị gắn kết giữa các thành viên dự án với nhau, với khách hàng cũng
như trong tổ chức.
5. Courage: Giá trị của sự can đảm lãnh nhận và cam kết với công việc, can đảm công
khai minh bạch mọi thông tin…
2.1.4 Trọng tâm của Scrum
1. Timeboxing: Khoảng thời gian là cố định trong mỗi Sprint của dự án.
2. Learning from mistakes and self managing (Adaptive): Học hỏi, rút kinh nghiệm
từ những sai lầm mắc phải và tự chủ động quản lý.
3. Shippable Code: Code đặt trọng tâm vào mục tiêu ngắn hạn và sản phẩm được
đóng gói thành nhiều lần theo từng giai đoạn để sử dụng thử và cải tiến.
2.2. Khung làm việc của agile scrum
2.3. Mô hình phát triển trong agile scrum
Khác với mô hình phát triển sản phẩm theo waterfall, agile scrum phát triển sản phẩm theo các
vòng lặp tăng trưởng, mỗi vòng lặp được xác định thời gian là 2-4 tuần và kết thúc mỗi vòng lặp
sẽ có sản phẩm chạy được.
6/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
2.4. Trình tự các công việc trong một Sprint
Scrum master & development team nhận requirement từ Product owner (Product Backlog)
Scrum master & development team sẽ ngồi với nhau để thiết lập quy tắc làm việc cho đội và
định nghĩa hoàn thành.
Scrum master & development team sẽ ngồi họp kế hoạch sprint
-
Thiết lập mục tiêu sprint
-
Lựa chọn các việc có thể hoàn thành trong sprint đó
-
Đưa ra các giải phát để hoàn thành các công việc đó
7/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
-
Mỗi member trong development team sẽ tự đưa ra estimate thời gian hoàn thành công
việc của mình
-
Sau khi có được sự thống nhất giữa member với toàn bộ team và scrum master, cả
team sẽ thực hiện log task cần thực hiện lên Jira, số lượng công việc, thời gian hoàn
thành cần đúng theo kế hoạch đã đề ra trong buổi họp (QA sẽ check cài này)
Scrum master sẽ là người Start sprint trên Jira => bắt đầu quá trình phát triển
Development team bắt đầu tham gia vào quá trình thực hiện công việc theo plan đã đề ra
-
Hàng ngày, all member trong team cần log work lên Jira, việc log work cần làm càng
thường xuyên càng tốt, nó sẽ phản ánh hiện trạng thực tế của các task.
-
Khi các task đang trong quá trình thực hiện, cần đổi trạng thái chính xác tương ứng để
scrum master có cái nhìn tổng quát về sprint.
-
Mỗi ngày cả team cần họp Scrum hàng ngày
Đồng bộ hóa công việc toàn team
Cập nhập kế hoạch và tiến độ công việc
Nêu ra được các khó khăn, issue gặp phải để cả team đứa ra các solution giải
quyết kịp thời
-
Ví trí họp nên cố định, và thời gian họp ko nên kéo dài (15-30 mins)
Scrum master phải thường xuyên theo dõi Burndown chart sprin để xem tiến độ của
sprint nhanh hay chậm như thế nào => từ đó đưa ra phương án giải quyết giúp
development team
Mọi công việc vẫn phải tuân thủ theo mô hình: design, code, test
Sau khi kết thúc spint, cũng là lúc các task công việc đã hoàn thành (Done trên Jira), toàn
team sẽ ngồi họp tổng kết sprint (bao gồm scrum master, PO, Development team)
-
Trình bầy những hạng mục đã hoàn thành của Product backlog và những hạng mục
chưa hoàn thành (nếu có)
-
Cần trình rõ ràng các lý do, các phương án đã thực hiện để giải quyết issue cho PO
-
PO cần sử dụng các kỹ năng nghiệp vụ để xác định sản phẩm đã đạt được chất
lượng như mong muốn hay chưa
Họp cải tiến sprint (retrospective)
-
Thành phần gồm Scrum master, Development team, có thể có cả PO
-
Câu hỏi đặt ra cho toàn team là: Đã làm tốt những gì, và chưa tốt những gì
Mỗi member chuẩn bị 1 tờ giấy và ghi ra 3 điểm tốt, 3 điểm chưa tốt trong sprint
vừa rồi
Tổng hợp tất cả các kết quả, và nêu ra các kết quả được nhắc đến nhiều nhất
Cả team sẽ đưa ra ý kiến, cách khắc phục các vấn đề tồn đọng
Lưu ý đây là buổi họp mang tính xây dựng, không nên đặt những câu hỏi tại sao
sai ? vì sao chưa đạt được ? mà nên cùng nhau đưa ra các ý kiến để giải quyết
vấn đề tốt hơn
8/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
2.5. Các vai trò và trách nhiệm của đội ngũ trong agile Scrum
Heo: Là những người cam kết làm việc với dự án và trực tiếp thực hiện các công việc thực tế
của dự án.
Gà: Không phải là vai trò có thật trong Scrum, nhưng vẫn phải đưa vai trò này vào trong một
số các buổi họp, đặc biệt là bàn giao sản phẩm. Vì những người này chính là những người
sử dụng hoặc tác động đến sản phẩm hay quá trình xây dựng sản phẩm.
2.2.1.1 Vai trò của “Heo” trong mô hình Scrum
1. Product owner
Xác định lộ trình phát triển sản phẩm.
Xác định thứ tự ưu tiên cho các tính năng của sản phẩm.
Thiết lập các qui tắc trong việc phát triển sản phẩm.
Mô tả và duy trì mức độ chi tiết cho các tính năng của sản phẩm.
Sẵn sàn chuẩn bị cho những cuộc đàn phám có thể xảy ra.
Định hướng nghiệp vụ trong quá trình phát triển sản phẩm.
Chấp nhận và xác định mức độ có thể chấp nhận sản phẩm (xác định thời điểm kết thúc việc
phát triển sản phẩm).
Vị trí này có thể là: Trưởng phòng sản xuất, trưởng phòng kinh doanh, quản trị dự án… hoặc
khách hàng.
2. Scrum master
Bảo vệ nhóm và giữ cho họ tập trung tới mục tiêu đã xác định.
Loại bỏ các trở ngại đối với nhóm để hướng tới mục tiêu của Sprint.
Chấp hành, thi hành các qui tắc đối với nhóm.
9/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
Là thành viên điều phối của nhóm.
Đại diện cho nhóm trước các bên liên quan.
Kỹ năng cần thiết cho Scrum Master:
Đặt việc phục vụ nhóm lên dàng đầu.
Lắng nghe đồng đội cũng như các bên liên quan.
Phương pháp làm việc hướng tợi việc tự tổ chức nhóm.
Tạo điều kiện (loại bỏ trở ngại).
3. Development Team
Làm việc đa năng trong dự án (có thể làm nhiều công việc khác nhau không phụ thuộc
chuyên môn).
Không phân cấp thứ bậc trong dự án (không ai quản lý ai).
Tất cả cùng chịu trách nhiệm với sản phẩm bàn giao cho khách hàng.
Báo cáo tình hình công việc mình làm cho Scrum Master và cả Team.
2.6. Vai trò của “Gà” trong mô hình Scrum
1. Stakeholders (customers, vendors)
Đây là những người cho phép dự án được triển khai và những người mà dự án phụ thuộc và
soạn ra những thỏa thuận về lợi ích trong việc phát triển phần mềm trong dự án.
Những người này chỉ tham gia trực tiếp vào dự án trong những buổi demo hoặc bàn giao sản
phẩm để kiểm chứng khả năng thực tế của hệ thống phần mềm.
2. Managers
Những người sẽ thiếp lập/xây dựng môi trường làm việc cho sự phát triển của sản phẩm
trong tổ chức.
2.7. Các hoạt động trong Agile
1. Họp kế hoạch (Sprint Planning meeting)
Thời gian: Kéo dài tối đa 4 giờ (2 giờ với Sprint 2 tuần, 3 giờ với Sprint 3 tuần…).
Thành phần tham gia: Product Owner, Scrum Master và Team.
Thiết lập mục tiêu Sprint
Lựa chọn các việc cho sprint (Sprint backlog)
10/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
-
Product Owner cần chuẩn bị Product Backlog (đủ chi tiết để hiểu) trước khi tiến hành
Sprint Planning Meeting.
-
Team thực hiện kéo các yêu cầu từ Product Backlog vào Sprint Backlog dựa theo thứ
tự ưu tiên và Velocity của Team.
-
Mở rộng (làm rõ) yêu cầu hơn bằng cách phân rã các tính năng thành các Task hoặc
viết các User Story ở mức vừa đủ chi tiết để lên kế hoạch cho chúng.
-
Các ước lượng có thể được điều chỉnh lại khi xem xét và thảo luận trong buổi họp
này. Các task trong sprint backlog được phân rã để giá trị ước lượng nằm từ 1 giờ
đến 16 giời.
-
Các thành viên Team tự nhận task cho mình.
-
Các công việc (nội dung, ước tính, người thực hiện…) có thể thay đổi trong quá trình
thực hiện Sprint sao cho đạt năng xuất cao nhất có thể.
-
Tính năng có mức độ ưu tiên thấp hơn có thể được đưa vào Sprint Backlog nếu nó
phù hợp với Velocity hơn và được Product Owner chấp thuận.
Một số lưu ý khi lập kế hoạch cho sprint
- Xác định độ dài cho Sprint (2-4 tuần) và không đổi trong suốt dự án.
- Tính toán công suất cho team: thường thì một ngày làm việc 6 tiếng/ 1 ngày là hiệu quả, dự
đoán các ngày nghỉ có thể có và buffer cho các rủi ro là 20%
- Những task chưa có người nhận thì không nên thực hiện giao luôn trong buổi họp kế hoạch
- Sprint backlog luôn là một kế hoạch thay đổi theo thời gian, thường 30-40% công việc trong
sprint backlog sẽ bị thay đổi trong quá trình thực hiện sprint. Vì thế trong buổi họp kế hoạch
sprint các thông tin chưa rõ ràng trong yêu cầu chỉ được làm rõ ở mức đơn giản đủ để hiểu
và lên kế hoạch cho chúng. Việc làm rõ chi tiết sẽ được người đảm nhận task làm rõ với PO
khi họ chuẩn bị tiến hành task.
2. Họp sprint hàng ngày (Daily Scrum/standup meeting)
Mục địch:
-
Đồng bộ hóa công việc
-
Cập nhật kế hoach và tiến độ công việc
Cuộc họp này phải được tiến hành hàng ngày với địa điểm và thời gian chính xác được
đặt cố định trong suốt Sprint.
Thành phần tham gia: Tất cả mọi người đều được chào đón tham gia buổi họp này (Product
Owner, Customer, Managers, Other Teams…) nhưng chỉ “Heo” (Product Owner, Scrum
Master, Team) được phép lên tiếng.
Thời gian: Buổi họp này chỉ tiến hành trong vòng 15 phút (có thể nhiều hơn tùy vào số lượng
thành viên Team, nhưng không vượt quá 30 phút).
11/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
Ba câu hỏi bắt buộc các thành viên Team phải trả lời:
-
Đã làm được gì kể từ lần họp trước?
-
Sẽ làm gì từ giờ cho tới lần họp tiếp theo?
-
Bạn có gặp vấn đề hay khó khăn gì trong công việc không?
Scrum Master là người sẽ điều phồi thời gian để mọi người tập trung vào mục tiêu buổi họp,
Các thành viên báo cáo cho nhau, KHÔNG báo cáo cho Scrum master.
Sau buổi họp đội thực hiện:
-
Cập nhật Burn Down Chart và ghi lại các vấn đề khó khăn mà Team gặp phải.
-
Cập nhật Sprint Backlog với các task và đánh giá mới.
-
Scrum master hỗ trợ nhóm xử lý các trở ngại/ khó khăn.
Lưu ý: Scrum hàng ngày có hiệu quả hay không thì cần trả lời được các câu hỏi sau
• Nhóm có tự quản lý?
• Nhóm có chia sẻ công việc?
• Các báo cáo của nhóm có rõ ràng?
• Các nhiệm vụ quá lớn?
• Nó có lâu quá không?
• Có trở ngại nào được tìm ra không?
• Có vướng mắc nào được tháo gỡ không?
• Có hành động cải tiến nào không?
3. Họp sơ kết sprint (Sprint Review Meeting)
Cuộc họp này diễn ra vào ngày cuối cùng của Sprint.
Mục đích:
-
Xem xét lại những công việc đã làm được và chưa làm được của Sprint.
-
Kiểm tra có đạt mục tiêu Sprint hay không
Nội dung:
-
Team sẽ trình bày các hạng mục đã hoàn thành của Proudct backlog với Product
onwner và các bên liên quan (demo sản phẩm).
-
Không trình bày những tính năng chưa “hoàn thành”
-
Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại độ ưu tiên
-
Đây không phải buổi DEMO, chuẩn bị ít hơn 30 phút
-
Product Owner nên sử dụng kĩ thuật kiểm thử chấp nhận để đánh giá các tính năng
Thời gian: Cuộc họp này chỉ kéo dài tối đa 4 tiếng.
Thành phần tham gia: Product Owner, Scrum Master, Team và các bên liên quan.
Chú ý: hạn chế hoặc không dùng Power Point để trình bày mà phải demo trên sản phẩm
thật.
12/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
4. Họp cải tiến (Sprint Retrospeciton meeting)
Mục đích:
-
Xem xét lại toàn bộ quá trình làm việc vào cuối mỗi Sprint.
-
Tìm kiếm sự cải tiến
Thành phần tham gia: Chỉ bao gồm Scrum Team.
Nội dung: Tất cả các thành viên của Team tự đánh giá về bản thân và phản ánh các vấn đề
đã làm tốt hoặc chưa tốt của Team trong Sprint vừa qua.
Có hai câu hỏi chính cần trả lời trong buổi họp:
-
Những điểm đã làm tốt trong Sprint vừa qua là gì?
-
Những điểm nào cần cải thiện trong Sprint sắp tới?
Scrum Master giúp nhóm tìm hiểu, không đưa ra câu trả lời và sẽ tổng kết lại thứ tự ưu tiên
của các vấn đề cần cải thiện dựa trên sự thống nhất của cả Team.
Thời gian: Buổi họp này kéo dài tối đa 2 tiếng.
5. Các cuộc họp khác của nhóm
Họp Kế hoạch Phát hành
-
Hiểu rõ được mục tiêu cần phát hành
-
Hiểu được chi tiết nội dung yêu cầu của khách hàng
-
Ước tính và đặt được các thứ tự ưu tiên Backlog
-
Tính toán được giá trị velocity của team
-
Tạo nên một bản kế hoạch phát hành
-
Lên kế hoạch cho các bản cập nhập sau khi phát hành
-
Đối tượng tham dự gồm: Product Owner, SCRUM Master, Delivery Team, Customers
Managers
Họp làm mịn Product Backlog
-
Phân tách các hạng mục của backlog thành các nhóm Thực thi và chờ trong Product
Backlog
-
Những hạng mục thuộc nhóm Thực thi sẽ được triển khai
-
Các hạng mục Chờ sẽ được xác định lại độ ưu tiên và tiếp tục làm mịn sau đó
Họp review User story
Họp Rà soát mã nguồn (Code Review)
2.8. Các tạo tác (Artifact) trong Scrum
1. Product Backlog
13/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
a) Khái niệm
Là tài liệu ở mức độ cao nhất của dự án (tài liệu tổng quan và quan trọng nhất). Là một list
các Product backlog Item.
Product owner xác định giá trị nghiệp vụ của các PBI và được sắp xếp theo thứ tự ưu tiên
của nhu cầu nghiệp vụ.
Tài liệu này chỉ xác định việc dự án cần làm ra sản phẩm gì mà không quan tâm tới việc làm
như thế nào và ai là người thực hiện.
Lưu ý:
-
Tài liệu này do Product Owner quản lý. Đội Scrum có quyền bổ sung công việc vào
Product Backlog dưới sự phê duyệt của Product owner.
-
Ước tính kích cỡ (size) và công sức (effort) của các PBI à do scrum team thống nhất
và đưa ra.
-
Bugs khách hàng tìm được không được sửa ngày vì lúc này team đang thực hiện
sprint khác nên cần phải đưa vào Product Backlog để thực hiện trong các sprints sau.
Product Backlog được phát triển lớn dần theo thời gian và có tính chất không bao giờ
có thể hoàn thành. Như vậy dự án sẽ kết thúc bất kể khi nào Product Owner cảm thấy
hài lòng về sản phẩm và quyết định dừng việc phát triển lại, cho dù thời điểm đó
Product Backlog có hoàn thiện được bao nhiêu phần trăm đi nữa.
-
Các tính năng chỉ cần mô tả ở mức chi tiết đủ để Scrum Team có thể hiểu và đưa vào
triển khai trong Sprint. Mọi chi tiết với từng yêu cầu sẽ được Scrum Team làm rõ với
Product Owner khi triển khai yêu cầu thực tế trong Sprint.
Một số thông tin bắt buộc cần có trong Product Backlog:
-
Product Backlog Item: User Stories, Features, Bugs…
-
Business Value: Giá trị nhu cầu của nghiệp vụ (Extra High, High, Medium, Low)
-
Product Size: Kích thước ước tính của Team với từng Item.
14/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
-
Priority: Thứ tự ưu tiên thực hiện của Item (phụ thuộc vào Business Value và Product
Size).
b) Xác định thư tự ưu tiên của các Product backlog Item
Mục đích: Sắp xếp thứ tự ưu tiên thực hiện của các Product Backlog Item.
Các bước:
-
Đầu tiên cần xác định giá trị yêu cầu nghiệp vụ trước
-
Sau đó sẽ ưu tiên thực hiện các yêu cầu nghiệp vụ có giá trị quan trọng cao.
Lưu ý:
-
Thứ tự ưu tiên cũng được sở hữu và điều chỉnh bởi Product Owner, khi đó Scrum
Team có thể thỏa thuận với Product Owner nếu cần thay đổi thứ tự ưu tiên này.
-
Chúng cần được xem xét lại và điều chỉnh bất cứ khi nào có những yêu cầu mới hoặc
yêu cầu thay đổi phát sinh.
Các tiêu chí cho việc xác định thứ tự ưu tiên như sau:
- Business Priority: Đặt ưu tiên cao cho những
Item có nhu cầu nghiệp vụ cao nhất.
- Risk: Đặt ưu tiên cao cho những Item có khả năng
rủi ro cao nhất để xử lý chúng trước, tránh bị kéo
dài về cuối Sprint.
- Estimates: Đặt ưu tiên lựa chọn thực hiện các
Item sao cho vừa đủ với thời gian của Sprint.
Ví dụ Product backlog:
Priority
Size
Value
(from Team)
(from Product Owner)
Description
1
Feature A
3
Extra-High
2
Feature B
5
Extra-High
3
Feature C
3
High
4
Feature D
8
Extra-High
15/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
5
Feature E
5
High
6
Feature F
2
Medium
7
Feature G
13
High
8
Feature H
3
Low
c) Các kỹ thuật xác định độ ưu tiên của các Product backlog Item
Phương pháp ước lượng bằng Story Points:
o
Thiết đặt size theo giá trị số Geometric series: 1,2,4,8,16,32…
o
Thiết đặt size theo giá trị số Fibonacci series: 1,2,3,5,8..
o
Việc ước lượng size chỉ mang tính tương đối, không thể chính xác tuyệt đối được.
o
Ưu điểm: Độ chính xác của size không quan trọng bằng tính nhất quán của chúng. (Sự nhất
quán giữa tính năng lớn và tính năng nhỏ phải được thể hiện, không dùng số bừa bãi).
o
Nhược điểm: Giá trị ước tính của một Team cụ thể không thể áp dụng cho một Team khác,
cũng không thể mang ra so sánh hay đong đếm chung với Team khác
Phương pháp T-Shirt Sizing:
o
Sử dụng kí hiệu: S, M, L, XL..
o
Thường được ưu tiên lựa chọn sử dụng sau Story Point vì tính đơn giản của nó.
o
Là một cách thức tốt cho việc ước tính kích thước tương đối.
o
Ưu điểm: Dễ dàng sử dụng và nắm bắt.
o
Nhược điểm: Khá là khó khăn cho việc so sánh kích thước với thời gian cần tiêu tốn để thực
hiện.
Phương pháp Playing Pocker:
16/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
o
Việc ước lượng Size cho các Product
Backlog Item thường được thực hiện
thông qua cách thức chơi Planning
Pocker.
o
Với cách thức này mỗi thành viên của
Team sẽ có một bộ bài Pocker với
những lá bài giống nhau được lựa chọn
phù hợp theo phương pháp estimate
đã nói ở trên.
o
Mỗi người sẽ úp lá bài mình định chấm
điểm Size cho Item đang được nhắc
tới, sau đó lật bài. Nếu các thành viên
chấm điểm lệch nhau thì người cho cao
nhất và thấp nhất sẽ giải thích lý do,
tiếp đó Team sẽ chấm điểm lại một lần
nữa để thống nhất Size cho Item.
Phương pháp MoSCoW
o
Được áp dụng chủ yếu với Product
Owner trong việc ước tính Business
Value.
o
Nó là một kỹ thuật được hiểu như là lời
khẳng định về nhu cầu nghiệp vụ của
mỗi User Story với các bên liên quan.
- Must have: Bắt buộc phải có.
- Should have: Nên có.
- Could have: Có thể có hoặc không.
- Won’t have: Không cần thiết.
2. Sprint Backlog
Khái niệm:
-
Sprint Backlog là kết quả của quá trình lập kế hoạch cho Sprint.
17/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
-
Là tài liệu chứa thông tin về việc làm thế nào để Team có thể xây dựng được các tính
năng trong Sprint. Các tính năng sẽ được chia thành nhiều Task khác nhau để thực
hiện.
-
Các tính năng trong Product Backlog sẽ được lựa chọn đưa vào Sprint Backlog và
được bóc tách thành các Task để thực hiện dựa.
Tài liệu này chỉ ra các công việc cần làm, thời gian thực hiện và người thực hiện.
Lưu ý:
-
Các Sprint task trong Sprint Backlog (nội bộ Team) được thu thập trên sự đồng thuận
của cả team.
-
Thành viên Team sẽ tự nhận task cho mình để thực hiện, sẽ không ai giao việc cho họ
mà họ sẽ được chủ động tự quản.
-
Các task sẽ được ước lượng thời gian thực hiện và ghi lại vào Sprint Backlog. Việc
ước lượng này sẽ được thực hiện bởi cả Team.
-
Các task được chia nhỏ để ước lượng thời gian thực hiện từ 1 giờ đến 16 giờ
-
Mọi thành viên Team đều được phép cập nhật Sprint Backlog trong suốt quá trình
thực hiện Sprint cho phù hợp với công việc thực tế.
-
Sprint Backlog là tài sản chung của cả Team, mọi thành viên đều phải có trách nhiệm
và nghĩa vụ quản lý nó.
Ví dụ sprint backlog:
Product
Backlog
Item
Task
Volunteer
Effort (h)
Day1
Day2
Day3
Day4
Day5
Task1
DEV1
8
4
1
0
Task2
DEV4
5
3
1
0
Task3
DEV2
4
4
2
0
Task4
DEV3
2
3
3
1
0
Task5
DEV4
2
1
0
Task6
DEV1
3
1
0
Task7
DEV2
6
3
1
0
Task8
DEV3
4
2
0
3
0
Feature 1
Feature 2
Total:
34
18/23
14
7
6
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
3) Năng suất làm việc của team (Velocity) và cách xác định
Khái niệm:
-
Là năng xuất của một Scrum Team có thể hoàn thành bao nhiêu Product Backlog Item
trong mỗi Sprint.
Được đo và tính toán bằng Story Point.
Ý nghĩa: Sau khi xác định được Velocity chúng ta có thể dùng nó để lập kế hoạch dự án, kế
hoạch phát hành (bàn giao) sản phẩm và dự báo trước ngày hoàn thành sản phẩm.
Lưu ý:
-
Được xác định bằng cách review và tổng hợp thông số từ một vài Sprint với thành
phần Scrum Team và thời gian thực hiện mỗi Sprint là không đổi.
-
Không nên thay đổi thành phần Scrum Team, thời gian của mỗi Sprint cũng như giá trị
Velocity quá nhiều.
Để xác định Velocity cho một Scrum Team mới, chúng ta cho Scrum Team này chạy Sprint 1
– 3 Sprint tự do mà không có Velocity, sau Sprint thứ 3 chúng ta sẽ tổng hợp được giá trị
Velocity chính xác. Tuy nhiên chúng ta cũng có thể giả lập Velocity cho Team ngay từ đầu,
sau đó điều chỉnh dần ở Sprint thứ 3.
Ví dụ:
19/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
4. User Story
Khái niệm:
-
Được gọi là Details Document, ghi mô tả chi tiết các tính năng.
-
Do người chịu trách nhiệm xử lý trức tiếp trao đổi với Product Owner/Customer để làm
rõ và viết User Story, sau đó được break thành các task để thực hiện
-
Là công cụ được sử dụng phổ biến trong Scrum và các phương pháp Agile khác để
thể hiện nhu cầu người dùng.
Cách viết theo phương pháp INVEST:
-
Independent: Story phải độc lập, không bị phụ thuộc vào Story khác.
-
Negotiable: Có thể thỏa thuận để thay đổi (thêm/bớt).
-
Valuable (to users/customers): Phải có giá trị đối với người dùng/khách hàng.
-
Estimable: phải đủ chi tiết để có thể ước lượng được.
-
Small: Chỉ cần ngắn gọn, không quá nhiều, quá dài dòng.
-
Testable: Phải rõ ràng để có thể chứng thực được.
Nội dung user story:
-
Là <người dùng cụ thể\vai trò>, Tôi muốn <làm gì đó> để
5. Định nghĩa hoàn thành (Definition of Done)
Khái niệm:
-
Khi một hạng mục Product backlog Item hoặc gói tăng trưởng (Incremental) cho là
hoàn thành, mọi người phải hiểu rõ “Hoàn thành” như thế nghĩa là thế nào?
20/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
-
Việc định nghĩa “hoàn thành” phụ thuộc vào từng nhóm Scrum, nhưng mọi thành viên
phải chia sẻ chung một cách hiểu về việc hoàn thành một công việc, để đảm bảo tính
minh bạch và trong suốt.
-
Định nghĩa “ Hoàn thành” được dùng để đánh giá khi nào công việc thực sự hoàn
thành trên mỗi gói tăng trưởng của sản phẩm.
-
Định nghĩa hoàn thành đươc thiết lập trong buổi thảo luận của Product owner với đồi
Scrum vào đầu dự án.
-
Định nghĩa hoàn thành thay đổi theo thời gian. Hỗ trợ việc tổ chức và khả năng đội
sản xuất tháo gỡ các trở lực, có thể cho phép bổ sung thêm các hoạt động mới vào
trong Định nghĩa hoàn thành đối với chức năng hoặc Sprint.
-
Cần có định nghĩa hoàn thành cho: User story, Sprint và Release.
Ví dụ các định nghĩa hoàn thành:
-
DOD for User Story
User story được cả đội hiểu giống nhau
Tất cả user story được product owner phê duyệt.
Sự thay đổi user story phải được product owner phê duyệt và product
backlog phải được update
-
DOD for Sprint
Các task trong print phải <= 8 hour
Code phải viết theo chuẩn coding convension
Tất các code phải được review và thỏa mãn checklist code review
Tất cả code được Unit test và không có lỗi
21/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
Sản phẩm được integration test và không có lỗi
Sản phẩm được triển khai trên môi trường system test, được System test và
không có lỗi.
-
DOD for Release
Tất cả tài liệu được cập nhật đầy đủ
Sản phẩm được triển khai trên môi trường thật,được UAT test và không có
lỗi và được khách hàng ký xác nhận kết quả UAT.
6. Biểu đồ Burndown Chart
Khái niệm:
-
Là một biểu đồ công khai thể hiện tình trạng công việc còn tồn đọng của Sprint (số
effort còn phải sử dụng).
-
Cần được cập nhật hàng ngày, nó là cái hình tổng quan và đơn giản về diễn tiến của
Sprint. Và nó được thực hiện cho tới ngày kết thúc Sprint (phát hành sản phẩm).
Ví dụ:
2.9. Những lưu ý khi chạy sprint
-
Tránh thay đổi: mục tiêu sprint, thành viên trong development team, chất lượng mục
tiêu, phạm vi của tính năng
-
Khi họp kế hoạch sprint, nên chia các task ra càng nhỏ càng tốt, nên estimate 1 task
<= 8h làm việc (nếu task lớn hơn thì nên chia làm nhiều task nhỏ) => mục đích của
việc này là để Scrum master dễ dàng quản lý trạng thái của các task đã hoặc chưa
22/23
Hướng dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum
hoàn thành, giúp biểu đồ Burndown chart của sprint thể hiện được chi tiết trạng thái
công việc
-
1 sprint nên ngắn hơn 30 ngày
-
Không nên thay đổi độ dài của sprint, tốt nhất là từ 3- 4 tuần để không làm thay đổi
nhịp độ làm việc của team
-
QA nên theo suốt quá trình team hoạt động từ họp lên kế hoạch -> họp cái tiến sprint,
đưa ra các solution cùng scrum master giải quyết các vấn đề trong team. Nếu có
effort, QA nên giúp team phát triển đảm bảo chất lượng các sản phẩm làm ra.
Các sản phẩm làm ra đều phải có check list
QA review check list và các sản phẩm làm ra
Comment nếu có
Sản phẩm chỉ được release sau khi QA FI hoàn thành và chấp nhận
23/23
