Tải bản đầy đủ (.doc) (27 trang)

tìm hiểu mô hình phát triển agile

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (709.4 KB, 27 trang )

ĐẠI HỌC QUỐC GIA – HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
BÁO CÁO
MÔN HỌC: QUẢN LÝ DỰ ÁN PHẦN MỀM
ĐỀ TÀI: TÌM HIỂU MÔ HÌNH PHÁT TRIỂN AGILE
Giảng viên: TS. Trương Anh Hoàng - TS. Phạm Ngọc Hùng
Khóa: K18 CNPM - Nhóm 1
Học viên: Phạm Minh Tuấn
Phạm Hữu Bằng
Nguyễn Thúy Hồng
Trần Thị Hiên
Phạm Thị My
Mục lục
Giới thiệu 5
Phương pháp quản lý dự án 6
Cách tiếp cận theo phương pháp Agile 9
Đánh giá 22
Kết luận 25
Tài liệu tham khảo 27
2
Danh mục hình vẽ
Hình 1 - Phương pháp quản lý dự án Agile 5
Hình 2 - Mô hình phát triển thác nước 7
Hình 3 - Dự án như những hệ thống thích nghi phức hợp 12
Hình 4 - Ba tiêu chí đánh giá thành công của một dự án phần mềm 14
Hình 5 - Sơ đồ tổ chức nhóm làm việc 16
Hình 6 - Tầm nhìn chỉ đạo 17
Hình 7 - Các quy tắc đơn giản 19
Hình 8 - Thông tin mở trong phát triển dự án 20
Hình 9 - Quản lý theo hình thức nới lỏng 21
Hình 10 - Mô hình lãnh đạo trong quản lý dự án 22


Hình 11 - Quá trình thực hiện mô hình phát triển Scrum 23
Danh mục bảng
Bảng 1- So sánh ưu, nhược điểm của các mô hình phát triển phần mềm 25
3
TÌM HIỂU MÔ HÌNH PHÁT TRIỂN AGILE
Tóm tắt– “Phương pháp quản lý dự án Agile là một trong những phương pháp
quản lý dự án đang ngày một trở nên phổ biến và được nhiều người quan tâm.
Thay vì cách tiếp cận của nhiều phương pháp quản lý dự án khác, Agile là phương
pháp tiếp cận hướng tới giá trị khách hàng, bao gồm chuyển giao một sản phẩm
đúng yêu cầu khách hàng với một mức giá “hợp lý” tại thời điểm đúng như khách
hàng mong muốn.”
Từ khóa – Agile project management, project management methodology.
4
Giới thiệu
1. Đặt vấn đề
Quản lý dự án là một vấn đề khó và quản lý dự án phần mềm cũng luôn phải
đối mặt với những vấn đề chung và vấn đề đặc thù trong phạm trù của các dự án
phần mềm. Trong môi trường phát triển và biến động như hiện nay, các dự án phần
mềm luôn phải trả các chi phí lớn trong những vấn đề liên quan đến quản trị dự
án.Nếu trước kia nói đến dự án phần mềm thì người ta thường nghĩ đến quy trình
phức tạp và nhiều giai đoạn trải qua khoảng thời gian khá dài từ vài tháng đến vài
năm để hoàn thành dự án. Việc này dẫn đến chi phí phát triển các phần mềm bị đội
lên rất cao và thiếu tính cạnh tranh nên các phương pháp cũ dần dần chỉ còn được
áp dụng cho các dự án cụ thể, yêu cầu rõ ràng và dễ bảo trì.
Hình 1 - Phương pháp quản lý dự án Agile
Ngày nay, cùng với việc yêu cầu phát triển sản phẩm ngày càng chất lượng
nhưng cũng cần có tính cạnh tranh về thời gian và chi phí, các phương pháp mới ra
đời phải đáp ứng được tiêu chí là: nhanh chóng bàn giao được sản phẩm, tiếp xúc
thường xuyên để ghi nhận ý kiến khách hàng và quan trọng nhất là tạo ra sản phẩm
có tính cạnh tranh cao. Một trong các phương pháp quản lý dự án được đưa ra đó

cần kể đến phương pháp Agile.
Mô hình phát triển phần mềm linh hoạt Agile là một phương pháp Agile chủ
trương hướng tới một cách tiếp cận nhằm mục đích tránh việc lãng phí thời gian,
chi phí trong phát triển phần mềm và tăng cường sự đáp ứng với vấn đề thay đổi
trong quá trình phát triển phần mềm.Nó bao gồm nhiều rất nhiều phương pháp
luận, quy trình và thực nghiệm để hỗ trợ cho việc phát triển phần mềm trở nên
5
nhanh chóng và dễ dàng. Mục tiêu quan trọng nhất mà phương pháp Agile hướng
đến là “giá trị khách hàng”. Khi mà phương pháp Agile đã định ra rõ ràng khái
niệm “giá trị khách hàng” là gì thì tất cả các phương pháp luận hay quy trình bao
hàm trong nó sẽ được xây dựng để xoay quanh làm sao để đạt được nó.
Báo cáo được chia làm 5 phần:
− Phần được tiếp theo đây bằng cách làm rõ khái niệm “giá trị khách
hàng” và sự linh hoạt trong quản lý dự án mà phương pháp Agile hướng
đến.
− Phần trình bày tổng quan về triết lý và phương pháp luận của một số
phương pháp quản lý dự án khác nhau.
− Phần sẽ đi sâu hơn vào hướng tiếp cận cũng như chi tiết của phương
pháp Agile.
− Đưa ra ví dụ về mô hình phát triển Scrum và kết thúc đánh giá phương
pháp Agile so với một số phương pháp khác trong Phần IV.
− Kết luận của nhóm trong Phần .
2. Giá trị khách hàng
Giá trị khách hàng luôn là mục tiêu quan trọng nhất xuyên suốt phương pháp
luận và cách tiếp cận theo phương pháp quản lý Agile. Đối với mọi mô hình quản
lý dự án theo phương pháp Agile, giá trị khách hàng có thể hiểu là khách hàng luôn
muốn nhận được một sản phẩm như mong muốn với một giá cả hợp lý trong một
khoảng thời gian như mong đợi.Đối với phương pháp Agile, sản phầm như khách
hàng mong muốn là sản phẩm bao gồm một cách chính xác các thuộc tính như
khách hàng đưa ra.Giá cả hợp lý có thể được hiểu là một giá cả mà khách hàng

