Đề tài: Tìm hiểu về Agile project managemen

Chia sẻ: Cuong Vo | Ngày: | Loại File: DOCX | Số trang:15

Thêm vào BST

Báo xấu

204
lượt xem 29
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Đề tài tham khảo: Tìm hiểu về Agile project managemen bộ môn Phương pháp mô hình hóa. Phương pháp quản lý dự án linh hoạt 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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Đề tài: Tìm hiểu về Agile project managemen

ĐẠ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