ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

QUẢN LÝ DỰ ÁN CHO KỸ SƯ
BÁO CÁO CASE STUDIES 12
GVHD: Nguyễn Thị Đức Nguyên

Thực hiện: Nhóm 12

Tên MSSV Phân công Hoàn
thành
(700%)
Nguyễn Tấn Đạt K1300794 Introduction & Traditional versus 100%
Agile Methods
Phạm Ngọc Thư K1304057 Applying Agile PM to Large 100%
Projects & Summary
Lê Văn Tây 21303572 Dịch, tóm tắt case, soạn ppt 100%
Nguyễn Viết Nam K1302457 SNAP SHOT FROM PRACTICE 100%
Tạ Công Khôi G1301910 Agile PM 100%
Nguyễn Ngọc Tuấn 21304565 Tra lời câu hỏi Case 100%
Nguyễn Đức Tuấn 41204276 Tra lời câu hỏi Case 100%

Tp Hồ Chí Minh, tháng 12 năm 2016

1
2
 GIỚI THIỆU VỀ PHƯƠNG PHÁP QUẢN LÝ DỰ ÁN AGILE

I/. Cơ sở lý thuyết:

1 - ý tưởng

1 - chiến lược

3 - cơ quan

4 - xác định dự án

5 - ước tính

6 - mạng lưới dự án

7 - quản lý rủi ro

8 - nguồn tài nguyên lịch trình và chi phí

9 - giảm thời gian

10 - khả năng lãnh đạo

11 - đội dự án

12 - gia công phần mềm

13 - quá trình giám sát

3
14 - dự án kết thúc

15 - Agile PM

Chúng tôi biết ít hơn về dự án hôm nay hơn bất cứ lúc nào trong tương lai.

-Chet Hendrickson

Khi bước vào thời kỳ quản lý dự án mới, nhiều chuyên gia công nhận rằng một
kiểu phù hợp cho tất cả dự án không đáp ứng nhu cầu của họ. Sự công nhận này
đặc biệt đúng đối với những người làm việc trên các dự án phần mềm và phát triển
sản phẩm, trong đó sản phẩm cuối cùng vẫn chưa được xác định và phát triển theo
thời gian. môi trường dự án này đòi hỏi sự linh hoạt và khả năng quản lý thay đổi
khi có thêm thông tin và địa điểm tìm kiếm. Bước vào quản lý dự án Agile (Agile
PM). Thay vì cố gắng để có kế hoạch toàn bộ như trước, Agile PM dựa vào gia
tăng, chu kỳ phát triển lặp đi lặp lại để hoàn thành dự án.

Ken Schwaber sử dụng sự tương đồng của việc xây dựng một ngôi nhà để giải
thích sự khác biệt giữa gia tăng, phát triển lặp lại và quản lý dự án truyền thống.
Phương pháp truyền thống sẽ là người mua không thể di chuyển vào trong nhà cho
đến khi toàn bộ ngôi nhà được hoàn thành. Phương pháp lặp đi lặp lại sẽ xây dựng
ngôi nhà từng phòng một. Các đường ống dẫn nước, điện, và cơ sở hạ tầng sẽ được
xây dựng cho các phòng quan trọng nhất (như là bếp) đầu tiên và sau đó mở rộng
đến từng phòng như đã định. Mỗi một căn phòng được hoàn thành, những người
xây dựng và người mua sẽ đánh giá tiến độ và thực hiện điều chỉnh. Trong một số
trường hợp, người mua sẽ nhận ra rằng họ không cần them, họ cảm thấy đã thỏa
mãn. Trong trường hợp khác, họ sẽ thêm tính năng mà họ đã không nhận ra rằng
họ cần phải có. Cuối cùng ngôi nhà được xây dựng để phù hợp với mong muốn của
khách hàng.

Agile PM rất lý tưởng cho các dự án thăm dò, trong đó yêu cầu cần phải được phát
hiện và công nghệ mới được thử nghiệm. Nó tập trung vào sự hợp tác tích cực giữa
các nhóm dự án và đại diện khách hàng, phân tách các dự án thành chức năng nhỏ,
và thích ứng với yêu cầu thay đổi. Trong khi nguyên tắc phát triển lặp đi lặp lại đã
được khoảng một thời gian, chỉ mới gần đây phương pháp Agile đã ăn sâu trong
nghề quản lý dự án.

4
Trong chương này, các nguyên tắc cốt lõi của Agile PM sẽ được thảo luận và so
sánh với các phương pháp quản lý dự án truyền thống. Một phương pháp nhanh cụ
thể gọi là Scrum được sử dụng để mô tả các nguyên tắc trong hành động. Chương
này kết thúc với một cuộc thảo luận về những hạn chế và quan tâm. Mục tiêu
không phải là để đưa ra một mục toàn diện của tất cả các phương pháp kết hợp với
Agile PM nhưng để cung cấp một nền tảng trên cách làm việc nhanh nhẹn.

Phương pháp truyền thống với Phương pháp Agile

phương pháp tiếp cận truyền thống để quản lý dự án tập trung duy trì vững chắc
trên toàn diện kế hoạch lên từ trước. Lý do là nếu bạn có kế hoạch, thực hiện kế
hoạch của mình, và thực hiện khắc phục trên độ lệch so với kế hoạch, bạn có một
xác suất thành công cao. Khi phạm vi dự án đã được thiết lập vững chắc, từng chi
tiết của dự án được xác định thông qua WBS. Hầu hết các vấn đề và rủi ro được
xác định và đánh giá trước khi dự án bắt đầu. Các ước tính được thực hiện, nguồn
lực được giao, điều chỉnh được thực hiện, và cuối cùng là một lịch trình cơ bản và
ngân sách được tạo ra. Kiểm soát các dự án là một sự so sánh kế hoạch so với hành
động thực tế và khắc phục để phục hồi lại kế hoạch.

