Đang tải... (xem toàn văn)
Chương 3 - Phương pháp Agile. Chương này cung cấp cho người học những kiến thức cơ bản về: Tuyên ngôn của phương pháp Agile, các nguyên lý của phương pháp Agile, so sánh Agile và waterfall, nguyên tắc cơ bản của phương pháp Agile, tính phù hợp của các phương pháp Agile, một số phương pháp Agile phổ biến.
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 J Paul Gibson: Agile Methods October 2011 Pros Cons Scrum sử dụng Sprint nhỏ để chia hệ thống thành thành phần nhỏ cách hiệu phân chia cho nhóm Scrum hoạt động ban quản lý “tin tưởng nhà phát triển sử dụng phán đốn riêng mình” để hồn thành nhiệm vụ Các thuộc tính scrum khả kiểm sốt nhẹ nhàng tinh tế Vì vậy, đội ngũ phát triển trẻ chưa trưởng thành, Scrum trở rủi ro ng Scrum thiết kế lý tưởng cho cơng ty có “các phương pháp nhanh có” Do đó, cơng ty phải có số kiến thức làm việc phương pháp nhanh trước sử dụng Scrum J Paul Gibson: Agile Methods October 2011 co Một hoạt động scrum “cuộc họp scrum hàng ngày”, giúp thành viên nhóm đưa chứng việc hoàn thành nhiệm vụ cho phép cải tiến liên tục, cho phép áp dụng kỹ thuật từ lên cách nhanh chóng Lean development (phát triển tinh gọn) c om Scrum an 29 30 Lean development ng th 29 30 J Paul Gibson: Agile Methods October 2011 Lean Software Development – key ideas du o Lean software development dịch nguyên tắc thực hành sản xuất tinh gọn sang lĩnh vực phát triển phần mềm Được điều chỉnh từ Hệ thống sản xuất Toyota, tiểu văn hóa ủng hộ tinh gọn xuất cộng đồng Agile: • u • cu • is a translation of lean manufacturing principles and practices to the software development domain Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community: • J Paul Gibson: Agile Methods October 2011 Cuộc sống dễ dàng nhiều khách hàng ngừng thay đổi suy nghĩ họ Hãy để khách hàng trì hỗn định họ xác họ muốn lâu tốt họ yêu cầu điều đó, đưa cho họ nhanh đến mức họ khơng có thời gian để thay đổi ý định Các thiết kế tuyệt vời đến từ nhà thiết kế vĩ đại nhà thiết kế vĩ đại hiểu thiết kế xuất họ phát triển hiểu biết ngày cao vấn đề, thu thập số lượng lớn yêu cầu Cung cấp hệ thống làm việc nhanh QUESTION: Do you agree with this? 31 31 32 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt Lean Software Development J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods October 2011 October 2011 Lean software development: focus on testing Eliminate waste Bất kỳ hoạt động không “tự trả giá” nỗ lực giảm thiểu nơi khác hệ thống cần loại bỏ Amplify learning Các nhà phát triển cần học phương pháp để tạo hệ thống mạnh mẽ Decide as late as possible Lợi ích việc đưa định vào phút cuối tránh đưa định sai lầm sớm sau phải sửa chữa sau co ng c om Deliver as fast as possible Nguyên tắc bạn cung cấp nhanh, làm giảm hội thay đổi yêu cầu Điều phải trả giá lớn thay đổi đến muộn trình phát triển Empower the team Để người chịu trách nhiệm, có động lực gắn bó với đội, họ cần phải chịu trách nhiệm kết ủy quyền để biến thành thực Build integrity in: Điều quan trọng hệ thống trì tính tồn vẹn suốt chu trình phát triển Điều có nghĩa phải kiểm tra tích hợp, kiểm thử đơn vị kiểm thử chung, đặc biệt từ khách hàng See the whole Đừng chia nhỏ hệ thống thành nhiều phần mà giữ nguyên toàn hệ thống an 33 34 ng th 33 34 J Paul Gibson: Agile Methods October 2011 cu u du o Lean software development: focus on testing J Paul Gibson: Agile Methods Lean Software Development October 2011 Pros Cons Tư toàn hệ thống, khó hệ thống phức tạp, giúp đảm bảo tính qn tồn vẹn hệ thống Giảm thời gian tích hợp kể từ phát triển dạng đơn vị số Với hệ thống lớn hệ thống phức tạp, cách để nhà phát triển hình dung cấu trúc thông qua việc phân vùng hệ thống Nhưng LSD đề xuất điều ngược lại, điều khó thực Nhóm làm việc thiết kế quy trình riêng mình, đưa cam kết riêng, thu thập thông tin cần thiết để đạt mục tiêu tự lập sách để đạt mốc quan trọng Quyết định muộn tốt ảnh hưởng xấu đến lịch trình Điều làm tổn hại đến phát triển song song làm tăng thời gian thực 35 35 36 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt Extreme Programming J Paul Gibson: Agile Methods October 2011 J Paul Gibson: Agile Methods October 2011 Extreme Programming (XP) ng c om From: Embracing Change with Extreme Programming, Beck, 1999 co XP is not this extreme! an 37 38 J Paul Gibson: Agile Methods October 2011 du o Extreme Programming (XP) Embracing Change with Extreme Programming, Beck, 1999 ng th 37 38 Extreme Programming (XP) J Paul Gibson: Agile Methods Embracing Change with Extreme Programming, Beck, 1999 October 2011 Làm để xác định thời điểm nên lập trình? Khơng thể lập trình biết lập trình cu u XP coi khoảng thời gian trước hệ thống vào sản xuất lần bất thường nguy hiểm vòng đời dự án cần khắc phục nhanh tốt Tuy nhiên, dự án phải Kết hợp phân tích tổng thể dạng câu chuyện số lượng trường hợp sử dụng Mỗi câu chuyện phải theo định hướng kinh doanh, kiểm tra ước tính Một tháng khoảng thời gian dài để đưa câu chuyện cho dự án Khách hàng chọn phát hành cách chọn tính có giá trị (được gọi câu chuyện XP) số tất câu chuyện có, xác định chi phí câu chuyện tốc độ nhóm việc cài đặt câu chuyện Khách hàng chọn câu chuyện lần lặp lại cách chọn câu chuyện có giá trị cịn lại phát hành, thơng báo lại chi phí câu chuyện tốc độ nhóm Các lập trình viên biến câu chuyện thành nhiệm vụ chi tiết nhỏ mà họ tự nhận trách nhiệm Sau đó, lập trình viên biến nhiệm vụ thành tập hợp trường hợp kiểm thử để chứng minh nhiệm vụ hoàn thành Làm việc với đối tác, lập trình viên làm cho trường hợp kiểm thử chạy, đồng thời cải tiến thiết kế để trì thiết kế đơn giản cho tồn hệ thống 39 39 40 40 CuuDuongThanCong.com https://fb.com/tailieudientucntt J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods October 2011 October 2011 XP Practices I (Usually associated with Agile) XP Practices I (Usually associated with Agile) Planning game Khách hàng định phạm vi thời gian phát hành dựa ước tính lập trình viên cung cấp Các lập trình viên triển khai chức yêu cầu câu chuyện lần lặp Small releases Hệ thống đưa vào sản xuất vài tháng, trước giải toàn vấn đề Các phát hành thực thường xuyên — nơi từ hàng ngày đến hàng tháng Metaphor Hình dạng hệ thống xác định phép ẩn dụ tập hợp phép ẩn dụ chia sẻ khách hàng lập trình viên Simple design Tại thời điểm, thiết kế chạy tất tests, truyền đạt thứ mà lập trình viên muốn giao tiếp, khơng chứa mã trùng lặp có mã lớp phương thức Quy tắc tóm tắt là, "Nói thứ lần lần Tests Các lập trình viên viết test đơn vị Các tests thu thập tất chúng phải chạy xác Khách hàng viết test chức cho câu chuyện lần lặp lại Tất thử nghiệm nên chạy, thực tế, phải đưa định kinh doanh so sánh chi phí cho lỗi biết chi phí chậm trễ .c om Refactoring Thiết kế hệ thống phát triển thông qua biến đổi thiết kế có để giữ cho tất thử nghiệm hoạt động co ng Continuous integration Tích hợp mã hệ thống sau không vài Khi tích hợp, hệ thống xây dựng từ đầu tất kiểm tra phải vượt qua thay đổi bị loại bỏ an 41 42 ng th 41 42 J Paul Gibson: Agile Methods October 2011 J Paul Gibson: Agile Methods October 2011 du o XP Practices II (also found outside Agile) XP – Daily Communication is Key Pair programming Tất mã viết hai người hình / bàn phím / chuột cu u Collective ownership Mọi lập trình viên cải thiện mã đâu hệ thống vào lúc họ thấy có hội On-site customer Một khách hàng ngồi với nhóm tồn thời gian 40-hour weeks Khơng làm thêm tuần thứ hai liên tiếp Ngay thời gian làm thêm sử dụng thường xuyên dấu hiệu vấn đề lớn cần giải Open workspace Nhóm làm việc phịng lớn với buồng nhỏ Lập trình viên theo cặp làm việc máy tính thiết lập trung tâm Just rules Khi thành viên nhóm Extreme, bạn đăng ký để tuân theo quy tắc Nhưng chúng quy tắc Nhóm thay đổi quy tắc lúc miễn họ đồng ý cách họ đánh giá tác động thay đổi 43 43 44 44 CuuDuongThanCong.com https://fb.com/tailieudientucntt J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods The pros of XP October 2011 Để XP thành cơng, cần có kiến thức chun mơn quan trọng • Xây dựng câu chuyện người dùng - Một câu chuyện người dùng mô tả vấn đề cần giải hệ thống xây dựng Những câu chuyện phải viết người dùng phải dài khoảng ba câu Câu chuyện người dùng không mô tả giải pháp, sử dụng ngôn ngữ kỹ thuật chứa yêu cầu truyền thống • Chuyển câu chuyện thành mã - Vì câu chuyện người dùng ngắn mơ hồ, XP hoạt động đại diện khách hàng có mặt để xem xét phê duyệt việc triển khai câu chuyện người dùng • Biến câu chuyện thành mã thử nghiệm - Kiểm thử đơn vị trọng tâm XP, hai điểm xoay quanh chiến lược kiểm thử thông thường giúp kiểm tra hiệu nhiều: Các lập trình viên viết kiểm tra riêng họ họ viết kiểm tra trước viết mã • Thiết kế phát triển - Không phá vỡ thử nghiệm có 45 phải hỗ trợ phát triển gia tăng mở rộng • • • • • • • Nếu hoàn thành tốt, XP cải thiện tinh thần đồng đội Nó xây dựng lực thực tất thành viên nhóm Nó làm cho ngày làm việc thú vị trung thực Nó đưa người khỏi khối họ nói chuyện với TDD (Test-driven development) dạy nhà phát triển cách viết mã chất lượng cách cải thiện quan niệm họ thiết kế; giúp họ cải thiện ước tính Nó cải thiện hồ sơ nhà phát triển Nó cung cấp cho quản lý nhiều công cụ, bao gồm khả dự đốn, tính linh hoạt nguồn lực, tính quán khả hiển thị thực diễn Nó cung cấp cho khách hàng khả xem liệu cơng ty thực lời hứa hay khơng Bạn không dành nhiều thời gian cho họp ngu ngốc, lãng phí bạn khơng tạo nhiều tài liệu vơ ích an co ng • October 2011 c om Extreme Programming (XP) 46 u Thiết kế trở nên tiềm ẩn thay rõ ràng Dựa vào thiết kế rủi ro Rất khó để viết tests tốt Lặp lại thường xuyên làm giảm chất lượng Để làm tốt, bạn cần phải làm thường xuyên - khó để giới thiệu thành cơng cu • • • • • J Paul Gibson: Agile Methods October 2011 du o The cons of XP ng th 45 46 47 47 CuuDuongThanCong.com https://fb.com/tailieudientucntt ... nhiều phần mà giữ nguyên to? ?n hệ thống an 33 34 ng th 33 34 J Paul Gibson: Agile Methods October 2011 cu u du o Lean software development: focus on testing J Paul Gibson: Agile Methods Lean Software. .. this? 31 31 32 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt Lean Software Development J Paul Gibson: Agile Methods J Paul Gibson: Agile Methods October 2011 October 2011 Lean software. .. 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ó