HỌC VIỆN NGÂN HÀNG

KHOA HỆ THỐNG THÔNG TIN QUẢN LÝ

AGILE
PHÁT TRIỂN PHẦN MỀM LINH HOẠT

(agile software development – gọi tắt là Agile)

 TỔNG QUAN AGILE

❖Những vấn đề nổi cộm trong phát triển sản phẩm

❖Sự ra đời của Agile
❖Tuyên ngôn Phát triển Phần mềm Linh hoạt
❖Cách tiếp cận lặp tăng trưởng và truyền thống
❖Khi nào Agile, khi nào không?
 Những vấn đề nổi cộm trong phát triển sản phẩm

• Chỉ 35% dự án thành công

• 31% dự án bị huỷ
• 64% chức năng không được or ít được
user sử dụng đến.
Khủng hoảng phương pháp luận, và sự ra đời của Agile
 Agile là gì?

Phát triển phần mềm linh hoạt hoặc Lập trình

linh hoạt ( Agile software development hay Agile
programming) là một phương thức thực hiện các dự
án công nghệ phần mềm, phương thức này khuyến
khích sự thay đổi khi phát triển dự án và đưa sản
phẩm đến tay người dung sao cho nhanh nhất.
 TUYÊN NGÔN PHÁT TRIỂN PHẦN MỀM LINH HOẠT

Các yêu cầu bên phải vẫn còn giá trị, nhưng các mục ở bên trái được đánh giá cao hơn.
Ý nghĩa của tuyên ngôn AGILE
 Cá nhân và sự tương tác...
Cá nhân và sự tương hỗ quan trọng
hơn quy trình và công cụ”
Ý tưởng là đặt trọng tâm vào con người và sự tương hỗ giữa
những thành viên trong nhóm, điều này không có nghĩa là phủ
nhận tầm quan trọng của quy trình và công cụ nhưng trong
Agile nó được đặt sau yếu tố con người.
 Sản phẩm dùng được…

“Sản phẩm dùng được quan trọng

hơn tài liệu về sản phẩm”

Việc tạo ra và cập nhật các tài liệu về sản phẩm là bắt buộc.
Đứng với góc độ khách hàng thì khách hàng chỉ quan tâm
đến sản phẩm có hoạt động được và tốt hay không.
Vậy tập trung quá nhiều cho việc tạo tài liệu là không cần
thiết, dành thời gian đó để trao đổi để hiểu thêm về công
việc phải làm.
 Cộng tác với khách hàng…

Cộng tác với khách hàng

quan trọng hơn đàm phán hợp đồng

“Khách hàng là thượng đế”,… cách duy nhất để có thể

làm việc tốt là phải cộng tác với khách hàng để hiểu
được khách hàng muốn gì và cần gì để có thể tư vấn
và điều chỉnh mong muốn của khách hàng thay vì chỉ
dựa vào những điều đã quy định trong hợp đồng
 Phản hồi với sự thay đổi…

Phản hồi với sự thay đổi

quan trọng hơn bám theo kế hoạch

Không có dự án nào không có sự thay đổi điều chỉnh khi thực thi
mặc dù kế hoạch đã được định ra rõ ràng từ đầu do vậy cần tập
thích nghi với thay đổi.
Agile không khuyến khích cho sự thay đổi nhưng khuyến khích
chúng ta tập thích nghi với thay đổi.
 Đặc trưng Agile

Tính lặp (Iterative)

❖ Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại.
❖ Các phân đoạn (Iteration hoặc Sprint) có khung thời gian
ngắn (từ một đến bốn tuần).
❖ Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ
các công việc cần thiết như lập kế hoạch, phân tích yêu cầu,
thiết kế, triển khai, kiểm thử (với các mức độ khác nhau) để cho
ra các phần nhỏ của sản phẩm.
❖ Agile thường phân rã mục tiêu thành các phần nhỏ với quá
trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, và không
thực hiện việc lập kế hoạch dài hạn.
 Đặc trưng Agile

Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary)

❖Cuối các phân đoạn, nhóm phát triển thường cho ra

