CHAPTER 3 AGILE METHODS

󾠰

CHAPTER 3: AGILE METHODS
Phương pháp phát triển linh động - Agile
Methods
Agile Manifesto
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. These are our
values and principles.
/>
Individuals and interactions (Cá nhân hóa và sự tương tác): over processes
and tools (Hướng đến mỗi cá nhân và sự tương tác).
Working software (Phần mềm chạy được): over comprehensive
documentation (Viết mã nguồn hơn là tập trung vào các tài liệu).
Customer collaboration (Cộng tác giữa người dùng/khách hàng): over
contract negotiation (Cộng tác với khách hàng để lấy được sự tin tưởng của
khách hàng từ đó mới ký hợp đồng).
Responding to change (Sự đáp ứng thay đổi): over following a plan (Phản
hồi nhanh chóng với các sự thay đổi hơn là làm theo các kế hoạch).

CHAPTER 3: AGILE METHODS

1


⇒ Phương pháp này chú trọng những việc được đề ra ở bên trái nhiều hơn.
Ưu tiên hàng đầu của dự án phần mềm theo phương pháp agile là thỏa mãn
khách hàng thông qua việc phát triển và phân phối liên tục các phần mềm có
chất lượng.
Chấp nhận những sự thay đổi cho dù đã qua quá trình phát triển.
Giúp cho sản phẩm có thế mạnh hơn trong việc cạnh tranh.

Chuyển giao những phần mềm hoạt động tốt một cách thường xuyên (hàng
tuần hoặc hàng tháng).
Xây dựng các môi trường khuyến khích những người có động lực cao phát
triển.
Trao đổi trực tiếp mặt đối mặt (Thay vì thơng qua tài liệu như phương pháp
truyền thống).
Các phần mềm hoạt động tốt là độ đo của tiến độ phần mềm.
Đây là phương pháp giúp tăng mức độ phát triển bền vững của một dự án.
Các nhà tài trợ, đội ngũ phát triển phần mềm và người dùng có thể duy trì
phần mềm với một khoảng dài hạn.
Tiếp tục tập trung vào kỹ thuật tốt và thiết kế đẹp.
Simplicity - đơn giản hóa khối lượng độ công việc.
Các kiến trúc tốt, yêu cầu và thiết kế đều được đưa ra bởi các nhóm tự tổ chức
(Self-organizing team).
Nhóm có thể tự kiểm điểm lại thường xuyên để điều chỉnh các thức làm việc của
mình.

⇒ Agile là một tư tưởng và có rất nhiều phương pháp được sinh ra theo tư tưởng
này.

Extreme Programming - Phương pháp lập trình cực
đoan
“Take known good practices and push them to extremes.”:
Cái gì làm tốt thì phải làm tốt hơn
The planning game: Cách lên kế hoạch như một trò chơi.

CHAPTER 3: AGILE METHODS

2

Small Release: Chuyển giao phần mềm liên tục (Nhiều hơn cả phương pháp
agile).
Thiết kế đơn giản (Thiết kế những gì mình thấy trước mắt).
Refactoring (Thay đổi mã nguồn nhưng chức năng khơng thay đổi)
Lập trình song song.
Liên tục hội nhập.
Làm việc 40 tiếnng 1 tuần.
On - site Customer.
Coding standards.

The 12 Practices
The planning game: cách lên kế hoạch như một trò chơi
Đưa những yêu cầu dưới dạng câu chuyện mang tính thực tế
Đặt quyết định cho những người có kiến thức tốt nhất
Yêu cầu nghiệp vụ → KH
Yêu cầu phần mềm → Developer
Lên kế hoạch trong tầm hiểu biết của mình
Có một trò chơi là Planning Poker
Small Releases: chuyển giao sản phẩm nhỏ lẻ
Lấy phản hồi của người dùng nhanh
Có bao nhiêu stories hoàn thành trong một giai đoạn → biết được tiến độ
của dự án
Metaphor: mượn hình ảnh thực tế
Thơng qua thảo luận
Cung cấp những cái nhìn
Kết nối chương trình với bên ngoài để dễ hiểu hơn
Simple Design: thiết kế đơn giản
Không cần quá phức tạp về sau
Dễ chỉnh sửa, bảo trì và mơ tả

CHAPTER 3: AGILE METHODS

3


