ĐẠI HỌC BÁCH KHOA HÀ NỘI

Đề tài:

TÌM HIỂU VỀ AGILE PROJECT MANAGEMENT

Giảng viên hướng dẫn :

P.GS Huỳnh Quyết Thắng

Sinh viên thực hiện :
Nguyễn Văn Vơn
Phạm Đức Anh
Bạch Quốc Cường
Trần Đức Thành

Hà Nội, 14 tháng 9 năm 2017

1
14/09/2017


Mục lục

2
14/09/2017


I.

II.

SỰ RA ĐỜI CỦA MÔ HÌNH AGILE
1. Bối cảnh.
Chúng ta có rất nhiều phương pháp giúp xác định con đường phát tri ển phần
mềm ví dụ như một số quy trình:
- Mô hình thác nước.
- Mô hình xoắn ốc.
- Mô hình hướng đối tượng.
- Mô hình làm bản mẫu.
Các phương pháp kể trên chủ yếu là dự đoán trước cho quy trình phát triển phần
mềm. Do đó các phương pháp này thường tạo ra một bản kế hoạch từ thời điểm đầu
dự án và xác định được thời gian hoàn thành của dự án. Nhưng vấn đề quan trọng nhất
vẫn là “sự thay đổi yêu cầu người dùng”. Và phương pháp truyền thống thì hạn chế sự
thay đổi yêu cầu từ khách hàng. Điều này giúp duy trì kế hoạch dự án ban đầu nhưng
không đem lại sự thỏa mãn hoàn toàn cho khách hàng. Một phần mềm tốt là phần
mềm mà đem lại cho khách hàng sự hài lòng. Chính sự hạn chế từ những phương pháp
truyền thống mà cần có một phương pháp hay quy trình phát triển phần mềm mới ra
đời. Quy trình phát triển phần mềm linh hoạt (Agile) ra đời và phần nào đáp ứng được
yêu cầu ấy.
Phương pháp quản lý dự án linh hoạt (Agile project management) ra đời từ đầu
những năm 90, với ý tưởng khắc phục những nhược điểm của mô hình truyền thống cụ
thể là mô hình thác nước.
2. Agile là gì?
Agile là tên gọi chung để chỉ các phương pháp phát triển nhanh, linh hoạt. “Agile”
nghĩa là nhanh nhẹn, khéo léo, linh hoạt.
Agile không phải là một phương pháp cụ thể mà là một triết lí cùng với nhóm các
phương pháp và phương pháp luận phát triển sản phẩm dựa trên nguyên tắc phát triển
phân đoạn lặp và tăng trưởng với mục tiêu là phần mềm phải có khả năng biến đổi,
phát triển và tiến hóa theo thời gian mà không phải làm lại từ đầu.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mềm

trong những khung thời gian ngắn và sự cộng tác chặt chẽ với khách hàng. Điểm nổi
bật là khả năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu.
Điểm quan trọng làm lên sự khác biệt của Agile so với các mô hình truyền thống đó
là: các mô hình truyền thống là mô hình theo kế hoạch, còn mô hình Agile thì không
nhất thiết phải tuân theo kế hoạch, nó có thể có những bước đột phá để tạo ra một
phần mềm hiệu quả nhất.
TÌM HIỂU CHUNG VỀ AGILE
1. Tuyên ngôn Agile.
 Cá nhân và tương tác hơn là quy trình và công cụ:
Tất nhiên quy trình và công cụ cũng là điều quan trọng. Sẽ không thể có một
phần mềm tốt nếu như quy trình và công cụ không tốt. Nhưng điều mà bản
tuyên ngôn nhấn mạnh là vai trò của từng cá nhân và mối quan hệ giữa các cá
nhân trong đội ngũ phát triển phần mềm. Ý nghĩa quan trọng nhất của Agile là
3

14/09/2017


mọi người cùng làm việc trong nhóm, chia sẻ thông tin thoải mái với nhau hơn
là tập trung theo sát một quy trình hay công cụ nào đó.
 Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm.
