Xem mẫu
- ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
KHOA CÔNG NGHỆ PHẦN MỀM
Đề tài:
TÌM HIỂU VỀ AGILE PROJECT MANAGEMENT
Giảng viên hướng dẫn: Th.S Nguyễn Công Hoan
Sinh viên thực hiện:
Trần Anh Quân 11520305
Nguyễn Trung Nguyên 11520258
Võ Văn Tịnh 11520416
Tp.Hồ Chí Minh, tháng 11 năm 2013
11/14/2013
- I. SỰ RA ĐỜI CỦA MÔ HÌNH AGILE
1. Bối cảnh.
Chúng ta có rất nhiều phương pháp giúp xác định con đường phát triển phần mềm ví dụ
như một số quy trình:
- Mô hình thác nước.
- Mô hình xoắn ốc.
- Mô hình hướng đối tượng.
- Mô hình làm bản mẫu.
Các phương pháp kể trên chủ yếu là dự đoán trước cho quy trình phát triển phần mềm.
Do đó các phương pháp này thường tạo ra một bản k ế ho ạch t ừ th ời đi ểm đ ầu d ự án và
xác định được thời gian hoàn thành của dự án. Nhưng vấn đ ề quan tr ọng nhất v ẫn là “s ự
thay đổi yêu cầu người dùng”. Và phương pháp truyền thống thì h ạn ch ế sự thay đ ổi yêu
cầu từ khách hàng. Điều này giúp duy trì kế hoạch dự án ban đầu nh ưng không đem l ại s ự
thỏa mãn hoàn toàn cho khách hàng. Một phần m ềm tốt là ph ần m ềm mà đem l ại cho
khách hàng sự hài lòng. Chính sự hạn chế từ những phương pháp truyền thống mà c ần có
một phương pháp hay quy trình phát triển phần mềm m ới ra đời. Quy trình phát tri ển ph ần
mềm linh hoạt (Agile) ra đời và phần nào đáp ứng được yêu cầu ấy.
Phương pháp quản lý dự án linh hoạt (Agile project management) ra đ ời t ừ đ ầu nh ững
năm 90, với ý tưởng khắc phục những nhược điểm của mô hình truyền thống cụ thể là mô
hình thác nước.
2. Agile là gì?
Agile là tên gọi chung để chỉ các phương pháp phát tri ển nhanh, linh ho ạt. “Agile” nghĩa
là nhanh nhẹn, khéo léo, linh hoạt.
Agile không phải là một phương pháp cụ thể mà là m ột tri ết lí cùng v ới nhóm các
phương pháp và phương pháp luận phát triển sản phẩm dựa trên nguyên tắc phát tri ển
phân đoạn lặp và tăng trưởng với mục tiêu là phần mềm phải có khả năng bi ến đ ổi, phát
triển và tiến hóa theo thời gian mà không phải làm lại từ đầu.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát tri ển phần m ềm trong
những khung thời gian ngắn và sự cộng tác chặt chẽ với khách hàng. Điểm nổi bật là khả
năng sửa chữa biến đổi phần mềm ngay cả khi dự án đã bắt đầu.
Điểm quan trọng làm lên sự khác biệt của Agile so với các mô hình truyền th ống đó là:
các mô hình truyền thống là mô hình theo kế hoạch, còn mô hình Agile thì không nh ất thi ết
phải tuân theo kế hoạch, nó có thể có những bước đột phá để tạo ra một phần m ềm hi ệu
quả nhất.
II. TÌM HIỂU CHUNG VỀ AGILE
1. Tuyên ngôn Agile.
Cá nhân và tương tác hơn là quy trình và công cụ:
Tất nhiên quy trình và công cụ cũng là điều quan tr ọng. Sẽ không th ể có m ột
phần mềm tốt nếu như quy trình và công cụ không tốt. Nhưng đi ều mà b ản tuyên
ngôn nhấn mạnh là vai trò của từng cá nhân và m ối quan hệ gi ữa các cá nhân trong
đội ngũ phát triển phần mềm. Ý nghĩa quan trọng nhất c ủa Agile là m ọi ng ười
cùng làm việc trong nhóm, chia sẻ thông tin thoải mái v ới nhau h ơn là t ập trung
theo sát một quy trình hay công cụ nào đó.
Sản phẩm xài được quan trọng hơn tài liệu về sản phẩm.
Điều này không có nghĩa là chúng ta không phải thu thập lại t ư li ệu đ ể phát
triển, chỉ là ít nhấn mạnh thu thập tư liệu và tập trung nhiều h ơn cho vi ệc vi ết
phần mềm. Bởi vì đối với một dự án muốn thành công thì ph ải thu th ập tài li ệu
đầy đủ. Nhưng bản thân tài liệu cũng không thể giúp được gì n ếu không có m ột
sản phẩm phần mềm thực sự. Vì thế, việc tạo ra sản phẩm phần mềm quan tr ọng
11/14/2013
- hơn, và tài liệu chỉ đóng vai trò hỗ trợ phần mềm, mô tả phần mềm một cách chính
xác. Trong Agile thì sẽ ít viết tài liệu nếu khách hàng không yêu c ầu nhi ều v ề tài
liệu, việc viết tài liệu một cách cụ thể được xem là không th ực sự c ần thi ết và
thường bỏ qua để đơn giản hóa. Agile chỉ viết những gì mà cần thi ết nhất mà m ọi
người muốn đọc.
Hợp tác với khách hàng hơn là thương thuyết hợp đồng
Việc ký kết hợp đồng là quan trọng nhưng không đủ. Một môi trường hợp tác tốt
sẽ giúp cho những người phát triển đưa ra giải pháp tốt nhất cho khách hàng. Các
hợp đồng định nghĩa những điều khoản ràng buộc mà trong đó c ả hai bên đ ối tác
phải tuân theo. Nhưng những người phát triển cần phải hợp tác v ới khách hàng đ ể
có thể hiểu rõ yêu cầu cũng như ý muốn cụ thể của khách hàng. Agile khuyến
khích khách hàng cùng tham gia vào dự án hơn là chỉ vi ết hợp đ ồng đ ể r ồi khách
hàng sẽ chẳng làm gì với nhóm dự án phát triển phần mềm.
Phản ứng theo thay đổi hơn là theo sát kế hoạch:
Việc lập kế hoạch cho phát triển phần mềm là không thể thiếu. Kế ho ạch giúp
công việc định hướng tốt hơn. Tuy nhiên thực tế có rất nhiều thay đ ổi, và c ứ nh ất
nhất tuân theo kế hoạch sẽ dễ dẫn đến thất bại. Do đó cần đáp ứng với thay đ ổi
để có sự điều chỉnh sao cho phù hợp. Chính vì vậy, nhóm phát tri ển luôn s ẵn lòng
đón nhận thay đổi hơn là chỉ làm theo kế hoạch dự án (đã có trước) vì thay đổi của
khách hàng luôn diễn ra và cả kế hoạch của dự án cũng sẽ thay đổi khi yêu cầu c ủa
khách hàng thay đổi. Đây là một điểm cho thấy rõ sự linh ho ạt trong Agile, và nó
mang lại cho khách hàng sự thỏa mãn cao nhất.
2. Nguyên tắc Agile
Các phương pháp phát triển phần mềm theo Agile có 12 nguyên tắc c ụ th ể nh ư sau, 12
nguyên tắc này là sự thể hiện 4 tuyên ngôn của Agile m ột cách cụ thể và có tính th ực ti ễn
cao hơn:
- Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục
- Giao phần mềm chạy được cho khách hàng một cách thường xuyên. Chu kì ngắn
tốt hơn chu kì dài
- Chào đón việc thay đổi yêu cầu, thậm chí là những thay đổi yêu cầu muộn
- Nhà kinh doanh và kỹ sư lập trình phải làm việc cùng nhau hàng ngày trong suốt dự
án
- Các dự án được xây dựng xung quanh những cá nhân có động lực. Cung cấp cho
họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc
- Trao đổi trực tiếp mặt đối mặt là phương pháp hiệu quả nhất để truyền đạt thông
tin
- Phần mềm chạy được là thước đo chính của tiến độ
- Phát triển bền vững và duy trì được nhịp độ phát triển liên tục
- Liên tục quan tâm đến kĩ thuật và thiết kế để cải tiến sự linh hoạt
- Sự đơn giản là cần thiết – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành
- Nhóm tự tổ chức
- Thích ứng thường xuyên với sự thay đổi
Một số diễn giải về các nguyên tắc:
Nguyên tắc Miêu tả
Khách hàng nên tham gia chặt chẽ trong
suốt quá trình phát triển. Vai trò của họ là
cung cấp và quy định mức độ ưu tiên các
Khách hàng tham gia
yêu cầu mới về hệ thống, và đánh giá hệ
thống tại các lần lặp – các phiên bản nhỏ
của sản phẩm cuối cùng.
11/14/2013
- Phần mềm được phát triển một cách tăng
dần từng đợt (increment), trong đó khách
hàng chỉ ra các yêu cầu cần được đưa vào
Chuyển giao tăng dần mỗi đợt. Nhóm phát triển sẽ giao phần
mềm từng đợt cho khách hàng, mỗi đợt sẽ
là phiên bản mới được thêm một số chức
năng như yêu cầu.
Kĩ năng phát triển của đội cần được ghi
nhận và khai thác. Các thành viên của đội
Con người thay vì quy trình cần được tự do phát triển cách làm việc
của riêng mình mà không cần đến các quy
trình quy phạm định trước.
Hiểu rằng hệ thống sẽ thay đổi nên thiết
kế hệ thống sao cho nó có thể chấp nhận
Chấp nhận thay đổi được thay đổi đó. Hệ thống phải linh hoạt
nhất, để có thể đáp ứng thay đổi của
khách hàng.
Chú trọng vào tính giản dị dễ hiểu của
phần mềm đang được phát triển cũng như
của quy trình phát triển. Chủ động nỗ lực
Gìn giữ tính giản dị, dễ hiểu
loại bỏ sự phức tạp ra khỏi hệ thống bất
cứ khi nào có thể. Muốn linh hoạt thì phải
đơn giản những gì đang làm sẽ làm.
3. Đặc trưng của các phương pháp Agile
- Tính lặp (Iterative):
Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi
là Iteration hoặc Sprint) thường có khung thời gian ngắn (từ m ột đ ến b ốn tu ần). Trong
mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế
hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử … để cho ra các ph ần nh ỏ c ủa
sản phẩm. Các phương pháp Agile thường chia mục tiêu cuối cùng thành các phần nhỏ
với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, không th ực hi ện vi ệc l ập
kế hoạch dài hạn, hoặc thậm chí công việc lập kế ho ạch, làm mịn kế hoạch đ ược th ực
hiện liên tục trong suốt quá trình làm việc.
- Tính tiệm tiến (Incremental) và tiến hóa (Evolutionary):
Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ c ủa sản ph ẩm cu ối
cùng. Các phần nhỏ này thường là đầy đủ, có khả năng ch ạy t ốt, đ ược ki ểm th ử c ẩn
thận và có thể sử dụng. Theo thời gian, phân đoạn này tiếp n ối phân đo ạn kia, các ph ần
chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu c ầu c ủa khách hàng
được thỏa mãn. Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn
bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các d ự án Agile l ớn d ần
lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành.
- Tính thích ứng ( adaptive):
Do các phân đoạn chỉ kéo dài trong một khoảng th ời gian ngắn, và vi ệc l ập k ế ho ạch
cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển đều có th ể đ ược
đáp ứng theo cách thích hợp. Trong khi nhóm phát tri ển đang sản xu ất ra các gói ph ần
mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm có th ể đánh giá các
yêu cầu này và có thể đưa vào làm việc trong phân đoạn tiếp theo. Theo đó, các quy trình
Agile thường thích ứng rất tốt với các thay đổi.
- Nhóm tự tổ chức (self-organizing) và liên chức năng (cross-functionality):
11/14/2013
- Các nhóm tự thực hiện 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 hay làm việc dựa trên một sự phân c ấp rõ ràng trong m ột t ổ ch ức nào c ả.
Các nhóm 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”. Nhóm tự tổ chức có nghĩa là nó đã đủ các kĩ năng 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.
- Quản lý tiến trình thực nghiệm (Empirical Process Control):
Các nhóm Agile ra các quyết định dựa trên các dữ li ệu th ực ti ễn thay vì tính toán lý
thuyết hay các tiền giả định. Việc phân nhỏ dự án thành các phân đoạn ngắn góp ph ần
gia tăng các điểm mốc để nhóm phát triển thu thập dữ kiện cho phép điều ch ỉnh các
chiến lược phát triển của mình. Nói cách khác, Agile rút ngắn vòng đ ời ph ản h ồi đ ể d ễ
dàng thích nghi và gia tăng tính linh hoạt. Theo thời gian, các chi ến l ược này s ẽ ti ến g ần
đến trạng thái tối ưu (vì càng ngày càng có nhiều dữ li ệu thực ti ễn h ơn), nh ờ đó nhóm có
thể kiểm soát được tiến trình, và nâng cao năng suất lao động.
- Giao tiếp trực diện(face-to-face communication):
Agile đánh giá cao việc giao tiếp trực diện hơn là giao ti ếp gián ti ếp thông qua gi ấy t ờ.
Về giao tiếp với khách hàng, Agile khuyến khích nhóm phát tri ển tr ực ti ếp nói chuyện
với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì ph ụ thu ộc nhi ều
vào các loại văn bản.
Trong giao tiếp giữa nội bộ nhóm phát triển với nhau. Agile khuyến khích các thành
viên trực tiếp trao đổi và thống nhất với nhau về việc phát triển sản phẩm. B ản thân các
nhóm agile thường nhỏ (ít hơn mười hai người, một nhóm lớn thường được phân nhỏ với
cơ chế hợp tác đặc thù để luôn luôn có thông lượng giao tiếp tối đa) để đơn gi ản hóa quá
trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Các nhóm phát tri ển th ường t ạo ra các
thói quen và cơ chế trao đổi trực diện một cách thường xuyên. Một trong các c ơ ch ế
thường thấy là các cuộc họp tập trung hằng ngày (Daily Meeting, Daily Scrum, Standup
Meeting). Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm c ủa mình bi ết
mình đã làm gì? Đang làm gì? Sắp làm gì? và Đang gặp phải khó khăn nào? trong quá trình
làm việc.
- Phát triển dựa trên giá trị (value-based development):
Nhóm Agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại di ện
của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao h ơn,
mang lại giá trị hơn sớm nhất có thể cho dự án. Nh ờ đó các d ự án Agile th ường giúp
khách hàng tối ưu hóa được giá trị của dự án. Một cách gần như trực ti ếp, Agile gia tăng
đáng kể độ hài lòng của khách hàng.
III. CÁC PHƯƠNG PHÁP AGILE
1. Phân loại
11/14/2013
- Hiện nay có nhiều phương pháp Agile, nhưng thực sự chúng không ph ải là m ột ph ương
pháp mà là một hệ thống các triết lý và tập hợp các giá trị và nguyên tắc.
Agile giống như một cây dù với nhiều phương pháp Agile khác nhau, có th ể phân lo ại chúng
thành 2 nhóm cơ bản: lightweight approaches(tiếp cận nhanh) và fuller approaches(ti ếp c ận
đầy đủ hơn).
Trong đó:
Lightweight approaches là các phương pháp như Scrum, Extreme programming, lean, …
Fuller approaches là các phương pháp như Dynamic System Development Method
DSDM Atern, Agile Unified Process(AUP),…
Sau đây là một số nguyên tắc của các phương pháp trên:
Scrum: tập trung vào việc quản lý agile và tổ chức tốt hơn cho các đội phát triển.
XP(Extreme Programming): trong phương pháp này có một s ố yếu t ố qu ản lý,
nhưng nhấn mạnh yếu tố thực hành kỹ thuật hơn các phương pháp khác.
Lean Software Development: nhằm giảm tối thiểu chi phí đầu tư cho dự án.
DSDM – Dynamic Systems Development Method: phương pháp này nhằm rút ngắn
thời gian các vòng lặp(Sprint) của dự án.
2. Tỉ lệ được sử dụng của các phương pháp Agile
Theo khảo sát mới đây (2011) của Forrester Research, các cách ti ếp c ận ph ổ bi ến trong
phát triển phần mềm có thể kể đến gồm Scrum, Iterative (Iterative Development - phát
triển lặp), Waterfall, TDD, Kanban, XP.
Phương pháp Tỉ lệ trả lời "có dùng"
Scrum 81.5%
Iterative 58.5%
Waterfall 44.4%
Test-Driven Development37.1%
(TDD)
11/14/2013
- Kanban 37.1%
eXtreme Programming (XP) 35.6%
Lean Software Development 32.7%
Bảng thống kê một phần này cho thấy phần l ớn các công ty hi ện nay đã b ắt đ ầu s ử
dụng Scrum như là cách tiếp cận cơ bản. Bên cạnh đó, nhi ều công ty đã k ết h ợp các
phương pháp lại với nhau trong thực tiễn. Ví dụ 44.4 % các công ty có s ử d ụng Waterfall,
như vậy có nghĩa là một tỉ lệ nhất định nào đó v ừa dùng waterfall, v ừa s ử d ụng Scrum
trong hoạt động của mình. Điều này có thể do các nguyên nhân lịch sử, ho ặc các ràng bu ộc
về chính sách, luật pháp hoặc văn hóa. Đó cũng là một tình huống khá phổ biến đối với các
công ty mới lần đầu “bước chân” vào “ma trận các phương pháp Agile”.
Bảng dưới đây của VersionOne khảo sát trên các công ty Agile, cho thấy nh ững ph ương
pháp phổ biến được sử dụng:
IV. SCRUM
1. Scrum là gì?
Scrum là một quy trình phát triển phần m ềm theo mô hình linh ho ạt (agile) ph ổ bi ến
nhất hiện nay được dùng trong phát triển các sản phẩm phần mềm từ đơn gi ản đến phức
tạp. Được phát triển bởi Ken Schwaber và Jeff Sutherland từ đầu những năm 1990.
Cách làm và triết lí của Scrum đã dần được áp dụng trong các lĩnh v ực khác nh ư d ịch
vụ, giáo dục, marketing v.v. Hiện nay, định nghĩa Scrum là gì đ ược ghi trong tài li ệu Scrum
11/14/2013
- Guide (Hướng dẫn Scrum) và được cập nhật thường xuyên bởi chính các tác gi ả t ại
http://scrum.org.
2. Mô tả về Scrum
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.
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.
2.i. Các thành tố tạo nên Scrum?
Scrum bao gồm các giá trị cốt lõi(còn gọi là "ba chân", hay ba tr ụ c ột c ủa Scrum), các
vai trò(nhóm Scrum), các sự kiện, và các công c ụ (artifacts, hay đ ồ ngh ề) đặc thù c ủa
Scrum.
a) Ba chân (hay giá trị cốt lõi) của Scrum
Scrum là một phương pháp linh hoạt (agile), vì thế nó tuân thủ các nguyên tắc c ủa
Agile Manifesto (xem thêm Tuyên ngôn Agile). Ngoài ra Scrum hoạt động dựa trên ba giá
trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi.
Minh bạch (transparency)
Trong Scrum, tính minh bạch được đề cao như là giá trị c ốt lõi c ơ b ản nhất. Mu ốn
thành công với Scrum, thông tin liên quan tới quá trình phát tri ển ph ải minh b ạch và
thông suốt. Các thông tin đó có thể là: tầm nhìn (vision) v ề sản phẩm, yêu c ầu khách
hàng, tiến độ công việc, các khúc mắc và rào cản v.v. Từ đó m ọi người ở các vai trò các
nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá tr ị đ ể nâng cao hi ệu
quả công việc. Các công cụ và cuộc họp trong Scrum luôn đảm bảo thông tin được minh
bạch cho các bên.
11/14/2013
- Thanh tra (inspection)
Công tác thanh tra liên tục các hoạt động trong Scrum đảm b ảo cho vi ệc phát l ộ các
vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham
gia dự án. Truy xét kĩ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và các c ải
tiến liên tục trong Scrum.
Thích nghi (adaptation)
Scrum rất linh hoạt như các phương pháp phát triển linh hoạt (agile software
development) khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin
minh bạch hóa từ các quá trình thanh tra và làm vi ệc, Scrum có th ể phản h ồi l ại các thay
đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.
b) Ba Vai trò (nhóm Scrum)
Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò v ới
trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao
gồm: Product Owner (chủ sản phẩm), Scrum Master và Development Team (Đ ội s ản
xuất hay Nhóm Phát triển).
Product Owner (chủ sản phẩm)
Là người chịu trách nhiệm về sự thành công của dự án, được xem là ti ếng nói c ủa
khách hàng, và hoạt động như một đại diện cho khách hàng trong các cu ộc h ọp l ập k ế
hoạch, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra c ủa các nhà phát tri ển
phần mềm.
Scrum Master
Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có th ể làm vi ệc hi ệu qu ả
với Scrum.
Development Team (Đội sản xuất, hay Nhóm phát triển)
Một nhóm liên chức năng (cross-functional) tự quản lý để ti ến hành chuyển đ ổi các
yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.
c) Bốn Cuộc họp (4 Events)
Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cu ộc h ọp) nhằm t ạo môi
trường và quy cách hoạt động và cộng tác cho các thành viên trong d ự án. Các l ễ nghi
này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint di ễn ra (Daily
Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective).
Sprint Planning (Họp Kế hoạch Sprint)
Diễn ra đầu mỗi sprint, nhóm phát triển gặp gỡ với Product Owner đ ể lên k ế ho ạch
làm việc cho một Sprint. Công việc lập kế hoạch bao gồm vi ệc ch ọn l ựa các yêu c ầu
cần phải phát triển, phân tích và nhận biết các công vi ệc ph ải làm kèm theo các ước
lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách th ức lập k ế ho ạch
từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất
một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi v ới các tình
hình thực tiễn trong tiến trình đi đến sản phẩm.
11/14/2013
- Daily Scrum (Họp Scrum hằng ngày)
Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong kho ảng 15 phút đ ể
Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải
trong quá trình phát triển phần mềm suốt một Sprint.
Sprint Review (Họp Sơ kết Sprint)
Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát l ại các công vi ệc đã
hoàn tất trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đ ổi c ần thi ết cho s ản
phẩm.
Sprint Retrospective (Họp Cải tiến Sprint)
Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint
vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.
d) Các công cụ (artifacts) Scrum
Scrum sử dụng các công cụ rất đơn giản nhưng hiệu quả để trợ giúp công việc.
Chúng bao gồm bản yêu cầu của chủ sản phẩm được gọi là Product backlog, bản k ế
hoạch của từng Sprint (Sprint Backlog) và biểu đồ Burndown Chart.
Product backlog
Đây là danh sách ưu tiên các tính năng (feature) ho ặc đầu ra khác c ủa d ự án, có th ể
hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner ch ịu trách
nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product
Backlog dựa trên các giá trị do Product Owner định nghĩa (th ường là giá tr ị th ương m ại
– business value).
Sprint backlog
11/14/2013
- Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint
Planning). Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ
ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới
dạng danh sách công việc (TODO list).
Burndown Chart
Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn
lại để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của
Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown
Chart). Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định
nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.
2.ii. Scrum vận hành như thế nào?
11/14/2013
- Product Owner tạo ra Product Backlog chứa các yêu c ầu c ủa d ự án v ới các h ạng m ục
được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu
cầu của Product Owner với sự lặp đi lặp lại các giai đo ạn n ước rút t ừ 1 đ ến 4 tu ần làm
việc (gọi làSprint) với đầu vào là các hạng m ục trong Product Backlog, đ ầu ra là các gói
phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product
Increment). Trước khi cả nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng h ọp
với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi lập kế ho ạch
(theo cách làm của Scrum) là Sprint Backlog chứa các công việc c ần làm trong su ốt m ột
Sprint. Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và th ực
hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ ti ến đ ộ công vi ệc cũng nh ư các
vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền đ ể t ự qu ản lí và
tổ chức lấy công việc của mình để hoàn thành công vi ệc trong Sprint. Khi k ết thúc
Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuy ển giao
(shippable) cho khác hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cu ối Sprint s ẽ giúp
khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì ph ải làm
hoặc còn gì phải thay đổi hay cải tiến. Sau khi kết thúc việc đánh giá Sprint, Scrum
Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) đ ể tìm ki ếm
các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên t ục h ọc h ỏi
và trưởng thành qua từng Sprint.
Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog
đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình
hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng m ục mang
lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang
lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn đ ược c ải ti ến,
nhóm Scrum thường có năng suất lao động rất cao. Đây là hai l ợi ích to l ớn mà Scrum
mang lại cho tổ chức.
V. SO SÁNH AGILE VÀ WATERFALL
1. Waterfall
11/14/2013
- Dự án phần mềm sẽ đượ thực hiện tuần tự qua các bước c ố định, tách r ời nhau và theo
kế hoặc định sẵn, rất hạn chế những sự thay đổi trong quá trình th ực hi ện. V ới waterfall thì
nhất thiết phải hết giai đoạn “Nhu cầu” mới được chuyển sang giai đo ạn “Thi ết kế”, không
thể thực hiện “Mã hóa” mà chưa làm “Design” .
Mặc dù các quy trình hiện tại theo mô hình waterfall đã có những cải biên cho phép nh ững
phản hồi (feedback) tới các bước trước đó, nhằm giúp quy trình linh ho ạt h ơn, nh ưng v ề b ản
chất, chúng vẫn tách rời nhau như vậy.
Hơn thế nữa, các hoạt động trong đội ngũ phát triển phải dựa vào kế ho ạch. Quản lí s ẽ
lập kế hoạch, rồi giao việc, rồi kiểm soát (tiến độ, năng suất, chất lượng v.v.) d ựa theo k ế
hoạch; nhân viên làm việc theo tinh thần tuân thủ kế hoạch, ít phản h ồi. Cách làm vi ệc tách
biệt và tuần tự này được phản ánh rõ nét trong cơ c ấu các phòng ban ch ức năng (test,
development, management), các vai trò của cá nhân (tester, developer, QA, PM, BA ...) – m ỗi
người có mô tả công việc rõ rệt, không ai giẫm chân lên công việc của người khác; và các
quy trình nghiệp vụ chặt chẽ được văn bản hóa (hay pháp chế hóa) trong phạm vi tổ chức.
Cũng chính do được thực hiện theo kế hoạch vạch ra từ trước nên v ới Waterfall, ta ước
tính được thời gian hoàn thành và ngân sách thực hiên c ủa d ự án v ới đ ộ chính xác cao
hơn.
Quá trình phát triển dự án theo mô hình Waterfal có xu h ướng đ ược an toàn h ơn b ởi đ ược
định hướng bởi kế hoạch. Ví dụ một nhà thiết kế bỏ dự án đó gi ữa ch ừng thì cũng không
phải là 1 vấn đề lớn. Bởi Waterfall có sẵn kế hoạch định hướng và tài li ệu đ ầy đ ủ nên khi 1
nhà thiết kế khác tiếp nhận vị trí bị bỏ lại vẫn có thể dễ dàng ti ếp tục d ự án mà không g ặp
vấn đề gì khó khăn.
Nhược điểm: Waterfall có điểm yếu lớn nhất đó là sự cứng nhắc và thiếu linh ho ạt c ủa
mình. Việc thay đổi thiết kế dự án ở bất cứ giai đoạn nào gần như đ ồng nghĩa v ới vi ệc b ắt
đầu tất cả lại từ đầu nên việc thay đổi là gần như k thể xảy ra. Do đó quá trình l ập kế ho ạch
khi sử dụng mô hình waterfall là vô cùng quan tr ọng, bạn c ần thu th ập toàn b ộ yêu c ầu t ừ
khách hàng.
2. Agile
11/14/2013
- Khác với waterfall truyền thống, Agile không làm vi ệc theo ki ểu tuân th ủ k ế ho ạch (plan-
driven) mà lựa chọn việc “thích ứng với sự thay đổi”.
Đặc biệt thích hợp cho các dự án mà mục tiêu cuối cùng chưa đ ược xác đ ịnh r ỏ
ràng ngay từ đầu. Khi áp dụng agile thì các mục tiêu đó sẽ dần được sang r ỏ trong quá
trình thực hiện dự án. Agile là mô hình thường dùng để thực hiện thăm dò phát tri ển sản
phẩm . Trong các dự án thăm dò , đội được khám phá cách th ức m ới đ ể gi ải quy ết m ột
vấn đề hoặc cố gắng để khám phá ra một khách hàng mới hoặc phân khúc thị trường.
Nó hầu như không tiếp cận tuần tự, mà là chồng lấp (overlapping - tức là các công vi ệc
được tiến hành không tuần tự, có thể song song, có thể đồng th ời v ới sự c ộng tác ch ặt ch ẽ
hướng đến mục tiêu chung) để xây dựng phần mềm. Dự án th ường đ ược chia thành các
module nhỏ để thực hiện song song.
Nhược điểm:
• Agile mặc dù rất linh hoạt do không bị c ố định b ởi 1 k ế ho ạch nào nh ưng cũng
chính vì vậy mà tất cả mọi thứ vẫn còn chút mơ hồ, rất khó khăn để xác định chính xác
được các mốc thời gian của dự án hay ngân sách dự án.
• Agile luôn sẳn sàng lắng nghe mọi phản hồi (feedback) t ừ khách hàng và thay đ ổi
theo. Tuy nhiên cũng chính vì vậy mà có thể thời gian của d ự án sẽ b ị kéo dài lên r ất
nhiều khi có quá nhiều yêu cầu thay đổi từ khách hàng.
11/14/2013
- KẾT LUẬN
Có thể tóm lược đặc điểm của 2 mô hình trên như sau:
Agile Waterfall
Linh hoạt Cứng nhắc
Các bước chồng lấp, không cần Các bước tách biệt, yêu cầu các bước
tuần tự tuần tự
Luôn chấp nhận sự thay đổi Rất hạn chế sự thay đổi
Không có kế hoạc cố định Có kế hoạc cố định từ khi bắt đầu
Phù hợp các dự án chưa xác định Dùng cho các dự án mà kế hoạch đã
chính xác mục tiêu cuối cùng được lập ra với đầy đủ yêu cầu và mục
tiêu
Agile và Waterfall, mỗi phương pháp mang những đặc điểm riêng, có ưu có khuyết,
không thể nói cái nào tốt hơn cái nào. Trong khi Waterfal thích hợp h ơn cho các d ự án tĩnh, ít
có sự thay đổi trong suốt quá trình phát triển, thì Agile l ại thích h ợp cho các d ự án nh ỏ, n ơi
thay đổi có thể thực hiện trong suốt quá trình thực hiện dự án. Do đó, đ ể m ỗi mô hình phát
huy được tối đa tác dụng, thì hãy dùng nó đúng nơi, đúng chỗ!
VI. TÀI LIỆU THAM KHẢO
1. http://blog.simplilearn.com/project-management/agile-project-management
2. http://www.allaboutagile.com/agile-methodologies/
3. http://www.scrum.org/
4. http://hanoiscrum.net/hnscrum/whatscrum
5. https://www.udemy.com/blog/agile-vs-waterfall/
6. http://www.hanoiscrum.net
7. http://hanoiscrum.net/hnscrum/learning/106-tongquanagile1
11/14/2013
nguon tai.lieu . vn
