Đề tài Tìm hiểu về agile project management

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINHTRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TINKHOA 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 Mục lục SỰ RA ĐỜI CỦA MÔ HÌNH AGILE 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. 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. TÌM HIỂU CHUNG VỀ AGILE 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 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. 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 tham gia 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 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. Chuyển giao tăng dần 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 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. Con người thay vì quy trình 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 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. Chấp nhận thay đổi 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 đượ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. Gìn giữ tính giản dị, dễ hiểu 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 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. Đặ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): 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. CÁC PHƯƠNG PHÁP AGILE Phân loại 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. 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 Development (TDD) 37.1%    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: SCRUM 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 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 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. 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. 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. 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. 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. 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. 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. 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 Đâ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ó. Scrum vận hành như thế nào? 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. SO SÁNH AGILE VÀ WATERFALL Waterfall 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. Agile 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. 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 tuần tự Các bước tách biệt, yêu cầu các bước 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 chính xác mục tiêu cuối cùng Dùng cho các dự án mà kế hoạch đã đượ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ỗ! TÀI LIỆU THAM KHẢO 1. 2. 3. 4. 5. https://www.udemy.com/blog/agile-vs-waterfall/ 6. 7.