quản lý dự án truyền thống đòi hỏi một mức độ khá cao khả năng dự báo có hiệu
quả. Đối với kế hoạch được quản lý hữu dụng cần phải có một ý tưởng vững chắc
vào những gì đang được thực hiện và làm thế nào để làm điều đó. Ví dụ, khi nói
đến xây dựng một cây cầu bắc qua một con sông, các kỹ sư có thể vẽ trên công
nghệ và thiết kế nguyên tắc đã được chứng minh để lập kế hoạch và thực hiện dự
án. Không phải tất cả các dự án được hưởng sự chắc chắn như vậy. Hình 17.1 nói
đến vấn đề này và thường được sử dụng để hỗ trợ việc sử dụng Agile PM.

Dự án không chắc thay đổi tùy theo mức độ phạm vi dự án được biết đến và ổn
định và các công nghệ được sử dụng đã biết và đã được chứng minh. Nhiều dự án,
như ví dụ cầu, cũng như các dự án xây dựng khác, các sự kiện, mở rộng sản phẩm,
các chiến dịch tiếp thị, ..v.v có phạm vi thành lập tốt và sử dụng công nghệ đã
được chứng minh để cung cấp một mức độ dự đoán cho việc lập kế hoạch hiệu quả.
Tuy nhiên, khi phạm vi dự án và / hoặc công nghệ không được biết đầy đủ, mọi thứ
dự đoán được trở nên ít hơn nhiều. Ví dụ, dự án phát triển phần mềm, là tiếng xấu
của việc đi làm muộn và vượt ngân sách, thường liên quan đến nhiều khách hàng
khác nhau với các nhu cầu khác nhau. Những nhu cầu thường xuyên thay đổi và

5
thường khó nói rõ. Trong nhiều trường hợp, khách hàng chỉ bắt đầu hiểu những gì
họ thực sự mong muốn khi chúng được cung cấp với sự mô tả một ai đó về những
gì họ muốn. Dưới những điều kiện này dự án sẽ rất khó khăn nếu không sẽ vô ích
để phát triển một danh sách chi tiết các yêu cầu về phạm vi lúc khởi động dự án.

Công nghệ có thể là một nguồn không thể dự đoán. Ví dụ, một nhóm phát triển sạc
với thiết kế xe điện thế hệ tiếp theo có thể biết họ xây dựng một chiếc xe với sức
chứa bốn người lớn thoải mái và đi hơn 200 dặm trước khi sạc, nhưng họ có thể
không biết nếu các công nghệ pin tồn tại để cấp nguồn cho chiếc xe. Một lần nữa
nó sẽ rất khó khăn để phát triển một kế hoạch đáng tin cậy khi những câu hỏi như
vậy tồn tại.

Điểm mấu chốt là kỹ thuật truyền thống PM đã được phát triển để hoạt động trong
vùng dự đoán được nơi phạm vi của dự án là được xác định khá rõ và công nghệ để
sử dụng được thành lập. Agile hoạt động trong vùng không thể đoán trước. Agile
PM đại diện cho một sự thay đổi cơ bản cách xa phương pháp quản lý dự án kế
hoạch định hướng truyền thống bằng cách áp dụng một cách tiếp cận thực nghiệm
hơn và thích ứng để quản lý dự án. Các dự án phát triển chứ không được thực thi.
Một số khác biệt giữa Agile PM và quản lý dự án truyền thống được hiển thị trong
Bảng 17.1.

Traditional Aglie
Thiết kế từ trước Thiết kế liên tục
Phạm vi cố định Phạm vi linh hoạt
Phân phối Tính năng/ yêu cầu
Cố định thiết kế càng sớm càng tốt Cố định thiết kế trễ càng tốt
Không chắc chắn thấp Không chắc chắn cao
Tránh sự thay đổi Tiếp nhận thay đổi
Tương tác khách hàng thấp Tương tác khách hàng cao
Nhóm dự án thông thường Nhóm tự tổ chức dự án

Về cơ bản, Agile PM có liên quan đến việc lập kế hoạch và lịch trình cuốn sóng
phương thức dự án (xem Chương 5). Đó là, các dự án thiết kế cuối cùng không biết
chi tiết và liên tục được phát triển thông qua một loạt các bước lặp gia tăng theo
thời gian. Khung thời gian lặp lại ngắn ( "hộp thời gian") thường kéo dài từ một
đến bốn tuần. Mục tiêu của mỗi lần lặp là để phát triển một sản phẩm hoàn toàn
khả thi đáp ứng một hoặc mong muốn thêm nhiều tính năng sản phẩm để chứng
6
minh với khách hàng và các bên liên quan khác. Vào cuối mỗi lần lặp, các bên liên
quan và khách hàng xem xét tiến độ và đánh giá lại các ưu tiên để đảm bảo sự liên
kết với nhu cầu của khách hàng và mục tiêu của công ty. Điều chỉnh được thực
hiện và một chu kỳ lặp đi lặp lại khác nhau bắt đầu. Mỗi lần lặp mới công việc của
các dòng trước và bổ sung thêm khả năng mới cho các sản phẩm cải tiến (xem hình
17.2) để sản xuất một phiên bản tiếp theo, mở rộng các sản phẩm xem ảnh chụp từ
thực tế: IDEO cho một ví dụ về phát triển lặp trong hành động.

Phát triển quá trình lặp lại cho những ưu điểm trọng sau đây:

+ Tích hợp liên tục, kiểm tra và xác nhận của các sản phẩm phát triển.

+ Báo cáo thường xuyên tiến độ làm tăng khả năng rằng các sản phẩm cuối cùng sẽ
đáp ứng nhu cầu khách hàng.

+ Phát hiện sớm những khiếm khuyết và những vấn đề.

ẢNH CHỤP TỪ THỰC TẾ IDEO: Bậc thầy về thiết kế

IDEO, trụ sở tại Palo Alto, California, là một trong những công ty thiết kế hàng
đầu thế giới. Họ chịu trách nhiệm cho một loạt các cải tiến sản phẩm bao gồm:
Chuột máy tính đầu tiên của Apple, Airflow vợt Head, Zyliss Salad Spinner và
điện thoại Nokia N Gage thông minh. Nhiều khách hàng IDEO bao gồm Pepsi-
Cola, 3M, Logitech, Nike, và HBO. IDEO đã giành được nhiều giải thưởng thiết
kế công nghiệp xuất sắc BusinessWeek/IDSA hơn bất kỳ hãng nào khác.

