AGILE

2.1. Agile bắt đầu xuất hiện như thế nào?

Trước năm 2001, nhiều phương pháp phát triển phần mềm đã được hình thành nhằm giải quyết những khó khăn của các dự án phần mềm truyền thống.

Một số phương pháp tiêu biểu:

• Extreme Programming (XP) // lập trình cực hạn, tập trung vào phản hồi nhanh, kiểm thử, lập trình cặp và cải thiện chất lượng kỹ thuật.
• Scrum // framework phát triển sản phẩm theo những chu kỳ làm việc.
• Crystal // nhóm phương pháp phát triển phần mềm chú trọng con người và giao tiếp.
• DSDM (Dynamic Systems Development Method) // phương pháp phát triển hệ thống linh hoạt.
• Feature-Driven Development (FDD) // phát triển phần mềm dựa trên các chức năng cụ thể.

Những phương pháp này không xuất hiện ngẫu nhiên. Chúng được hình thành từ những kinh nghiệm thực tế của các chuyên gia phần mềm trong nhiều năm.

Nhiều người trong số họ sau này tham gia cuộc gặp tại Snowbird và cùng tạo ra Agile Manifesto.

2.2. Snowbird — khoảnh khắc lịch sử của Agile

Tại Snowbird, Utah, Hoa Kỳ.

• Thời gian: 11–13/02/2001.
• Địa điểm: The Lodge at Snowbird, Utah, Hoa Kỳ.
• Số người tham gia: 17 người.

Họ đến từ nhiều trường phái phát triển phần mềm khác nhau, bao gồm XP, Scrum, DSDM, Crystal, Adaptive Software Development và Feature-Driven Development.

Danh sách 17 người tham gia:

STT	Họ tên
1	Kent Beck
2	Mike Beedle
3	Arie van Bennekum
4	Alistair Cockburn
5	Ward Cunningham
6	Martin Fowler
7	James Grenning
8	Jim Highsmith
9	Andrew Hunt
10	Ron Jeffries
11	Jon Kern
12	Brian Marick
13	Robert C. Martin
14	Steve Mellor
15	Ken Schwaber
16	Jeff Sutherland
17	Dave Thomas

Đây là danh sách được công bố trên trang chính thức của Agile Manifesto.

Họ có tạo ra Scrum tại Snowbird không?

Không.

Scrum đã tồn tại trước Agile Manifesto.

Ken Schwaber và Jeff Sutherland đã trình bày Scrum công khai tại hội nghị OOPSLA năm 1995. Scrum bắt nguồn từ những năm đầu thập niên 1990.

Do đó, cần phân biệt:

• Scrum là một trong những phương pháp đã hình thành trước Agile Manifesto.
• Agile Manifesto được tạo ra năm 2001, trong một cuộc gặp có sự tham gia của những người theo nhiều phương pháp phát triển phần mềm khác nhau.
• Scrum không được tạo ra tại cuộc gặp Snowbird.
• Agile không sinh ra Scrum. Scrum là một trong những phương pháp có trước và góp phần vào phong trào Agile.

Timeline lịch sử

1. 1960s — Software Crisis

Những khó khăn trong việc phát triển phần mềm quy mô lớn được thảo luận rộng rãi.

2. 1970 — Royce paper

Winston W. Royce công bố bài nghiên cứu về quản lý phát triển hệ thống phần mềm lớn.

3. 1980s–1990s — Nhiều phương pháp phát triển mới

Các cách tiếp cận nhằm giải quyết những hạn chế của quy trình phát triển truyền thống tiếp tục xuất hiện.

4. 1990s — Scrum, XP, Crystal…

Nhiều phương pháp linh hoạt được hình thành và phát triển.

5. 1995 — Scrum được trình bày công khai

Ken Schwaber và Jeff Sutherland giới thiệu Scrum tại OOPSLA.

6. 2001 — Agile Manifesto

17 chuyên gia gặp nhau tại Snowbird và công bố Tuyên ngôn Phát triển Phần mềm Agile.

2.3. Agile thực sự là gì?

Agile // linh hoạt, thích nghi là một tập hợp các giá trị và nguyên tắc định hướng cách phát triển phần mềm.

Agile không phải một framework duy nhất.