nghĩ rằng nó là một giá cả xứng đáng với sản phẩm được bàn giao.Cuối cùng,
khoảng thời gian cho phép cũng chính là điều khách hàng mong đợi. Đó là khái
niệm rõ ràng về “giá trị khách hàng” đối với phương pháp Agile.
Phương pháp quản lý dự án
Quản lý dự án là một khái niệm liên quan đến việc lập kế hoạch, tổ chức, thúc
đẩy và kiểm soát nguồn lực nhằm đạt được một mục tiêu cụ thể nào đó. Có hai
thách thức quan trọng nhất đối với quản lý dự án.Thách thức đầu tiên chính là làm
sao để đạt được tất cả mục tiêu của dự án với những ràng buộc của môi trường và
hoàn cảnh. Thách thức này bao gồm phạm vi của dự án, thời gian, chất lượng và
kinh phí. Thách thức thứ hai chính là làm sao để có thể tối ưu những cung cấp đầu
6
vào (có thể là giảm thiểu chi phí) và kết hợp chúng với những mục tiêu được định
sẵn.
Có rất nhiều cách tiếp cận đối với việc quản lý các hoạt động của dự án như lặp,
gia tăng, chia pha Trong phần này, nhóm chúng tôi sẽ điểm qua một số cách tiếp
cận hay được sử dụng trong thực tế.
3. Tiếp cận truyền thống
Cách tiếp cận theo dạng chia pha truyền thống hay gặp nhất (xuất hiện trong rất
nhiều các biến thể khác) chỉ ra một chuỗi các bước thực hiện dự án cần được hoàn
thành để hoàn thành dự án. Các bước đó có thể được liệt kê ra dưới đây:
- Bước 1: Khởi đầu
- Bước 2: Lập kế hoạch và thiết kế
- Bước 3: Thực thi và xây dựng / triển khai
- Bước 4: Giám sát và điều khiển hệ thống
- Bước 5: Kết thúc dự án
Tuy nhiên, trong thực tế, mỗi dự án có thể có những tiến hóa khác nhau. Đối
với các dự án không thành công thì có thể sẽ được hủy trước cả bước kết thúc dự
án. Nhiều dự án khác lại có thể thực hiện Bước 2, 3, 4 lặp đi lặp lại đến khi dự án
thành công (đạt được những mục tiêu đã đặt ra của dự án).Phụ thuộc vào những
lĩnh vực khác nhau, cách tiếp cận này có thể có những tên gọi cũng như nội dung

tương ứng thích hợp khác nhau. Đối với các dự án phần mềm, cách tiếp cận này
thường được biết đến với tên gọi mô hình thác nước (waterfall).
Hình 2 - Mô hình phát triển thác nước
7
Tuy nhiên, đã có nhiều nghiên cứu cũng như thống kê gần đây đã chỉ ra mô
hình thác nước thường chỉ thành công đối với những dự án cỡ nhỏ, hoặc những dự
án được đề xuất với một hiểu biết sâu sắc từ phía khách hàng cũng như đơn vị triển
khai. Còn đối với những dự án có kích thước lớn, mô hình thác nước thường thất
bại hoặc đem lại chi phí quản lý dự án rất lớn. Nhược điểm lớn nhất của mô hình
thác nước chính là không cho phép có sự thay đổi trong quá trình thực hiện dự án,
những thay đổi càng xuất hiện muộn trong vòng đời dự án thì càng phải trả giá lớn
về tiền bạc và thời gian.
4. PRINCE2
PRINCE2 là cách tiếp cận có cấu trúc được giới thiệu vào năm 1996.PRINCE2
là sự kết hợp giữa phương pháp PROMPT và MITP.Ưu điểm của PRINCE2 là
cung cấp một bộ khung tiêu chuẩn để quản lý các dự án. PRINCE2 mô tả những
quy trình để phối hợp giữa con người và các hoạt động dự án, hay nói cách là là
phương pháp để thiết kế và giám sát dự án. Tuy nhiên, mô hình PRINCE2 cũng
gặp nhược điểm khi đề cao vai trò của giám sát trong dự án nhằm đạt được các
mục tiêu đề ra của dự án. Con người tham gia trong dự án có thể sẽ chịu nhiều áp
lực khi dự án được thực hiện. Chính điều này đôi khi làm các dự án sa đà quá
nhiều vào vấn đề giám sát, chi phí của dự án sẽ được đưa nhiều vào hoạt động
giám sát trong khi giá trị khách hàng mới là điều nên được quan tâm nhiều nhất.
5. CCPM
Quản lý Chuổi dự án quan trọng (CCPM) là một phương pháp lập kế hoạch và
quản lý dự án đặt trọng tâm chính trên các nguồn lực cần thiết để thực hiện nhiệm
vụ dự án. Được phát triển bởi Eliyahu M. Goldratt. Một chuỗi mạng dự án quan
trọng sẽ có xu hướng giữ nguồn tài nguyên quá tải, nhưng sẽ đòi hỏi họ phải được
linh hoạt trong thời gian bắt đầu của họ và để nhanh chóng chuyển đổi giữa các tác
vụ và các chuỗi công việc để giữ cho toàn bộ dự án đúng tiến độ.