7
Cách tiếp cận của IDEO để thiết kế sản phẩm chủ yếu dựa trên một quá trình phát
triển lặp lại trong những sản phẩm mẫu được sử dụng để khám phá và hoàn thiện
hơn nữa những sản phẩm ý tưởng. Giám đốc điều hành Tim Brown nói rằng mục
tiêu của nguyên mẫu "là để tìm hiểu về những điểm mạnh và điểm yếu của ý tưởng
và xác định hướng đi mới mà nguyên mẫu có thể mất đi."

Ví dụ, IDEO đã làm việc với Procter và Gamble để phát triển mới một ống kem
đánh răng Crest. Thách thức là để cải thiện nắp vặn truyền thống, mà luôn luôn lấy
được kem đánh răng. Giải pháp đầu tiên của IDEO là một nắp bật lên, cửa ra. Tuy
nhiên, khi các nhà thiết kế tạo ra nguyên mẫu thô và theo dõi người sử dụng chúng,
họ nhanh chóng nhận thấy rằng người sử dụng tiếp tục cố gắng để mở nắp mặc dù
họ đã biết nó làm việc như thế nào. Các nhà thiết kế đã kết luận rằng các hành
động là một điều tốt, thói quen được ăn sâu vào mà có lẽ sẽ không thể nào phá vỡ.
Vì vậy, họ đã kết hợp đưa ra: một nắp vặn đi trong đó có một sợi ngắn nhưng vẫn
có thể dễ dàng để làm sạch.

Tạo mẫu được tập trung giải quyết các vấn đề quan trọng từng cái một. Brown
khuyến cáo rằng nguyên mẫu chỉ cần mất nhiều thời gian và nỗ lực cần thiết để tạo
ra thông tin phản hồi hữu ích và phát triển một ý tưởng.

Ví dụ, IDEO đã làm việc trên một chiếc ghế cho Vecta, một cao cấp sản xuất nội
thất văn phòng. Dự án đã phát triển tới mức mà các đòn bẩy điều chỉnh độ cao mà
nghiêng với chiếc ghế trở nên quan trọng. Nhóm nghiên cứu đã không xây dựng
toàn bộ ghế hoặc thậm chí các cơ chế nghiêng. Họ chỉ cần xây dựng các đòn bẩy
nhỏ và giao diện của nó với cơ chế nghiêng. Chỉ mất một vài giờ. Khi hoàn thành
nguyên mẫu nhanh chóng chứng minh rằng nguyên tắc sẽ làm việc.

"Nó không quan trọng bạn thông minh như thế nào, ý tưởng đầu tiên của bạn về
một cái gì đó không bao giờ là đúng", Brown cho biết, "vì vậy giá trị tuyệt vời của
tạo mẫu và tạo mẫu nhanh chóng và không tốn kém, là bạn tìm hiểu về các ý tưởng
và làm cho nó tốt hơn."

Ngày càng có nhiều bằng chứng cho thấy sự phát triển lặp đi lặp lại và tiến hóa là
cấp trên để quản lý dự án kế hoạch định hướng truyền thống khi nói đến việc tạo ra
các sản phẩm mới (Xem Highlight nghiên cứu:Thực hành phát triển sản phẩm mà
làm việc)

8
NGHIÊN CỨU NỔI BẬC: Phát triển sản phẩm thực tế công việc

Alan MacCormack và các đồng nghiệp của ông tại Harvard Business School đã
tiến hành hai năm nghiên cứu sâu của 29 dự án phần mềm để trả lời câu hỏi: "Liệu
phát triển tiến hóa, chứ không phải là mô hình thác nước, dẫn đến thành công
hơn?" Các mô hình thác nước là tên được sử dụng trong ngành công nghiệp phần
mềm cho các phương pháp truyền thống để quản lý trong đó một cấu trúc quá trình
phân hủy (PBS) được sử dụng để đầu xác định tất cả các yêu cầu lên phía trước và
sau đó bắt đầu một dự án thiết kế, xây dựng, tích hợp, kiểm tra, triển khai các trình
tự.

Ngược lại, phát triển tiến hóa là một phương pháp lặp đi lặp lại trong đó khách
hàng kiểm tra phiên bản đầu tiên của phần mềm và yêu cầu xuất hiện và được tinh
chế sau mỗi lần trình diễn. Nghiên cứu kết luận:

. . . nghiên cứu của chúng tôi cho thấy một chương trình nghị sự rõ ràng cho các
nhà quản lý: Nhận một phiên bản tính năng thấp của sản phẩm vào tay khách hàng
ở giai đoạn sớm nhất có thể và sau đó áp dụng một phương pháp lặp để thêm chức
năng.

Nghiên cứu xác định một số thực hành có tương quan thống kê với các dự án thành
công nhất:

1. Một chu kỳ cuộc sống lặp đi lặp lại với bản phát hành đầu tiên của sản phẩm tiến
hóa để các bên liên quan để xem xét và phản hồi.

2. hợp hàng ngày của phần mềm mới và phản hồi nhanh chóng các thay đổi thiết
kế.

3. Một đội bóng với một kinh nghiệm trên diện rộng vào vận chuyển nhiều dự án.

MacCormack khẳng định rằng sự không chắc chắn về các dự án phần mềm ra lệnh
"microprojects" ngắn -down đến mức độ tính năng. Điều này không chỉ giới hạn
cho các dự án phần mềm chỉ nhưng để bất kỳ nỗ lực sản phẩm mới mà không chắc
chắn là cao và nhu cầu thông tin phản hồi của khách hàng và tinh tế là rất quan
trọng để thành công.

9
Cần lưu ý rằng Agile PM không phải là một phương pháp thiết lập, nhưng một gia
đình của các phương pháp thiết kế để đáp ứng những thách thức của dự án không
thể đoán trước. Một vài trong số những người nổi tiếng hơn được liệt kê ở đây:

+ Rcrum

+ RUP (Rational Unified Process)

+ Extreme Programming (XP)

+ Crystal Clear

+ Modeling Agile

+ Dynamic Product Development Method (DSDM)