Điều này không có nghĩa là chúng ta không phải thu thập lại tư liệu để phát
triển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều hơn cho việc viết
phần mềm. Bởi vì đối với một dự án muốn thành công thì phải thu thập tài liệu
đầy đủ. Nhưng bản thân tài liệu cũng không thể giúp được gì nếu không có một
sản phẩm phần mềm thực sự. Vì thế, việc tạo ra sản phẩm phần mềm quan
trọng hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một
cách chính xác. Trong Agile thì sẽ ít viết tài liệu nếu khách hàng không yêu cầu
nhiều về tài liệu, việc viết tài liệu một cách cụ thể được xem là không thực sự
cần thiết và thường bỏ qua để đơn giản hóa. Agile chỉ viết những gì mà cần

thiết nhất mà mọi người muốn đọc.
 Hợp tác với khách hàng hơn là thương thuyết hợp đồng
Việc ký kết hợp đồng là quan trọng nhưng không đủ. Một môi trường hợp tác
tốt sẽ giúp cho những người phát triển đưa ra giải pháp tốt nhất cho khách hàng.
Các hợp đồng định nghĩa những điều khoản ràng buộc mà trong đó cả hai bên
đối tác phải tuân theo. Nhưng những người phát triển cần phải hợp tác với
khách hàng để có thể hiểu rõ yêu cầu cũng như ý muốn cụ thể của khách hàng.
Agile khuyến khích khách hàng cùng tham gia vào dự án hơn là chỉ viết hợp
đồng để rồi khách hàng sẽ chẳng làm gì với nhóm dự án phát triển phần mềm.
 Phản ứng theo thay đổi hơn là theo sát kế hoạch:
Việc lập kế hoạch cho phát triển phần mềm là không thể thiếu. Kế hoạch
giúp công việc định hướng tốt hơn. Tuy nhiên thực tế có rất nhiều thay đổi, và
cứ nhất nhất tuân theo kế hoạch sẽ dễ dẫn đến thất bại. Do đó cần đáp ứng với
thay đổi để có sự điều chỉnh sao cho phù hợp. Chính vì vậy, nhóm phát triển
luôn sẵn lòng đón nhận thay đổi hơn là chỉ làm theo kế hoạch dự án (đã có
trước) vì thay đổi của khách hàng luôn diễn ra và cả kế hoạch của dự án cũng sẽ
thay đổi khi yêu cầu của khách hàng thay đổi. Đây là một điểm cho thấy rõ sự
linh hoạt trong Agile, và nó mang lại cho khách hàng sự thỏa mãn cao nhất.
2. Nguyên tắc Agile
Các phương pháp phát triển phần mềm theo Agile có 12 nguyên tắc cụ thể như sau, 12
nguyên tắc này là sự thể hiện 4 tuyên ngôn của Agile một cách cụ thể và có tính thực
tiễn cao hơn:
- Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
- Giao phần mềm chạy được cho khách hàng một cách thường xuyên. Chu kì ngắn
tốt hơn chu kì dài
- Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
- Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt
dự án
4
14/09/2017



-

Các dự án được xây dựng 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
Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông
tin
Phần mềm chạy được là thước đo chính của tiến độ
Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
Nhóm tự tổ chức
Thích ứng thường xuyên với sự thay đổi
Một số diễn giải về các nguyên tắc:
Nguyên tắc
Khách hàng tham gia

Chuyển giao tăng dần

Con người thay vì quy trình

Chấp nhận thay đổi

Gìn giữ tính giản dị, dễ hiểu

Miêu tả
Khách hàng nên tham gia chặt chẽ trong s
trình phát triển. Vai trò của họ là cung cấp
định mức độ ưu tiên các yêu cầu mớ

thống, và đánh giá hệ thống tại các lần lặ
phiên bản nhỏ của sản phẩm cuối cùng.
Phần mềm được phát triển một cách tă
từng đợt (increment), trong đó khách hàn
các yêu cầu cần được đưa vào mỗi đợt
phát triển sẽ giao phần mềm từng đợt ch
hàng, mỗi đợt sẽ là phiên bản mới được th
số chức năng như yêu cầu.
Kĩ năng phát triển của đội cần được ghi
khai thác. Các thành viên của đội cần đượ
phát triển cách làm việc của riêng m
không cần đến các quy trình quy phạ
trước.
Hiểu rằng hệ thống sẽ thay đổi nên thiế
thống sao cho nó có thể chấp nhận được t
đó. Hệ thống phải linh hoạt nhất, để có
ứng thay đổi của khách hàng.
Chú trọng vào tính giản dị dễ hiểu của ph
đang được phát triển cũng như của quy trì
triển. Chủ động nỗ lực loại bỏ sự phức tạp
hệ thống bất cứ khi nào có thể. Muốn li
thì phải đơn giản những gì đang làm sẽ làm

