1. Tổng quan về Agile

1.1. Giới thiệu

Phương pháp Phát triển phần mềm Agile là phương pháp phát triển phần mềm linh hoạt. Nó gồm một quá trình làm việc tương tác và tích hợp để có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt. Giá trị cuối cùng trong phát triển Agile là nó cho phép các nhóm phân phối giá trị nhanh hơn, với chất lượng và khả năng dự đoán cao hơn, cũng như khả năng đáp ứng với sự thay đổi cao hơn. Scrum và Kanban là hai trong số những phương pháp Agile được sử dụng rộng rãi nhất.

1.2. Tuyên ngôn Agile (4 Agile values)

Vào năm 2001, bản tuyên ngôn Agile (Agile Manifesto) đã được thống nhất và ra đời bởi một nhóm người có uy tính trong phát triển phần mềm:

• Individuals and interactions over processes and tools: Cá nhân và sự tương tác hơn là quy trình và công cụ

• Working software over comprehensive documentation: Phần mềm chạy tốt hơn là tài liệu đầy đủ

• Customer collaboration over contract negotiation: Cộng tác với khách hàng hơn là đàm phán hợp đồng

• Responding to change over following a plan: Phản hồi với sự thay đổi hơn là bám theo kế hoạch

1.3. 12 nguyên tắc của Agile (12 Agile principles)

1. Ưu tiên cao nhất là hài lòng 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 mỗi 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. Scrum

2.1. Tổng quan

1. Giới thiệu

Scrum là một “bộ khung làm việc” cơ bản để tiếp cận những công việc phức tạp. Dựa trên bộ khung này, nhóm làm việc có thể áp dụng những quy trình, kỹ thuật khác nhau cho công việc của mình… Nó là một thành viên của họ Agile.

2. Scrum có ích gì cho phát triển phầm mềm hiện nay

Nó giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào những công đoạn cần thiết đáp ứng được nhu cầu của khác hàng đưa ra. Ba giá trị cốt lỏi của Scrum gồm: sự minh bạch (transparency), thanh tra (inspection) và thích nghi (adaptation).

3. Lợi ích mà Scrum mang lại

Tính minh bạch, kiểm tra, và thích nghi là 3 nền tảng cơ bản của Scrum. Và dưới đây là những lý do tại sao nên dùng Scrum.

1. Cải thiện chất lượng phần mềm, dễ học và dễ sử dụng.

2. Rút ngắn thời gian phát hành phần mềm, cho phép khách hàng sử dụng sản phẩm sớm hơn.

3. Nâng cao tinh thần đồng đội, tối ưu hóa hiệu quả và nỗ lực của đội phát triển.

4. Gia tăng tỷ suất hoàn vốn đầu tư (ROI)

5. Tăng mức độ hài lòng của khách hàng

6. Kiểm soát dự án tốt, cải tiến liên tục

7. Giảm thiểu rủi ro khi xây dựng sản phẩm

2.2. Scrum Team

Trong Scrum, đội ngũ tham gia phát triển phần mềm chia làm 3 vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu các công việc đặc thù như sau:

• Product Owner: Nhiệm vụ của Product Owner là đảm bảo việc quản lý những công việc còn tồn đọng (Product backlog) của việc phát triển sản phẩm phần mềm. Product Owner phải liên tục cập nhật thông tin cho các thành viên trong team để họ hiểu về yêu cầu hay các tính năng cần có của sản phẩm ngay cả khi họ không trực tiếp phát triển tính năng đó.

• Development Team: là một nhóm liên chức năng (cross-function) sẽ tham gia vào việc phát triển từng tính năng cụ thể. Các thành viên này có thể sẽ có kỹ năng khác nhau và một số sẽ giỏi về những kỹ năng nhất định. Tuy nhiên khi sử dụng Scrum thì tất cả các thành viên của Development Team yêu cầu phải có khả năng làm việc thay thế vị trí của nhau và không ai chỉ chịu trách nhiệm phát triển một (hoặc một số) tính năng nhất định.

• Scrum Master: sẽ chịu trách nhiệm cho việc lên kế hoạch để phân công công việc, sắp xếp thứ tự ưu tiên giải quyết những công việc tồn đọng nào có trong Backlog trước, tổ chức các buổi họp với Product Owner để theo dõi tình hình và nắm thông tin cần thiết.

Một Scrum Team tối đa 9 người, thường là 7 người (bao gồm PO, Scrum Master và 5 developers). Team nhỏ nhất 4 người bao gồm PO, Scrum Master và 2 developers.