+ Lean Development

+ Rapid Product Development (RPD)

Trong khi mỗi một trong các phương pháp có yếu tố độc đáo và các ứng dụng, nhất
là dựa trên các nguyên tắc Agile sau:

+ Tập trung vào khách hàng giá trị, ưu tiên sử dụng kinh doanh theo định hướng
của các yêu cầu và tính năng.

+ Lặp đi lặp lại và gia tăng chuyển-tạo dòng chảy giá trị cho khách hàng bằng cách

"Chunking" chuyển hoạt động dự án thành từng bước nhỏ.

+ Thí nghiệm và thích ứng- kiểm giả thiết sớm và xây dựng công tác nguyên mẫu
để thu thập ý kiến phản hồi của khách hàng và hoàn thiện các yêu cầu sản phẩm.

+ Các thành viên tự tổ chức quyết định với nhau và những gì nên được thực hiện.

+ Nhóm liên tục cải thiện-phản ánh, học hỏi và thích ứng với thay đổi; công việc
thông báo kế hoạch.

Các phương pháp Agile gọi là "Scrum" sẽ được sử dụng để minh họa các nguyên
tắc cốt lõi được đưa vào hoạt động.

10
Scrum có thể được truy trở lại công việc của Hirotaka Takeuchi và Ikujiro Nonaka
vào năm 1986 đã mô tả một cách tiếp cận toàn mới trong nỗ lực phát triển sản
phẩm thương mại mới. Họ so sánh cách tiếp cận này của một đội chéo chức năng
hợp tác để phát triển một sản phẩm mới đến bóng bầu dục, nơi mà toàn đội "cố
gắng đi xa như một đơn vị, đi bóng qua lại." Ẩn dụ scrum đã được mở rộng và tinh
chế thành một khuôn khổ khá quy tắc đó đã rất thành công về công nghệ cao và
các dự án phát triển phần mềm (xem Ảnh chụp từ thực hành linh hồn tìm kiếm).

Scrum, giống như các phương pháp Agile khác, bắt đầu với một định nghĩa phạm
vi cấp cao và hiện sân chơi bóng chày và ước tính chi phí cho dự án. Các ước tính
quy mô và chi phí nên hoàn toàn đủ rằng quản lý là thoải mái với dự toán. Lý
thuyết này là từ yêu cầu phát triển theo thời gian, lập kế hoạch lên phía trước chi
tiết sẽ bị lãng phí.

Ở vị trí của một WBS sản phẩm, Scrum sử dụng tính năng sản phẩm như phân phôi.
Một tính năng được định nghĩa như là một phần của một sản phẩm mà cung cấp
một số chức năng hữu ích cho một khách hàng. Trong trường hợp của một dự án
phần mềm, một tính năng có thể là một khách hàng của ngân hàng có thể thay đổi
mã PIN của mình. Trong trường hợp của một sản phẩm công nghệ cao, nó có thể là
3G truy cập không dây.

Các tính năng được ưu tiên bởi giá trị cao nhất nhận thức của họ. Nhóm dự án đã
khắc phục những ưu tiên cao nhất, khả thi tính năng đầu tiên. Ưu tiên được đánh
giá lại sau mỗi lần lặp. Lặp đi lặp lại được gọi là chạy nước rút và không nên kéo
dài hơn bốn tuần. Mục tiêu của mỗi nước rút là để sản xuất các tính năng đầy đủ
chức năng. Điều này buộc các đội để giải quyết quyết định khó khăn ban đầu để
tạo ra một bản demo hoàn toàn khả thi. tính năng cụ thể được tạo ra theo bốn giai
đoạn: phân tích, thiết kế, xây dựng và thử nghiệm (xem hình 17.3). Mỗi tính năng
có thể được coi như là một dự án nhỏ.

Giai đoạn đầu tiên là phân tích và xem xét các yêu cầu chức năng đó sẽ là cần thiết
để hoàn thành các tính năng. Các đội cam kết đáp ứng các yêu cầu này.

Giai đoạn thứ hai là sự phát triển của một thiết kế đáp ứng các yêu cầu của tính
năng này. Giai đoạn thứ ba là xây dựng các tính năng để nó là chức năng. Cuối
cùng, tính năng được kiểm tra và ghi chép lại. Vào cuối của mỗi nước rút, tính

11
năng này được chứng minh. Trong khuôn khổ chạy nước rút này, Scrum dựa trên
vai trò cụ thể, các cuộc họp, và các tài liệu / bản ghi để quản lý dự án.

SNAPSHOT FROM PRACTICE

Hơn 2792 sinh mạng mất đi khi Trung tâm thương mại thế giới (WTC) sụp đổ ngày
11/9/2001. Trong khi đội cứu hộ làm việc cả ngày lẫn đêm để phục hồi thiệt hại,
một nhóm nhỏ các kỹ sư phần mềm ở Michigan bắt đầu

Thành phố New York đã thuê Gene Codes, the Ann Arbor, Michigan, công ty
bioinformatics ( công nghệ thông tin sinh học), để tái tạo (reinvent) khoa học nhận
biết khối lượng DNA bằng cách tạo ra phần mềm cái mà sẽ kiểm tra và làm phù hợp
những gì còn lại của nạn nhân và ghép chúng lại với gia đình của họ ( để nhận dạng
xem là người thân của ai). Họ có thể làm như vậy càng sớm càng tốt with no erros.
Các chuyên gia dự đoán ( predicted ) rằng sức mạnh của sự sụp đổ và sức nóng dữ
dội của các đám cháy thì 25% những gì còn lại của nạn nhân có thể được nhận dạng.