3. Đặc trưng của các phương pháp 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 (được
gọi là Iteration hoặc Sprint) thường 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ử … để cho ra các
5

14/09/2017


-

-

-

-

-

phần nhỏ của sản phẩm. Các phương pháp Agile thường chia mục tiêu cuối cùng
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ể,
không thực hiện việc lập kế hoạch dài hạn, hoặc thậm chí công việc lập kế hoạch,
làm mịn kế hoạch được thực hiện liên tục trong suốt quá trình làm việc.
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. Khác với mô hình phát triển Thác nước – vốn chỉ cho
phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong
các dự án Agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ
để phát hành.
Tính thích ứng ( 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. Trong khi nhóm phát triển đang sản xuất ra

các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm có
thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn tiếp theo.
Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi.
Nhóm tự tổ chức (self-organizing) và liên chức năng (cross-functionality):
Các nhóm tự thực hiện 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 một tổ chức
nào 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ý. Họ không làm việc theo cơ chế
“mệnh lệnh và kiểm soát”. Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng cần
thiết cho việc phát triển phần mềm, do vậy nó có thể đượ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.
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 thay vì tính toán
lý thuyết hay các tiền giả định. Việc phân nhỏ dự án thành các phân đoạn ngắn góp
phần gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều chỉnh
các chiến lược phát triển của mình. Nói cách khác, Agile rút ngắn vòng đời phản hồi
để 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 (vì càng ngày càng có nhiều dữ liệu thực tiễn hơn), nhờ
đó nhóm có thể kiểm soát được tiến trình, và nâng cao năng suất lao động.
Giao tiếp trực diện(face-to-face communication):
Agile đánh giá cao việc giao tiếp trực diện hơn là giao tiếp gián tiếp thông qua
giấy tờ. Về giao tiếp với khách hàng, Agile khuyến khích nhóm phát triển trực tiếp
6

14/09/2017


-


nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ
thuộc nhiều vào các loại văn bản.
Trong giao tiếp giữa nội bộ nhóm phát triển với nhau. Agile khuyến khích các
thành viên trực tiếp trao đổi và thống nhất với nhau về việc phát triển sản phẩm. Bản
thân các nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớn thường được
phân nhỏ với cơ chế hợp tác đặc thù để luôn luôn có thông lượng giao tiếp tối đa) để
đơ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 việc.
Phát triển dựa trên giá trị (value-based development):
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. Một cách gần như trực tiếp, Agile
gia tăng đáng kể độ hài lòng của khách hàng.

7
14/09/2017


III.

CÁC PHƯƠNG PHÁP AGILE
1. Phân loại

Hiện nay có nhiều phương pháp Agile, nhưng thực sự chúng không phải là một
phương pháp mà là một hệ thống các triết lý và tập hợp các giá trị và nguyên tắc.

Agile giống như một cây dù với nhiều phương pháp Agile khác nhau, có thể phân loại
chúng thành 2 nhóm cơ bản: lightweight approaches(tiếp cận nhanh) và fuller
approaches(tiếp cận đầy đủ hơn).
Trong đó:
 Lightweight approaches là các phương pháp như Scrum, Extreme programming,
lean, …
 Fuller approaches là các phương pháp như Dynamic System Development Method
DSDM Atern, Agile Unified Process(AUP),…
Sau đây là một số nguyên tắc của các phương pháp trên:
 Scrum: tập trung vào việc quản lý agile và tổ chức tốt hơn cho các đội phát
triển.
 XP(Extreme Programming): trong phương pháp này có một số yếu tố quản lý,
nhưng nhấn mạnh yếu tố thực hành kỹ thuật hơn các phương pháp khác.
 Lean Software Development: nhằm giảm tối thiểu chi phí đầu tư cho dự án.
 DSDM – Dynamic Systems Development Method: phương pháp này nhằm rút