6. Quản lý dự án linh hoạt (Agile)
Quản lý dự án linh hoạt dựa trên cơ sở các nguyên tắc về quản lý tương tác con
người. Phương pháp Agile thường được sử dụng nhiều trong môi trường công
nghiệp phần mềm, website, công nghệ, sáng tạo hoặc quảng cáo – những môi
trường thường có sự thay đổi liên tục, đòi hỏi sự thích ứng liên tục và đạt được
những giá trị cho khách hàng tốt nhất có thể.
8
Cách tiếp cận theo phương pháp Agile
7. Bản tuyên ngôn cho phương pháp phát triển phần mềm linh hoạt Agile
a. Lịch sử ra đời của tuyên ngôn
Tháng 2 năm 2001 , 17 nhà phát triển phần mềm đã họp mặt tại khu trượt
tuyết Snowbird , Utah và đưa ra Tuyên ngôn Phương pháp phát triển phần mềm
linh hoạt (Agile Manifesto). Tuyên ngôn gồm 4 điểm :
o Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.
o Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.
o Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.
o Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn.
b. 12 nguyên tắc của mô hình Agile
o Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản
phẩm sớm và liên tục.
o Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai
đoạn cuối.
o Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt
hơn chu kì dài.
o Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau
hàng ngày.
o Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ.
o Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.
o Các chức năng đã họat động là thước đo chính cho tiến độ dự án.
o Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản

lí…phải có khả năng tham gia dự án một cách liên tục.
o Liên tục cải tiến chất lượng thiết kế và mã nguồn.
o Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt.
o Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự
chủ.
o Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến
hiệu quả công việc.
9
8. Cơ sở phương pháp Agile
Để hiểu hơn về phương pháp Agile, dưới đây là một số kỹ thuật cơ bản được sử
dụng xuyên suốt trong phương pháp luận cũng như quy trình của Agile.
− Phát hành các phiên bản nhỏ của chương trình (hoặc hệ thống). Dự án được
chia làm nhiều thành phần nhỏ với mục đích dễ quản lý về độ phức tạp cũng
như làm sao để nhận được phản hồi từ khách hàng và người dùng cuối nhanh
nhất có thể. Các phiên bản thường được bàn giao trong khoảng 1 đến 3
tháng.
− Đây là phương pháp phát triển lặp và tăng dần. Các dự án được quản lý theo
phương pháp Agile được chia làm nhiều vòng lặp nhỏ. Mỗi vòng lặp đều bao
gồm đầy đủ các bước như lập kế hoạch, đặc tả yêu cầu, thiết kế, viết mã
nguồn và kiểm thử. Như vậy, phương pháp Agile sẽ gồm nhiều vòng lặp,
trong đó mỗi vòng lặp đã có đầy đủ các pha như mô hình “thác nước”
(waterfall). Tùy theo đặc thù của các dự án phần mềm và theo yêu cầu của
khách hàng, mỗi vòng lặp có thể tương ứng với một hoặc một vài chức năng
mới hoặc chức năng được cải tiến.
− Tùy theo tính chất của dự án, khoảng thời gian của một vòng lặp trong các
dự án sử dụng phương pháp Agile có thể là từ 2 tuần đến 1 tháng. Người
quản trị dự án có thể cân nhắc dựa trên nhiều yếu tố khác nhau như thời gian
lặp càng ngắn thì số phiên bản của chương trình (hoặc hệ thống) sẽ càng
nhiều và đồng thời sẽ có càng nhiều phản hồi (góp ý) từ khách hàng và
người dùng cuối. Nhưng ngược lại thời gian lặp càng ngắn thì áp lực lên tất

cả các thành viên dự án cũng như việc lập kế hoạch tổng thể dự án sẽ phức
tạp hơn. Chính vì thế, đối với phương pháp Agile, việc cân đối thời gian lặp
là một trong những nhiệm vụ quan trọng của người quan trị dự án.
− Khác với nhiều mô hình khác như mô hình thác nước, phương pháp Agile
đòi hỏi sự tập trung cao độ của tất cả thành viên dự án, các bên liên quan đến
dự án, khách hàng và đôi khi là cả người dùng cuối. Bởi mỗi vòng lặp có thể
chỉ diễn ra trong vỏn vẹn 2 tuần, trong 2 tuần đó sẽ luôn đòi hỏi sự có mặt
của tất cả các cá nhân liên quan. Việc kết nối qua thư điện tử, điện thoại, gặp
10
mặt, tổ chức họp sẽ liên tục được thúc đẩy để tăng tính tương tác với tất cả
thành viên liên quan đến dự án.
− Thích hợp với những dự án phần mềm mà bản thân khách hàng đôi khi cũng
chưa hoàn toàn hiểu về ý tưởng và mong muốn. Sản phẩm của họ sẽ được
tiến hóa và ngày một hoàn thiện hơn thông qua từng vòng lặp của dự án.
Theo thời gian, ý tưởng ban đầu của khách hàng sẽ ngày một rõ ràng và gần
với mong muốn hơn. Như vậy, phương pháp Agile có thể giúp tối ưu sự thỏa
mãn và hài lòng của khách hàng (bởi mỗi phiên bản tương ứng với mỗi vòng
lặp sẽ chỉ được thực hiện khi nhận được sự đồng ý của khách hàng) với
những chi phí ít tốn kém và sự thực thi đơn giản hiệu quả.
− Việc lựa chọn tính năng nào để phát triển là hoàn toàn tùy theo mong muốn
của khách hàng. Những tính năng được yêu cầu và được xếp loại mức độ ưu
từ cao xuống thấp. Việc xếp loại mức độ ưu tiên được thực hiện bởi sự cộng
tác với các nhà phát triển và khách hàng dựa trên lý thuyết trò chơi (mục
đích là tối đa hóa lợi ích của cả 2 bên và tối thiểu hóa rủi ro của đối tác). Các
nhà phát triển dự tính khả năng cố gắng của họ để hoàn thành chức năng cần
thiết trong khi khách hàng quyết định độ cần thiết trong nghiệp vụ của chức
năng.
− Do đó, mô hình Agile yêu cầu tính hợp tác trong nhóm làm việc rất cao và
rất cần sự đóng góp, chia sẻ giữa các thành viên vì mục đích hoàn thành dự
án. Mô hình làm việc theo cặp được áp dụng theo nguyên lý các nhà phát