Gene Codes đã thuê Wiliam Wake, một huấn luyện viên phần mềm tự do, để làm việc
với nhóm của họ ( 8 kỹ sư phần mềm trong dự án). Wake được giới thiệu nhóm với
Agile PM. Dưới dự hướng dẫn của Wake một môi trường tương tác cao và sự giao
tiếp được tạo ra bên trong đội ngũ lập trình bằng cách thường xuyên bàn bạc các kế
hoạch, tempered bằng cách kiểm tra định kỳ, và phản hồi của người sử dụng. Kiểm
tra được thực hiện trước, trong và sau khi mã (code) được viết để đảm bảo các lỗi
không lặp lại lần 2.
12
Mỗi cuối tuần, nhân viên nhìn lại những gì đã làm. Họ liệt kê những việc đã làm tốt,
những gì cần cải thiện (improvement) trong những tờ ghi chú màu hồng huỳnh
quang, xanh, vàng, biến đổi toàn bộ các bức tường thành trường hợp mô phỏng nghệ
thuật cuộc sống ( dán notes lên tường một cách nghệ thuật ). Dưới những “worked
well” a note said : “ Tìm ra cách để sử dụng hình thức chỉnh lỗi trên một lớp thử
nghiệm”. Một hình vuông dưới “the need improvement” loại chỉ đọc “I’m tired”.

Lòng yêu nước hoặc sự chuyên nghiệp, đội thường xuyên đến lúc 7:00 a.m và làm
việc đến nửa đêm. Kỹ sư như Dave Relyea chỉ muốn giúp đỡ. “chúng tôi đã nghĩ về
các nạn nhân, các gia đình và những người tại sở y tế đã làm việc không nghỉ. Những
gì họ đã trải qua khiến chúng tôi cảm thấy chúng tôi chưa bao giờ đủ chăm chỉ” (we
never work hard enough).

Sản phẩm tạo ra từ công sức của họ “the Mass Fatality Identification System (M-
FISys)” chứ hơn 164 000 dòng code. M-FISys kết nối tất cả thông tin trong dự án
nhận dạng : 11 641 mẫu tăm bông từ 7 166 gia đình, 7861 vật dụng cá nhân và kết
quả của 3 kiểu kiểm nghiệm DNA, gần 20 000 người còn lại. Khả năng nhầm lẫn là
1/3,58 triệu.

Cuối cùng với sự giúp đỡ của M-FISys New York Medical có thể nhận dạng được
1521 người trong số 2792.

VAI TRÒ VÀ TRÁCH NHIỆM

Ba vai trò chính : sở hữu sản phẩm, đội phát triển, đội sản xuất.

Product owner (chủ sở hữu sản phẩm) : đóng vai trò đại diện cho khách hàng để
đại diện cho lợi ích (interest) của khách hàng . Họ có vai trò đảm bảo rằng đội ngũ
phát triển (development team) tập trung nỗ lực (efforts) của họ vào việc phát triển
một sản phẩm cái sẽ đáp ứng mục tiêu kinh doanh của dự án. Product owner thành
lập (establishs) danh sách ban đầu các sản phẩm tính năng và ưu tiên chúng trong
sản phẩm dự trữ. Product owner thương lượng mục tiêu chạy nước rút và hàng tồn
đọng với nhóm phát triển. Product owner có quyền thay đổi tính năng và sự ưu tiên
mỗi lần kết thúc đợt chạy nước rút nếu muốn. Product owner nắm toàn quyền trong
việc yêu cầu và có quyền từ chấp nhận hoặc từ chối sản phẩm. Product owner quyết
định dự án đã hoàn thành hay chưa. Product owner là người nắm giữ tầm nhìn sản
phẩm và xem lợi tức đầu tư.

Development team : Team này có trách nhiệm phân phối sản phẩm. Một nhóm đặc
thù gồm từ 5-9 người có nhiều kỹ năng ( đa chức năng). Ở đây không chỉ định vai trò
13
hay chức danh, mỗi người nhận trách nhiệm khác nhau dựa trên tính chất công việc.
Nhóm tự tổ chức theo nghĩa họ quyết định cả 2 và làm thế nào công việc được hoàn
tất (vừa quản lý vừa nhân viên). Các thành viên nhóm nên thống nhất (cách làm
việc) để sự phối hợp mặt đối mặt được diễn ra. Họ có trách nhiệm đạt được các cam
kết tại các buổi họp.

Scrum Master (aka Project Manager) : có nhiệm vụ giải quyết các trở ngại cho các
nhóm và tổ chức bên dưới. The Scrum master không phải lãnh đạo của một nhóm
nhưng hoạt động như là sự kết nối giữa các nhóm và bên ngoài. Họ không có quyền
lực chính thức. Thay vào đó họ có trách nhiệm đảm bảo the Scrum process được tôn
trọng. Họ giúp Product owner làm theo kế hoạch và giữ cho nhóm này luôn tràn
đầy sức mạnh. The Scrum master phục vụ giống 1 huấn luyện viên hơn là một quản
lý.

Scrum Meetings

Scrum Meetings sử dụng hàng loạt các cuộc họp phối hợp để quản lý quá trình phát
triển (Hình)

Sprint Planning : tại mỗi thời điểm bắt đầu một giai đoạn nước rút, chủ sở hữu sản
phẩm ( product owner) và nhóm phát triển (development team) thương lượng về
Product backlog Item nhóm sẽ cố gắng làm trong sprint này. Chủ sở hữu sản phẩm
có trách nhiệm chỉ ra tính năng nào là quan trọng nhất, và development team có
trách nhiệm xác định những gì có thể thực hiện trong sprint này. Nếu nó không thể
hoàn thành trong 4 tuần , nhóm này sẽ làm việc với Product owner để hạ các tính
năng thành các phần nhỏ có thể làm được. Tất cả cam kết được ghi lại trong Product
backlog (phần việc tồn đọng cần được giải quyết). Nhóm sử phát triển sản phẩm
(development team) sử dụng Product backlog này để ưu tiên công việc cần thực hiện
và phân công trách nhiệm ban đầu. Những nhiệm vụ này được ghi lại trong sprint
backlog (danh sách nhiệm vụ xác định công việc của nhóm trong sprint). Một cuộc
họp đã hoãn thì mục tiêu Sprint không thể thay đổi.

Daily Scrum (họp hàng ngày) : nhịp tim của dự án là những cuộc họp hàng ngày
(daily Scrum). Mỗi ngày làm việc vào cùng thời gian, địa điểm, các thành viên đứng
thành 1 vòng tròn và lần lượt trả lời các câu hỏi theo những key question :