các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ
này thường là đầy đủ, có khả năng chạy tốt, được kiểm
thử cẩn thận và có thể sử dụng .
❖Theo thời gian, phân đoạn này tiếp nối phân đoạn kia,
các phần chạy được này sẽ được tích lũy, lớn dần lên
cho tới khi toàn bộ yêu cầu của khách hàng được thỏa
mãn.
 Đặc trưng Agile

Tính thích ứng (hay thích nghi – adaptive)

❖Do các phân đoạn chỉ kéo dài trong một khoảng thời
gian ngắn, và việc lập kế hoạch cũng được điều chỉnh
liên tục, nên các thay đổi trong quá trình phát triển
đều có thể được đáp ứng theo cách thích hợp .
❖ Theo đó, các quy trình agile thường thích ứng rất tốt
với các thay đổi.
 Đặc trưng Agile
Nhóm tự tổ chức và liên chức năng
❖Cấu trúc nhóm agile thường là liên chức năng(cross-
functionality) và tự tổ chức(self-organizing). Theo đó,
các nhóm này tự thực hiện lấy việc phân công công
việc mà không dựa trên các mô tả cứng về chức danh
hay làm việc dựa trên một sự phân cấp rõ ràng trong
tổ chức
❖Các nhóm cộng tác với nhau để ra quyết định, theo dõi
tiến độ, giải quyết các vấn đề mà không chờ mệnh
lệnh của các cấp quản lý.
❖Được trao quyền để tự ra quyết định, tự quản lí và tổ
chức lấy công việc của chính mình để đạt được hiệu
quả cao nhất.
 Đặc trưng Agile
Quản lý tiến trình thực nghiệm (Empirical Process
Control)
❖Các nhóm agile ra các quyết định dựa trên các dữ liệu
thực tiễn.
❖Agile rút ngắn vòng đời phản hồi (short feedback life
cycle) để dễ dàng thích nghi và gia tăng tính linh hoạt.
❖ Theo thời gian, các chiến lược này sẽ tiến gần đến
trạng thái tối ưu, nhờ đó nhóm có thể kiểm soát được
tiến trình, và nâng cao năng suất lao động.
 Đặc trưng Agile

Giao tiếp trực diện(face-to-face communication)

❖ Một số mô hình phát triển phần mềm dựa rất nhiều vào công việc giấy tờ, ,...
Agile đánh giá cao hơn việc giao tiếp trực diện thay vì gián tiếp thông qua giấy
tờ.
❖ Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình
viên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với
nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao
đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai
thành các chức năng theo yêu cầu.
❖ Bản thân các nhóm agile thường nhỏ để đơn giản hóa quá trình giao tiếp, thúc
đẩy việc cộng tác hiệu quả.
❖ Các nhóm phát triển thường tạo ra các thói quen và cơ chế trao đổi trực diện
một cách thường xuyên. Một trong các cơ chế thường thấy là các cuộc họp tập
trung hằng ngày (daily meeting, Daily Scrum, standup meeting). Tại đây, tất cả
các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì,
đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm
 Đặc trưng Agile
Phát triển dựa trên giá trị (value-based
development)
❖Một trong các nguyên tắc cơ bản của agile là “phần
mềm chạy tốt chính là thước đo của tiến độ”. Nguyên
tắc này giúp nhóm dám loại bỏ đi các công việc dư
thừa không trực tiếp mang lại giá trị cho sản phẩm.
❖Để vận hành được cơ chế “làm việc dựa trên giá trị”,
nhóm agile thường làm việc trực tiếp và thường
xuyên với khách hàng (hay đại diện của khách hàng),
cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu
tiên cao hơn, mang lại giá trị hơn sớm nhất có thể cho
dự án. Nhờ đó các dự án agile thường giúp khách
hàng tối ưu hóa được giá trị của dự án.
Thành công của Agile

1
9
Thành công của Agile

2
0
Thành công của Agile

2
1
Các phương pháp Agile
Các phương pháp Agile
Các phương pháp Agile
Agile vs Mô hình thác nước
Agile vs Mô hình thác nước

2
6
Agile vs Mô hình thác nước
Agile vs Mô hình thác nước