triển và cả các người khác thực hiện công việc theo nhóm 2 người để tăng sự
cộng tác cũng như chia sẻ kiến thức và nâng cao chất lượng sản phẩm.
− Phát triển phần mềm dựa trên phát triển hướng kiểm thử (test-driven
development). Các nhà phát triển viết các kịch bản kiểm thử trước khi họ
viết mã nguồn và thay đổi, tiến hóa mã nguồn để sao cho mã nguồn thỏa
mãn được các test case. Thay vì thẩm định tính hợp lệ của mã nguồn thì thực
hiện các kịch bản kiểm thử sẽ nâng cao chất lượng và độ tin cậy đối với sản
phẩm. Quá trình này gồm các bước sau:
o Viết một test case đơn giản nhất trước.
o Cài đặt class/method ở mức tối giản nhất để có thể vượt qua test
case đó.
11
o Tối ưu hóa mã nguồn.
o Bổ sung test case mới và lặp lại quá trình cho đến khi tất cả các yêu
cầu được thỏa mãn.
9. Quản lý dự án linh hoạt
Quản lí dự án linh hoạt (Agile Project Management – APM) là công việc tiếp
thêm năng lượng, nâng cao vị thế và cho phép các đội dự án bằng cách nhanh nhất
và đáng tin cậy nhất để chuyển giao những sản phẩm thương mại thông qua việc
tương tác khách hàng và liên tục học hỏi và thích ứng với những thay đổi về yêu
cầu và môi trường của khách hàng.
Phương pháp Agile coi các dự án như những hệ thống sống hay còn gọi là
những hệ thống thích nghi phức hợp (Complex Adaptive Systems - CAS). Trong
đó sẽ bao gồm nhiều tác nhân tự động, tương tác qua lại lẫn nhau theo nhiều cách
khác nhau. Sự tương tác của mỗi tác nhân riêng lẻ được giám sát bởi các quy tắc
đơn giản và nội tại và đặc tả bởi các phản hồi cố định. Trật tực phức hợp phát sinh
từ chính nội tại của hệ thống chứ không phải do sự áp đặt từ phía ngoài. Những hệ
thống thích nghi phức hợp này có khả năng thích nghi đối với những hoàn cảnh
khác nhau và với những môi trường khác nhau.
Hình 3 - Dự án như những hệ thống thích nghi phức hợp

Thực hiện dự án theo phương pháp Agile vai trò của người quản lí dự án cũng
thay đổi, thay vì bảo các thành viên trong đội làm gì thì họ phải tổ chức hướng dẫn
đội đáp ứng với những thay đổi. Họ có trách nhiệm cá nhân hơn với các thành viên
12
khác trong đội, có vai trò giám sát. Người quản lí là người chủ sản phẩm là người
làm việc chặt chẽ với khách hàng để quyết định cái gì sẽ được dựng và theo trật tự
nào. Người chủ sản phẩm xác định tính năng của sản phẩm, chọn khi nào phần
mềm sẽ được đưa ra và điều chỉnh các tính năng và ưu tiên khi cần.
10. Quy tắc APM
Cũng như mọi phương pháp khác, APM được xây dựng trên hai quan điểm
quan trọng: ở mức cơ bản thì APM cần đơn giản nhưng kiên định về mặt nguyên
tắc và giá trị, ở mức ứng dụng thì APM đưa ra một cách thực hiện linh hoạt trong
thực tiễn, có khả năng thích nghi tốt với sự thay đổi của môi trường và trong mọi
trường hợp. Với những quan điểm đó, APM dựa trên cơ sở các khái niệm về CAS
được nghiên cứu và đưa ra những nguyên tắc cơ bản cốt lõi như dưới đây:
- Thúc đẩy sự liên kết và hợp tác. Con người được coi là tác nhân chính ảnh
hưởng đến giá trị, sự thay đổi, học tập và thích nghi. Được chia sẻ tầm nhìn
giúp mọi người được liên kết và hành động vì mục tiêu chung. Khi mọi
người được liên kết chặt chẽ, sự cạnh tranh không lành mạnh sẽ được giảm
thiểu và sự hợp tác làm việc với nhau để cùng có lợi sẽ được đẩy mạnh.
- Khuyến khích sự xuất hiện và tự tổ chức. Quy trình và thực hành được
làm tối thiểu đơn giản. Con người tự tổ chức cung cấp giá trị kinh doanh lớn
nhất. Mô hình phức tạp bao gồm cả hành vi tự tổ chức và cấu trúc tối ưu,
xuất hiện từ tương tác gần giữa nhiều người theo các quy tắc đơn giản.
- Học tập và thích ứng. Thông tin phản hồi được sử dụng liên tục cho học
tập, thay đổi thích ứng và cải tiến.
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. 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.
Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là
thành công khi 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. Thành công ở mức cá nhân giúp kích
thích các thành viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì
và tiến hóa của sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà
13
nhóm mang lại cho công ty. Các phương pháp Agile giúp cho dự án phần mềm đạt
được ba thành công này.
Hình 4 - Ba tiêu chí đánh giá thành công của một dự án phần mềm
Thành công ở mức công ty: Agile nhằm đến việc tạo ra giá trị cho công ty
trong khi làm giảm chi phí. Đồng thời, Agile giúp sớm xác định các kì vọng đối
với sản phẩm đang được phát triển. Nhờ đó, những dự án không mang lại giá trị
như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty. Theo phương
pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với
đội dự án. Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển
trước và được đưa vào vận hành sớm nhất có thể. Các phiên bản mới với các tính
năng mới sẽ lần lượt được đưa thêm vào. Ngoài ra, Agile giúp tăng cường khả
năng giao tiếp giữa các thành viên trong nhóm. Chất lượng mã nguồn được cải tiến
liên tục. Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên.
Thành công về mặt kĩ thuật: Trong Extreme Programming, một phương pháp
tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau. Nhờ vậy, các chi tiết
quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai
người. Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống,
cho phép một phiên bản mới của phần mềm được phát hành bất cứ khi nào nó góp
thêm một giá trị đáng kể. Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một
chức năng trước khi chuyển sang chức năng tiếp theo. Bởi vậy, tiến độ công việc
được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay
đổi từ phía khách hàng. Ngoài ra, Extreme Programming cũng đề xuất những quy
tắc giúp tạo ra các thiết kế và các đọan mã tốt. Chẳng hạn, quy tắc “phát triển dựa

