ĐẠ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
STT
Họ và tên
Nội dung công việc
Trần Thị Hiền
11
Tìm hiểu các
kiến thức chung về
Agile
Viết báo cáo
22
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
Tìm hiểu các kiến thức chung về Agile
33
Phan Thị Luân
Viết báo cáo
Tìm hiểu về sự phát triển của Agile
44
Phạm Đức Mạnh
Thiết kế Slide
Tổng hợp các kiến thức chung về Agile
55
Nguyễn Thị Yến
Viết và chỉnh sửa báo cáo
4
TIỂU LUẬN MÔN HỌC QUẢN LÝ DỰ ÁN
MỤC LỤC
1. Giới thiệu phát triển lặp:........................................................................................6
2. Agile Development................................................................................................11
2.1 Khái niệm:........................................................................................................11
2.2 Quá trình vận hành Agile:.................................................................................12
2.3 Quản lý dự án theo phương pháp Agile............................................................13
2.4 Vai trò của người quản lý Agile........................................................................14
2.5 Chia sẻ trách nhiệm quản lý..............................................................................17
2.6 Vai trò khác của quản lý...................................................................................18
2.7 Hồ sơ của người quản lý dự án.........................................................................19
2.8 Kỹ năng lãnh đạo - Đối phó với sự thay đổi ....................................................21
2.9 Kỹ năng quản lý – Xử lý phức tạp....................................................................22
3. Các đặc điểm của phương pháp Agile.................................................................23
KẾT LUẬN ...............................................................................................................29
TÀI LIỆU THAM KHẢO..........................................................................................30
5
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
6
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
hữu
cơ
Hướng
dẫn tầm
nhìn
Thúc đẩy sự khéo léo của phần
Xác định các nhóm dự án
mềm.
Thiết kế cấu trúc hình thức ba chiều
Bồi dưỡng đội ngũ cộng tác
Nhóm người làm việc có tính kỷ luật
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
Phát triển tầm nhìn của đội
Khám phá kết quả kinh doanh
Giới hạn đội
Phân chia phạm vi dễ dàng
Hình dung một tương lai tốt
Ước tính mức độ cố gắng(nỗ lực)
đẹp
Thiết kế một hộp tầm nhìn
Tạo và duy trì các mong đợi
Xây dựng một trạng thái thang máy
tự giác
Đề xuất một doanh nghiệp đáp ứng
công nghệ.
được chia sẻ.
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.
Tích cực thực hiện cuộc họp
Tiến hành chấp nhân thử nghiệm.
Quản lý phát hành phần mềm
Cái chung giữa các thành viên trong
hàng ngày.
Thông
tin mở
Khuyến khích thông tin phản
nhóm.
hồi
trên trang web.
Xây dựng niềm tin
Ghép nối các phần lại với nhau
Liên kết ngôn ngữ với thành
Khuyến khích sử dụng các thông tin
viên.
Phù hợp với tình hình phong
cách của bạn.
tản nhiệt
Sơ đồ dòng giá trị của dự án
Kiểm soát phân cấp.
Thiết lập một nhiệm vụ kéo quản lý
Hỗ trợ việc di chuyển của
lãnh đạo.
Ánh
sáng
cảm ứng
Đàm phán với khách hàng đại diện
Tìm hiểu để đi với dòng chảy
Duy trì chất lượng làm việc
hệ thống.
Quản lý các dòng chảy
Sử dụng hành động chạy nước rút.
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.
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)
Trau dồi một sự hiện diện
được thể hiện
Thiết lập
lãnh đạo
Thực hành việc học đã được
Nhận cộng đồng bằng thông tin
phản hồi hàng ngày.
thể hiện.
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
Tổ chức các đội
Trách nhiệm
Thúc đẩy sự liên kết
và hợp tác
chính
Hướng dẫn các
phiên bản
Người quản lý Agile, huấn luận viên
kỹ thuật, khách hàng, đội.
Các quy luật đơn
giản
Khuyến khích sự
xuất hiện và tự tổ
chức
Người quản lý Agile chịu trách nhiệm
Người quản lý Agile, huấn luận viên
kỹ thuật, khách hàng, đội.
Thông tin mở
Light Touch
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
đạo
lập
lãnh
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
- Xem thêm -