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