14
trên kiểm thử” (test-driven development) trợ giúp lập trình viên viết các chương
trình thực hiện đúng chức năng mong muốn.
Thành công về mặt cá nhân: Mỗi thành viên trong dự án Agile, dù ở bất kì
cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản
thân. Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của
mình đối với dự án được nâng cao, chẳng hạn trong việc ước lượng và lập kế
hoạch. Quyền tự chủ của đội dự án cũng được tăng cường. Các tester nhận thấy họ
có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm được các công việc lặp
lại một cách nhàm chán. Nhà quản lí dự án hài lòng vì kiểm soát được tiến độ công
việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng. Khách hàng,
người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều kiển được
hướng đi của dự án và các ý kiến được lắng nghe.Các nhà lãnh đạo cao cấp sẽ cảm
thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty.
Để đạt được ba thành công như vậy, chúng ta phải kể đến tập các quy tắc trong
phương pháp quản lý dự án phần mềm Agile. Kiểu quản lý dự án mềm dẻo, linh
hoạt Agile đã đưa ra một tập các quy tắc và các nhà quản lý dự án phải luôn luôn
tuân thủ các quy tắc đồng thời phải lựa chọn, sửa đổi cách thức thực hiện sao cho
phù hợp với vị trí cũng như quy mô của dự án. Các quy tắc đó là:
1. Các quy tắc tổ chức nhóm APM (The APM practices Organic Teams).
2. Tầm nhìn người lãnh đạo (Guiding Vision).
3. Các quy tắc đơn giản (Simple Rules).
4. Thông tin mở (Open Information).
5. Kiểm soát nới lỏng (Light Touch).
6. Sự lãnh đạo thích nghi (Adaptive Leadership).
Quy tắc 1: Tổ chức nhóm (Organic Teams): Quy tắc này cho phép kết nối và
phối hợp thông qua mối quan hệ chặt chẽ trên các nhóm nhỏ, linh hoạt.
Nhóm là một nhóm người làm việc chung với nhau nhằm mục đích điều hành
hay quản lý một công việc nào đó. Nhóm hoạt động có mục đích, có phối hợp, có
kế hoạch.

15
Hình 5 - Sơ đồ tổ chức nhóm làm việc
Sự tự tổ chức và thứ tự sắp xếp một phần là do kiểu tương tác đa dạng hoặc sự
phối hợp giữa thành viên trong dự án. Sự tự tổ chức dự án trong các nhóm nhỏ
được hiểu ngầm định là hình thức tương tác thấp và cũng có thể là nguyên nhân
gây ra các kiểu tương tác đa dạng của thành viên trong dự án. Thông thường các
nhóm được xây dựng theo một cấu trúc đặc biệt phụ thuộc vào nhiều yếu tố như
quy mô dự án, tính chất công việc của từng nhóm, nguồn nhân lực, chi phí, thời
gian…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 (title) 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 này 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” (command and control).
Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng (competency) 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.
Ví dụ, nhóm phát triển phần mềm bao gồm người phát triển phần mềm và các
nhà phân tích kinh doanh được lựa chọn theo chuyên môn của họ (J2EE, các dịch
vụ tài chính,…). Nếu cần nhiều công sức thì cần thêm nhiều nhân lực. Đây là cách
quản lý dự án máy móc, chắc chắn với cách quản lý này thì sẽ dẫn đến tình trạng
dư thừa một số bộ phận. Mỗi bộ phận được thiết kế ra để thực hiện một chức năng
riêng, và các bộ phận mở rộng được thêm vào hệ thống để tăng thêm khả năng
hoặc để khôi phục các bộ phận đang tồn tại. Với các dự án APM, các nhà quản lý
linh hoạt tìm kiếm để đưa ra chức năng dư thừa. Thay vì thêm các bộ phận dự
16
phòng (người phát triển, nhà phân tích kinh doanh…), các thành viên trong nhóm
đang tồn tại sẽ đảm nhận thêm các chức năng mở rộng. Như vậy, những thành viên
này không chỉ có kỹ năng trong lĩnh vực chuyên môn của họ mà còn giỏi trong các
lĩnh vực khác. Agile còn cho phép các thành viên được quay vòng hoặc cho phép
nhóm phối hợp tổ chức nhóm thành phần để thích ứng với sự thay đổi điều kiện

