TÌM HIỂU về managing agile project

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TIỂU LUẬN
MÔN HỌC: QUẢN LÝ DỰ ÁN PHẦN MỀM
CHUYÊN ĐỀ:
TÌM HIỂU VỀ Managing Agile Project
Giáo viên hướng dẫn: TS. Trương Anh Hoàng
TS. Phạm Ngọc Hùng
Nhóm học viên: 1. Trần Thị Hiền
2. Nguyễn Anh Khiêm*
3. Phan Thị Luân
4. Phạm Đức Mạnh
5. Nguyễn Thị Yến
Hà Nội 04/2013
LỜI CẢM ƠN
Lời đầu tiên chúng em xin cảm ơn thầy TS. Trương Anh Hoàng và TS. Phạm Ngọc
Hùng, thầy đã nhiệt tình giảng dạy và hướng dẫn chúng em làm bài tập lớn môn Quản lý
dự án phần mềm trong học kỳ này.
Chúng tôi cũng gửi lời cảm ơn tới các bạn học viên lớp Quản lý dự án đã có những
ý kiến đóng góp giá trị cùng những lời động viên khích lệ khi thực hiện tiểu luận này.
Hà Nội, ngày 31 tháng 03 năm 2013
Học viên nhóm 2
Trần Thị Hiền
Nguyễn Anh Khiêm*
Phan Thị Luân
Phạm Đức Mạnh
Nguyễn Thị Yến
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
BẢNG PHÂN CÔNG CÔNG VIỆC

S
TT
Họ và tên Nội dung công việc
1
1
Trần Thị Hiền
Tìm hiểu các kiến thức chung về Agile
Viết báo cáo
2
2
Nguyễn Anh Khiêm
Tổng hợp các kiến thức chung về Agile
Viết báo cáo và thiết kế Slide
3
3
Phan Thị Luân
Tìm hiểu các kiến thức chung về Agile
Viết báo cáo
4
4
Phạm Đức Mạnh
Tìm hiểu về sự phát triển của Agile
Thiết kế Slide
5
5
Nguyễn Thị Yến
Tổng hợp các kiến thức chung về Agile
Viết và chỉnh sửa báo cáo
3
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN

MỤC LỤC
2.3 Quản lý dự án theo phương pháp Agile 13
1. Sự thỏa mãn của khách hàng 24
2. Thích nghi với việc thay đổi yêu cầu 25
3. Bàn giao sản phẩm thường xuyên 25
4. Làm việc cùng nhau thường xuyên 25
5. Xây dựng dự án cùng các cá nhân cầu tiến 26
6. Giao tiếp mặt đối mặt 26
7. Đo tiến độ dự án bằng khả năng thực thi của phần mềm 26
8. Giữ tốc độ phát triển ứng dụng một cách ổn định 27
9. Chú ý đến sự phát triển của công nghệ 27
10. Đạt đến sự đơn giản là điều thiết yếu phải làm 27
11. Tự tổ chức 27
12. Phản ánh và Điều chỉnh 28
TÀI LIỆU THAM KHẢO 30
4
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
DANH MỤC CÁC HÌNH VẼ
Hình 1: Mô hình thác nước 7
Hình 2: Mô hình thác nước mở rộng 8
Hình 3: Mô hình chữ V 8
Hình 4: Mô hình Prototype 8
Hình 5: Mô hình xoắn ốc 9
Hình 6: Mô hình lãnh đạo và quản lý 17
5
DANH MỤC TỪ VIẾT TẮT
Từ viết tắt Giải thích
Agile Agile software development
APM Agile Project Management
ID Interative Development

BDD Behavior Driven Development
TDD Test Driven Development
DDD Domain Driven Design
5
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
XÁC ĐỊNH VAI TRÒ & TRÁCH NHIỆM CỦA QUẢN LÝ AGILE
Với phương pháp phát triển phần mềm truyền thống là “waterfall” hay “RUP”,
thời gian hoàn thiện hay nâng cấp một phiên bản phần mềm thường kéo dài gần một
năm trời như Windows hay nhiều phần mềm khác, thường một năm thậm chí hơn, các
công ty mới cho ra một bản nâng cấp.
Với phần mềm được phát triển theo Agile tiêu biểu như Chrome, một năm, trình
duyệt này cho ra vài ba bản nâng cấp. Thậm chí chỉ mất một tuần để cho ra sản phẩm
đầu tiên rồi một tuần sau lại ra một bản cập nhật, cứ liên tục như vậy. Với xu hướng
mobile hóa như hiện nay, phát triển phần mềm ứng dụng theo Agile là rất phù hợp để
nhanh có sản phẩm đưa ra thị trường.
Quy trình quản lý dự án phần mềm: 7 bước.
B1: Định nghĩa bài toán.
B2: Phân tích
B3: Thiết kế
B4: Lập trình.
B5: Tích hợp hệ thống.
B6: Nghiệm thu.
B7: Vận hành.
1. Giới thiệu phát triển lặp:
Là một kiểu phát triển phần
mềm mà chu trình sống của phần
mềm được chia thành các vòng
lặp liên tiếp nhau.
Ví dụ: Giả sử sau khi nghiên
cứu yêu cầu từ phía khách hàng, ta

