Agile & Scrum Development Process - HAVA SOFT

Agile Values?

• Đề cao tương tác giữa các cá nhân hơn process, tools (email,…).
• Coi trọng working software hơn document (sản phẩm release cho mỗi sprint phải là chạy được), chưa có document mà đã có software hơn thì vẫn được.
• Đặt vai trò khách hàng cùng làm software nhiều hơn là contract negotiation, nghĩa là khách hang phải có nghĩa vụ tham gia vào quá trình develop.
• Gia tăng khả năng đáp ứng thay đổi hơn so với yêu cầu ban đầu, không bị giới hạn bởi planning ban đầu.

12 PRINCIPLES

1. Early delivery phải chạy được thì khách mới hài lòng.
2. Chấp nhận thay đổi yêu cầu.
3. Cố gằng early delivery (vài tuần, vài ngày / lần)
4. BA và developer phải nói chuyện, làm việc chặt chẽ với nhau hàng ngày.
5. Những người làm trong team phải tuyệt đối tin tưởng nhau (phải có quá trình để các thành viên trust lẫn nhau, chứ không thể nào mà trust được liền).
6. Đề cao face-to-face dicuss với nhau (hơn là chat, email…), do đó các thành viên trong team thường nói chuyện với nhau.
7. Progress chỉ được tính dựa vào khả năng working được của Software.
8. Sản phẩm do team Agile làm ra phải là lâu dài chứ không phải chỉ 1 thời gian ngắn
9. Do thời điểm ban đầu System được design không phải lúc nào cũng hoàn hảo, cho nên team phải liên tục cải tiến Software (về technical, design).
10. Cần làm cái gì thì chỉ cần làm cái đó (không cần làm những cái dư thừa), càng đơn giản càng tốt, dĩ nhiên cũng phải tính đến các khía cạnh mở rộng sau này.
11. Team tự tổ chức, tự design, không nên làm theo 1 design do ai đó tổ chức, mà nên là trong team làm.
12. Chấp nhận thay đổi (process, requirement,…)

TOP AGILE TECHNIQUES

• Daily standup
• Sprint planning
• Retrospective

SCALE AGILE

• Scale Agile Framework (SAFe), process khá nặng, teamsize khoảng 50 người.
• Scrum of Scrum
• Sportify (thuần túy Agile nhất)

SCRUM INTRODUCTION

• Lightweight Agile to manage software development
• Không chỉ đội ngũ phát triểu, mà khách hàng cũng phải chấp nhận thay đổi có thể ảnh hưởng đến tiến độ dự án, chỉ có chập nhận thay đổi thì mới tạo ra những Software khách hàng hài lòng. Dĩ nhiên ở khía cạnh management thì phải aware được nếu thay đổi thì sẽ ảnh hưởng nhu thế nào.
• Build được team tự tổ chức, tự giác với công việc.

SCRUM VALUES

• Courage: mọi người đều có quyền, và được khuyến khích để làm những việc khó trong project
• Focus: mọi người đều focus vào mục tiêu chung của team (Sprint goals)
• Commitment: mỗi người phải cùng đóng góp vào trong team để đạt lợi ích của cả team.
• Respect: các thành viên phải tôn trọng nhau, không nên phân biệt vùng miền, thành thị, nông thông, dân tộc, tôn giáo, levels
• Openness: các thành viên phải open với nhau, cũng nhu open với bên ngoài để get support, có issues thì không nên dấu giếm.

SCRUM FRAMEWORK

Team

Product Owner

• Đại diện cho khách hàng, nắm requirement liên quan đến product, product backlog
• Xác định mức độ ưu tiên, scope, schedule cho các requirement, để team biết được nên làm cái gì trước.
• Demonstrate solutions cho các stakeholeder quan trọng, đặc biệt là khách hàng
• Tạo Product roadmap và Vision

Scrum Team

• Tự tổ chức, tự quản lý
• Estimate effort cho từng Stories
• Planning cho từng Sprint
• Execute Sprint, Repospective
• Thường 7 người (up to 10)
• Team phải Cross Functional (analyze requirement, design, develop, test,…). Không nhất thiết các thành viên đều biết tất cả, chỉ 1 số người biết là được, miễn sao merge lại cuối cùng thì team phải biết những chuyện này.

