NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) 1 1 Chương 3 Phương pháp Agile • Outline – 1 Đặt vấn đề – 2 Tuyên ngôn của phương pháp Agile – 3 Các nguyên lý của phương pháp Agile[.]
Chương Phương pháp Agile • Outline NHẬP MƠN CƠNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) • Scrum • Lean development • Extreme Programming (XP) co ng c om – Đặt vấn đề – Tuyên ngôn phương pháp Agile – Các nguyên lý phương pháp Agile – So sánh Agile Waterfall – Nguyên tắc phương pháp Agile – Tính phù hợp phương pháp Agile – Một số phương pháp Agile phổ biến an Mơ hình thác nước – nhắc lại du o Đặt vấn đề ng th • Mơ hình Thác nước (nổi bật năm 70) • Mơ hình thác nước mơ hình vịng đời lâu đời nhất; đề xuất Winston Royce vào năm 1970 • Mơ hình gọi thác nước thường vẽ với chuỗi hoạt động qua giai đoạn vòng đời “xuống dốc” từ trái sang phải: • Do đó: cu – Khơng xác định rủi ro – Xây dựng sai sản phẩm – Bị cơng nghệ chi phối u • Tại dự án phần mềm lại thất bại? – phân tích, yêu cầu, đặc tả, thiết kế, cài đặt, kiểm thử, bảo trì – Việc áp dụng quy trình vòng đời phần mềm tốt giúp giải vấn đề – Tuy nhiên, điều khơng đảm bảo thành cơng Vì khơng có q trình phát triển hồn tồn hợp lý • Có nhiều phiên mơ hình thác nước: – giai đoạn / hoạt động cấu trúc theo mức độ chi tiết khác – phản hồi linh hoạt 3 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt Vòng đời lý tưởng - Thác nước (Nghiêm ngặt) Khơng có phản hồi Non-strict waterfall model co ng c om • Mặc dù mơ hình thác nước nhấn mạnh chuỗi tuyến tính pha, thực tế, thực tế có lượng lớn lặp lại pha trước đó, điểm tạo mũi tên dẫn ngược lên thác nước an • Điểm mạnh: u cầu du o Mơ hình thác nước ng th • Mơ hình thác nước: – Nhấn mạnh việc hoàn thành giai đoạn trước tiếp tục – Nhấn mạnh việc lập kế hoạch sớm, đầu vào khách hàng thiết kế – Nhấn mạnh kiểm tra phần khơng thể thiếu vịng đời – Cung cấp cổng chất lượng giai đoạn vòng đời u – trọng nhiều vào tài liệu phân tích thiết kế cu • Phương pháp Agile: – kết hợp trình tạo mẫu dựa thử nghiệm: nơi có phát triển liên tục lập trình (viết mã) liên tục xác nhận yêu cầu khách hàng • Điểm yếu: – Phụ thuộc vào yêu cầu xác định sớm từ đầu – Phụ thuộc vào việc tách yêu cầu khỏi thiết kế – Không khả thi số trường hợp địi hỏi có nhiều thay đổi – Nhấn mạnh vào sản phẩm quy trình 7 8 CuuDuongThanCong.com https://fb.com/tailieudientucntt History of Agile: Where Did it Come From? Lịch sử Agile • Agile khơng phải công cụ hay phương pháp nhất, mà triết lý đưa vào năm 2001 • Agile thay đổi đáng kể từ cách tiếp cận phát triển phần mềm nặng theo hướng tài liệu chẳng hạn mơ hình thác nước Pekka Abrahamsson, Juhani Warsta, Mikko T Siponen, and Jussi Ronkainen 2003 New directions on agile methods: a comparative analysis In Proceedings of the 25th International Conference on Software Engineering (ICSE '03) IEEE Computer Society, Washington, DC, USA, 244-254 .c om 1990 co ng 2000 an 10 ng th 10 Tuyên ngôn phương pháp Agile du o Agile: Values, Principles and Methods cu u • Cách tốt để phát triển phần mềm làm điều giúp người khác làm điều Thơng qua việc này, giá trị sau nhận ra: – Các cá nhân tương tác qua quy trình cơng cụ – Phần mềm làm việc dựa tài liệu toàn diện – Sự hợp tác khách hàng trình đàm phán hợp đồng – Đáp ứng thay đổi so với việc tuân theo kế hoạch • Mặc dù giá trị có mục bên phải, mục bên trái coi trọng http://agilemanifesto.org/ 11 11 12 12 CuuDuongThanCong.com https://fb.com/tailieudientucntt Agile: 12 nguyên lý .c om Phần mềm làm việc thước đo tiến Các quy trình Agile thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển người dùng trì tốc độ phát triển liên tục Sự quan tâm liên tục, xuất sắc kỹ thuật thiết kế tốt giúp tăng cường nhanh nhẹn 10 Sự đơn giản - nghệ thuật tối đa hóa khối lượng cơng việc chưa hồn thành - điều cần thiết 11 Các kiến trúc, yêu cầu thiết kế tốt xuất từ nhóm dự án 12 Theo định kỳ, nhóm phản ánh cách trở nên hiệu hơn, sau điều chỉnh hoạt động cho cho phù hợp ng Ưu tiên cao làm hài lịng khách hàng thơng qua việc phân phối sớm liên tục phần mềm có giá trị Hoan nghênh yêu cầu thay đổi, giai đoạn muộn việc phát triển Các quy trình nhanh khai thác thay đổi lợi cạnh tranh khách hàng Cung cấp sản phẩm phần mềm thường xuyên, từ vài tuần đến vài tháng, ưu tiên khoảng thời gian ngắn Người kinh doanh nhà phát triển phải làm việc hàng ngày suốt dự án Xây dựng dự án xung quanh cá nhân có động lực Cung cấp cho họ môi trường hỗ trợ mà họ cần, tin tưởng để họ hoàn thành công việc Phương pháp hiệu để truyền tải thơng tin đến nhóm phát triển trị chuyện trực tiếp co Agile: 12 nguyên lý an 13 14 Nguyên tắc bản: số lần lặp du o Agile vs Waterfall ng th 13 14 • Các phương pháp luận Agile gồm bước lặp lại • Các nhóm nhỏ làm việc với bên liên quan để xác định nguyên mẫu nhanh, chứng khái niệm phương tiện trực quan khác để mô tả vấn đề cần giải Nhóm xác định yêu cầu cho việc lặp lại, phát triển mã, xác định chạy tập lệnh kiểm tra tích hợp người dùng xác minh kết • Việc kiểm định diễn sớm nhiều q trình phát triển cu u • Waterfall có giai đoạn riêng biệt với điểm kiểm tra phân phối, phương thức nhanh có lần lặp đầu lần lặp nhanh mã nguồn sử dụng để đánh giá đáp ứng yêu cầu thay đổi phát triển người dùng • Waterfall giả định hiểu rõ yêu cầu từ đầu Nhưng phát triển phần mềm, bên liên quan thường khơng biết họ muốn khơng thể nói rõ u cầu họ Với kiểu thác nước, phát triển mang lại khách hàng muốn khách hàng u cầu • Với Agile nhấn mạnh vào khách hàng yêu cầu họ 15 15 16 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt Tính phù hợp phương pháp Agile Một số phương pháp Agile phổ biến ng Phát triển quy mô lớn (> 20 nhà phát triển) Phát triển phân tán (các nhóm khơng nằm chung) Các cơng ty kiểm sốt kỳ quặc Khách hàng người liên hệ không đáng tin cậy Bắt buộc quy trình nhanh nhóm phát triển Nhà phát triển thiếu kinh nghiệm co – – – – – – Scrum Lean Development Extreme programming (XP) Adaptive Software Development (ASD) Agile Modeling Crystal Methods Dynamic System Development Methodology (DSDM) • Feature Driven Development • • • • • • • c om • Khó xác định loại dự án phần mềm phù hợp cho cách tiếp cận Agile • Nhiều tổ chức lớn gặp khó khăn việc chuyển từ phương pháp truyền thống sang phương pháp Agile (linh hoạt) • Khi Agile có rủi ro: an 17 18 ng th 17 18 J Paul Gibson: Agile Methods Scrum October 2011 du o ‘Scrum’ (liên quan đến “scrimmage”) thuật ngữ nhóm người chơi tụ tập với để hồn thành cơng việc mơn bóng bầu dục Trong phát triển phần mềm, cơng việc đưa phát hành Scrums cho vấn đề xấu "Cách tiếp cận quản lý dự án thích ứng tốt cho dự án phần mềm xấu" u Comes from Japan and based from industrial process control theory: cu Takeuchi, Hirotaka and Nonaka, Ikujiro: The New New Product Development Game, Harvard Business Review, 1986 “Stop running the relayy race and take up rugby” "Dừng chạy đua tiếp sức chơi bóng bầu dục" Speed Up development Peter DeGrace and Leslie Hulet Stahl Wicked Problems, Righteous Solutions 1990 Yourdon Press Nhiều vấn đề hệ thống mà nhà phát triển phần mềm gặp phải (các đặc điểm xấu): Khơng có cơng thức xác cho vấn đề xấu Những vấn đề xấu khơng có quy luật dừng Giải pháp cho vấn đề xấu đúng-hay-sai mà tốt-hay-xấu Khơng có thử nghiệm tức thời cuối giải pháp cho vấn đề xấu Mọi giải pháp thực cho vấn đề xấu có hậu Các vấn đề xấu khơng có tập hợp giải pháp tiềm tốt Mọi vấn đề xấu xa Mọi vấn đề xấu coi nguyên nhân vấn đề khác Nguyên nhân vấn đề xấu giải thích theo nhiều cách 10 Người lập kế hoạch (thiết kế) khơng có quyền sai 19 19 20 20 CuuDuongThanCong.com J Paul Gibson: Agile Methods October 2011 https://fb.com/tailieudientucntt J Paul Gibson: Agile Methods Scrums phases J Paul Gibson: Agile Methods Main scrum concepts October 2011 October 2011 Burndown chart Biểu đồ này, cập nhật ngày, cho thấy cơng việc cịn lại sprint Biểu đồ burndown sử dụng để theo dõi tiến trình spint định mục phải loại bỏ khỏi sprint backlog hoãn lại sprint Scrum Phase c om Product backlog Product backlog danh sách đầy đủ yêu cầu — bao gồm lỗi, yêu cầu nâng cao, cải tiến khả sử dụng hiệu suất — khơng có phát hành sản phẩm ScrumMaster ScrumMaster người chịu trách nhiệm quản lý dự án Scrum co ng Sprint backlog Sprint backlog danh sách hạng mục tồn đọng định cho sprint, chưa hoàn thành Trong thực tế phổ biến, khơng có hạng mục tồn đọng sprint phải hai ngày để hoàn thành Sprint backlog giúp nhóm dự đốn mức độ nỗ lực cần thiết để hoàn thành sprint an 21 22 J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods Scrum Meetings du o October 2011 October 2011 Quá trình phát triển chia thành loạt lần lặp ngắn gọi spint Trước sprint, thành viên nhóm xác định hạng mục tồn đọng cho sprint Khi kết thúc sprint, nhóm xem xét sprint để nêu rõ học kinh nghiệm kiểm tra tiến độ cu u Scrum Meetings ng th 21 22 Trong thời gian spint, nhóm có họp hàng ngày Mỗi thành viên nhóm mơ tả công việc thực ngày hôm đó, tiến độ từ ngày hơm trước Để giữ cho họp ngắn gọn, họp phải tiến hành với tất người (họp đứng phòng) The backlog is key: it is populated during the planning phase of a release and defines the scope of the release Việc tồn đọng khóa: điền vào pha lập kế hoạch lần phát hành sản phẩm xác định phạm vi phát hành 23 Khi đủ backlog thực để người dùng cuối tin phát hành đáng đưa vào sản xuất, kết thúc trình phát triển Sau đó, nhóm thực kiểm tra tích hợp, đào tạo tài liệu cần thiết để phát hành sản phẩm 23 24 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt J Paul Gibson: Agile Methods Scrum Meetings J Paul Gibson: Agile Methods Scrum Meetings October 2011 Cuộc họp đứng hàng ngày (còn gọi "cuộc họp hàng ngày", "cuộc họp hàng ngày", "điểm danh buổi sáng", v.v.), để giữ họp ngắn, mô tả sau: October 2011 Mục đích cho daily stand-up Good Start, Improvement, Focus, Team, Status (GIFTS) • Cả nhóm họp hàng ngày để cập nhật tình trạng nhanh chóng Có số mục tiêu cho họp đứng hàng ngày: • Để giúp khởi đầu ngày tốt đẹp • Để hỗ trợ cải thiện • Để củng cố tập trung • Để củng cố tinh thần đồng đội • Để thơng báo xảy c om • Tuy nhiên việc không thực đảm bảo giúp phân biệt phương án hiệu với việc lãng phí thời gian • Đối với người có kinh nghiệm, với việc đứng lên theo năng, gặp cố họ biết phải điều chỉnh để khắc phục tình hình The purpose is not to meet it is to improve Joe Ely, "More on Daily Start-Up Meetings" co • Điều mang lại giá trị đáng kể cho đội ng • Đối với người bắt đầu, thứ gặp trục trặc, có khả họ tìm giải pháp (những phải làm) có nhiều khả từ bỏ hồn việc khơng hỗ trợ an 25 26 ng th 25 26 du o Scrum Meetings u Ai tham dự? Mọi người đại diện từ lĩnh vực khác muốn biết và/hoặc đóng góp vào dự án Trạng thái giao tiếp nhiều họp cần nhiều nỗ lực cu Do Thay số tất họp báo cáo họp hàng ngày Bất kỳ trực tiếp tham gia muốn biết hoạt động hàng ngày dự án nên tham gia họp đứng hàng ngày Nhưng Những người khơng liên quan trực tiếp làm gián đoạn họp họ không rõ hành vi mong đợi Điều giải cách thông báo trước cho người tham gia quan sát viên tiêu dự kiến J Paul Gibson: Agile Methods Scrum Meetings October 2011 Ở đâu và nào? • • • • • • • Gặp gỡ nơi công việc xảy Cùng nơi, lúc Vào đầu ngày? … hay không? Đứng gần Chuẩn bị trước Mười lăm phút hơn… Thực giải vấn đề ngoại tuyến Khuyến khích quyền tự chủ (xoay người điều hành?) 27 27 28 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt ... https://fb.com/tailieudientucntt History of Agile: Where Did it Come From? Lịch sử Agile • Agile công cụ hay phương pháp nhất, mà triết lý đưa vào năm 2001 • Agile thay đổi đáng kể từ cách tiếp cận phát triển phần mềm nặng... để phát triển phần mềm làm điều giúp người khác làm điều Thơng qua việc này, giá trị sau nhận ra: – Các cá nhân tương tác qua quy trình cơng cụ – Phần mềm làm việc dựa tài liệu to? ?n diện – Sự... Ronkainen 20 03 New directions on agile methods: a comparative analysis In Proceedings of the 25th International Conference on Software Engineering (ICSE '' 03) IEEE Computer Society, Washington, DC,