2
8
 Agile vs Mô hình thác nước

Iterative
29
 Agile vs Mô hình thác nước

Incremental
30
3
1

Agile mang lại cho chúng ta những gì?

• Khả năng thích ứng được với sự thay đổi
• Cộng tác hiệu quả và tuyệt vời
• Sản phẩm sớm được đưa ra thị trường
• Tạo ra được những chức năng phù hợp với
những gì mà sản phẩm cần.
• Giảm rủi ro
• Học hỏi, thích nghi, giao hàng!
• Tự hào về nghề nghiệp của mình
• Hoàn toàn minh bạch
• Thích thú trong việc xây dựng sản phẩm
Khi nào dùng Agile ?
Khi nào dùng Agile ?
Khi nào dùng Agile ?
 Khi nào thì không nên áp dụng Agile?

• Điều kiện thị trường ổn định và có thể tiên lượng

• Yêu cầu rất rõ ràng và luôn ổnđịnh
• Khách hàng không thể cộng tác thường xuyên
• Công việc tương tự những gì đã làm trước đó, và giải pháp
là rất rõ ràng. Đặc tả chi tiết có thể làm ra với sự dự đoán rõ
ràng và chính xác. Vấn đề có thể giải quyết tuần tự qua
từng bộ phận chức năng mà không gặp trở ngại nào.
• Khách hàng không thể bắt đầu kiểm thử các phần sản phẩm
cho tới khi sản phẩm hoàn chỉnh
• Thay đổi phút chót rất tốn kém, hoặc không thể
• Sai sót trong thực thi có thể dẫn đến thảm họa không thể
cứu vãn được.
 HỌC VIỆN NGÂN HÀNG
KHOA HỆ THỐNG THÔNG TIN QUẢN LÝ

Scrum framework
Scrum là gì?
Scrum là gì?
Scrum là gì?
 Khái lược về Scrum
❖ Scrum là một khung làm việc trong đó con người có thể xác
định các vấn đề thích nghi phức tạp, nhưng vẫn giữ được
năng suất và sáng tạo để chuyển giao các sản phẩm có giá trị
cao nhất.
❖ Scrum có các tính chất:
➢ nhẹ nhàng
➢ dễ hiểu
➢ rất khó để tinh thông
❖ Scrum là khung làm việc đã được sử dụng để quản lý quá
trình phát triển các sản phẩm phức tạp từ đầu những năm
1990.
❖ Scrum không phải là một quy trình hay một kĩ thuật cụ thể,
nó là một khung làm việc cho phép bạn sử dụng nhiều quy
trình và kĩ thuật khác nhau. Scrum làm rõ độ hiệu quả tương
đối của công tác quản lý và phát triển sản phẩm, từ đó cho
phép bạn cải tiến nó.
 Khung làm việc Scrum

❖Khung làm việc Scrum bao gồm một Nhóm Scrum với
các vai trò được phân định rõ ràng, các sự kiện, các
đồ nghề và các quy tắc. Mỗi thành phần trong khung
làm việc phục vụ một mục đích rõ ràng và nòng cốt
trong việc sử dụng và thành công của Scrum.
❖Các chiến lược cụ thể để sử dụng Scrum có thể rất
khác nhau
❖Các quy tắc của Scrum gắn kết các yếu tố sự kiện, vai
trò, đồ nghề với nhau, điều khiển các mối quan hệ và
tương tác giữa chúng.
 BA VAI TRÒ
❖ Product Owner (chủ sản phẩm): Là
người chịu trách nhiệm về sự thành
công của dự án, người định nghĩa các
yêu cầu và đánh giá cuối cùng đầu ra
của các nhà phát triển phần mềm.
❖ Scrum Master: Là người có hiểu biết
sâu sắc về Scrum và đảm bảo nhóm
có thể làm việc hiệu quả với Scrum.
❖ Development Team (Đội sản xuất,
hay Nhóm phát triển) Một
nhóm liên chức năng (cross-
functional) tự quản lý để tiến hành
chuyển đổi các yêu cầu được tổ chức
trong Product Backlog thành chức
năng của hệ thống.
BA TRỤ CỘT CỦA SCRUM