thống kê được phần mềm có tổng
cộng 50 chức năng. Giả sử ta
chọn 2 trong số 50 chức năng
trên, ước lượng thời gian thực
hiện 2 chức năng đó trong vòng khoảng 2 tuần chẳng hạn, để thực hiện hoàn chỉnh. Ta
xây dựng phần mềm hoàn chỉnh phần mềm với chỉ 2 chức năng đó, rồi chuyển cho
khách hàng sử dụng và đánh giá. Sau đó, khách hàng sẽ đưa ra đánh giá về 2 chức năng
mà ta đã làm. Giả sử trong 2 chức năng đó, có 1 chức năng chưa hoàn chỉnh hoặc chưa
6
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
đáp ứng đúng yêu cầu khách hàng, ta giữ lại chức năng đó cùng với những đánh giá của
khách hàng. Tiếp theo trong 48 chức năng còn lại, ta lại chọn ra 3 chức năng nữa, cộng
với chức năng cũ là thành 4 chức năng và ước lượng thời gian hoàn thành trong vòng 2
tuần. Ta lại xây dựng phần mềm hoàn thiện với chỉ 4 chức năng đó. Sau khi xây dựng
xong, ta lại đưa cho khách hàng chạy thử và xem phản hồi, đánh giá từ khách hàng. Tiếp
tục ta lại chọn ra thêm 10 chức năng nữa để xây dựng, và ước lượng thời gian hoàn
thành trong vòng cũng 2 tuần. Càng ngày ta có thể xây dựng phần mềm càng nhanh vì ta
đã gần như nắm bắt được hệ thống, càng ngày càng có kinh nghiệm xây dựng các chức
năng cho hệ thống đó. Theo đó, ta sẽ chọn thời gian cho mỗi vòng lặp là cứ 2 tuần. Hệ
thống của chúng ta từ nhỏ, sẽ to dần to dần cho đến khi hoàn tất tất cả chức năng mà
khách hàng yêu cầu.
Mục tiêu của mỗi vòng lặp là một hệ thống được xây dựng, kiểm thử cẩn thận,
chạy ổn định và có thể đưa vào sử dụng.
Mỗi vòng lặp đều gồm các bước phân tích yêu cầu, thiết kế, phát triển, tích hợp (có
thể ban đầu chúng ta chưa cần thực hiện bước này), kiểm thử và vận hành, chuyển giao
cho khách hàng sử dụng và nhận phản hồi. Kết quả của mỗi vòng lặp là một release
hoàn chỉnh, và release sau phải bao gồm cả release trước đó chứ không phải là release
độc lập.
Điểm khác biệt so với những mô hình cổ điển (water fall, V model…)
Hình 1 : Mô hình thác nước

7
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Hình 2 : Mô hình thác nước mở rộng
Hình 3 : Mô hình chữ V
Hình 4: Mô hình Prototype
8
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Hình 5: Mô hình xoắn ốc
Chẳng hạn ta có phần mềm phát triển trong vòng 2 năm:
- Nếu phát triển theo water fall: ta có thể thực hiện việc phân tích yêu cầu trong
vòng 3 tháng, thiết kế hệ thống trong vòng 3 tháng, phát triển trong vòng 1 năm và bảo
trì trong vòng 6 tháng còn lại.
- Nếu phát triển theo phát triển lặp: 3 tuần đầu thực hiện phân tích yêu cầu của 2
chức năng, sau đó thiết kế hệ thống và phát triển hoàn thiện 2 chức năng đó, kiểm thử và
chuyển cho khách hàng sử dụng và đánh giá. Trong 3 tuần tiếp theo, ta thực hiện phân
tích yêu cầu của 5 chức năng khác, sau đó thiết kế hệ thống và phát triển 5 chức năng
này, kiểm thử và lại chuyển giao cho khách hàng sử dụng và đánh giá. Quá trình này cứ
lặp đi lặp lại, công việc trong mỗi vòng lặp tương tự nhau. 3 tuần đầu chúng ta vẫn có
phần phân tích yêu cầu, 3 tuần kế tiếp vẫn có phần phân tích yêu cầu,… cho đến 3 tuần
cuối cùng của 2 năm ta vẫn có phần phân tích yêu cầu. Đối với water fall, việc phân tích
yêu cầu chỉ xảy ra ở 3 tháng đầu tiên, qua thời gian này là đã chuyển sang bước khác.
Khái niệm “time-boxed” trong phát triển lặp: có nghĩa là chúng ta cố định thời
gian kết thúc 1 vòng lặp.
Khái niệm trên nghe có vẻ đơn giản nhưng
chúng ta cần lưu ý như sau. Quay trở lại “tam
giác chất lượng”, ta có 4 thành phần ảnh hưởng
đến dự án, đó là yêu cầu của khách hàng, thứ 2
là chất lượng của dự án, thứ 3 là nguồn lực mà
chúng ta có, và cuối cùng là thời gian. Vậy
“time-boxed” ở đây có ý nghĩa gì? Ở đây, nó có

nghĩa rằng chúng ta cố định phần thời gian thực
9
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
hiện (chẳng hạn như 5 ngày, sau 5 ngày yêu cầu phải cho ra 1 hệ thống nhỏ), ta có thể
thay đổi các yếu tố khác. Chẳng hạn, trong 5 ngày yêu cầu thực hiện 20 tính năng của
phần mềm, nhưng vào thời điểm đó, các yếu tố khác không đủ để đáp ứng yêu cầu này,
và ta phải giảm 1 đỉnh của tam giác lại, chẳng hạn ta đề xuất giảm xuống còn 10 tính
năng để làm sao sau 5 ngày cho ra được hệ thống. Hoặc là với 20 tính năng đó, với
nguồn nhân lực hiện tại không đủ đáp ứng được, có thể đề xuất thêm người vào làm để
đảm bảo sau 5 ngày cho ra được hệ thống. 3 cạnh của tam giác có thể thay đổi nhưng
đỉnh thời gian không thay đổi, cố định.
Khái niệm phát triển tiến hóa và thích nghi trong phát triển lặp:
Chẳng hạn ta chia dự án ra thành 10 vòng lặp, mỗi vòng lặp 3 tuần, yêu cầu khách
hàng đưa ra là 100 chức năng. Ở vòng lặp đầu tiên, giả sử ta hiểu được 20% yêu cầu và
phát triển được hệ thống hoàn thiện đáp ứng 20% yêu cầu đó với 2 chức năng. Đến vòng
lặp tiếp theo, giả sử ta hiểu được thêm 10% yêu cầu và phát triển được thêm 3 chức
năng (cộng với 2 chức năng đã làm ở vòng lặp trước nữa là thành 5 chức năng, tức 5%).
Đến vòng lặp sau, ta hiểu được thêm 20% yêu cầu và phát triển được thêm 3 chức năng
nữa. Đến vòng lặp thứ 4, giả sử ta hiểu được thêm 40% yêu cầu và làm được thêm 2
chức năng nữa. Sang vòng lặp thứ 5, ta dừng việc phân tích yêu cầu, mặc dù còn 10%
yêu cầu ta chưa hiểu nó ra sao, ta tập trung phát triển thêm 10 chức năng nữa cho hệ
thống. Khi đó, hệ thống hiện tại có 20 chức năng. Sau đó, giả sử ở vòng lặp thứ 6, ta
không phát triển hệ thống nữa mà tập trung phân tích 10% yêu cầu còn lại của khách
hàng, khi đó ta đã hiểu hết các yêu cầu mà khách hàng đưa ra. Sang những vòng lặp tiếp
theo, ta cứ việc phát triển hệ thống để hoàn thiện các chức năng còn lại.
10
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
* Điểm đặc trưng của phát triển lặp:
- Ban đầu yêu cầu cùa khách hàng không phải lúc nào cũng rõ ràng, khó mà xác
định “đúng” được. Thay vì bỏ ra một khoảng thời gian để xác định hết yêu cầu của