1. Những gì bạn đã hoàn thành kể từ cái Scrum trước.

2. Bạn sẽ làm gì từ giờ cho tới Scrum tiếp theo.
3. Điều gì xảy ra khi bạn làm việc một cách hiệu quả

14
Một Scrum thường kéo dài 15 phút, được tổ chức cạnh một tấm bảng trắng, tại đó
các nhiệm vụ và trở ngại được ghi lại. Scrum master (người chịu trách nhiệm cho
quy trình scrum) sẽ xóa các trở ngại đi khi chúng được giải quyết.

Cuộc họp phải được bắt đầu đúng giờ. Ai trễ bị phạt bởi Scrum master và đóng góp
từ thiện, đó là quy tắc phổ biến. Cuộc hợp thường được giới hạn bởi 3 câu hỏi cốt lõi.
Ngay sau đó những ai liên quan trực tiếp gặp nhau để bàn luận những vấn đề nổi trội.

Giá trị của Scrum là nó tạo ra cơ hội để mọi người được biết tình trạng dự án hàng
ngày. Nó duy trì ý thức về bản sắc của một nhóm là khuyến khích sự cởi mở và giải
quyết vấn đề trong thời gian thực (gặp nhau để giải quyết). Có tất cả mọi người báo
cái những gì họ lên kế hoạc làm cho ngày hôm đó tạo ra một lời hứa xã hội từ đó xây
dựng trách nhiệm.

Chú ý lại một lần nữa là các nhóm tự quản lý. Scrum master không giao trách nhiệm
hàng ngày cho các thành viên, nhóm tự quyết định với nhau. Scrum master có vai trò
quan sát Scrum được thực hiện một cách chính xác. Họ không phải quản lý của nhóm
mà là quản lý quá trình.

Sprint Review (cuộc họp sơ khảo Sprint)

Vào cuối mỗi Sprint, nhóm cho thấy các công việc thực tế tăng trưởng sản phẩm mà
họ đã xây dựng cho Product owner và các bên liên quan khác. Phản hồi từ Product
owner và các bên liên quan. Product owner quyết định việc nào đã hoàn thành, việc
nào cần tiếp tục thực hiện và việc nào cần đưa lại vào Product backlog. Các nhóm có
thể nhân cơ hội này để đề xuất các cải tiến và các tính năng mới với Product owner
( được chấp nhận hoặc từ chối). Cuộc họp sơ kết Sprint (Sprint review meeting) là
cơ hội để kiểm tra và điều chỉnh các sản phẩm. Những hiệu chỉnh sẽ là chủ đề của các
cuộc họp lập kế hoạch Sprint tiếp theo.

15
Sprint Retrospective (cuộc họp cải tiến Sprint)

Mục đích của Sprint Retrospective là để phản ánh và xác định các hành động cụ thể
cái mà cải thiện những Sprint trong tương lai. Các Scrum master thường tạo điều
kiện cho cuộc họp này và nhóm quyết định những thay đổi sẽ thực hiện trong cách
họ làm việc cùng nhau trong Sprint tiếp theo. Các phản ánh cam kết của Scrum để
tiếp tục cải tiến và giá trị của nó không chỉ cải thiện sản phẩm mà còn là sự tương tác
trong nhóm.

Product and Sprint Backlogs

Mỗi dự án đều có Product backlog và Sprint Backlog. Product owner kiểm soát
Product backlog và nhóm quản lý Sprint backlog. Product backlog là danh sách ưu
tiên của khách hàng các tính năng quan trọng mong muốn khi dự án hoàn thành. Chỉ
có Product owner mới có thể thay đổi Product backlog và các ưu tiên của nó.
Product backlog thường xác định các chức năng, ước tính thời gian, chi phí và công
việc còn lại. Bằng cách quan sát tỉ lệ hoàn thành các tính năng, Product owner có thể
ước tính ngày hoàn thành và xem xét trade-off thêm hoặc giảm chức năng. Xem hình
17.5 là một Product backlog của một dự án phần mềm.

Sprint backlog được phát triển và kiểm soát bởi nhóm. Nó là công việc nhóm cam kết
hoàn thành trong thời gian Sprint tiếp theo. Các Sprint backlog liệt kê các công việc
phải hoàn thành để cung cấp một tính năng chức năng hoặc phân đoạn của một tính
năng. Sprint backlog cũng có vai trò như là một tài liệu thể hiện tình trạng bằng cách
liệt kê người chịu trách nhiệm cho mỗi công việc, thời gian làm việc còn lại và ghi lại
các nhiệm vụ đã hoàn tất, trong quá trình hoặc chưa bắt đầu. Xem hình 17.6 là một ví
dụ cho Sprint backlog

16
Scrum không sử các công cụ quản lý dự án thông thường như biểu đồ Gantt hay sơ
đồ mạng. Thay vào đó nó dựa trên các hàng ngày và sự tham gia tích cực của Product
owner để quản lý công việc. Rủi ro được giảm xuống bởi chu kì phát triển ngắn và sự
kiểm tra nghiêm ngặt.

Applying Agile PM to Large Projects:

Scrum và hầu hết các phương pháp nhanh nhẹn là lý tưởng cho dự án khác biệt

có thể được hoàn thành bởi một nhỏ, nhóm 5 đến chín người. Nhanh nhẹn các
phương pháp có thể được sử dụng lớn hơn quy mô dự án, trong đó một số đội đang
làm việc trên các tính năng khác nhau tại cùng một lúc. Trong thực tế tình trạng
này được gọi là "mở rộng". Thách thức chính với tỉ lệ là tích hợp-đảm bảo rằng các
tính năng khác nhau được tạo ra làm việc trong sự hòa hợp với nhau.

Không có không có giải pháp dễ dàng để thách thức hội nhập. Quan trọng lên-phía
trước lập kế hoạch là cần thiết để interdependences các tính năng khác nhau mà sẽ
quản lý được phát triển. Điều này được gọi là "dàn dựng" và thường là chủ đề lặp
đi lặp lại phát triển đầu tiên. Ở đây giao thức và vai trò của điều phối những nỗ lực
và đảm bảo khả năng tương thích được thiết lập. Điều này được hỗ trợ bằng cách
thiết lập một sản phẩm rõ ràng tầm nhìn do đó quyết định thương mại-off là phù
hợp ở cấp độ đội bóng địa phương.