ngắn thời gian các vòng lặp(Sprint) của dự án.
2. Tỉ lệ được sử dụng của các phương pháp Agile
Theo khảo sát mới đây (2011) của Forrester Research, các cách tiếp cận phổ biến
trong phát triển phần mềm có thể kể đến gồm Scrum, Iterative (Iterative Development
- phát triển lặp), Waterfall, TDD, Kanban, XP.
Phương pháp

Tỉ lệ trả lời "có dùng"
8

14/09/2017


Scrum
81.5%

Iterative
58.5%
Waterfall
44.4%
Test-Driven Development 37.1%
(TDD)
Kanban
37.1%
eXtreme
Programming 35.6%
(XP)
Lean
Software 32.7%
Development
Bảng thống kê một phần này cho thấy phần lớn các công ty hiện nay đã bắt đầu sử
dụng Scrum như là cách tiếp cận cơ bản. Bên cạnh đó, nhiều công ty đã kết hợp các
phương pháp lại với nhau trong thực tiễn. Ví dụ 44.4 % các công ty có sử dụng
Waterfall, như vậy có nghĩa là một tỉ lệ nhất định nào đó vừa dùng waterfall, vừa sử
dụng Scrum trong hoạt động của mình. Điều này có thể do các nguyên nhân lịch sử,
hoặc các ràng buộc về chính sách, luật pháp hoặc văn hóa. Đó cũng là một tình huống
khá phổ biến đối với các công ty mới lần đầu “bước chân” vào “ma trận các phương
pháp Agile”.
Bảng dưới đây của VersionOne khảo sát trên các công ty Agile, cho thấy những
phương pháp phổ biến được sử dụng:

IV.

SCRUM
9


14/09/2017


1. Scrum là gì?
Scrum là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile) phổ biến
nhất hiện nay được dùng trong phát triển các sản phẩm phần mềm từ đơn giản đến
phức tạp. Được phát triển bởi Ken Schwaber và Jeff Sutherland từ đầu những năm
1990.
Cách làm và triết lí của Scrum đã dần được áp dụng trong các lĩnh vực khác như
dịch vụ, giáo dục, marketing v.v. Hiện nay, định nghĩa Scrum là gì được ghi trong tài
liệu Scrum Guide (Hướng dẫn Scrum) và được cập nhật thường xuyên bởi chính các
tác giả tại .
2. Mô tả về Scrum
Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường
mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự
thay đổi và yêu cầu tốc độ cao.
Một sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống.
Các tác vụ trong sprint được chia ra thành các danh mục, đội làm việc sẽ phát triển và
đánh giá lại sao cho đạt được mục đích ban đầu trong khoảng thời gian đề ra.
i. Các thành tố tạo nên Scrum?
Scrum bao gồm các giá trị cốt lõi(còn gọi là "ba chân", hay ba trụ cột của
Scrum), các vai trò(nhóm Scrum), các sự kiện, và các công cụ (artifacts, hay đồ
nghề) đặc thù của Scrum.

a) Ba chân (hay giá trị cốt lõi) của Scrum
Scrum là một phương pháp linh hoạt (agile), vì thế nó tuân thủ các nguyên tắc
của Agile Manifesto (xem thêm Tuyên ngôn Agile). Ngoài ra Scrum hoạt động dựa
trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra
và Thích nghi.
 Minh bạch (transparency)

Trong Scrum, tính minh bạch được đề cao như là giá trị cốt lõi cơ bản nhất.
Muốn thành công với Scrum, thông tin liên quan tới quá trình phát triển phải minh
bạch và thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) về sản phẩm, yêu
10
14/09/2017


cầu khách hàng, tiến độ công việc, các khúc mắc và rào cản v.v. Từ đó mọi người ở
các vai trò các nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị
để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm
bảo thông tin được minh bạch cho các bên.
 Thanh tra (inspection)
Công tác thanh tra liên tục các hoạt động trong Scrum đảm bảo cho việc phát lộ
các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các
bên tham gia dự án. Truy xét kĩ càng và liên tục là cơ chế khởi đầu cho việc thích
nghi và các cải tiến liên tục trong Scrum.
 Thích nghi (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.
b) Ba Vai trò (nhóm Scrum)
Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò
với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này
bao gồm: Product Owner (chủ sản phẩm), Scrum Master và Development Team
(Đội sản xuất hay Nhóm Phát triển).
 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, được xem là tiếng nói của