khách hàng, chúng ta có thể phát triển dần dần, từ từ hiểu yêu cầu của khách hàng. Khi
áp dụng phát triển lặp, đối với khách hàng đó là điều tốt vì nó làm tăng độ tin cậy của
khách hàng đối với sản phẩm (sau mỗi vòng lặp, sản phẩm đưa ra đó là hệ thống, phần
mềm hoàn chỉnh cho dù chức năng còn ít và khách hàng có thể biết được sản phầm của
mình nó như thế nào).
- Khách hàng có thể thay đổi yêu cầu bất cứ lúc nào, và phát triển lặp được đưa ra
để đáp ứng việc này.
- Trở ngại lớn nhất của phát triển lặp đó là việc ước lượng, định giá cho dự án, bởi
vì chúng ta sẽ không có yêu cầu từ đầu, do đó cũng sẽ không có thiết kế ngay từ đầu. Ở
những vòng lập đầu tiên, việc ước lượng có thể cho sai số gấp 3 lần bình thường .
Nhưng càng về sau, sai số sẽ ngày càng nhỏ đi.
2. Agile Development
Agile là một mô hình phát triển phần mềm kế thừa từ phát triển lặp.
2.1 Khái niệm: là phương pháp phát triển lặp cố định thời gian của từng vòng lặp, đưa
ra các sản phẩm (release) theo hướng tiến hóa dần, có kế hoạch thích hợp (không phải
cố định), sẵn sàng cho mọi sự thay đổi nếu có xảy ra.
(P/S: phát triển lặp có thể không cần cố định về thời gian.)
* Bốn khái niệm (đặc điểm) quan trọng trong phát triển Agile:
11
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
- Con người và sự tương tác giữa người với người đặt lên trên quy trình và công cụ
sử dụng: có nghĩa là quy trình hiện tại là như vậy nhưng ta hoàn toàn có thể thay đổi nó
một chút (thêm phần này, bớt phần kia).
- Phần mềm làm việc thay cho tài liệu phức tạp: trọng tâm của phát triển Agile đó
là sản phẩm đưa ra (có thể nhảy vào coding vẫn được miễn là code đúng, code chạy;
không cần thiết kế vẫn được).
- Việc tương tác với khách hàng đặt lên trên các hợp đồng, thương thảo: như đã nói
ở phần trên, thì sau mỗi vòng lặp chúng ta sẽ chuyển giao cho khách hàng sản phẩm để
nhận phản hồi, đánh giá từ khách hàng.
- Sẵn sàng cho sự thay đổi thay vì theo như kế hoạch nhất định.

2.2 Quá trình vận hành Agile:
Đầu tiên là phải xác định vấn đề phải giải quyết cho phần mềm, sau đó đưa ra các
khái niệm, ý tưởng để giải quyết vấn đề đó. Tiếp theo, chúng ta đưa ra chứng minh cho
khách hàng xem là ta có thể thực hiện được (proof of concept) – không nên thiên về kỹ
thuật nên hướng về phần nghiệp vụ nhiều hơn. Đây là bước quan trọng bắt buộc khi phát
triển theo Agile. Sau khi 2 bên đã đồng ý và ký kết hợp đồng xong, chúng ta sẽ bắt đầu
đi vào quy trình phát triển phần mềm. Quy trình phát triển phần mềm trong Agile tương
tự như khi phát triển lặp nhưng không hoàn toàn là phát triển lặp.
Như đã trình bày ở trên thì Agile không tập trung vào các yêu cầu, tài liệu. Vậy
làm sao chúng ta biết và nắm yêu cầu của khách hàng? Trong Agile có 1 khái niệm đó
là Story.
Một dự án bao gồm rất nhiều story được xếp theo thứ tự mức độ ưu tiên. Khi phát
triển phần mềm, chúng ta phải lấy theo thứ tự độ ưu tiên giảm dần.
Phương pháp quản trị dự án Agile đang được nhiều doanh nghiệp phần mềm Việt
Nam nghiên cứu triển khai. Tại Việt Nam, hai năm gần đây, nhiều công ty phần mềm
bắt đầu chú ý tới phương pháp này vì giúp rút ngắn quá trình phát triển một phần mềm,
nhanh có sản phẩm đưa ra thị trường, tối ưu hóa đầu tư.
Khái niệm phát triển phần mềm linh hoạt (agile software development - gọi tắt là
agile) là một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên
12
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
các nguyên tắc, theo đó nhu cầu và giải pháp thông qua sự hợp tác giữa các nhóm với
nhau.
Theo quan niệm truyền thống: một dự án phần mềm được coi là thành công khi sản
phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách
hàng. Tuy nhiên trên thực tế nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc
vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích hoặc không
mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng.
Phương pháp Agile là phương pháp quản trị dự án linh hoạt, giúp một dự án
ngoài việc đạt các yếu tố truyền thống nói trên còn thỏa mãn ba tiêu chí: Thành công ở

mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty.
Triết lí Agile gồm 4 điểm:
 Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.
 Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.
 Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.
 Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn.
