Phát triển phần mềm theo Agile Scrum cho startup

1. Agile Scrum
for your startup
Kevin Vu
https://www.linkedin.com/in/kevinmecloud/

2. What is Agile
Tuyên ngôn của Agile
∙ “Cá nhân 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 sự thay đổi hơn là bám theo kế hoạch”

3. What is Agile
12 nguyên tắc 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

4. Why Agile

5. Why Agile Lợi ích của Agile
∙ Các tính năng có giá trị cao được phát triển và phân phối nhanh hơn với các chu kỳ ngắn.
∙ Giảm chi phí bằng cách tập trung nỗ lực phát triển vào các tính năng có độ ưu tiên cao.
∙ Giảm công việc phi sản xuất (ví dụ: viết thông số kỹ thuật hoặc các tạo phẩm khác mà không ai sử dụng)
∙ Tạo động lực cho Nhóm phát triển vì họ sẽ thấy được đóng góp của họ được sử dụng và có giá trị.
∙ Công việc phát triển phù hợp với nhu cầu của khách hàng và trị trường.
∙ Việc lập kế hoạch và theo dõi tốn ít dễ dàng, cụ thể và tập chung hơn.
Hơn hết, theo rất nhiều thống kê khoa học, Agile tỏ ra vượt trội về giá trị mang lại. Từ năm 2009, Tiến sĩ David F Rico đã
so sánh Agile với các phương pháp quản lý dự án phần mềm truyền thống khi nghiên cứu 7.500 dự án.Theo đó áp dụng
Agile cho thấy:
∙ 41% dự án tốt hơn về giá trị kinh doanh tổng thể
∙ 83% dự án ra thị trường nhanh hơn
∙ 50% dự án có chất lượng tốt hơn
∙ 50% dự án có chi phí ít tốn kém hơn
∙ 83% dự án có năng suất tốt hơn

6. What is Scrum
Ba trụ cột của Scrum là Tính minh bạch, Sự thanh tra và Sự thích nghi
(Transparency, Inspection & Adaptation)

7. What is Scrum
3 Loại nội dung của Scrum bao gồm: Vai trò, Tạo tác và Sự kiện

8. Tư tưởng Scrum
➔ Minh bạch (Transparency)
Thanh tra (Inspect)
Thích nghi (Adaptation)
➔
➔
➔
Họp đứng hàng ngày ( tối đa 15phút)
Họp tổng kết trước khi bắt đầu Sprint tiếp theo
1 Scrum Master, 1 Product Owner, 3-9
developers
➔
➔
➔
Phát hiện và loại bỏ các cản trở (impediments)
Họp Sprint Planning (Sprint 1 tuần -> họp
2 giờ; Sprint 2 tuần -> họp 4 giờ)
Tăng cường giao tiếp

9. Scrum Team
➔ Product Owner
Quản lý Backlog, Đánh mức
độ ưu tiên, xây dựng
Roadmap.
➔ Developers
Xác định phạm vi, Implementing, Tự tổ chức,
Rã task, Cập nhật kết quả hàng ngày.
➔ Scrum Master
Huấn luyện, dẫn dắt thay đổi, loại bỏ trở ngại,
phục vụ team, bảo vệ team.

10. What is Scrum

11. What is Scrum

12. What will scrum do for you?
• Scrum là một khung làm việc giúp chúng ta phát triển bền vững các sản phẩm phức tạp
• Scrum là phương tiện giúp mọi người nhận ra/đưa ra các vấn đề cần giải quyết sớm và chính xác
• Scrum không giải quyết vấn đề, mà tạo điều kiện để chính chúng ta cùng nhau xử lý chúng.
o Thiết lập tầm nhìn về sản phẩm
o Thiết lập sự ưu tiên trong Product Backlog
o Lên kế hoạch release sản phẩm
o Trao đổi hàng ngày / Họp review và Họp tổng kết
o Lập biểu đồ Năng suất (Burndown) và đo Vận tốc (Veloctiy) của team
• Thúc đẩy TÍNH MINH BẠCH và CỞI MỞ:

13. What will scrum do for you?
● Developers từ chuyên biệt sang cross-functional (liên chức năng)
● Team từ cần chỉ đạo sẽ tự tổ chức (self-organizing)
● Developers tự quyết định phần việc có thể hoàn thành
● Team tự quyết định Thế nào là hoàn thành (Definitionof done)

14. Product Backlog
• Là một danh sách chứa tất cả những
thứ cần làm cho sản phẩm đó.
• Được quản lý và sắp xếp thứ tự bởi
Product Owner.

15. Sprint Backlog
• Là danh sách công veeiecj được xác định và ưu tiên bởi Scrum Team trong một Sprint
• Danh sách này chính là các mục lấy từ Product Backlog (gọi là PBI viết tắt của Product Backlog Item)