❖Minh bạch,
❖Thanh tra
❖ Thích nghi.
 BA TRỤ CỘT CỦA SCRUM

Transparency ❖ Tài chính minh bạch, công việc minh

bạch, quy trình minh bạch, đánh giá minh
bạch, chiến lược minh bạch, hiệu quả
minh bạch, vấn đề cũng phải được minh
bạch
❖ Thiếu minh bạch, tổ chức dễ rơi vào tình
huống rủi ro, ít khả năng thích ứng thiếu
thông tin để ra quyết định chính xác
❖ Thiếu minh bạch, tổ chức có thể bị phụ
thuộc vào một vài cá nhân hoặc nhóm lợi
ích, khó phát triển bền vững và trường
tồn.
❖ Minh bạch thường phải kèm thông suốt.
Vì thiếu thông suốt, giá trị của minh bạch
bị giảm xuống.
 BA TRỤ CỘT CỦA SCRUM

Inspection
❖ Người sử dụng Scrum phải
thường xuyên thanh tra các tạo
tác và tiến độ đến đích để phát
hiện các bất thường không theo
ý muốn.
❖ Tần suất thanh tra không nên
quá dày để khỏi ảnh hưởng đến
công việc.
❖ Công tác thanh tra có ích nhất
khi được thực hiện bởi người có
kĩ năng tại các điểm quan trọng
của công việc
 BA TRỤ CỘT CỦA SCRUM

Adaptation
Scrum rất linh hoạt như các
phương pháp phát triển linh hoạt
(agile software development)
khác. Nhờ đó nó mang lại tính
thích nghi rất cao. Dựa trên các
thông tin minh bạch hóa từ các
quá trình thanh tra và làm việc,
Scrum có thể phản hồi lại các thay
đổi một cách tích cực, nhờ đó
mang lại thành công cho dự án.
 BA TRỤ CỘT CỦA SCRUM

❖Scrum cung cấp bốn cơ hội chính thức cho việc

thanh tra và thích nghi trong các Sự kiện Scrum,
bao gồm:
▪ Buổi Họp Kế hoạch Sprint (Sprint Planning Meeting)
▪ Họp Scrum hằng ngày (Daily Scrum)
▪ Sơ kết Sprint (Sprint Review)
▪ Cải tiến Sprint (Sprint Retrospective)
 Scrum framework

Vai trò Tạo tác • Sự kiện

• PO: Product Owner • Gói tăng trưởng • Sprint
• SM: Scrum Master • Product backlog • Sprint planning
• Dev team • Sprint backlog • Daily MTG
• Review MTG
• Retrospective
 Các sự kiện trong SCRUM

❖ Là các hoạt động xảy ra trong suốt vòng đời của quá trình phát triển.
❖ Các sự kiện chính trong Scrum là:
❖ Sprint: Là khung thời gian ít hơn một tháng để Nhóm Scrum thực
hiện tất cả những hoạt động cần thiết để sản xuất được một phần
tăng trưởng của sản phẩm. Tất cả các sự kiện khác của Scrum đều
được diễn ra trong khung thời gian của một Sprint.
❖ Lập kế hoạch Sprint: Là sự kiện diễn ra ở đầu mỗi Sprint để chuẩn
bị cho toàn bộ Sprint. Buổi Lập kế hoạch Sprint được chia làm 2
phần riêng biệt với 2 mục đích khác nhau. Phần 1 nhằm trả lời câu
hỏi: “Chúng ta sẽ làm gì?”. Phần 2 nhằm trả lời câu hỏi: “Chúng ta
sẽ làm như thế nào?”.
❖ Scrum Hằng ngày: Là buổi trao đổi ngắn mà Nhóm Phát triển thực
hiện đều đặn hằng ngày nhằm cập nhật và đồng bộ công việc giữa
các thành viên. Sự kiện này cũng được coi là buổi tái-lập kế hoạch
của Nhóm Phát triển.
 Các sự kiện trong SCRUM

❖ Sơ kết Sprint: Là sự kiện diễn ra ở cuối Sprint nhằm thanh tra và