Testing
Kiểm thử đơn vị: hàm, lớp, thành phần làm ra
Làm thường xuyên, liên tục → Phải kiểm thử tự động và tự động hoá
càng nhiều càng tốt để giảm chi phí.
Kiểm thử hệ thống → thực hiện bởi khách hàng → Kiểm tra lại yêu cầu
phần mềm (User stories)
Refactoring: thay đổi mã nguồn nhưng chức năng không đổi
Phải làm liên tục thường xuyên
Thiết kế liên tục → Tiết kiệm chi phí

💡

Trong phương pháp truyền thống có Refactoring hay khơng?
Phương pháp nào thực hiện Refactoring nhiều hơn? Vì sao?
Phương pháp truyền thống là phải làm tuần tự, thiết kế đầy đủ, nhu
cầu thay đổi khơng nhiều.
Cịn lại là xu hướng thay đổi nhiều do khơng có kế hoạch từ trước
hoặc kế hoạch ngắn hạn, dẫn đến phải thay đổi nhiều.

Pair Programming: lập trình đơi
Driver and navigator.
Sau một thời gian đổi vai trò lại.
Truyền đạt kinh nghiệm lẫn nhau giữa hai người.
Chất lượng phần mềm tốt hơn, phát hiện lỗi tốt hơn.

Giảm giai đoạn kiểm thử.
Trong thực tế ít dùng pair programming.
Collective Ownership: làm chủ tập thể
Mọi người đều sở hữu mã nguồn
Có thể thay đổi code ở bất kì đâu
Khơng thiết lập modules cá nhân
Giảm được rủi ro nếu một người bị ảnh hưởng, hỗ trợ công việc lẫn nhau.
Continuous Integration: tích hợp liên tục

CHAPTER 3: AGILE METHODS

4


Tất cả đều chạy được liên tục
Có những bản releases thường xuyên và nhanh
Giảm thiểu trường hợp đợi quá lâu và quá chênh lệch, dẫn đến lỗi (”big
bang integration disasters”)
40-hour Week
Không làm việc liên tục → Chất lượng công việc giảm
On-site Customer: KH đến làm việc
Trao đổi trực tiếp với LTV
LTV không biết mọi thứ
Coding Standards
Đảm bảo mã nguồn theo một tiêu chuẩn mã nguồn
Mọi người có thể hiểu mã nguồn

The planning game
Mô tả phần mềm dưới dạng câu chuyện người dùng.
Giao những công việc phù hợp cho những người có chun mơn.

Lên kế hoạch phù hợp với khả năng kiến thức của chúng ta.

Small Release
Chuyển giao các phiên bản nhỏ để nhận được các phản hồi nhanh của khách hàng.
Từ đó biết được tiến độ phát triển của dự án.

Metaphor - Ẩn dụ
Mượn những hình ảnh trong thực tế để diễn đạt những gì trong dự án.
Kết nối chương trình với tiến độ cơng việc.

Simple Design
Thiết kế cho những yêu cầu đơn giản. Những cái phức tạp sẽ được để lại về sau.

⇒ Dễ dàng chỉnh sửa, duy trì.

Testing - Kiểm thử đơn vị
Kiểm thự các hàm, lớp, thành phần được tạo ra để.

CHAPTER 3: AGILE METHODS

5


Được thực hiện thường xuyên và liên tục. (Kể cả với các chức năng đã được làm
rồi).
Việc kiểm thử này được thực hiện bởi khách hàng.

Refactoring
Là một quá trình chỉnh sửa mã nguồn mà không đổi chức năng của mã nguồn (thay
đổi tên hàm, di chuyển qua các vị trí khác,…)

Được làm thường xuyên.
Thiết kế là quan trọng được giữ vững trong suốt q trình
trình phát triển.

💡

⇒ giảm chi phí trong quá

Giữa phương pháp phát triển phần mềm truyền thống và phương
pháp hiện đại, phương pháp nào cần refactoring nhiều hơn?
Trong các phương pháp phát triển phần mềm truyền thống các thay đổi
vạch ra chi tiết từ trước, khó thay đổi trong q trình phát triển.
Cịn trong phương pháp này các thay đổi được đưa ra trong suốt quá
trình phát triển phần mềm
Việc Refactoring nhiều hơn.

⇒

Pair Programming
Giúp truyền đạt các kinh nghiệm lẫn nhau giữa 2 người.
Làm cho chất lượng phần mềm tốt hơn.

⇒ Tiết kiệm thời gian và chi phí.

Về lâu dài tổng thời gian phát triển sẽ được giảm xuống.

💡

Thực tế Pair Programming rất ít được dùng trong thực tế. Bởi vì việc
tương tác giữa 2 người có nhiều trục trặc (bất đồng quan điểm, cái tôi lớn,

…).