bên ngoài. Khi dự án yêu cầu kích thước nhóm lớn, sự tổ chức dự án tập trung vào
các nhóm nhỏ, bằng cách tổ chức các nhóm con làm việc đồng thời, đây là chiến
lược tốt nhất để đảm bảo cho việc mở rộng quy mô dự án.
Quy tắc 2: Tầm nhìn chỉ đạo (Guiding Vision): Tổ chức nhóm liên kết và chỉ
đạo với mô hình chia sẻ tinh thần
Hình 6 - Tầm nhìn chỉ đạo
Các nhà lãnh đạo phải là những người có tầm nhìn xa, những người có khả năng
dự báo trước những xu thế lớn, biến tầm nhìn trở thành hiện thực và luôn phát triển
các chiến lược và chiến thuật mới. Một tầm nhìn xa sẽ giúp người lãnh đạo vạch
trước những chiến lược hoạt động dài hạn, dự đoán trước những biến động có thể
xảy ra trong tương lai để chuẩn bị, tìm cách thích nghi và đón đầu cơ hội. Để làm
được điều này, họ cần phải có hiểu biết về các xu hướng hay các nghiên cứu và kỹ
năng mới nhất. Ngoài ra, người lãnh đạo phải xác định được tương lai, nhiệm vụ
và mục tiêu cụ thể của dự án đang cần triển khai. Tóm lại, khả năng lãnh đạo là
đỉnh điểm của nghệ thuật và khoa học lãnh đạo, vì nó làm cho những môn nghệ
thuật và tất cả công việc khác trở nên hữu dụng. Một trong những tố chất của nó
ngoài “tầm nhìn” là “trí thông minh xúc cảm”, đây là một kỹ năng có thể rèn luyện
được. Kỹ năng này được hiểu như là khả năng nhận biết, xác định thấu hiểu và
17
quản lý thành công cảm xúc của bản thân và của người khác, người lãnh đạo thấu
hiểu các tầng nấc cảm xúc và cách biểu hiện của họ thì mới có khả năng hiểu được
cảm xúc của người khác cũng như nhân viên dưới quyền. Kỹ năng này sẽ giúp ích
cho việc truyền cảm hứng, thúc đẩy, và định hướng mọi người thực hiện những
công việc, những điều mà họ mong muốn. Một người lãnh đạo thực sự phải biết
động viên, khuyến khích để nhân viên đạt được mục tiêu của tổ chức bằng chính
niềm say mê của mình.
Mô hình tinh thần (mental model) của con người chính là cơ chế của sự dự đoán
và thích ứng với những thay đổi. Một tầm nhìn phải thỏa mãn được câu hỏi
“Chúng ta muốn đạt được gì”. Do vậy, khi tầm nhìn của một dự án được chuyển
sang kiểu trình bày mục đích của dự án và truyền đạt tới tất cả các thành viên trong

nhóm, thì điều này sẽ giúp cho việc chia sẻ mô hình tinh thần cũng như chi phối
lớn đến hành vi của các thành viên trong khi họ thực hiện các nhiệm vụ của dự án.
Người lãnh đạo là người truyền cảm hứng cho nhân viên để nhân viên biết như thế
nào là tốt nhất và làm thế nào để đẩy nhanh tiến độ dự án. Nếu mọi người hào
hứng với ý tưởng của người lãnh đạo thì đó chính là bởi họ đã được người lãnh đạo
truyền cảm hứng.
Một ví dụ thực tế của quy tắc này đó là, tầm nhìn của Chủ tịch Hồ Chí Minh đã
đưa dân tộc Việt Nam chúng ta đi đến thành công trong công cuộc cách mạng giải
phóng dân tộc, giải phóng đất nước thoát khỏi cảnh nô lệ lầm than. Để làm được
điều này, Bác Hồ kính yêu của chúng ta phải có tầm nhìn xa trông rộng và ngoài ra
Người đã thành công trong việc chia sẻ mục tiêu chung của dân tộc tới những trái
tim và khối óc của mọi người dân.
Một ví dụ khác của quy tắc này là sự lãnh đạo của người chỉ huy trong quân đội
Mỹ. Người lính đều biết rằng lãnh đạo của họ không thể lúc nào cũng có mặt khắp
nơi. Vì vậy, các nhà lãnh đạo quân đội thiết lập rõ ràng nội dung chỉ đạo để dẫn
đường chỉ lối cho người lính giúp họ có thể thực hiện các hành động và các quyết
định trong khi mất phương hướng. Chính vì vậy, ngay cả khi nhiệm vụ đặt trên vai
của người cấp bậc thấp nhất thì người đó vẫn có thể gánh vác được nhiệm vụ.
Thông thường các kỹ thuật quản lý dự án yêu cầu phải tạo ra một kế hoạch chi
tiết cho từng đối tượng chuyên môn đối với mục đích của dự án. Không nhất thiết
phải đầu tư thời gian và công sức vào lập kế hoạch chi tiết nâng cao vì điều đó sẽ
thay đổi theo giả thiết và đầu vào thay đổi, các nhà quản lý năng động duy trì một
18
hướng đi đủ tốt. Điều đó có nghĩa là thay vì bố trí chi tiết kế hoạch dự án với các
nhiệm vụ chủ chốt, họ tập trung vào kết quả đầu ra mong muốn, và cho phép kế
hoạch và các nhiệm vụ liên quan của họ cần phải đạt được kết quả xuất hiện theo
thời gian.
Quy tắc 3: Các quy tắc đơn giản (Simple Rules): Thiết lập một tập quy tắc
đơn giản, tạo ra các quy tắc xử lý đối với nhóm.
Hình 7 - Các quy tắc đơn giản