Nó không phải một quy trình bắt buộc tất cả team phải thực hiện theo cùng một cách.

Agile nhấn mạnh:

• Tạo ra giá trị cho khách hàng.
• Nhận phản hồi sớm và thường xuyên.
• Thích nghi khi yêu cầu thay đổi.
• Cộng tác giữa con người.
• Liên tục cải thiện sản phẩm và cách làm việc.

Có thể hình dung:

 

 

Agile

// Tư duy, giá trị và nguyên tắc

│

├── Scrum

│   // Framework

│

├── Kanban

│   // Phương pháp quản lý luồng công việc

│

├── XP

│   // Phương pháp tập trung vào kỹ thuật phát triển

│

├── Crystal

│   // Nhóm phương pháp chú trọng con người và giao tiếp

│

└── …

Phân biệt Agile, Scrum và Sprint

Agile

// Tư duy, giá trị và nguyên tắc

↓

Scrum

// Framework áp dụng tư duy linh hoạt

↓

Sprint

// Chu kỳ làm việc cố định trong Scrum

• Agile: Định hướng cách suy nghĩ và ra quyết định.
• Scrum: Framework cung cấp cấu trúc để phát triển sản phẩm phức tạp.
• Sprint: Một chu kỳ làm việc có độ dài cố định trong Scrum.

Một lỗi rất phổ biến là đồng nhất Agile với Scrum.

Agile ≠ Scrum.

Một team có thể áp dụng Agile bằng Scrum, Kanban, XP hoặc kết hợp nhiều cách tiếp cận khác nhau.

2.4. Agile Manifesto — Tuyên ngôn Agile

Manifesto // tuyên ngôn.

Tài liệu Manifesto for Agile Software Development được công bố vào năm 2001, bao gồm 4 giá trị cốt lõi và 12 nguyên tắc.

Bốn giá trị cốt lõi

Value 1

Individuals and interactions over processes and tools

Con người và sự tương tác được coi trọng hơn quy trình và công cụ.

Giải thích

Công cụ quan trọng, quy trình quan trọng, nhưng con người giao tiếp và phối hợp với nhau còn quan trọng hơn.

Ví dụ trong project E-commerce:

Developer A:

“Tao tưởng API trả productId.”

 

Developer B:

“Ủa, tao trả id.”

Nếu hai developer chỉ dựa vào Jira, Git và documentation mà không trao đổi với nhau, sự khác biệt trong cách hiểu có thể khiến frontend và backend không tích hợp được.

Agile coi trọng việc giao tiếp và cộng tác để giải quyết những hiểu lầm đó.

Value 2

Working software over comprehensive documentation

Phần mềm chạy được được coi trọng hơn tài liệu đầy đủ một cách toàn diện.

Giải thích

Điều này không có nghĩa Agile ghét tài liệu hoặc không cần documentation.

Ý nghĩa là phần mềm thực sự hoạt động được được ưu tiên hơn việc chỉ tập trung tạo ra những bộ tài liệu hoàn chỉnh mà chưa tạo được sản phẩm có giá trị.

Ví dụ:

Trường hợp A

50 trang

Tài liệu hoàn chỉnh

0 chức năng chạy được

Trường hợp B

10 trang

Tài liệu cần thiết

Login, Register, Checkout chạy thật

Agile thiên về trường hợp B nếu những chức năng đó đã đáp ứng yêu cầu và tạo ra giá trị.

Value 3

Customer collaboration over contract negotiation

Hợp tác với khách hàng được coi trọng hơn việc chỉ thương lượng hợp đồng.

Giải thích

Không có nghĩa là không cần hợp đồng.

Thay vào đó, team không nên để hợp đồng ban đầu trở thành thứ quan trọng hơn việc hợp tác với khách hàng để tạo ra sản phẩm phù hợp với nhu cầu thực tế.

Ví dụ:

Ban đầu khách hàng yêu cầu website có 10 chức năng.

Sau hai tháng, khách hàng nhận thấy chức năng A không còn cần thiết nhưng lại muốn bổ sung chức năng B.

Với tư duy Agile, team và khách hàng cùng xem xét lại ưu tiên và điều chỉnh kế hoạch nếu phù hợp.

Value 4

Responding to change over following a plan

Thích nghi với thay đổi được coi trọng hơn việc chỉ bám theo kế hoạch.