16. Story Points
• Là một công cụ để ước tính nỗ lực
(effort) cần bỏ ra để hoàn thành 01
user story.
• Được cả Nhóm phát triển đánh giá
thông qua buổi Planning Poker
• Có nhiều cách để đánh Story Points:
⮚ Theo dãy số tự nhiên: 1, 2, 3, 4, 5,…
⮚ Theo T-shirt size: XS, S, M, L,…
⮚ Lũy thừa của 2 (1, 2, 4, 6, 8, 16)
⮚ Fibonacci 1, 2, 3, 5, 8, 13, 21

17. Velocity
• Là giá trị cho biết vận tốc thực hiện của Nhóm phát triển.
• Công thức: Số Story Point hoàn thành trong 1 sprint. Ví dụ 40.
• Vận tốc trung bình sẽ lấy trung bình số Story Point hoàn thành trong các sprint.
Chúng ta cần biết vận tốc để :
- Hiểu được giới hạn của team khi đề ra khối lượng công việc được hứa hoàn thành cho 1 Sprint
- Dự đoán trước bao nhiêu công việc được hoàn thành và có thể chuyển giao ở một thời điểm nhất định.

18. Burndown Chart
• Là biểu đồ trong một Sprint để thể về khối lượng công việc còn lại tới khi hoàn thành.
Lợi ích của Burndown Chart:
⮚ Biết được lượng công việc đã hoàn thành, cần
hoàn thành trong sprint
⮚ Tiến độ thực tế đang nhanh hay chậm so với tiến
độ lý tưởng để có biện pháp điều chỉnh
• Trục Y: thể hiện tổng khối lượng story points cần hoàn thành.
• Trục X: số ngày làm việc trong 01 Sprint
• Đường lý tưởng (Ideal line): tiến độ mong đợi mỗi ngày
• Đường thực tế (Actual line): tiến độ thực tế

19. Sprint Planning Meeting
• Sprint Planning là một cuộc họp mà nhóm phát triển quyết định những gì sẽ được thực hiện và nó sẽ
được thực hiện như thế nào trong mỗi sprint.
• Đây là một nỗ lực hợp tác dưới sự tham gia của Scrum Master, người tạo điều kiện cho cuộc họp và
chủ sở hữu sản phẩm mô tả các chi tiết của PBIs và các tiêu chí chấp nhận của họ, giúp cả team xác
định công việc và nỗ lực để hoàn thành các cam kết trong mỗi sprint.

20. Daily Standup Meeting
• Cuộc họp hàng ngày của nhóm phát triển, tối đa 15 phút, luôn tại cùng một địa điểm và thời gian
định trước, nên là buổi sáng.
• Nhóm phát triển đánh giá tiến độ cho sprint, lập kế hoạch cho 24 giờ tiếp theo, đồng bộ hóa các hoạt
động, xác định những trở ngại thông qua việc trả lời 3 câu hỏi:
⮚ Đã làm gì vào hôm qua?
⮚ Sẽ làm gì hôm nay?
⮚ Cái gì đang cản trở công việc?
❖ Nếu phát hiện tra các cản trở, Scrum Master sẽ giúp giải quyết sau cuộc họp,
chứ không giải quyết hoặc thảo luận phương án ngay tại chỗ

21. Sprint Review (Demo) Meeting
• Scrum Team trình bày và chứng minh sự gia tăng sản phẩm.
• Scrum Team và các bên liên quan tham gia cuộc họp.
• Scrum Team nhận được phản hồi từ các bên liên quan.
• Các phản hồi được lưu ý và chúng sẽ sử dụng làm hướng dẫn cho bước tiếp theo

22. Sprint Retrospective
• Inspect (thanh tra) và adapt (thích nghi) là một trong những điều quan trọng nhất trong Agile Scrum
và cuộc họp này là để thanh tra và đưa ra cơ hội thích nghi cho đội Scrum.
• Inspect (thanh tra) xem sprint đã thông qua như thế nào.
• Quyết định cái gì và làm thế nào về các thích nghi với tiến trình cải tiến.
• Thiết lập các hành động cho lần tiếp theo.

23. Refinement (Grooming) Meetings
• Cuộc họp này bao gồm:
- Phân tích Requirements chuyên sâu.
- Phân tích User stories thành những thành phần nhỏ hơn.
- Ước tính các PBI mới.
- Đánh giá lại các PBI hiện có.
⮚ 5 đến 10 phần trăm của mỗi Sprint phải được dành
riêng cho các cuộc họp Product Backlog Refinement
(PBR) Meetings. Nếu không được hoàn thành, sprint
planning sẽ trở nên hoàn toàn sai lầm