Dự án phát triển phần mềm tiêu biểu trên thế giới theo phương pháp Agile là
Chrome với khả năng cập nhật phiên bản mới liên tục. Trước năm 2011, Agile ở Việt
Nam chưa được quan tâm nhiều.
Các công ty khó tìm kiếm các chuyên gia am hiểu Agile để phát triển các sản phẩm
của riêng họ hoặc đáp ứng yêu cầu của khách hàng về mặt phương pháp luận. Hiện nay,
càng nhiều doanh nghiệp Việt Nam có xu hướng phát triển phần mềm theo phương pháp
này.
2.3 Quản lý dự án theo phương pháp Agile
Lãnh đạo và quản lý là hai hệ thống hành động đặc biệt và bổ xung cho nhau. Mỗi
hoạt động có chức năng và đặc trưng riêng. Cả hai đều cần thiết cho sự thành công trong
môi trường kinh doanh ngày nay.
Như đã nêu trong chương 1 “Định nghĩa quản lý dự án Agile”, ngoài Scum,
phương pháp Agile không xác định rõ vai trò của quản lý dự án. Có lẽ sự thiếu rõ ràng
phát sinh từ thực tế không có thỏa thuận chung (phổ biến) trong ngành công nghiệp như
những gì ý nghĩa của tiêu đề “Quản lý dự án”. Tôi đã thấy nó được sử dụng khác nhau
bao gồm cả hai và loại trừ chức năng cũng như kiến trúc kỹ thuật, quá trình phát triển
quản lý, quản lý nhân sự, quản lý dự án, quản lý thay đổi, đánh giá hiệu quả, theo dõi dự
án, kế toán và ngân sách. Mặc dù sự mâu thuẫn này nó đã được kinh nghiệm của tôi mà
quản lý dự án được định nghĩa là những cá nhân chịu trách nhiệm xây dựng và nhóm
13
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
lãnh đạo chịu trách nhiệm cho thành công hay thất bại của họ- nó đóng vai trò quan
trọng trong việc cung cấp giá trị kinh doanh. Chương này giới thiệu vai trò như vậy của
một cá nhân – người quản lý Agile – người chịu trách nhiệm cho việc cung cấp giá trị

kinh doanh. Các dự án sử dụng phương pháp phát triển phần mềm Agile. Nó cũng có vai
trò yêu cầu và các kỹ năng và giá trị cơ bản.
2.4 Vai trò của người quản lý Agile
Vai trò của người quản lý Agile là để lãnh đạo việc cung cấp các giá trị kinh doanh
dự án Agile bằng cách thiết lập các nguyên tắc và thực hành APM (Agile Project
Management) và các cá nhân thể hiện giá trị APM (được mô tả sau trong chương này).
Bảng 2-4 cho thấy trách nhiệm khác nhau cần thiết để thực hiện vai trò này có
liên quan đến các nguyên tắc và thực hành APM.
Bảng 2-4. Vai trò và trách nhiệm của người quản lý Agile
QUẢN LÝ DỰ ÁN AGILE
Thực
hành
APM
Lãnh đạo Quản lý
Hướng dẫn nguyên tắc 1: Thúc đẩy sự liên kết và hợp tác
Đội cơ
hữu
• Thúc đẩy sự khéo léo của phần
mềm.
• Bồi dưỡng đội ngũ cộng tác
• Hình thức là hướng dẫn hợp tác
• Triển khai chính thức
• Các nhóm làm việc
• Xác định các nhóm dự án
• Thiết kế cấu trúc hình thức ba chiều
• Nhóm người làm việc có tính kỷ luật
tự giác
• Đề xuất một doanh nghiệp đáp ứng
công nghệ.
Hướng

dẫn tầm
nhìn
• Phát triển tầm nhìn của đội
• Giới hạn đội
• Hình dung một tương lai tốt
đẹp
• Tạo và duy trì các mong đợi
được chia sẻ.
• Khám phá kết quả kinh doanh
• Phân chia phạm vi dễ dàng
• Ước tính mức độ cố gắng(nỗ lực)
• Thiết kế một hộp tầm nhìn
• Xây dựng một trạng thái thang máy
Hướng dẫn nguyên tắc 2: Khuyến khích sự xuất hiện và tự tổ chức
Quy luật
đơn giản
• Tranh thủ đội ngũ cho sự thay
đổi
• Tập trung vào kinh doanh
• Đánh giá thực trạng
• Điều chỉnh các phương pháp
• Xây dựng một bản kế hoạch/các chức
14
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
năng còn tồn đọng.
• Xây dựng kế hoạch lặp lặp lại/ những
việc còn tồn đọng.
• Tạo điều kiện thuận lợi cho phần
mềm phát triển, mã lệnh, kiểm thử, và
triển khai.

• Tiến hành chấp nhân thử nghiệm.
• Quản lý phát hành phần mềm
Thông
tin mở
• Tích cực thực hiện cuộc họp
hàng ngày.
• Khuyến khích thông tin phản
hồi
• Xây dựng niềm tin
• Liên kết ngôn ngữ với thành
viên.
• Cái chung giữa các thành viên trong
nhóm.
• Đàm phán với khách hàng đại diện
trên trang web.
• Ghép nối các phần lại với nhau
• Khuyến khích sử dụng các thông tin
tản nhiệt
• Sơ đồ dòng giá trị của dự án
Ánh
sáng
cảm ứng
• Phù hợp với tình hình phong
cách của bạn.
• Hỗ trợ việc di chuyển của
lãnh đạo.
• Tìm hiểu để đi với dòng chảy
• Duy trì chất lượng làm việc
cuộc sống
• Xây dựng trên thế mạnh của

cá nhân
• Quản lý các cam kết thông
qua tương tác cá nhân.
• Kiểm soát phân cấp.
• Thiết lập một nhiệm vụ kéo quản lý
hệ thống.
• Quản lý các dòng chảy
• Sử dụng hành động chạy nước rút.
Hướng dẫn nguyên tắc 3: Việc nghiên cứu (học tập) và thích ứng (thiết lập)
Thiết lập
lãnh đạo
• Trau dồi một sự hiện diện
được thể hiện
• Thực hành việc học đã được
thể hiện.
• Nhận cộng đồng bằng thông tin
phản hồi hàng ngày.
• Giám sát và thích ứng các quy tắc
đơn giản.
• Giám sát các thực hành APM
• Thường xuyên tiến hành phản ánh
về dự án
15
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
• Thực hiện kịch bản lập kế hoạch
Trách nhiệm của người quản lý Agile được thể hiện trong bảng 2-4: được chia làm
hai loại trách nhiệm lãnh đạo và trách nhiệm quản lý. Tại sao lại có sự khác biệt này?
Mặc dù lãnh đạo và quản lý đôi khi được sử dụng để thay thế cho nhau, họ tham khảo
khác nhau như bên mô tả.
Người lãnh đạo hay quản lý họ mất gì?