Giải thích

Đây là một trong những giá trị quan trọng nhất để hiểu Agile.

Không có nghĩa kế hoạch là vô dụng. Kế hoạch vẫn cần thiết, nhưng team cần có khả năng điều chỉnh khi xuất hiện thông tin mới.

Ví dụ:

Sprint 1:

Làm Product Filter

↓

User feedback:

“Filter này khó dùng.”

↓

Team:

Xem xét và điều chỉnh UI

↓

Sprint 2:

Cải thiện Filter

Câu quan trọng phía sau bốn giá trị

Agile Manifesto có một câu giải thích rằng các yếu tố ở vế bên phải vẫn có giá trị, nhưng những yếu tố ở vế bên trái được coi trọng hơn.

“While there is value in the items on the right, we value the items on the left more.”

Điều này có nghĩa:

Không phải:

Processes = xấu

Tools = xấu

Documentation = xấu

Contracts = xấu

Plans = xấu

Mà là:

Processes + People

Documentation + Working Software

Contracts + Collaboration

Plan + Adaptation

Hai phía đều có giá trị, nhưng Agile đặt ưu tiên cao hơn vào phía bên trái của bốn cặp giá trị.

2.5. Mười hai nguyên tắc Agile

Nếu bốn giá trị là tư tưởng định hướng, thì 12 Principles // 12 nguyên tắc là cách diễn giải tư tưởng đó thành những định hướng thực tiễn.

Principle 1 — Early and continuous delivery

Satisfy the customer through early and continuous delivery of valuable software.

Ý nghĩa: Đưa phần mềm có giá trị đến khách hàng sớm và liên tục.

Ví dụ thay vì đợi một năm để hoàn thiện toàn bộ chức năng, team có thể phát triển theo từng phần:

Sprint 1 → Login

Sprint 2 → Product

Sprint 3 → Cart

Sprint 4 → Checkout

Mỗi lần bàn giao cần tạo ra giá trị thực tế, chứ không chỉ là một phần code chưa sử dụng được.

Principle 2 — Welcome changing requirements

Welcome changing requirements, even late in development.

Ý nghĩa: Chấp nhận và xem xét những thay đổi về yêu cầu, kể cả khi dự án đã đi vào giai đoạn phát triển muộn.

Ví dụ:

Requirement cũ:

Thanh toán COD

↓

Khách hàng:

“User toàn dùng MoMo.”

↓

Team:

Xem xét bổ sung thanh toán MoMo

Thay đổi không nhất thiết là kẻ thù. Trong một số trường hợp, thay đổi giúp sản phẩm phù hợp hơn với thị trường và người dùng.

Principle 3 — Deliver working software frequently

Deliver working software frequently.

Ý nghĩa: Phát hành phần mềm hoạt động được với tần suất phù hợp.

Thay vì:

1 năm → 1 lần release

Team có thể chia công việc thành các chu kỳ phát triển, liên tục hoàn thiện và phát hành những phần sản phẩm đáp ứng yêu cầu.

Principle 4 — Business people and developers work together

Business people and developers must work together daily throughout the project.

Ý nghĩa: Người làm nghiệp vụ và developer cần hợp tác thường xuyên trong suốt dự án.

Ví dụ:

Business

↕

Developer

↕

Trao đổi yêu cầu

↕

Kiểm tra cách triển khai

Không nên để quy trình giao tiếp chỉ là:

Business

↓

Gửi requirement

↓

Developer

↓

3 tháng sau

↓

“Ủa, sao làm sai?”

Principle 5 — Build projects around motivated individuals

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Ý nghĩa: Xây dựng dự án dựa trên những cá nhân có động lực, cung cấp môi trường và sự hỗ trợ cần thiết, đồng thời tin tưởng họ hoàn thành công việc.

Ví dụ:

Thay vì để quản lý liên tục chỉ định từng thao tác nhỏ, team có thể trao quyền tự chủ nhất định cho developer trong việc lựa chọn cách triển khai kỹ thuật.

Principle 6 — Face-to-face conversation

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Ý nghĩa: Giao tiếp trực tiếp thường là một phương pháp hiệu quả để truyền đạt thông tin trong team phát triển.

Điều này không bắt buộc team phải ngồi cùng một phòng.