khách hàng, và hoạt động như một đại diện cho khách hàng trong các cuộc họp lập
kế hoạch, 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.
c) Bốn Cuộc họp (4 Events)
Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi
trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án. Các lễ
nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra
(Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective).
 Sprint Planning (Họp Kế hoạch Sprint)
Diễn ra đầu mỗi sprint, nhóm phát triển gặp gỡ với Product Owner để lên kế
hoạch làm việc cho một Sprint. Công việc lập kế hoạch bao gồm việc chọn lựa các
yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo
các ước lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức
lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không
diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự
thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.
 Daily Scrum (Họp Scrum hằng ngày)
11
14/09/2017


Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để
Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải
trong quá trình phát triển phần mềm suốt một Sprint.
 Sprint Review (Họp Sơ kết Sprint)
Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc

đã hoàn tất trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết
cho sản phẩm.
 Sprint Retrospective (Họp Cải tiến Sprint)
Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện
Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản
phẩm.
d) 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.
Chúng bao gồm bản yêu cầu của chủ sản phẩm được gọi là Product backlog, bản kế
hoạch của từng Sprint (Sprint Backlog) và biểu đồ Burndown Chart.
 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

12
14/09/2017


Đâ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
13
14/09/2017


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ó.
ii. Scrum vận hành như thế nào?

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng
mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần
các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 1 đến
4 tuần làm việc (gọi làSprint) với đầu vào là các hạng mục trong Product Backlog,
đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially
Shippable Product Increment). Trước khi cả nhóm cùng đua nước rút trong Sprint,
đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả
của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công
việc cần làm trong suốt một Sprint. Trong suốt quá trình phát triển, nhóm sẽ phải
cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để
chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng
nhau. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để
hoàn thành công việc trong Sprint. Khi kết thúc Sprint, nhóm tạo ra các gói phần
mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác hàng.
Buổi họp sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được
nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay
đổi hay cải tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng
tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi
Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua
từng Sprint.

Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product
Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án
căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các
hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó
Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn
luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi
ích to lớn mà Scrum mang lại cho tổ chức.

14
14/09/2017


V.

SO SÁNH AGILE VÀ WATERFALL
1. Waterfall

Dự án phần mềm sẽ được thực hiện tuần tự qua các bước cố định, tách rời nhau và
theo kế hoặc định sẵn, rất hạn chế những sự thay đổi trong quá trình thực hiện. Với
waterfall thì nhất thiết phải hết giai đoạn “Nhu cầu” mới được chuyển sang giai đoạn
“Thiết kế”, không thể thực hiện “Mã hóa” mà chưa làm “Design” .
Mặc dù các quy trình hiện tại theo mô hình waterfall đã có những cải biên cho phép
những phản hồi (feedback) tới các bước trước đó, nhằm giúp quy trình linh hoạt hơn,
nhưng về bản chất, chúng vẫn tách rời nhau như vậy.
Hơn thế nữa, các hoạt động trong đội ngũ phát triển phải dựa vào kế hoạch. Quản lí sẽ
lập kế hoạch, rồi giao việc, rồi kiểm soát (tiến độ, năng suất, chất lượng v.v.) dựa theo kế
hoạch; nhân viên làm việc theo tinh thần tuân thủ kế hoạch, ít phản hồi. Cách làm việc
tách biệt và tuần tự này được phản ánh rõ nét trong cơ cấu các phòng ban chức năng (test,
development, management), các vai trò của cá nhân (tester, developer, QA, PM, BA ...) –
mỗi người có mô tả công việc rõ rệt, không ai giẫm chân lên công việc của người khác;

và các quy trình nghiệp vụ chặt chẽ được văn bản hóa (hay pháp chế hóa) trong phạm vi
tổ chức.
 Cũng chính do được thực hiện theo kế hoạch vạch ra từ trước nên với Waterfall, ta
ước tính được thời gian hoàn thành và ngân sách thực hiên của dự án với độ chính
xác cao hơn.
Quá trình phát triển dự án theo mô hình Waterfal có xu hướng được an toàn hơn bởi
được định hướng bởi kế hoạch. Ví dụ một nhà thiết kế bỏ dự án đó giữa chừng thì cũng
không phải là 1 vấn đề lớn. Bởi Waterfall có sẵn kế hoạch định hướng và tài liệu đầy đủ