Lãnh đạo là vẽ hoặc hướng dẫn người khác bằng ảnh hưởng của họ. Mục đích
chính của lãnh đạo là đối phó với sự thay đổi. Các nhà lãnh đạo có ảnh hưởng đến hành
vi bằng nhiều phong cách khác tùy thuộc vào các tính riêng của họ. Lãnh đạo tốt mang
lại những điều tốt nhất với mọi người bằng cách đối xử với họ như những cá nhân đầy
đủ, sau đó thay vì chỉ đơn thuần là nhân viên , mặt khác , quản lý đề cập đến chính phủ
hoặc quản lý các công việc của dự án. Mục đích chính của quản lý là đối phó với sự
phức tạp. Theo dõi tiến độ, báo cáo tình trạng, tiến hành các cuộc họp, duy trì ngân sách,
thiết lập mục tiêu, và cung cấp đánh giá hiệu suất là ví dụ về các nhiệm vụ được định
hướng của quản lý. Quản lý tốt nhấn mạnh các tính hợp lý và kiểm soát trong việc đưa
kỹ thuật và trật tự phức tạp vốn có trong kinh doanh môi trường toàn cầu hiện nay. Mặc
dù quản lý và lãnh đạo là khác nhau, chúng bổ xung một cách khác nhau: Lãnh đạo cho
phép người quản lý Agile có ảnh hưởng đến mọi người về chỉ đạo hành vi của họ đến
những kết quả mong muốn và quản lý cho phép mình tổ chức dự án và quản lý sự phức
tạp của nó. Hình 6 minh họa sự bổ xung cân bằng này.
Kỹ năng quản lý và lãnh đạo cả hai đều quan trọng đối với người quản lý Agile để
tu luyện. Nếu không có quản lý, lãnh đạo mất một thành viên quan trọng. Có lãnh đạo
mà không có quản lý dẫn đến đội của họ sẽ thiếu sự phối hợp thích hợp như thủ tục báo
cáo không đầy đủ, và lập kế hoạch không đầy đủ. Có quản lý mà không có lãnh đạo sẽ
dẫn đến mất mát về tâm hồn của đội, quản lý không thể hình thành rõ rệt đội của họ,
giao tiếp hiệu quả với họ, và kết nối đủ với cá nhân ở mức độ khuyến khích họ.
16
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Hình 6. Lãnh đạo và quản lý (trích từ Bellinger 2004)
Cùng với nhau, các yêu cầu được kết hợp với vai trò lãnh đạo và quản lý có vẻ
cực kỳ khó khăn. May mắn thay mặc dù vai trò của người quản lý là quan trọng, những
không có nghĩa họ là lãnh đạo duy nhất của dự án.
2.5 Chia sẻ trách nhiệm quản lý
Để phù hợp với các đặc tính bình đẳng của phương pháp Agile, trách nhiệm của cả
lãnh đạo và quản lý được chia sẻ giữa người quản lý Agile, nhân viên kỹ thuật, khách
hàng và tất cả các thành viên khác trong đội dự án. Điều này chia sẻ trách nhiệm quản lý

dịch để được chia sẻ trách nhiệm cho việc thiết lập nguyên tắc APM và thực hành, minh
họa bảng 2-4
Bảng 2-5. Trách nhiệm quản lý được chia sẻ
Nguyên tắc APM Thực hành APM Trách nhiệm
Thúc đẩy sự liên kết
và hợp tác
• Tổ chức các đội
• Hướng dẫn các
phiên bản
• Người quản lý Agile chịu trách nhiệm
chính
• Người quản lý Agile, huấn luận viên
kỹ thuật, khách hàng, đội.
Khuyến khích sự
xuất hiện và tự tổ
chức
• Các quy luật đơn
giản
• Thông tin mở
• Light Touch
• Người quản lý Agile, huấn luận viên
kỹ thuật, khách hàng, đội.
• Người quản lý Agile chịu trách nhiệm
chính
• Người quản lý Agile chịu trách nhiệm
chính
Việc nghiên cứu học
tập và thiết lập
• Thiết lập lãnh
đạo

• Người quản lý Agile chịu trách nhiệm
chính
Như đã thể hiện trong kiểu chữ in đậm, người quản lý Agile có trách nhiệm chính
về các thực hành: Các tổ chức nhóm, thông tin mở, Light Touch và thiết lập lãnh đạo.
Đỗi với các thực hành khác, người lãnh đạo Agile là người có trách nhiệm được
xác định và giao tiếp yêu cầu cụ thể cho các thành viên khác tong nhóm và chịu trách
nhiệm với họ để thực hiện công việc, vai trò của người quản lý được thảo luận trong
phần tiếp theo.
17
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
2.6 Vai trò khác của quản lý
APM quy định ba vai trò đó cũng là trách nhiệm quản lý và bổ xung hỗ trợ người
quản lý Agile. Đó là vai trò cá nhân cho khách hàng, chủ sở hữu sản phẩm và huấn
luyện viên kỹ thuật và vai trò tập thể cho mỗi đội.
Khách hàng/ chủ sở hữu sản phẩm thường chịu trách nhiệm hướng dẫn kinh
doanh trong hình thức định nghĩa kết quả kinh doanh và tính năng định nghĩa và chấp
nhận. Người này có thẩm quyền cuối cùng và chịu trách nhiệm cho kế hoạch đã thực
hiện hoặc chức năng này còn lại bao gồm:
- Chủ sở hữu các chức năng còn lại/ kế hoạch đã thực hiện
- Xác định các yêu cầu chức năng cũng như các tính năng
- Làm việc với huấn luận viên kỹ thuật và các nhà phát triển các tính năng, nhiệm
vụ ưu tiên
- Cung cấp làm rõ và cuối cùng nói về các yêu cầu
- Chấp nhận tính năng cung cấp vào cuối mỗi lần lặp
Các huấn luyện viên kỹ thuật đưa ra các khía cạnh kỹ thuật của sản phẩm hoặc
thiết kế sản phẩm và phát triển. Người này có trách nhiệm liên quan chủ yếu đến việc áp
dụng các kỹ thuật thực hành, xây dựng kỷ luật về kỹ thuật và tư vấn các nhà phát triển
khác bao gồm:
- Chỉ đạo thiết kế và phát triển ứng dụng
- Thực hành phần mềm thủ công và huấn luyện và cố vấn các nhà phát triển khác.