thích nghi sản phẩm đang được xây dựng. Sự kiện này bao gồm 2
hoạt động chính đó là dùng thử sản phẩm và thảo luận về tình
hình của sản phẩm, hướng đi tiếp theo và những điều chỉnh đối
với sản phẩm nếu cần thiết.

❖ Cải tiến Sprint: Là một sự kiện quan trọng trong Scrum diễn ra
ngay sau buổi Sơ kết Sprint nhằm mục đích thanh tra và thích nghi
quy trình làm việc. Nói cách khác đây là dịp để Nhóm Scrum nhìn
lại quá trình làm việc của một Sprint và xác định những thay đổi
cần thiết đối với quy trình để làm việc tốt hơn trong Sprint sau.
 CÁC TẠO TÁC TRONG SCRUM
Các tạo tác trong Scrum là những công cụ hoặc kết quả được tạo ra và sử
dụng trong quá trình vận hành Scrum. Các tạo tác trong Scrum bao gồm:
❖ Product Backlog: Là nơi lưu trữ danh sách các tính năng mong muốn của
sản phẩm. Danh sách này được sắp xếp dựa trên độ ưu tiên của từng
hạng mục. Các hạng mục có độ ưu tiên cao hơn nằm ở phía trên của danh
sách và sẽ được Nhóm Phát triển lựa chọn để đưa vào sản xuất sớm, các
hạng mục có độ ưu tiên thấp hơn sẽ nằm ở phía cuối của danh sách và
được phát triển muộn hơn.
❖ Sprint Backlog: Là bảng công việc được Nhóm Phát triển sử dụng để quản
lý quá trình phát triển trong một Sprint. Sprint Backlog được Nhóm Phát
triển tạo ra trong buổi Lập kế hoạch Sprint và cập nhật trong suốt Sprint.
Sprint Backlog chứa danh sách các hạng mục được phát triển trong
Sprint và các công việc cần làm tương ứng với từng hạng mục để hoàn
thành nó.
❖ Phần tăng trưởng: Là tên gọi ngắn của Phần tăng trưởng Sản phẩm Có
khả năng Chuyển giao được (Potentially Shippable Product Increment) là
phần sản phẩm Nhóm Phát triển tạo ra cuối mỗi Sprint.
 Các bước thực hiện

❖Xây dựng Product Backlog;

❖Lập kế hoạch Sprint;
❖Scrum Hằng ngày;
❖Theo dõi tiến độ trong suốt Sprint;
❖Làm mịn Product Backlog;
❖Sơ kết Sprint;
❖Cải tiến Sprint;
❖Bắt đầu Sprint tiếp theo.
 Product Backlog

❖01. Product-Backlog-template
❖02. Product Owner Checklist
❖00.Planning Poker
 Lập kế hoạch Sprint

❖08.SMART rubric
❖07.Sprint-Backlog-template
❖05.Sprint Planning Checklist
 Dayly SCRUM

❖User-Story-template
 Theo dõi tiến độ Sprint

❖04. Burndown-Chart-sample
 Làm mịn Product Backlog

❖01. Product-Backlog-template
❖00.Planning Poker
 Sơ kết Sprint

❖06.Sprint Review Checklist

❖07.Sprint-Backlog-template
 Cải tiến Sprint

❖CÁC KỸ THUẬT CẢI TIẾN SPRINT-Retrospective

Techniques
❖DANH MỤC KIỂM TRA CẢI TIẾN SPRINT-Sprint
Retrospective Checklist
Bắt đầu Sprint tiếp theo
 SMART RUBRIC

❖Một Sprint bắt đầu bằng buổi Lập kế hoạch Sprint

để xác định Mục tiêu Sprint và lên kế hoạch các
công việc cần thực hiện. Sự kiện này được chia làm
hai phần: Phần thứ nhất để lựa chọn các công việc
cần làm trong Sprint và Phần thứ hai để quyết định
cách thức hoàn thành các công việc đã lựa chọn
trước đó.
❖SMART Rubric giúp bạn xác lập mục tiêu cho
Sprint tốt hơn.