Các phương pháp luận thường đi kèm với một tập đầy đủ các thành phần xử lý,
khuôn mẫu, chuyển giao và các quy tắc. Thông thường, các quy tắc thường quá
nghiêm khắc đến nỗi mà mọi người không thể tuân theo được tất cả các quy tắc đó.
Có một số quy tắc muốn có hiệu lực để mọi người bắt buộc phải tuân thủ thì
thường liên quan đến vấn đề tài chính. Đây thực sự là điều phản tác dụng. Đối với
các dự án APM, các thành viên trong nhóm tuân theo các quy tắc cơ bản (Simple
Rules).
Ví dụ về phương pháp luận linh động, các tiêu chuẩn thực tế của XP (Lập trình
cực hạn - Extreme programming) là một tập tốt các quy tắc cơ bản cho các dự
APM. Tập các quy tắc này được bắt đầu và được sự chấp thuận của tất cả các thành
viên trong nhóm, mặc dù nhóm có khả năng để thích nghi với các thực tế mà
không đang hoạt động hoặc phát sinh thêm các thực tế mới. Trong suốt dự án, nhà
quản lý linh động nhận biết các thực tế mà không tuân theo, cố gắng tìm kiếm
nguyên nhân tại sao không tuân theo được để từ đó có biện pháp khắc phục và loại
bỏ các rào cản thực tế để thực hiện.
19
Thông tin mở (Open Information): Thông tin được cung cấp và truy cập tự do
(không bị ràng buộc).
Ở các dự án linh động, thông tin là chất xúc tác cho sự thay đổi và thích ứng.
Tương tác giữa con người liên quan đến việc trao đổi thông tin liên tục. Sự phong
phú đa dạng của những tương tác giữa con người phụ thuộc phần lớn vào sự cởi
mở của thông tin.Đối với một đội ngũ linh động thì thông tin được mở và không bị
ràng buộc. Theo truyền thống, các nhà quản lý đã hạn chế sự mở và không bị ràng
buộc vì sợ rằng nó sẽ gây ra sự hỗn loạn. Tổ chức Silo cũng đã cản trở việc trao
đổi và mở thông tin miễn phí.Trên các dự án APM, trở ngại để trao đổi thông tin
do tổ chức silo được xác định và loại bỏ, giảm chu trình thời gian thông tin.
Hình 8 - Thông tin mở trong phát triển dự án
Luồng thông tin tự do và các thành viên trong nhóm được hưởng lợi từ sức
mạnh của dòng chảy không bị giới hạn này và trao đổi thông tin. Với mỗi người
tham gia trao dổi thông tin thì thông tin được chuyển đổi theo một cách nào đó –

kết quả của trao đổi.
Kiểm soát nới lỏng (LightTouch): Áp dụng kiểm soát thông minh để thúc đẩy
hơn trật tự xuất hiện và giá trị tối đa.
Quản lý truyền thống tập trung chủ yếu vào sự ổn định và kiểm soát dẫn đến
xây dựng các phương pháp, công cụ và áp dụng để cố gắng quản lý một thế giới
20
vốn đã không ổn định và không chắc chắn. Tuy nhiên, công cụ truyền thống đã thất
bại khi sự thất bại nhiệm vụ tuyến tính không dễ điều tiết quá trình mang tính chu
kỳ, và yêu cầu thường xuyên cập nhật để phản ánh thực tế sự thay đổi theo ngày
tháng và hoàn cảnh.Chính sự tập trung vào dạng kiểm soát như thế này đã làm mờ
mục đích kiểm soát ban đầu để tạo ra trật tự và phân phối giá trị.
Hình 9 - Quản lý theo hình thức nới lỏng
Vì thế một số nhà quản lý đã áp dụng kiểm soát nhiều hơn với hy vọng để cung
cấp đơn đặt hàng và giá trị. Tuy nhiên quan điểm này không tính được những điều
không chắc chắn vốn có trong thế giới thực. Những sự kiện bất ngờ có thể làm
hỏng những kế hoạch tốt nhất, chuyên gia không thích ứng tốt với quản lý vi
mô.Công cụ và kỹ thuật gặp những hạn chế khi sử dụng không hợp lý. Với cách
tiếp cận kiểm soát nới lỏng, các nhà quản lý thấy việc tăng việc kiểm soát không
làm giảm sự không chắc chắn, tăng trật tự và giá trị. Họ tiếp cận quản lý bằng cách
chấp nhận họ không thể biết mọi thứ và từ bỏ một số quyền kiểm soát để đạt được
trật tự và giá trị lớn hơn.
Sự lãnh đạo thích nghi (AdaptiveLeadership): Chỉ đạo dự án bằng cách liên
tục giám sát, học hỏi và thích nghi.
Sự sáng tạo và linh động nhất trong công việc của một đội thể hiện: có những
vấn đề xảy ra ở các khía cạnh không thể đoán trước sẽ chú trọng và giải quyết để
tránh rơi vào hỗn loạn. Lãnh đạo một nhóm bằng cách thiết lập một tầm nhìn định
21
hướng, nuôi dưỡng các đội nhỏ cơ hữu, thiết lập các quy tắc đơn giản, bảo vệ
thông tin mở và quản lý với một dạng kiểm soát lỏng là cực kỳ khó khăn.
Hình 10 - Mô hình lãnh đạo trong quản lý dự án