- Chỉ đạo việc thực hiện thực hành kỹ thuật (tức là lập trình cặp, thiết kế đơn giản,
tái cấu trúc, kiểm tra- điều khiển phát triển…).
- Cung cấp tiếng nói cuỗi cùng về kiến trúc kỹ thuật.
- Sở hữu trách nhiệm cuối cùng cho việc phần mã mỗi lần lặp.
Tất cả các thành viên trong đội được dự kiến là kỷ luật tự giác và tự hướng đến
một mức độ lớn. Họ có trách nhiệm thực hiện các hoạt động của họ với sự giám sát tối
thiểu và tự tối đa như:
- Mở rộng các kỹ năng của họ, bên ngoài chuyên môn của họ để đảm nhận nhiều
vai trò.
- Áp dụng kỷ luật tự giác để hoàn thành công việc một cách kịp thời.
- Phối hợp với các thành viên khác trong tinh thần đồng đội.
- Kéo nhiệm vụ mới từ kế hoạch còn tồn đọng/ kế hoạch lặp lại khi họ hoàn thành
nhiệm vụ.
- Nâng cao các vấn đề trong lĩnh vực hàng ngày và sự phản ánh của dự án
- Duy trì về sự liên tục thông báo tiến độ làm việc của nhóm.
18
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Có thể sắp xếp công việc của lãnh đạo được phân phối trong các đội dự án? Mặc
dù sự lôi cuốn của lãnh đạo thường nắm bắt được ý tưởng chung, thực tế là lãnh đạo tồn
tại trong một số các hình thức trên đội dự án rất tốt. Người quản lý dự án truyền cảm
hứng cho đội của họ với một tầm nhìn chung và các đại biểu và trao quyền cho đội của
họ, cung cấp tầm nhìn của nhà lãnh đạo. Huấn luận viên kỹ thuật dẫn đầu bằng ví dụ;
kiến trúc và thực hiện các giải pháp sáng tạo trong việc phân phối với các đội của họ là
lãnh đạo. Khách hàng cung cấp chuyên môn kinh doanh và chức năng sản xuất sản
phẩm linh hoạt là lãnh đạo. Dĩ nhiên, các nhà phát triển có tay nghề cao và các nhà phân
tích đưa ra khởi tạo chuyên môn xác minh trong phân phối hệ thống là những nhà lãnh
đạo cung cấp. Một nhóm Agile do đó bao gồm nhiều lãnh đạo, người quản lý Agile cần
nhận biết khởi tạo và luyện mô hình phân phối hay hợp tác trong khi vẫn chịu trách
nhiệm cuối cùng cho dự án. Sắp xếp như thế nào là phù hợp nhất cho những hoạt động
trong môi trường Agile hợp tác với các trách nhiệm cụ thể này? Loại kỹ năng mà cá

nhân nào cần ở đây? Một dự án cho quản lý Agile vạch ra các giá trị và kỹ năng cần
cho giả thiết rằng những trách nhiệm này tiếp tục được bảo đảm.
2.7 Hồ sơ của người quản lý dự án
Kiểu hoạt động Agile ban đầu liên quan đến việc chấp nhận tính bất định và tính
phức tạp: sau đó chỉ là những nhà quản lý Agile có thể trở nên có kỹ năng để thích nghi
với sự thay đổi. Khi vượt qua trở ngại ban đầu này, kiểu agile cũng yêu cầu xây dựng
những mỗi quan hệ gần gũi hơn và mạnh mẽ hơn với những nhà tài trợ dự án, các bên
liên quan, các khách hàng mà tập trung vào kết quả kinh doanh và giá trị khách hàng
kiểu hình. Nói chung những nhà quản lý agile cần hài lòng với:
- Phân tích trước mắt hạn chế và lập kế hoạch chi tiết hạn chế
- Sự cấp bách và phấn khích được áp đặt bởi phân khúc làm việc thường xuyên và
cung cấp từng bước
- Chia sẻ thẩm quyền với huấn luyện viên kỹ thuật và các thành viên khác trong
đội
- Tăng cường giao tiếp và những mối quan hệ với các nhà tài trợ dự án, các bên
liên quan và các khách hàng
- Huấn luyện cá nhân và cố vấn cho các thành viên trong đội
- Không ngừng định hướng giá trị khách hàng
Như đã mô tả trong phần tiếp theo, những nhu cầu này yêu cầu một dự án cho
quản lý Agile bao gồm một cam kết mạnh mẽ cho các giá trị nền tảng (cơ sở) và sự cân
bằng kỹ năng lãnh đạo và kỹ năng quản lý.
Các giá trị cá nhân: Trong cuốn “Từ xây dựng đến tồn tại”, Collins và Porras đã
củng cố ý tưởng rằng các công ty có tầm nhìn cả phân biệt được các giá trị cốt lõi vượt
19
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
thời gian của họ và kiên trì mục đích từ hoạt động thực tế và các chiến lược kinh doanh.
Họ thay đổi sau để thích nghi với mọi thế giới đang thay đổi, nhưng giữ vững nền tảng
trước đây của họ. Các chiến lược và thực hành khác nhau giữa các phương pháp agile/
hệ sinh thái – XP, Scrum, Crystal,… nhưng tuyên ngôn Agile đại diện cho một sự mạnh
mẽ, nền tảng được chia sẻ. Người quản lý Agile cần hỗ trợ các giá trị này và hành vi