Scrum Master:

• Chịu trách nhiệm hướng dẫn team member, đảm bào mọi người working theo Scrum process.
• Nếu trong quá trình develop, có gì cản trở, thí Scrum Master phải giải quyết.
• Giống như phục vụ team chứ không phải là chỉ đạo.
• Không nhất thiết phải là người biết về kỹ thuật, khi gặp 1 vấn đề gì đấy về technical thì Scrum Master có thể mời về để giải quyết cho team. Scrum Master chỉ việc tìm người để giải quyết cho team.

Artifacts

• Product Backlog
• Sprint Backlog
• Definition of Done

Events

• The Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

PROJECT MANAGER IN SCRUM

• Không có PM
• PM truyền thống có thể chuyển qua làm Scrum Master, Product Owner

SCRUM PROCESS

• Product Backlog
• Sprint Planning
• Sprint Backlog
• Spring Execution (Daily Scrum meeting)
• Deliverable Product
• Retrospective

SCRUM PLANNING

Product Planning:

• Thực hiện bởi Stakeholders, Product Owner
• Contract/Agreement
• Initialize Product Backlog
• Building Team

Release Planning:

• Do team làm, được tạo từ schedule tổng thể, quyết định features nào sẽ được release vào thời điểm nào
• Phụ thuộc vào team’s velocity (performance của team)
• Cần phải được thống nhất bởi Sponsor, Customers, Developers, Managers và các Stakeholder khác
• Mặc định Release Planning là không được chính xác lắm, nếu có thay đổi gì về Plan thì cũng không có gì đặc biệt. Tránh cho anh em làm overtime để đạt kế hoạch. Nhưng cũng không có nghĩa anh em làm tàn tàn, mà mình phải build được cái trust, phải làm hết sức của mình.
• Release cycles không nên để quá dài
• Plan release continuously

TEAM’s VELOCITY

• Tổng số lượng features có thể release được trong 1 iteration (Sprint)
• Velocity được đo cùng 1 Unit (Story points, days, hours)
• Chỉ được dùng cho Scrum team đó
• Các yếu tố ảnh hưởng đến Velocity:
  • Impediments (các yếu tố ảnh hưởng performance của team, vd: internet cty quá chậm)
  • Motivation (team có đủ động lực để làm hay không. vd: lương thấp)
  • Knowledge/expertise của team member (senior nhiều thì chắc sẽ làm tốt hơn)
  • Development environment (vd áp dùng automation testing thì sẽ đẩy nhanh được tốc độ integration & testing)
  • Project Transparency: thông tin không được chia sẻ, team member sẽ cảm thấy không được trust, cũng bị ảnh hưởng
• Team’ velocity chỉ tính đối với những user stories đã được Done

Definition of DONE

Cực kì quan trọng, phải define rõ ràng giữa stakeholders và Scrum team (vd: code phải có unit test, bảo nhiêu % coverage thì mới gọi là DONE)

SPRINT

• Sprint (hay Iteration) là đơn vị cơ bản của Scrum
• Mỗi Sprint thường kéo dài từ 2-4 tuần, trong 1 project nên xác định chỉ 1 lần (để làm cơ sở cho Team’s velocity cho việc planning).
• Trong mỗi Spring thì đảm bảo không có thay đổi nào đáng kể, làm ảnh hưởng đến Sprint Goal.
• Spring có thể Cancel, sảy ra khi khách hàng có những sự thay đổi, làm cho những gì mình làm không còn ý nghĩa gì nữa, thông thường sẽ cố gắng tránh việc này, để không lãng phí công sưc của team

SPRINT PLANNING