Những người ủng hộ nhanh nhẹn khuyên bạn nên tạo một cấu trúc Trung tâm (xem
hình 17.7) với sự chồng chéo vai trò và trách nhiệm quản lý các dự án lớn. Có rất
nhiều tính năng phát triển các nhóm. Nhóm hội nhập và xây dựng riêng biệt được
thành lập gồm các thành viên bán thời gian của từng nhóm tính năng. Đội bóng có
sự dính dáng vấn đề hội nhập thông qua các thử nghiệm và thiết lập các yêu cầu
17
cho các tính năng trong đội. Phối hợp các cấu trúc multiteam một nhóm dự án
Trung ương được tạo ra bao gồm một trình quản lý dự án cấp cao, một sản phẩm
quản lý (người đại diện cho lợi ích của khách hàng), và dẫn ("quản lý dự án") từ
các tính năng nhóm phát triển. Đội ngũ quản lý dự án cung cấp phối hợp và tạo
điều kiện cho dự án quyết định. Vai trò của họ là để chỉ đạo chứ không phải là chỉ
huy đội khác. Đội bóng có thể được thực sự, ảo, hoặc một sự kết hợp. Toàn bộ hệ
thống có một tinh thần hợp tác làm việc.

Limitations and Concerns (phạm vi và sự lo lắng):

Các phương pháp nhanh nhẹn trong các ngành công nghiệp phần mềm lớn ở một
mức độ rễ cỏ. Nhiều kỹ sư quản lý dự án thúc đẩy kế hoạch truyền thống coi
stifling phát triển có hiệu quả với quá nhiều nhấn mạnh vào quá trình và tài liệu
hướng dẫn và không đủ về sự sáng tạo và thử nghiệm. Đầu vào đó là một giai điệu
nổi loạn để di chuyển nhanh nhẹn, vì vậy nhiều như vậy, một vài trong số những
người sáng lập khóa xuất bản một tuyên ngôn nhanh nhẹn (xem ảnh chụp từ thực tế
trên liên minh một cách nhanh nhẹn). Tuyên ngôn khẳng định một bộ khác nhau
của các giá trị so với những người hiện đang được áp dụng để quản lý các dự án,
họ đã làm việc trên.

18
Bản chất cách mạng của Agile được phản ánh trong câu chuyện một IT manager đã
nói với các tác giả về những nỗ lực của mình lúc bằng cách sử dụng nhanh nhẹn
PM. Cô làm việc cho một công ty công nghệ cao lớn, đa quốc gia mà đã dành năm
năm rigidly thể chế một bộ truyền thống dự án quản lý chính sách và thủ tục. Mặc
dù nỗ lực tốt nhất của họ, vùng của cô luôn hoàn thành dự án phía sau lịch trình
với nhiều huỷ bỏ. Ra khỏi sự tuyệt vọng, cô bắt đầu bí mật bằng cách sử dụng
phương pháp nhanh nhẹn để hoàn thành dự án phần mềm. Bằng cách sử dụng
nhanh nhẹn am đội dự án của cô đã có thể để không chỉ đáp ứng nhưng đánh bại
dự án lịch — một hiếm trong công ty của mình. Khi đầu quản lý phải đối mặt với
cô ấy cho không phù hợp với quy trình, cô chỉ để thành công gần đây của cô tỷ lệ
để bảo vệ người còn lại một mình. Cuối cùng quản lý không thể tranh luận với
thành công, và cô ấy đã được cho phép mở rộng những nỗ lực của cô.

Nhanh nhẹn am không đáp ứng nhu cầu quản lý hàng đầu cho ngân sách, phạm vi,
và lịch trình điều khiển. Hãy nhớ rằng các ngôi nhà mới tương tự. Người mua nhận
chính xác những gì họ muốn nhưng không biết bao nhiêu nó sẽ chi phí. Cũng
không phải đã làm họ biết bao lâu nó sẽ mất hoặc thậm chí là những gì nó sẽ giống
như khi nó đã được thực hiện. Trong khi các sân chơi bóng chày ước tính được
cung cấp, các phương pháp nhanh nhẹn bằng cách rất tự nhiên của họ không cung
cấp các ước tính chi tiết về thời gian và chi phí quản lý thích. Không có vấn đề
thực tế như thế nào "nó phụ thuộc" là, quản lý cũng như các khách hàng quen làm
việc với một mức độ cao hơn của sự chắc chắn hơn Agile cung cấp. Để đáp ứng
với các con tài chính, nhiều tổ chức thiết lập "trần," đó là tối đa ngân sách mà nên
không được vượt quá sự phát triển của một sản phẩm nhất định hoặc dịch vụ.

Thậm chí nếu quản lý hoàn toàn mua vào các giá trị trong Agile, một chỉ đơn giản
là không thể cài đặt nó vào một tổ chức qua đêm, nó cần phải phát triển theo thời
gian. Nhiều người trong số Các nguyên tắc nhanh nhẹn, bao gồm cả tự tổ chức các
đội và hợp tác dữ dội, không tương thích với nền văn hóa công ty. Ví dụ, các
nguyên tắc của tự tổ chức các đội, các thành viên mà quyết định những người phải
làm gì, không phân biệt cấp bậc hoặc tiêu đề, mâu thuẫn với cấu trúc lệnh và kiểm
soát. Tương tự như vậy, cường độ cao hợp tác không phải cho tất cả mọi người.
Một người quản lý nhanh nhẹn thú nhận rằng cô đã có để cho một số của cô ấy

kỹ sư hàng đầu đi vì cá tính của họ lone wolf đã không tương thích với

19
nghiên cứu khoa học. Hầu hết các công ty báo cáo giới thiệu dần dần của quản lý
dự án nhanh nhẹn. Ví dụ, Hệ thống y tế Siemens bắt đầu với một đội ngũ Scrum
trong năm 2004, sau đó 10 Scrum đội vào năm 2005, 70 đội vào năm 2006, và hơn
97 đội vào năm 2007.