nhiệm vụ của họ và phong cách trong 4 giá trị cá nhân cốt lõi. Những giá trị này là sự
tin tưởng, hợp tác, học tập và lòng can đảm.
Sự tin tưởng: Niềm tin là cốt lõi của tất cả các mối quan hệ chuyên gia hiệu quả.
Trong một môi trường Agile chính thức hơn, chi phí trong các quá trình được giảm
xuống tối thiểu, nó đóng một vai trò đặc biệt quan trọng. Một mức độ cao hơn của sự tin
tưởng phát triển khi tất cả các bên có thể hiểu và xác định với nhau. Đó là chắc chắn dễ
dàng hơn nhiều để phát triển các loại niềm tin vào người khác với những người mà
chúng tôi đã làm việc được một thời gian. Tuy nhiên môi trường năng động không đủ
khả năng thư giãn (sang trọng). Do đó APM đòi hỏi một thái độ “tin tưởng đầu tiên” rồi
có niềm tin ở mọi người cho đến khi được chứng minh và ngược lại.
Hợp tác: Mỗi quan hệ hợp tác giữa các doanh nghiệp, khách hàng, chuyên gia và
các lập trình viên, giữa các thành viên trong nhóm và người quản lý, giữa khách hàng và
nhà cung cấp dịch vụ tất cả đi kèm với ít nhất một mức độ nào đó của sự căng thẳng.
Trước khi nhà quản lý Agile có thể làm việc trên các đội ngũ cộng tác, họ cần phải hợp
tác giá trị bản thân. Điều này đòi hỏi một sự sẵn sàng làm việc với những người khác
trong mối quan hệ ngang, và sự hiểu biết và đánh giá cao giá trị của sự hợp tác. Để hỗ
trợ học tập và thích ứng trong nhóm của họ, quản lý Agile đòi hỏi một cam kết sâu sắc
cá nhân hay học tập của đội. Người quản lý Agile được yêu cầu để xác định văn hóa mà
cho phép sự tự do tới thất bại, nhưng với kỷ luật không nhanh và học hỏi từ những sai
lầm.
Điều này sắp xếp của việc học là trung tâm xử lý mạnh mẽ với không chắc chắn,
không rõ ràng và phức tạp.
Lòng can đảm: Đây là giá trị quan trọng nhất cho nhà quản lý Agile bởi vì có vị trí
duy nhất của họ, thường là từ cạnh tranh lợi ích và các nhóm, người quản lý dự án có
những áp lực bất thường, phải tham gia với nhu cầu của nhiều người khác. Vì người
quản lý Agile yêu cầu về sự can đảm để nói không với những nhu cầu nhân cơ hội này
để đối đầu với những thực tế khó chịu, đứng lên để quản lý cấp cao đại diện cho đội của
họ, để đối phó với những xung đột của đội và chấp nhận những lời chỉ trích và học hỏi
từ những sai lầm. Để dẫn dắt đội của họ có hiệu quả, nhà quản lý Agile cần phải trau rồi
bốn giá trị cá nhân từ kỹ năng lãnh đạo, quản lý.

2.8 Kỹ năng lãnh đạo - Đối phó với sự thay đổi.
20
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Lãnh đạo đi quá thực tế trong cuộc sống hàng ngày, các nhà quản lý Agile yêu cầu
kỹ năng lãnh đạo cần thiết để kết nối các nhu cầu và mong muốn của các thành viên
trong đội. Tichy và Devanna xác định một số các đặc điểm của chuyển đổi giữa các nhà
lãnh đạo , người chuyển đổi có hiệu quả trong tổ chức. Họ xác định tự bản thân họ cũng
như sự thay đổi Agents (đạo lý) họ can đảm tin tưởng vào mọi người, giá trị định hướng,
học suốt đời, có thể đối phó với sự mơ hồ phức tạp và chắc chắn. Và họ có cái nhìn xa
trông rộng. Những điều này được xây dựng từ một quan điểm APM trong phần dưới
đây.
Quản lý Agile Aspire để chuyển đổi từ lãnh đạo
Họ tự nhận mình là tác nhân thay đổi, APM yêu cầu mọi người liên tục đánh thức
mọi việc bằng nhiều cách. Nơi người khác có thể hành động để hạn chế sự lựa chọn và
duy trì tình trạng hiện tại. Người quản lý Agile cần phải tận dụng cơ hội cho sự thay đổi
khi tác nhân thay đổi, họ cũng cần hiểu rằng mọi người là chìa khóa để thay đổi và làm
việc tích cực để đạt được sự tin tưởng trước khi họ giới thiệu sự thay đổi.
Họ là những cá nhân can đảm, APM yêu cầu phải từ bỏ sự thoải mái của các
hành vi đã được học của quá khứ và nổi bật vào tương lai với lòng van đảm. Người quản
lý Agile cần can đảm để tin tưởng vào người khác hoàn thành công việc mà không có sự
can thiệp, dựa vào mọi người khi mà cổ phần đang cao và thời gian là tiền bạc, để mạo
hiểm với lãnh thổ mới, liên tục thách thức hiện trạng, và tiếp tục tạo sự thoải mái của
quá khứ và tương lai và định hướng tới tương lai.
Họ tin tưởng ở mọi người, APM yêu cầu như lãnh đạo người mà có thể liên quan
tới mọi người ở mức độ cá nhân. Họ phải tin tưởng vào mọi người họ làm việc tới điểm
mà họ có thể ban hành một số kiểm soát tương tự cho giá trị lớn hơn, truyền cảm hứng
và động viên các thành viên trong nhóm của họ.
Họ là những giá trị thúc đẩy, người quản lý Agile cần phải duy trì cao tiêu chuẩn
đạo đức.Thay vì được thúc đẩy họ cần phải giải quyết bởi tài chính đạt được, công nhận,
thậm chí họ cần phải tin tưởng vào giá trị của họ.

Họ là những người học suốt đời vì sự thay đổi hàng ngày của các dự án Agile, điều
này là cần thiết học tập cho sự sống còn, quản lý Agile cần phải yêu thích việc học tập.
Với những người khác có thể tìm cách chấp nhận và thậm chí vô tình tạo ra những vấn
đề bằng cách không đặt câu hỏi hành động của họ, các nhà quản lý Agile lạo cam kết để
phân tích những ảnh hưởng của mình và hành động của người khác.
Với những người khác tìm sự an ủi trong thói quen, các nhà quản lý Agile khám
phá và thử nghiệm để cải thiện liên tục. Họ có khả năng xử lý những vấn đề mơ hồ với
sự phức tạp không rõ ràng không chắc chắn và có thể gây ra sự sợ hãi, lo âu. Một số cá
21
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
nhân không thể tiến xa hơn với sự lo âu và sự tin tưởng vào hành động. Người quản lý
Agile cần có khả năng hành động dứt khoát không đầy đủ thông tin.
Họ là những người nhìn xa, trông rộng. Nhà lãnh đạo nhìn xa hơn quá khứ và hiện
tạo để phân định rõ ràng và phát triển các phiên bản cho tương lai. Như vậy quản lý
Agile cần tin tưởng vào phiên bản của họ đủ mạnh và rõ ràng, nó đủ tốt để gây ảnh
hưởng đến những người khác để chia sẻ nó và hành động cách thực hiện nó.
Người quản lý Agile cần những kỹ năng lãnh đạo mạnh mẽ và họ cần phải khao
khát chuyển đổi lãnh đạo như vừa được định nghĩa.
2.9 Kỹ năng quản lý – Xử lý phức tạp
Nhà quản lý Agile cần có khả năng xử lý phức tạp với tập trung thử nghiệm, phân
tích, phản hồi, và học tập. Đối với điều này họ đòi hỏi kỹ năng quản lý thích ứng. Quản
lý thích ứng là quá trình hệ thống của mô hình thử nghiệm, giám sát để so sánh các kết
quả của quản lý thay thế hành động. Quản lý thích ứng tìm cách làm giảm sự không
chắc chắn trong các môi trường phức tạp thông qua phương pháp, tiếp cận cảm giác
chung “học bằng cách làm và thử nghiệm”. Người quản lý Agile cần áp dụng quản lý
thích ứng để đối phó với sự phức tạp bằng cách phân loại : bắt chước cách tự nhiên xây
dựng hệ thống phức tạp từ dưới lên trong phần nhỏ hơn sau khi mỗi đoạn đã từng được
thể hiện chứng minh là có đủ khả năng hoạt động độc lập.
Phát triển phần mềm linh hoạt (Agile software development – gọi tắt là Agile) là
một nhóm các phương pháp và phương pháp luận phát triển phần mềm dựa trên các

nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trưởng (incremental) ra đời vào
đầu những năm 90 theo đó nhu cầu và giải pháp tiến hóa thông qua sự hợp tác giữa các
nhóm tự quản và liên chức năng. Agile thường sử dụng cách lập kế hoạch thích ứng
(adaptive planning) việc phát triển và chuyển giao theo hướng tiến hóa; sử dụng các
khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá
trình phát triển.
Thuật ngữ agile chính thức được sử dụng rộng rãi theo cách thống nhất kể từ khi
“Tuyên ngôn Agile” được giới thiệu ra công chúng năm 2001. Nhờ tính linh hoạt, đa
dạng và hiệu quả cao, các phương pháp agile ngày càng trở thành sự lựa chọn hàng đầu
của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. Agile ra đời đã
khắc phục được những yếu điểm của phương pháp Waterfall truyền thống.
22
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
3. Các đặc điểm của phương pháp Agile
1. Được phát triển dựa trên quy trình phát triển lặp (Interative Development) – Mỗi
dự án được chia thành nhiều mảng nhỏ, dễ sử dụng và sửa đổi khi yêu cầu của khách
hàng thay đổi. Dự án sẽ thực hiện từng phần nhỏ này như từng dự án nhỏ cho đến khi tất
cả các yêu cầu của khách hàng được đáp ứng và dự án được bàn giao.
2. Cứ mỗi khi bàn giao các phần nhỏ được hoàn thành (deliverable) cho khách
hàng, khách hàng có thể đưa ra các thay đổi hoặc các yêu cầu mới cho dự án. Theo đó,
nhóm phát triển phần mềm có thể cập nhật và sửa đổi sản phẩm theo đúng yêu cầu
khách hàng mà không nhất thiết phải thực hiện lại từ đầu.
3. Từng phẩn nhỏ của dự án được test ngay trong quá trình làm dự án bằng các
Unit test tương ứng bởi chính các lập trình viên thay vì các tester độc lập. Quá trình test
này được thực hiện trong quá trình phát triển trước khi tích hợp phần mềm.
4. Yêu cầu về việc gặp mặt trao đổi thông tin thường xuyên , cùng bàn bạc và
thống nhất để hoàn thành dự án đúng thời hạn, đồng thời cũng có sự tiếp xúc với khách
hàng thường xuyên để cập nhật những thay đổi về yêu cầu.
5. Vì các quá trình của Agile đều thực hiện với nhân lực hoàn toàn là các lập trình
viên trong nhóm ban đầu, nên yêu cầu về kĩ năng của các lập trình viên sẽ cao hơn và

phải có kinh nghiệm trong lập trình và kiểm thử .

23
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
Agile phù hợp với các dự án có đặc điểm sau:
 Mức độ rủi ro thấp.
 Thành viên nhóm có kinh nghiệm.
 Yêu cầu thay đổi thường xuyên.
 Kích thước nhóm nhỏ. Các thành viên làm việc cùng một
địa điểm.
Phương pháp này là rất tốt cho các dự án nhỏ có từ hai tới tám người cùng làm
việc và thường xuyên trao đổi với nhau. Khía cạnh then chốt của lập trình Agile là từng
thành viên trong nhóm làm nhiều điều từ giao tiếp với khách hàng, thu nhận yêu cầu,
thiết kế kiến trúc, cho tới thiết kế cụ thể, viết mã, và đưa sản phẩm ra thị trường. Phương
pháp Agile có thể không có hiệu quả trong môi trường của các dự án lớn hay các tích
hợp lớn, điển hình có sự tham gia của hàng trăm người làm việc cùng với nhau.
Vì Agile tập trung cho các dự án nhỏ và có thời gian hoàn tất ngắn, phương pháp
này đòi hỏi có những cá nhân tài năng, những người sẵn lòng làm mọi chuyện và có
năng lực tổng quát hóa, có thể làm qua nhiều công đoạn trong vòng đời truyền thống của
sản phẩm (phần mềm). Phương pháp Agile cần có các cá nhân đa năng, có động lực,
biết nghiên cứu, biết phân tích, biết sáng tạo, và có các kỹ năng giao tiếp cần thiết để
hiểu thấu các vấn đề của khách hàng. Họ cũng phải là những người làm việc nhóm có
tính kỹ luật, và là những kỹ sư phần mềm tài ba có thể cho ra đời sản phẩm đúng hạn
thời gian cho phép.
12 nguyên lý và kỹ thuật của Agile. Đây chỉ là bước đầu của việc tìm hiểu thế
giới của quy trình phát triển phần mềm.
1. Sự thỏa mãn của khách hàng
Tiêu chí cần sự ưu tiên cao nhất đó là sự thõa mãn của khách hàng ngay bằng cách
mang lại giá trị ngay từ ban đầu và liên tục như vậy, chứ không phải là một sản phần
phần mềm đày đủ tính năng. Điều này có nghĩa là, chúng ta đang phát triển phần mềm,

và thêm vào ít nhất một tính năng cho mỗi vòng đời của nó.
Hãy thử tượng tượng rằng, chúng ta cần tạo một blog, vì vậy chúng ta cần làm
những điều sau:
1. Tạo trang hiển thị nội dung blog, và mang lại cho khách hàng
2. Tạo tính năng quản lý người dùng, và mang lại cho khách hàng
3. Thêm vào tính năng comment và mang lại cho khách hàng
24