Sự lãnh đạo thích nghi liên quan đến việc liên tục quan sát và đánh giá thực
tiễn, phân tích để cho kết quả mong muốn, và thực hiện chúng với tác dụng tối đa.
Sự lãnh đạo thích nghi cũng đòi hỏi sự hiểu biết về các phần khác nhau của dự án
và lực lượng tự nhiên của nó. Người quản lý nhanh nhẹn hiểu những ảnh hưởng
của sự tương tác lẫn nhau giữa các bộ phận của dự án và điều tiết dự án bằng cách
liên tục giám sát các dự án, và không ngừng học hỏi để thích hợp với cách tiếp cận
của mình.
Đánh giá
a. Giới thiệu về mô hình phát triển Scrum
Scrum đó là một quy trình phát triển phần mềm theo mô hình linh hoạt (Agile).
Công nghệ Agile cung cấp rất nhiều phương pháp luận, quy trình và các thực
nghiệm để cho việc phát triển phần mềm trở nên nhanh chóng và dễ dàng. 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.
22
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.
Hình 11 - Quá trình thực hiện mô hình phát triển Scrum
Thành phần chính quan trọng của scrum là các role (vai trò) và các cuộc trao
đổi đánh giá. Có các role chính là:
o Product Owner: là người làm những công việc bắt đầu cho dự án, tạo ra các
yêu cầu trong quá trình phát triển dự án. Phân tích mục tiêu, giải phóng các
kế hoạch.
o Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích,
bảo vệ đội làm việc và loại bỏ các trở ngại.
Đội làm việc ở scrum: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có
rất nhiều đội, nhiều người tham gia. Sẽ không có những lập trình viên

(programmer), người thiết kế (designer), kiểm thử viên (tester),… thường thấy ở
các dự án phần mềm truyền thống.
Các đội làm việc sẽ tiến hành cài đặt các chức năng được mô tả trong bản yêu
cầu.Họ tự quản lý, tổ chức và điều chỉnh đội làm việc của mình sao cho hiệu quả
lớn nhất.Tất cả các thành viên có ảnh hưởng như nhau đến sự thành công hoặc thất
bại của toàn bộ hệ thống hoặc các hệ thống nhỏ hơn trong đó.
23
Với các phương pháp truyền thống, việc lập kế hoạch dự án (xác định những
việc cần làm và thời gian kế thúc) dựa trên kinh nghiệm chứ không phải là môi
trường làm trực tiếp. Và so với kế hoạch đó khi bắt tay vào xây dựng thì thường có
độ trễ nhất định. Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định
từ đầu về thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát
triển thực tế.
o Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác
định linh hoạt theo môi trường sử dụng thực tế.
o Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban
đầu.
o Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao
đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được
đặt lên mức cao.
o Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho
những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn
có những buổi họp đánh giá lại ở những vòng lặp phát triển.
o Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các
phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất
nhiều và đầu ra của sản phẩm rất nhanh. Và khi đi sai hướng, có thể hủy
ngay sprint đó để quay lại với bản kế hoạch.
b. So sánh mô hình phát triển Agile và một số mô hình phát triển kinh điển
Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn. Có
phần mềm dùng một vài năm cho pha khảo sát, tìm hiểu vấn đề. Những trường hợp

như thế này thường xảy ra do chưa có phần cứng phù hợp để xây dựng phần mềm,
hoặc cần phải tiến hành khá nhiều nghiên cứu để tìm ra thuật toán hiệu quả. Có sản
phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để bảo
trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu của khách hàng.
Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận
thấy rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì
sản phẩm cũ. Cho đến nay có rất nhiều mô hình vòng đời phần mềm được sử dụng
và mỗi loại thì đều có ưu, nhược điểm riêng. Từ mô hình thác nước với tính ổn
định và dễ đổ vỡ với sự thay đổi, đến mô hình xoắn ốc lặp theo từng giai đoạn. Tất
24
cả các mô hình kinh điển này đều có những ưu, nhược điểm riêng mà các mô hình
phát triển phần mềm hiện đại như Agile cần kế thừa và tránh gặp phải các sai lầm,
giảm thiểu rủi ro khi khách hàng thay đổi yêu cầu, giúp khách hàng có thể sử dụng
những phiên bản sớm nhất để có nhận xét, nhằm mục đích hướng khách hàng làm
trung tâm ngay từ những vòng lặp đầu tiên.
Đặc điểm Waterfall Spiral Scrum
Xác định các giai đoạn
phát triển
Bắt buộc Bắt buộc Chỉ có giai đoạn lập kế
hoạch và kết thúc
Sản phẩm cuối cùng Được xác định
trong quá trình
lập kế hoạch
Được xác định trong
quá trình lập kế
hoạch
Xác định trong quá
trình xây dựng dự án
Chi phí sản phẩm Được xác định
trong quá trình

lập kế hoạch
Thay đổi cục bộ Xác định trong quá
trình xây dựng dự án
Ngày hoàn thành sản
phẩm
Được xác định
trong quá trình
lập kế hoạch
Thay đổi cục bộ Xác định trong quá
trình xây dựng dự án
Đáp ứng với môi trường
sử dụng
Trong kế hoạch
ban đầu
Trong kế hoạch ban
đầu
Xuyên suốt từ kế hoạch
đến xây dựng và kết
thúc
Kinh nghiệm trao đổi Đào tạo trước cho
đến khi bắt tay
làm dự án
Đào tạo trước cho
đến khi bắt tay làm
dự án
Thực hiện trong quá
trình làm dự án
Khả năng thành công Thấp Trung bình thấp Cao
Bảng 1- So sánh ưu, nhược điểm của các mô hình phát triển phần mềm
Kết luận

Do tập trung quá nhiều vào vấn đề kiểm soát và chi phí, những phạm trù liên
quan đến giá trị khách hàng lại không được quan tâm thích đáng, và trong nhiều dự
án phần mềm đã xảy ra những lãng phí lớn về nhân lực và vật lực. Phương pháp
Agile được nghiên cứu với mục tiêu hướng tới giá trị khách hàng và giảm lãng phí
25

×