Như đã nêu trước đó, phương pháp nhanh nhẹn dường như làm việc tốt nhất trên
các dự án nhỏ mà yêu cầu chỉ 5-9 dành riêng cho thành viên trong nhóm để hoàn
thành công việc. Ở đây truyền thông faceto-mặt thay thế tài liệu tốn thời gian và
không chính thức phối hợp dòng kiểm soát từ trên xuống. Mặc dù một số công ty
đã áp dụng thành công Agile PM cho các dự án lớn, những người khác đã vật lộn
với việc mở rộng quy mô và thách thức. Quá thường xuyên phối hợp yêu cầu làm
suy yếu khả năng thích ứng của nhóm nhỏ, mà là một sức mạnh chính của Agile
PM.

Công ty tận hưởng sự thành công về các dự án lớn có xu hướng để có một lịch sử
mạnh sử dụng Agile dự án nhỏ, và Agile nguyên tắc này là một phần của sản phẩm
của họ văn hóa phát triển.

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.”

II/. Tình huống của nhóm:

Giới thiệu về Quản lý dự án linh hoạt Agile:

Prem mở hồi bằng cách nói rằng ông đã nhận được một cuộc gọi từ chủ của mình
và cô ấy đã không hài lòng với sự tiến bộ. Prem nói rằng ông và nhóm nghiên cứu
đã theo súng để có được trở lại theo dõi. Danh sách những thứ thứ mà đi tốt trong
thời gian chạy nước rút thứ hai là ngắn và khi nó đến thời gian để thảo luận về
những cải tiến đã có một sự im lặng khó xử. Kendra nói lên và bắt đầu bằng cách

20
nói rằng cô ấy đã đi lại và xem xét các cuốn sách Scrum. Cô tiếp tục nói rằng cô ấy
nghĩ toàn bộ ý tưởng đằng sau Scrum là nhóm nghiên cứu đã làm việc để giải
quyết những vấn đề riêng của họ và nó không phải là vai trò Prem để chơi nhiệm
vụ chủ. Một vài thành viên trong nhóm khác thì thầm thỏa thuận. Prem trở nên
phòng thủ và nói nếu anh không can thiệp nó đã có thể lấy ngay cho đội để giải
quyết vấn đề. Một thành viên khác cho biết ông nghĩ đó là một sai lầm cho phép
Isaac để thay đổi các cam kết nước rút. Prem đã đồng ý về nguyên tắc đó là sự thật,
nhưng nói rằng đôi khi bạn phải uốn cong các quy tắc để làm những gì là đúng.
Ông đã khuyên nhủ các nhóm bằng cách nói rằng họ đã phải thực hành được nhanh
nhẹn hơn. Các hồi kết thúc với vài khuyến nghị cụ thể khác hơn rằng để có được
trở lại theo dõi, Prem cảm thấy ông sẽ có để có được thậm chí còn tham gia nhiều
hơn trong việc thực hiện dự án. Các cuộc họp lập kế hoạch chạy nước rút 3 tiếp
theo đã được nhiều hơn một hình thức. Isaac cập nhật các sản phẩm tồn đọng với
các ưu tiên sửa đổi và Prem ký tắt cho các đội như những gì họ sẽ phải cam kết. Có
rất ít sự tương tác giữa các nhóm và Isaac trừ tìm kiếm làm rõ về các yêu cầu hiệu
suất cho các tính năng cụ thể. Các đội gặp nhau dưới sự lãnh đạo của Prem cho
Scrums hàng ngày của họ. Đôi khi Scrums đã vượt quá 15 phút bình thường như
Prem xem xét tiến độ và mô tả chi tiết những gì cần phải làm ngày hôm đó. Isaac
thỉnh thoảng hiện lên, ưu tiên thay đổi, việc xem xét và trả lời các câu hỏi. Kendra
làm việc chăm chỉ trên các bài tập của mình và thường xuyên nhận được lời khen
ngợi từ Prem cho công việc cũng được thực hiện. Một buổi tối khi các đội đã cùng
nhau cho một vài loại bia và sushi, một trong những thành viên trong nhóm đã rút
ra một bảng và hỏi ai muốn làm cho đặt cược đầu tiên trên khi họ nghĩ rằng dự án
sẽ được thực hiện. Sau nhiều sprints, Isaac cuối cùng đã ký tắt vào các tính năng
mới nhất và tuyên bố các dự án hoàn thành. Một "yahoo" tập thể ra đời từ đồng đội.
Sau cuộc họp Kendra đã đi xung quanh thu thập tiền từ mỗi thành viên cô đã dự
đoán rằng dự án sẽ phải mất 12 tuần dài hơn dự định.

1. Bạn sẽ đánh giá nỗ lực P2P ra sao tại giới thiệu Scrum?

2. Những thách thức hiện một mặt tổ chức khi áp dụng một cách tiếp cận Agile
như Scrum?

3. P2P đã có thể được thực hiện những gì để nâng cao thành công?

4. Tóm tắt:

21
Các team đã họp lại với nhau dưới sự lãnh đạo của Prem cho Scrums hàng ngày
của họ. Kendra cho rằng : toàn bộ ý tưởng đằng sau Scrum là nhóm nghiên cứu đã
làm việc để giải quyết những vấn đề riêng của họ. Thành viên khác nghĩ đó là một
sai lầm cho phép Isaac để thay đổi các cam kết nước rút.

Ông Prem đã khuyên nhủ các nhóm phải thực hành một cách nhanh nhẹn hơn.

Có rất ít sự tương tác giữa các nhóm và Isaac trừ tìm kiếm làm rõ về các yêu cầu
hiệu suất cho các tính năng cụ thể.

Sau nhiều sprints, Isaac cuối cùng đã ký tắt vào các tính năng mới nhất và tuyên bố
các dự án hoàn thành.

III/. Tài liệu tham khảo:

Tài liệu tham khảo :

[1] http://iviettech.vn/viettech/1795-lam-ro-cac-vai-tro-trong-scrum.html

[2] http://hanoiscrum.net/hnscrum/learning/92

[3] ebook “project managerment- the managerial process”

22