Collective Ownership - Làm chủ tập thể
Mỗi người đều có thể sở hữu mã nguồn của nhóm mình. Có thể cập nhật bởi bất cứ
người nào trong team.
Làm giảm thiểu rủi ro khi một người sở hữu và người đó rịi nhóm hay nghỉ việc →
những người khác khơng thể truy cập được.

CHAPTER 3: AGILE METHODS

6


💡

Mọi người có thể hiểu được tổng thể mã nguồn và chia sẻ công việc với
nhau.

Continuous Intergration
Hệ thống được hoạt động liên tục để bảo bảo mã nguồn luôn chạy và khơng có lỗi.
Mỗi người phải up lên Github và đảm bảo mã nguồn của mình chạy được trước khi
rời văn phịng.

40-hour week
Khơng làm việc liên tục → Chất lượng cơng việc sẽ bị giảm.

On-site Customer
Những người có kiến thức về nghiệp vụ, về khách hàng sẽ làm việc trực tiếp với lập
trình viên để chia sẻ về kinh nghiệm và quy tắc cần trong môi trường làm việc.

Coding Standards
Phải đảm bảo mã nguồn theo một tiêu chuẩn được đề ra.
sửa và bảo trì.

⇒ Dễ dàng cho việc chỉnh

Tùy theo từng ngơn ngữ sẽ có những tiêu chuẩn khác nhau.

CHAPTER 3: AGILE METHODS

7


Scrum
Là một quy tắc trong phương pháp Agile sử dụng một tập hợp các quy tắc và thực
hành đơn giản để từng bước phát triển phần mềm.
Một số khái niệm của Scrum:
Daily Scrum: Một cuộc họp ngắn (ít hơn 30 phút) giúp nhóm có thể giám sát
các trạng thái và trao đổi về các vấn đề phát sinh.
Sprint: chu kỳ phát triển phần mềm (thường là 30 ngày).
Backlog:
Product backlog: danh sách ưu tiên của các sản phẩm được yêu cầu.
Sprint backlog: danh sách ưu tiên của các yêu cầu được phân bổ cho quá
trình sprint.
Impediments backlog: danh sách các vấn đề phát sinh.
Burndown chart: biểu đồ biểu diễn tiến độ.

Artifacts
Product backlog
Overall product requirements (Yêu cầu tổng thể về sản phẩm)

Items are estimated and prioritized. (Các mục được ước tính và ưu tiên)
Sprint backlog

CHAPTER 3: AGILE METHODS

8


Requirement items allocated for one sprint. (Các mục yêu cầu được phân bổ
cho một sprint)
Items are estimated prioritized. (Các mục được ước tính ưu tiên)

Scrum Roles
Scrum master:
Facilitate Scum practices.
Enforce Scrum principles.
Team:
Estimate product backlog.
Create sprint backlog.
Implement backlog items.
Product Owner:
Create vision and requirements.
Contact point.
Create releases plan.
Manager:
Ensure resources available.
Resources management.
Team building.

Activities

Release planning: Ưu tiên và phân bổ các tính năng cho các bản release.
Sprint planning:
Đưa ra các mục tiêu và phân bổ các hạng mục tồn đọng cho q trình
Sprint.
Daily Scrum: Có 3 câu hỏi cần được đặt ra bởi các thành viên trong team
What had been done since the last meeting?
What will be done by the next meeting?

CHAPTER 3: AGILE METHODS

9


What issue we have now?

⇒ Giúp mọi người trong nhóm có thể tập trung hơn cho dự án.
Sprint review:
Tổ chức cuối mỗi sprint.
Xem lại những chức năng đã hoàn thiện.
Quyết định những hướng đi đúng và chưa đúng.

Where Agile Methods Work Best?
Nhóm nhỏ (2-20 người).
Q trình lặp lại ngắn (1-2 tuần).
Những hệ thống không yêu cầu cao về độ an toàn.

Strengths and Weaknesses of Agile Methods
Thế mạnh:
Phù hợp với những mơi trường linh động
Thay đổi nhanh chóng, hỗ trợ tốt với những yêu cầu khẩn cấp.

Tránh các chi phí về tài liệu (tốn thời gian và nhân lực soạn tài liệu).
Trao quyền/khuyến khích mọi người làm việc.
Điểm yếu:
Địi hỏi trình độ và động lực cá nhân cao.
Khó thực hiện đối với những hệ thống quan trọng về độ an toàn.
Thường sẽ gặp sự cố khi áp dụng với những dự án lớn.

CHAPTER 3: AGILE METHODS

10