24. Product Owner
∙ Đại diện cho tiếng nói của khách hàng, người dùng.
∙ Phát triển tầm nhìn sản phẩm (Product Vision) và lên kế hoạch phát hành sản phẩm (Release plan)
∙ Thể hiện các tính năng của sản phẩm trên Product backlog và làm rõ chúng bằng việc mô tả thành
các User Stories.
∙ Đánh giá giá trị mỗi tính năng trên Product Backlog, ước lượng bao gồm cả chi phí, lợi ích, ROI.
∙ Sắp xếp thứ thự ưu tiên các tính năng trên Product Backlog để có thể đạt được mục tiêu và sứ mệnh của
sản phẩm.
∙ Tối đa hóa giá trị công việc của Development Team mang lại.
∙ Đảm bảo rằng Product Backlog được minh bạch, rõ ràng và dễ truy cập với toàn bộ team phát triển.
∙ Đảm bảo rằng Development Team hiểu được các tính năng và các yêu cầu trong Product Backlog.

25. Developer Team
∙ Là một nhóm tự tổ chức (self-organizing)
∙ Là một nhóm liên chức năng (cross-functional) 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
∙ Các thành viên trong nhóm phát triển có thể có các kĩ năng chuyên biệt, đặc thù nhưng họ phải chịu
trách nhiệm dưới một thể thống nhất là Nhóm phát triển
∙ Nhóm phát triển không chứa bất cứ một nhóm con nào khác với các chức năng đặc thù
∙ Họ nhận công việc, ước lượng thời gian hoàn thành và chịu trách nhiệm về chất lượng của phần công
việc mà mình đã nhận.
∙ Sửa lỗi và đóng góp vào việc cải tiến sản phẩm
∙ Hiểu và tuân thủ các quy trình trong Scrum
∙ Tham gia vào các sự kiện trong Scrum: Planning meeting, daily meeting, Retrospective meeting

26. Scrum Master
∙ Đảm bảo chắc chắn các Scrum team hiểu và làm theo quy trình.
∙ Giúp Product Owner tìm ra các kĩ thuật quản lý Product Backlog hiệu quả.
∙ Huấn luyện Nhóm Phát triển cách tự tổ chức và làm việc liên chức năng.
∙ Là “đày tớ” (servant leader) của nhóm, có trách nhiệm loại bỏ các trở ngại phát sinh.
∙ Cung cấp điều kiện thuận lợi cho các cuộc họp trong Sprint
∙ Bảo vệ nhóm bằng cách ngăn các phiền nhiễu từ bên ngoài và là bộ đệm ở giữa nhóm phát triển và các
bên liên quan khác.
∙ Dẫn dắt cuộc họp Scrum hàng ngày cho đến khi nhóm có thể tự tổ chức được.
∙ Điều hành ½ thời gian backlog grooming (đảm bảo nhóm có sự hiểu về yêu cầu giống nhau, làm rõ các
vấn đề kỹ thuật, và ước lượng), hoặc hỗ trợ các thành viên trong nhóm điều hành cuộc họp này.
∙ Hỗ trợ và tham gia vào Buổi họp tổng kết (Retrospective meeting).

27. Scrum Master
So sánh vai trò của Leader trong cách phát triển phần mềm truyền thống và Agile Scrum

28. User Story
∙ User Story là một tài liệu sơ giản về yêu cầu sản phẩm với góc nhìn người dùng.
∙ User story có định dạng:
o Là <người dùng cụ thể/vai trò> , tôi muốn <làm gì đó> để <phục vụ mục đích nào đó>.
o Ví dụ: Là một học sinh, tôi muốn tìm kiếm giáo viên để đăng ký học trực tuyến với họ
∙ User story nên theo mô hình 3C:
o Card (Thẻ): Thông thường, User Story được viết trên một thẻ nhỏ. Điều đó có nghĩa là nó thường
ngắn để có thể viết trên một thẻ. Nếu bạn có viết trên một hệ thống khác như Trello, Jira, Assembla
hoặc Redmine cũng nên giữ nó ngắn.
o Conversation (Trao đổi): Story là những câu truyện giữa khách hàng và Nhóm Phát triển. Do đó chi
tiết của User Story được làm rõ thông qua các cuộc trao đổi (nên là trực tiếp) với khách hàng. Nội
dung của User Story sẽ ngày càng cụ thể tuy thuộc vào độ ưu tiên của nó (nếu ưu tiên cao, cần làm
sớm thì sẽ có nọi dung chi tiết, nếu ưu tiên thấp thì chỉ chứa nội dung chung).
o Confirmation (Xác nhận): User Story có tiêu chí chấp nhận (Acceptance Criteria) để khách hàng suy
nghĩ cụ thể về yêu cầu và Nhóm Phát triển có thể hiểu yêu cầu rõ hơn và xác nhận được khi nào sản
phẩm hoàn thành

