Thực hiện phát triển sản phẩm theo phương pháp 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. Vậy làm thế nào để áp dụng agile thành công trong phát triển phần mềm? Các công ty phần mềm áp dụng agile như thế nào? ... Tài liệu này sẽ giải đáp các thắc mắc đó cho bạn

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 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

2 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

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

1.4 Thuật ngữ

có của hệ thống ở mức tổng quan

Sprint

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

phẩm, có khả năng bán ra thị trường hay chuyển tới người dùng

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 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

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

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)

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

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 Con người và sự tương tác hơn là Quy trình và công cụ

2 Phần mềm chạy tốt hơn là tài liệu đầy đủ

3 Công tác với khách hàng hơn là đàm phán hợp đồng

4 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

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

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 đó

- 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

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

 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)

- 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)

 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