Đọc thêm: https://www.mendix.com/blog/the-road-to-adopting-scrum-team-composition/

2.3. Sprint

1. Sprint là gì?

Sprint là mộ phân đoạn lặp đi lặp lại trong quy trình phát triển phần mềm, có khung thời gian thường là 1 tháng (từ 2 – 4 tuần) mà theo đó sản phẩm sẽ được release phiên bản mới. Khi một Sprint kết thúc thì Scrum Master cần phải chuyển trạng thái của nó sang Done.

Khi bắt đầu một Sprint thì Scrum Master cần đưa ra mục tiêu của Sprint đó và mục tiêu này không được phép thay đổi cho tới khi Sprint hoàn thành. Tuy nhiên Product Owner vẫn có quyền huỷ một Sprint trước thời hạn kết thúc của nó.

Mặc dù để làm điều này thì Product Owner cần sự đồng thuận của Development Team cũng như Scrum Master. Sau khi một Sprint kết thúc thì các bên sẽ dựa trên kết quả của Sprint đó để lên kế hoạch cho Sprint tiếp theo.

2. Những quy tắc trong Sprint

1. Không cho phép bất kì sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint (Sprint Goal)

2. Thành phần Nhóm Phát triển được giữ nguyên

3. Mục tiêu chất lượng không được cắt giảm

4. Phạm vi có thể được làm rõ và tái thương lượng giữa Product Owner và Nhóm Phát triển

2.4. 4 cuộc họp của Scrum (4 events)

1. Sprint Planning (họp kế hoạch Sprint)

Đây là bước đầu tiên cần phải thực hiện trước khi một Sprint bắt đầu. Development team họp với Product Owner để lên kế hoạch cho một sprint. Những công việc nào cần phải được hoàn thành trong Sprint này và làm sao để có thể hoàn thành những công việc này.

Sau khi thống nhất được số lượng công việc, thời gian hoàn thành thì chúng ta có thể bắt đầu Sprint. Trong khi thực hiện một Sprint chúng ta sẽ phải có những buổi họp được gọi là Daily Sprint hay Daily Meeting.

2. Daily Scrum (họp hàng ngày)

Các buổi họp Daily Scrum thường kéo dài khoản 15 phút, trong buổi họp này tất cả các thành viên sẽ lần lượt báo cáo lại:

• Những gì họ đã làm được ngày hôm qua

• Những gì họ cần làm ngày hôm nay

• Những khó khăn mà họ gặp phải

Mỗi buổi họp này sẽ giúp việc dự kiến được kế hoạch đưa ra trong Sprint đang làm sẽ tiến triển ra sao và liệu có cần phải cập nhật lại bản kế hoạch đã đưa ra hay không. Tất nhiên cần nhớ rằng việc thay đổi kế hoạch này không bao gồm thay đổi mục tiêu đã đưa ra của Sprint.

Ví dụ bạn có thể tăng thêm thời gian để hoàn thành một chức năng và qua đó khiến Sprint phải kéo dài hơn dự kiến. Tuy nhiên mục tiêu của Sprint (Sprint Goal) là cho phát hành một phiên bản mới cần được giữ nguyên.

3. Sprint Review (Họp sơ kết Sprint)

Là công việc được thực hiện bởi nhóm phát triển và Product Owner ở cuối mối Sprint nhằm đánh giá lại kết quả các công việc đã hoàn tất (DONE) và qua đó đề xuất các chỉnh sửa, thay đổi cần thiết cho sản phẩm ở Sprint sau.

4. Sprint Restrospective (Họp cải tiến Sprint)

Dưới sự trợ giúp của Scrum master, team phát triển sẽ tổng kết những kiến nghị và đánh giá từ bước Sprint Review ở trên để đưa ra những cải tiến nhằm nâng cao hiệu quả làm việc cũng như sản phẩm.

2.5. Các công cụ (artifacts) Scrum

Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.

Product backlog

Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án. Có thể hiểu như là danh sách yêu cầu (requirement) của dự án.

Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).

Sprint backlog

Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).

Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

Burndown Chart

Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc.

Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart).

Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

Đọc thêm: Scrum Roles, Scrum Events & Scrum Artifact

3. Thực hành

Learn scrum with Jira Software

Jira Agile Scrum (YouTube)

Một số công cụ Quản lý dự án khác: ClickUp, ShortCut, Trello