15
14/09/2017


nên khi 1 nhà thiết kế khác tiếp nhận vị trí bị bỏ lại vẫn có thể dễ dàng tiếp tục dự án mà
không gặp vấn đề gì khó khăn.
Nhược điểm: Waterfall có điểm yếu lớn nhất đó là sự cứng nhắc và thiếu linh hoạt của
mình. Việc thay đổi thiết kế dự án ở bất cứ giai đoạn nào gần như đồng nghĩa với việc bắt
đầu tất cả lại từ đầu nên việc thay đổi là gần như k thể xảy ra. Do đó quá trình lập kế
hoạch khi sử dụng mô hình waterfall là vô cùng quan trọng, bạn cần thu thập toàn bộ yêu
cầu từ khách hàng.
2. Agile

Khác với waterfall truyền thống, Agile không làm việc theo kiểu tuân thủ kế hoạch
(plan-driven) mà lựa chọn việc “thích ứng với sự thay đổi”.
 Đặc biệt thích hợp cho các dự án mà mục tiêu cuối cùng chưa được xác định rỏ
ràng ngay từ đầu. Khi áp dụng agile thì các mục tiêu đó sẽ dần được sang rỏ trong
quá trình thực hiện dự án. Agile là mô hình thường dùng để thực hiện thăm dò phát
triển sản phẩm . Trong các dự án thăm dò, đội được khám phá cách thức mới để giải
quyết một vấn đề hoặc cố gắng để khám phá ra một khách hàng mới hoặc phân khúc
thị trường.

Nó hầu như không tiếp cận tuần tự, mà là chồng lấp (overlapping - tức là các công việc
được tiến hành không tuần tự, có thể song song, có thể đồng thời với sự cộng tác chặt chẽ
hướng đến mục tiêu chung) để xây dựng phần mềm. Dự án thường được chia thành các
module nhỏ để thực hiện song song.

16
14/09/2017


Nhược điểm:
• Agile mặc dù rất linh hoạt do không bị cố định bởi 1 kế hoạch nào nhưng cũng chính
vì vậy mà tất cả mọi thứ vẫn còn chút mơ hồ, rất khó khăn để xác định chính xác
được các mốc thời gian của dự án hay ngân sách dự án.
• Agile luôn sẳn sàng lắng nghe mọi phản hồi (feedback) từ khách hàng và thay đổi
theo. Tuy nhiên cũng chính vì vậy mà có thể thời gian của dự án sẽ bị kéo dài lên rất
nhiều khi có quá nhiều yêu cầu thay đổi từ khách hàng.
KẾT LUẬN
Có thể tóm lược đặc điểm của 2 mô hình trên như sau:
Agile

Waterfall

Linh hoạt

Cứng nhắc

Các bước chồng lấp, không
cần tuần tự

Các bước tách biệt, yêu cầu các

bước tuần tự

Luôn chấp nhận sự thay đổi

Rất hạn chế sự thay đổi

Không có kế hoạc cố định

Có kế hoạc cố định từ khi bắt đầu

Phù hợp các dự án chưa xác
định chính xác mục tiêu cuối
cùng

Dùng cho các dự án mà kế hoạch đã
được lập ra với đầy đủ yêu cầu và
mục tiêu

Agile và Waterfall, mỗi phương pháp mang những đặc điểm riêng, có ưu có khuyết,
không thể nói cái nào tốt hơn cái nào. Trong khi Waterfal thích hợp hơn cho các dự án
tĩnh, ít có sự thay đổi trong suốt quá trình phát triển, thì Agile lại thích hợp cho các dự

17
14/09/2017


án nhỏ, nơi thay đổi có thể thực hiện trong suốt quá trình thực hiện dự án. Do đó, để
mỗi mô hình phát huy được tối đa tác dụng, thì hãy dùng nó đúng nơi, đúng chỗ!
VI.


CÁC CÔNG CỤ QUẢN LÝ DỰ ÁN
1. MyCollab

2. Odoo

3. Orange Scrum

18
14/09/2017


19
14/09/2017


VII.

TÀI LIỆU THAM KHẢO
1.
2.
3.
4.
5.
6.
7.

/> /> /> /> />
/>
20
14/09/2017