Với team remote, video call, chia sẻ màn hình và các hình thức trao đổi trực tiếp qua mạng cũng có thể hỗ trợ việc giao tiếp hiệu quả.

Cốt lõi là giảm hiểu nhầm và giúp thông tin được truyền đạt rõ ràng.

Principle 7 — Working software is the primary measure of progress

Working software is the primary measure of progress.

Ý nghĩa: Phần mềm hoạt động được là thước đo chính để đánh giá tiến độ phát triển.

Không chỉ dựa vào:

“Team đã viết 500 trang documentation.”

Hay:

“Team đã họp 30 tiếng.”

Hoặc:

“Jira có 100 task.”

Mà cần xem xét sản phẩm thực tế đã hoạt động và đáp ứng được những gì.

Principle 8 — Sustainable development

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Ý nghĩa: Team cần duy trì một nhịp độ làm việc bền vững trong thời gian dài.

Ví dụ:

Tuần 1:

80 giờ làm việc

🔥🔥🔥

 

Tuần 2:

80 giờ làm việc

🔥🔥🔥

 

Tuần 3:

Kiệt sức

💀

Một team liên tục làm việc quá sức có thể gặp vấn đề về chất lượng, sức khỏe và khả năng duy trì tiến độ.

Agile hướng tới nhịp độ làm việc ổn định thay vì chỉ chạy theo tốc độ ngắn hạn.

Principle 9 — Technical excellence and good design

Continuous attention to technical excellence and good design enhances agility.

Ý nghĩa: Chú trọng liên tục vào chất lượng kỹ thuật và thiết kế tốt giúp tăng khả năng thích nghi của sản phẩm.

Ví dụ:

Code nhanh

↓

Code chạy được

↓

Architecture không tốt

// Kiến trúc không tốt

↓

Bug tăng

↓

Sửa chữa khó khăn

↓

Thay đổi ngày càng tốn kém

Đây là lý do Agile không đồng nghĩa với việc code thật nhanh nhưng bỏ qua chất lượng.

Chất lượng code và kiến trúc tốt là một phần quan trọng giúp team tiếp tục thay đổi sản phẩm mà không phải trả chi phí sửa chữa quá lớn.

Principle 10 — Simplicity

Simplicity—the art of maximizing the amount of work not done—is essential.

Ý nghĩa: Đơn giản hóa công việc bằng cách tối đa hóa lượng công việc không cần làm.

Ví dụ, khách hàng yêu cầu AI recommendation trong khi website vẫn chưa có chức năng tìm kiếm sản phẩm.

Thay vì lập tức triển khai:

AI

+

Machine Learning

+

Vector Database

+

Recommendation Engine

Team có thể cân nhắc ưu tiên:

Search

+

Filter

+

Basic recommendation

trước.

Điều quan trọng là không làm thêm những thứ chưa thực sự cần thiết.

Principle 11 — Self-organizing teams

The best architectures, requirements, and designs emerge from self-organizing teams.

Ý nghĩa: Những kiến trúc, yêu cầu và thiết kế tốt có thể hình thành từ các team có khả năng tự tổ chức.

Thay vì mọi quyết định kỹ thuật đều phải chờ một người chỉ đạo, team có thể chủ động trao đổi và quyết định cách thực hiện công việc dựa trên năng lực và bối cảnh thực tế.

Principle 12 — Regular reflection and adjustment

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ý nghĩa: Team định kỳ nhìn lại cách làm việc, xác định những điều cần cải thiện và điều chỉnh hành vi tương ứng.

Ví dụ:

Sprint 1

 

❌ PR review quá chậm

❌ API documentation thiếu

✅ FE/BE phối hợp tốt

↓

Retrospective

// Nhìn lại cách làm việc

↓

Team quyết định

 

→ PR cần được review trong 24 giờ

→ BE cần document API

→ Giữ cách FE/BE đang phối hợp

↓

Sprint tiếp theo

↓

Thử cách mới

↓

Đo kết quả

↓

Retrospective

↓

Cải thiện tiếp

Đây chính là Continuous Improvement // cải tiến liên tục.

2.6. Agile không đồng nghĩa với làm nhanh hoặc làm tùy hứng

Có ba câu cần phân biệt:

Agile ≠ Làm nhanh

Agile không đơn giản là phải viết code thật nhanh hoặc rút ngắn mọi thời hạn.

Agile ≠ Làm tùy hứng

Agile không có nghĩa muốn làm gì thì làm, không cần lập kế hoạch hay quy trình.

Agile = Tạo giá trị, nhận feedback, thích nghi

Tạo ra giá trị → kiểm tra kết quả → nhận phản hồi → thay đổi khi cần.

Agile không đảm bảo sản phẩm sẽ hoàn hảo. Nó giúp team liên tục thích nghi dựa trên phản hồi và bằng chứng thực tế.

2.7. Feedback Loop — vòng lặp phản hồi

Feedback loop // vòng lặp phản hồi là quá trình nhận thông tin từ kết quả thực tế, sử dụng thông tin đó để điều chỉnh và tiếp tục phát triển.

Đây là một tư duy quan trọng trong Agile.

Ví dụ, team nghĩ rằng người dùng sẽ thích chức năng Product Filter.

Team nghĩ:

“User sẽ thích filter này.”

↓

Build

// Xây dựng chức năng

↓

User sử dụng

// Người dùng thật sử dụng

↓

Analytics / Feedback

// Dữ liệu sử dụng / phản hồi

↓

Phát hiện:

“80% user không dùng filter này.”

↓

Team thay đổi

// Điều chỉnh dựa trên dữ liệu

↓

Build phiên bản mới

↓

Đo lại

// Kiểm tra kết quả thay đổi

Thông qua vòng lặp này, team có thể nhận ra giả định ban đầu không phù hợp và thay đổi hướng phát triển.

2.8. Build – Measure – Learn – Adapt

Đây là cách diễn đạt một chu trình phát triển sản phẩm dựa trên việc học hỏi từ thực tế.

Build

// Xây dựng

↓

Measure

// Đo lường

↓

Learn

// Học từ kết quả

↓

Adapt

// Thích nghi, điều chỉnh

↓

Build tiếp

// Tiếp tục xây dựng

Chu trình này liên kết với nhiều lĩnh vực khác.

Thuật ngữ	Giải thích
Lean Startup	Phương pháp xây dựng sản phẩm dựa trên chu trình Build–Measure–Learn
MVP (Minimum Viable Product)	Phiên bản sản phẩm tối thiểu có thể đưa ra để kiểm chứng giả định
Product Management	Quản lý sản phẩm
DevOps	Cách kết hợp Development và Operations để cải thiện quá trình phát triển, triển khai và vận hành
CI/CD	Tự động hóa các hoạt động tích hợp, kiểm tra, phân phối hoặc triển khai phần mềm
A/B Testing	Thử nghiệm hai phiên bản khác nhau để so sánh kết quả
Product Analytics	Phân tích dữ liệu về cách người dùng sử dụng sản phẩm

2.9. Những phương pháp và công cụ liên quan đến Agile

Để hiểu Agile trong công việc thực tế, cần biết thêm các khái niệm thường xuất hiện cùng nó.

Thuật ngữ	Giải thích
Kanban	Phương pháp quản lý luồng công việc bằng cách trực quan hóa và giới hạn lượng công việc đang thực hiện
XP(Extreme Programming)	Phương pháp phát triển phần mềm tập trung mạnh vào thực hành kỹ thuật
Crystal	Nhóm phương pháp Agile chú trọng con người, giao tiếp và bối cảnh dự án
Scrum	Framework giúp team phát triển và duy trì sản phẩm phức tạp
Jira	Công cụ theo dõi và quản lý công việc, thường được sử dụng trong các team Agile
Git	Hệ thống quản lý phiên bản mã nguồn
GitHub	Nền tảng lưu trữ repository Git và hỗ trợ cộng tác phát triển phần mềm
CI/CD	Tự động hóa quá trình tích hợp, kiểm tra và đưa phần mềm đến môi trường phân phối hoặc triển khai
DevOps	Cách tiếp cận kết hợp phát triển và vận hành để đưa phần mềm từ code đến production nhanh và ổn định hơn

Các công cụ và phương pháp trên không phải tất cả đều thuộc riêng Agile. Chúng có thể được sử dụng trong nhiều mô hình và quy trình phát triển khác nhau.