TÌM HIỂU về managing agile project

Hình 5: Mô hình xoắn ốcChẳ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 trongvòng 3 tháng, thiết kế hệ t

ĐẠ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ùngNhó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 đầu tiên chúng em xin cảm ơn thầy TS Trương Anh Hoàng và TS Phạm NgọcHù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

BẢNG PHÂN CÔNG CÔNG VIỆC

2 Nguyễn Anh Khiêm

Tổng hợp các kiến thức chung về AgileViết báo cáo và thiết kế Slide

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

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

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

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ộtnă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áccô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ìnhduyệ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ướngmobile 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

lặp liên tiếp nhau

Ví dụ: Giả sử sau khi nghiên

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 Taxâ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 chokhá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

đá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ủakhá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ộngvớ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 2tuầ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ựngxong, 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ếptụ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ànthà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ứcnă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 giaocho 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 releasehoà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

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

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 trongvò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ảotrì 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 2chứ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ântí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ăngnà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ầncuố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íchyê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ờigian kết thúc 1 vòng lặp

Khái niệm trên nghe có vẻ đơn giản nhưngchúng ta cần lưu ý như sau Quay trở lại “tamgiá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

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ủaphầ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ínhnă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ớinguồ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áchhà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ònglặ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ứcnă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ăngnữ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 2chứ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, takhô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áchhà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ếptheo, 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

* Đ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ủakhá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ủakhá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ầnmề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ủamì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:

- 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áckhái niệm, ý tưởng để giải quyết vấn đề đó Tiếp theo, chúng ta đưa ra chứng minh chokhá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áttriể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ậylà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 đó

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

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ớinhau.

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ảnphẩ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áchhà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ộcvẫ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ôngmang 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ệtNam 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ẩmcủ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ápnà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ỗihoạ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 trongmô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àngphá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ểnquả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

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ò quantrọ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ủamộ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ó vaitrò 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

• 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

• 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

• Tiến hành chấp nhân thử nghiệm.

• Xây dựng niềm tin

• Liên kết ngôn ngữ với thành

• Ghép nối các phần lại với nhau

• Khuyến khích sử dụng các thông tintản nhiệt

• Sơ đồ dòng giá trị của dự án

• 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ý

• 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

• Thực hiện kịch bản lập kế hoạchTrách nhiệm của người quản lý Agile được thể hiện trong bảng 2-4: được chia làmhai 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ảokhá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 đíchchí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 manglạ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 địnhhướ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 chophé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ọ đếnnhữ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ứctạ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áocá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ọ