• Cả team sẽ làm dựa tren Team’s velocity, Product Backlog, Release Plan, Current Product (Kết quả của Sprint trước), Technologies -> Sprint prioritization -> Sprint Goal -> Lựa những Stories sẽ develop đưa vào Sprint Backlog, rồi estimate nó
• Thực hiện trước lúc bắt đầu mỗi Sprint
• Product Owner và Team sẽ cùng thỏa thuận Backlog sẽ làm cho Sprint đó. Scrum master sẽ đứng ở giữa control (developers không thể dựa vào hiểu biết technical để nói tôi chỉ làm được chừng đó, hoặc Team’s velocity chỉ có 30 mà Product Owner muốn làm 50 story points).
• Nên buffer planning 5% (hoặc hơn, không nên planning full).
• Product Owner add stories vào Sprint backlog, team sẽ tạo task để implement những stories này.

STORY ESTIMATION: STORY POINT

• 1 points ~ 4 hours (khi chưa có Team’s velocity)
• Fibonacci sequence: 1,2,3,5,8,13,20 or 21
• Max is 20 or 21: khoảng 2 tuần
• Khi đã có Team’s velocity thì sẽ ước lượng dụa trên những cái mà mình đã biết

PRODUCT BACKLOG

• Product Owner manage
• Backlog item phải có mô tả, độ ưu tiên, estimation
• Độ uu tiên xác định dựa trên value, neccesity, risk,…
• Có thể là Stories, enhancement, bugs,…

User Stories

• Mô tả requirement theo góc nhìn của User
  • Who: ai sẽ dùng chức năng đó?
  • What: chức năng gì cần phải làm?
  • Why: tại sao User cần feature đó?
• As a , I want so that I can
• Một User Story chỉ nên chiếm 1/4 Sprint.

Epic

Một User Story lớn, hoặc bao gồm nhiều Story khác nhỏ hơn.

Sprint Backlog

• List tất cả các công việc mà team phải làm trong Sprint đó
• Thông thường add từ Product Backlog bởi Team
• Chỉ Team mới có quyền thay đổi
• Các thành viên trong team nên chủ động pick task, không nên chỉ bốc task dễ, để task khó lại cho người khác làm

Scrum daily meeting

• Mỗi ngày 15′, tất cả đêu đứng, focus vào buổi họp, không làm việc riêng (chat, đọc báo)
• Mục đích không phải là report status cho Manager, mà để xem Sprint Goal đạt được đến mức độ nào, có vấn đề gì hay không
• Mỗi người trả lời 3 câu hỏi
  • Ngày hqua làm gì?
  • Hnay làm gì?
  • Có vấn đề, khó khăn gì hay không?
• Vấn đề nào giải quyết nhanh được thì giải quyết, không thì note lại, setup meeting khác để giải quyết
• Vấn đề nào quyết định nhanh được thì quyết định luôn
• Chia sẻ knowledge, khó khăn của bản thân, để mọi người giúp đỡ. Do mọi người đều nói, nên nâng cao tinh thần của team

Sprint Review

• Team và Product Owner sẽ review các công việc nào đã complete, còn tồn đọng để planning cho Sprint kế tiếp
• Lý tưởng diễn ra trong 2 tiếng (cho sprint 2 tuần)

Sprint Burndown Chart

Hiển thị tiến độ của sprint, dựa vào đó để ước lượng được có đạt được planning ban đầu hay không

Sprint Retrospective

• Host bởi Scrum Master
• Mục đích để review xem những gì làm tốt, và những gì làm chưa tốt
• Hai câu hỏi áp dụng
  • Cái gì làm tốt?
  • Cái gì cần phải improve cho next sprint?
• Diễn ra khoảng 2 tiếng (cho sprint 2 tuần)

How to ensure delivery quality?

• Team skill set
• Team’s communication
• Task validation: đảm bảo tất cả task phải thỏa mãn definition of done (unit test, code comment,…)
• Continuous Integration & Test
• Sprint Review: xác định output của mỗi Sprint có đúng requirement hay không.
• Sprint Retrospective
• Demos: sẽ thấy được system có work đúng với requirement hay không? có issue, bugs sẽ giải quyết được sớm?

Change Management

• Scrum chấp nhận tất cả các loại Change (kể cả process, requirement)
• Tất cả change liên quan đến requirement sẽ được add vào backlog

References:

https://web.microsoftstream.com/video/45b7413b-4a47-4a76-8dbf-0fc046a3e783

Chia sẻ:

• X
• Facebook

Thích Đang tải...

Có liên quan