29. User Story
∙ User story cũng nên tuân theo các tiêu INVEST:
o Independent (Độc lập): Độc lập với các User Story khác có nghĩa là mỗi story đều có thể triển khai
độc lập không phụ thuộc.
o Negotiable (Thương lượng được): User story không phải là các yêu cầu bắt buộc phải tuân theo
hoàn toàn, mà nó có thể được thay đổi cho phù hợp thông qua thương lượng.
o Valuable (Có giá trị): User Story phải có giá trị với khác hàng. Những người làm kỹ thuật có thể thấy
framework, database là quan trọng nhưng với khách hàng thì không. Điều này rất lưu ý với những
Product Owner có nền tảng kỹ thuật.
o Estimable (Ước lượng được): Một User Story tốt có thể ước lượng được mặc dù không cần quá
chính xác. Những User Story lớn hoặc không rõ ràng thường khó để ước lượng và cần phải chia nhỏ
xuống nữa.
o Sized appropriately (Kích thước phù hợp): Những User Story sắp được đưa vào sản xuất cần có kích
thước nhỏ tức là được mô tả rõ ràng nhất, những User Story chưa được đưa vào sản xuất trước
mắt có thể có kích thước lớn hơn.
o Testable (Kiểm thử được): Nếu nhóm phát triển biết như thế nào là User Story đó hoàn thành – có
thể kiểm thử được rõ ràng thì họ có thể hiểu rõ hơn công việc của mình, ít gây hiểu nhầm.

30. Definition of Done (DoD)
∙ Definition of Done (DoD) là một thoả thuận cơ sở để xác định điều kiện nghiệm thu công việc hoàn thành
của Scrum Team theo từng bối cảnh cụ thể của dự án Agile.
∙ DoD được tạo ra từ sự nỗ lực tương tác giữa các vai trò trong dự án Agile Scrum như Product Owner,
Scrum Master, Develoment Team.
∙ DoD được phát triển ở Sprint Planning đầu tiên của mỗi iteration và tiếp tục xem xét và điều chỉnh ở các
iteration trong tương lai.
∙ Thông thường nên phân làm 3 loại DoD, đó là:
o DoD cho User Story: Là danh sách các điều kiện làm cơ sở để xác định User Story đã hoàn thành
trong việc phát triển yêu cầu, triển khai code, kiểm thử
o DoD cho Sprint: Là danh sách các điều kiện cơ sở để xác định một Sprint thành công hay thất bại.
o DoD cho Release: Là danh sách các điều kiện cơ sở để xác định những công việc cần hoàn thành
cho một đợt phát hành

31. Definition of Done (DoD)
DoD giúp gì cho các vai trò trong đội dự án và các thành viên liên quan?
∙ Với vai trò Product Owner: Họ sẽ hình dung rõ ràng trách nhiệm hỗ trợ của mình trong việc lên kế
hoạch phát hành, trách nhiệm nghiệm thu, và trách nhiệm chuẩn bị thật tốt các yêu cầu và hỗ trợ
tối đa để team đạt hiệu suất cao trong công việc,…
∙ Với vai trò Nhóm phát triển: Họ hình dung rất rõ công việc cần hoàn thành, thúc đẩy các thành viên
trong nhóm chủ động, can đảm đưa ra cam kết và là tiền đề để xây dựng nhóm tự quản (Self-
Organizing), thúc đẩy họ điều chỉnh quy trình làm việc để nâng cao hiệu suất,…
∙ Với vai trò Scrum Master: Là cơ sở để giải quyết vấn đề xung đột giữa Product Owner,
Development team và các đối tượng liên quan, là cơ sở để xác định các trở ngại và tìm ra những
hạn chế trong hành vi các thành viên liên quan để đưa ra hướng đào tạo, huấn luyện phù hợp,…
∙ Với Stakeholders: Đây là cơ sở để họ nâng cao niềm tin với các thành viên của đội dự án và thúc
đẩy họ đưa ra cách tương tác phù hợp hơn để đội dự án cho ra sản phẩm chất lượng, phát hành
nhanh và giúp họ đạt được cơ hội kinh doanh sớm hơn.

32. Definition of Done (DoD): ví dụ

33. SCRUM
QUOTES

34. Thước đo tiến độ tốt
nhất là hiện ta có
bao nhiêu tính năng
chạy được?

35. Nếu dễ dàng nói “OK”
với điều chưa ổn, có
nghĩa là tạo điều kiện để
nó xảy ra lần nữa!

36. Giả như mọi thứ đều ổn
chỉ khiến vấn đề trở nên
tệ hơn.

37. Muốn làm tốt hơn
thì cần sự thay đổi.

38. Hãy cùng chạy thử
01 Sprint.