Bài giảng Lập trình cực đoan

LẬP TRÌNH CỰC ĐOANeXtreme Programming (XP) Trương Minh Sáng Phạm Công Phan Nguyễn Đức Anh Phùng Đức Kiên Nguyễn Quang Dũng Nhóm 3: NỘI DUNG Tổng quan về XP. Cách giải quyết của XP. Các quy tắc và luật lệ trong XP. Bắt đầu với XP như thế nào? Một dự án XP lý tưởng. Vai trò của con người trong XP. XP và các nhận xét. Kết luận. TỔNG QUAN VỀ XP TỔNG QUAN XP là gì? Đối tượng của XP? Một phương pháp luận mới Sự cải tiến của XP ĐẶT VẤN ĐỀ Lập trình đôi (Pair Programming) là một kỹ thuật lập trình mà sản phẩm phần mềm được tạo ra từ những cặp lập trình viên. Người viết code: nghĩ cụ thể về đoạn code đang viết Người quan sát: kiểm tra và suy nghĩ về chiến lược của toàn bộ chương trình LẬP TRÌNH ĐÔI Code được viết ra nhanh hơn, ít lỗi hơn Có ít nhất hai người hiểu thấu đáo về các đoạn code đã viết LẬP TRÌNH ĐÔI Có ít nhất hai người hiểu thấu đáo về các đoạn code đã viết. Khuyến khích các ý tưởng mới. Cỗ vũ tinh thần làm việc nhóm. Là một phương tiện để các lập trình viên học hỏi lẫn nhau. Tạo cơ hội tiếp thu kiến thức về hệ thống. Làm chuyện lập trình đở buồn chán. KHÁI NIỆM XP Là một cách tiếp cận thận trọng và kỷ luật trong phát triển phần mềm Là một con đường hiệu quả, ít rủi ro, linh hoạt, khoa học và có thể dự đoán để phát triển phần mềm. PHƯƠNG PHÁP LUẬN Phản hồi sớm, cụ thể và liên tục từ các chu kỳ ngắn. Cách tiếp cận lập kế hoạch tăng trưởng Khả năng lập lịch linh hoạt việc thi hành các chức năng đáp ứng lại sự thay đổi nghiệp vụ nếu cần. Các kiểm thử tự động viết bởi các lập trình viên để giám sát quá trình phát triển, làm tăng tính khả mở và tin cậy của hệ thống Hình thức giao tiếp trực tiếp, các kiểm thử và mã nguồn để truyền đạt cấu trúc hệ thống. Quá trình thiết kế tiến hóa không ngừng. Sự cộng tác chặt chẽ của các lập trình viên. Thói quen làm việc với xu hướng ngắn hạn của các lập trình viên cũng như xu hướng dài hạn của các dự án. ĐỐI TƯỢNG CỦA XP Dự án phát triển bởi đội từ 2-10 người. Phân phối phần mềm mà khách hàng cần vào đúng lúc mà họ cần. CẢI TIẾN CỦA XP Hầu hết các ý tưởng của XP là cũ Đặt tất cả các quy tắc vào một khung. Đảm bảo các quy tắc được thực hiện triệt để nhất có thể. Đảm bảo các quy tắc hỗ trợ lẫn nhau ở mức độ lớn nhất có thể. ĐẶC ĐIỂM CỦA XP Nhấn mạnh vào việc thỏa mãn yêu cầu khách hàng. Trao quyền cho lập trình viên thay đổi yêu cầu khách hàng. Tập trung vào làm việc theo nhóm XP cài đặt một con đường đơn giản nhưng hiệu quả để cho phép phong cách phát triển theo nhóm. THAY ĐỔI CÁCH LẬP TRÌNH Tập trung vào vấn đề con người. So sánh giữa một chương trình phức tạp, tối ưu và một chương trình đơn giản, dễ hiểu. Tập trung vào kiểm thử, phát hiện sớm các lỗi. Lập trình viên có quyền thay đổi yêu cầu nghiệp vụ từ phía khách hàng. THAY ĐỔI CÁCH LẬP TRÌNH Lập trình viên giao tiếp với khách hàng và đồng đội. Giữ thiết kế đơn giản và rõ ràng. Thu được phản hồi từ kiểm thử phần mềm. Phân phối chương trình đến khách hàng nhanh nhất có thể và bắt thực hiện thay đổi theo đề xuất khách hàng. CÁCH GIẢI QUYẾT CỦA XP ĐẶT VẤN ĐỀ Vấn đề cơ bản của phát triển phần mềm là rủi ro Các loại rủi ro: Sai lệch với lịch trình Dự án bị hủy bỏ Hệ thống chạy khó ĐẶT VẤN ĐỀ Các loại rủi ro: Tỷ lệ sai sót Hiểu sai yêu cầu Thay đổi yêu cầu Làm tăng tính chất lỗi Nhân viên nghỉ việc XP LÀM ĐƯỢC GÌ? Sai lệch với lịch trình. Dự án bị hủy bỏ . Không tương thích với hệ thống Tỉ lệ lỗi Hiểu sai yêu cầu Thay đổi yêu cầu Làm tăng tính chất lỗi Nhân viên nghỉ việc CÁC QUY TẮC VÀ LUẬT LỆ TRONG XP Lên kế hoạch Lập User stories Lập kế hoạch xuất phẩm Định kỳ tạo các sản phẩm nhỏ Đo tiến độ dự án Chia dự án thành các bước lặp Lên kế hoạch bắt đầu mỗi bước lặp Luân chuyển nhân lực Tổ chức họp đứng hàng ngày Sửa XP khi nó sụp Lập User Stories Được khách hàng lập ra để mô tả những gì hệ thống cần phải làm cho họ. Chúng gần giống như kịch bản sử dụng. Được sử dụng để ước lượng thời gian cho kế hoạch xuất phẩm. User stories còn hướng đến việc tạo ra các test chấp nhận. Lập User Stories Điểm khác biệt giữa User Stories và tài liệu yêu cầu là mức độ chi tiết. User Stories chỉ cung cấp đủ thông tin để ước lượng thời gian cài đặt story. Một điểm khác biệt khác giữa stories và tài liệu yêu cầu chính là sự tập trung vào nhu cầu người dùng. Nên cố gắng giữ các stories tập trung vào nhu cầu và các lợi ích của người dùng. Lên kế hoạch xuất phẩm Lên kế hoạch xuất phẩm để tạo một kế hoạch xuất phẩm là nền tảng cho toàn bộ dự án, dùng để tạo các kế hoạch cho các bước lặp. Điểm cốt lõi của cuộc họp kế hoạch xuất phẩm nhằm giúp đội phát triển ước lượng mỗi user story tốn bao thời gian về mặt ý tưởng. Khách hàng cũng quyết định story nào là quan trọng nhất và mức độ ưu tiên cao nhất để hoàn thành Lên kế hoạch xuất phẩm Có thể lên kế hoạch theo thời gian hay phạm vi. Tiến độ của dự án được dùng để xác định hoặc có bao nhiêu story có thể cài đặt trước một ngày dự tính (thời gian) hoặc thời gian một tập các story cần để hoàn thiện (phạm vi). Lên kế hoạch xuất phẩm Lên kế hoạch xuất phẩm một dự án có thể xác định bởi bốn biến: Phạm vi là bao nhiêu công việc được hoàn tất. Tài nguyên là bao nhiêu nhân lực tham gia. Thời gian là khi dự án hay sản phẩm được hoàn tất. Chất lượng là phầm mềm tốt đến mức nào và mức độ kiểm thử ra sao. Lên kế hoạch xuất phẩm Khi kế hoạch xuất phẩm được tạo ra, không được thay đổi các ước lượng user story. Do đó hãy cố gắng dàn xếp một kế hoạch khả thi và thương lượng tới khi người phát triển, khách hàng và nhà quản lý đồng ý với kế hoạch đó. Định kỳ tạo các sản phẩm nhỏ Đội phát triển cần phải thường xuyên xuất phẩm các phiên bản lặp của hệ thống cho khách hàng. Điều này rất quan trọng để thu thập các phản hồi có giá trị đúng lúc để có các tác động tới việc phát triển hệ thống. Đo tiến độ dự án Tiến độ dự án (hay tiến độ) là một thông số cho biết công việc tiến triển nhanh ra sao trong dự án Để đo tiến độ dự án, bạn chỉ việc đếm có bao nhiêu user story, hay có bao nhiêu tác vụ lập trình được hoàn tất trong suốt bước lặp. Tính tổng các ước lượng những story hay tác vụ nhận được. Đo tiến độ dự án Trong cuộc họp lên kế hoạch xuất phẩm, tiến độ dự án trong các story đã hoàn tất có thể được dùng để ước lượng bao nhiêu story sẽ được làm. Trong cuộc họp lên kế hoạch bước lặp, người phát triển được phép đăng ký để làm cùng số ngày ước lượng bằng với tiến độ dự án được đo trong bước lặp trước đó. Chia dự án thành các bước lặp Phát triển bước lặp tăng tính linh hoạt cho quá trình phát triển. Phân chia lịch trình phát triển của bạn thành khoảng một tá các bước lặp kéo dài 1 cho đến 3 tuần. Lên kế hoạch bắt đầu mỗi bước lặp Một cuộc họp lên kế hoạch cho bước lặp được tổ chức vào đầu mỗi bước lặp để tạo kế hoạch cho tác vụ lập trình của bước lặp đó. User story được khách hàng chọn cho bước lặp này từ kế hoạch xuất phẩm theo thứ tự mức độ giá trị nhất đối với khách hàng. Các test chấp nhận thất bại cần sửa cũng được lựa chọn. Luân chuyển nhân lực Luân chuyển nhân lực để tránh những mất mát chất xám nghiêm trọng và coding nút cổ chai. Đào tạo chéo (cross training) rất quan trọng để tránh việc cô lập kiến thức. Luân chuyển nhân lực quanh mã code kết hợp với lập trình đôi chính là đào tạo chéo. Luân chuyển nhân lực Điều này thay cho chỉ có vài người làm việc quá sức trong khi những thành viên khác trong đội có quá ít việc để làm, lúc này, cả đội sẽ có năng suất hơn. Lập trình đôi giúp ta có thể tránh giảm năng suất và đảm bảo tính liên tục tư duy. Tổ chức họp đứng hàng ngày Một cuộc họp đứng vào mỗi sáng để trao đổi các vấn đề, giải pháp, và đẩy mạnh trọng tâm của đội. Khi bạn tổ chức cuộc họp đứng, số người tham dự có thể dựa trên những ai thực sự cần thiết và sẽ tham gia đóng góp. Với số người tham gia giới hạn, hầu hết cuộc họp có thể tổ chức trước một máy tính, để có thể quan sát các đoạn code và thử nghiệm các ý tưởng. Sửa XP khi nó bị sụp Sửa chữa XP khi nó bị sụp. Theo sát các quy tắc của XP để khởi đầu. Các quy tắc phải được bám sát cho tới khi đội thay đổi nó. Hãy họp để nói về những gì đang làm và những gì không và nghĩ ra các cách để cải tiến XP. Thiết kế Tính đơn giản Chọn một ẩn dụ hệ thống Sử dụng thẻ CRC Sử dụng Spike Solution Không chèn các chức năng vào quá sớm Refactor bất cứ lúc nào và bất cứ khi nào có thể Tính đơn giản Một thiết kế đơn giản luôn mất ít thời gian để hoàn thành hơn một thiết kế phức tạp. Nếu bạn tìm thấy có gì đó quá phức tạp, thay thế nó bằng thứ đơn giản hơn. Sẽ luôn nhanh và rẻ hơn để thay thế đoạn mã phức tạp vào lúc này, trước khi bạn phí quá nhiều thời gian vào nó. Chọn một ẩn dụ hệ thống Chọn một ẩn dụ hệ thống để giúp toàn đội làm việc thống nhất bằng cách đặt tên các lớp và phương thức hợp lý. Những gì bạn đặt tên cho các đối tượng rất quan trọng cho việc hiểu toàn bộ thiết kế của hệ thống cũng như đoạn mã sử dụng lại. Sử dụng thẻ CRC Dùng thẻ CRC (Class, Responsibilities, Collaboration). Ưu điểm là nó giúp ta có cái nhìn tổng quan về đối tượng. Bản thân những thẻ CRC được dùng để đại diện cho những đối tượng. Sử dụng thẻ CRC Một vùng CRC giúp một người đóng vai hệ thống bằng cách nói về những đối tượng gửi thông điệp tới các đối tượng khác. Bằng việc đi lần lượt các bước như vậy, điểm yếu của quá trình và các vấn đề sẽ dễ dàng hé mở. Tạo Spike Solution để giảm ủi ro Tạo spike solution để tìm câu trả lời cho các vấn đề khó về công nghệ hay thiết kế. Mục đích điều này là giảm thiểu rủi ro của vấn đề công nghệ hoặc tăng độ tin cậy của ước lượng user story. Khi độ khó của mặt công nghệ đe dọa đến độ phát triển dự án, đặt một cặp developers vào vấn đề khoảng 1 hay 2 tuần để giảm thiểu rủi ro. Không chèn các chức năng vào quá sớm Giữ cho hệ thống không bị xáo trộn bởi các chức năng bạn cho rằng sẽ sử dụng sau này. Tất cả chúng ta muốn chèn chức năng đó ngay lúc này. Nhưng ta cần nhớ rằng, chúng ta sẽ không thực sự cần chúng. Bỏ qua các yêu cầu tương lai, tập trung vào công việc của hôm nay Luôn luôn refactor Khi chúng ta bỏ đi các dư thừa, loại bỏ các chức năng không được dùng, làm mới các thiết kế cũ, chúng ta đang refactor. Refactor xuyên suốt vòng đời dự án nhằm tiết kiệm thời gian và nâng cao chất lượng. Refactor nhằm giúp cho thiết kế đơn giản, tránh những xáo trộn vô nghĩa, và phức tạp. Nó giúp cho đoạn code của bạn sang sủa và súc tích, vì vậy rất dễ để hiểu, sửa đổi và mở rộng. Luôn luôn refactor Bạn có thể phải bỏ đi một thiết kế hoàn thiện và chấp nhận thiết kế được bạn khám phá bằng refactor. Bạn phải thấy rằng thiết kế mà bạn hình dung là một hướng dẫn tốt, nhưng giờ thì nó đã lỗi thời. Hãy bỏ các ý niệm của bạn về những gì hệ thống nên hay không nên và cố gắng quan sát một thiết kế mới khi nó hiện ra trước mắt bạn. NỘI DUNG LẬP TRÌNH VÀ KIỂM THỬ TRONG LẬP TRÌNH CỰC ĐOAN. NỘI DUNG LẬP TRÌNH: Luôn gắn liền khách hàng Lập trình theo chuẩn định trước Viết chương trình kiểm thử đơn vị trước Lập trình đôi trong mọi giai đoạn Tích hợp tuần tự NỘI DUNG LẬP TRÌNH: Thường xuyên ghép mã Sở hữu mã tập thể Đừng vội lạc quan NỘI DUNG Luôn gắn liền với khách hàng Là một yêu cầu của Lập trình Cực đoan ở mọi giai đoạn Khách hàng tham gia như một thành viên đội phát triển Sử ký người dùng. NỘI DUNG Lập trình theo chuẩn định trước Mã nguồn theo một mẫu và định dạng chuẩn Giúp cho toàn bộ đội phát triển hiểu mã nguồn NỘI DUNG Viết chương trình kiểm thử đơn vị trước Làm cho quá trình viết chương trình thực sự nhanh và dễ dàng hơn. Giúp lập trình viên thực sự hiểu được cái gì phải làm Lập trình viên nhận được phản hồi ngay lập tức. NỘI DUNG Lập trình đôi Sản phẩm của 2 lập trình viên và 1 chiếc máy tính Tăng chất lượng phần mềm mà không mất thời gian chuyển giao NỘI DUNG Tích hợp tuần tự Việc tích hợp song song gây nhiều lỗi không phát hiện được do kết hợp các module không được test cùng nhau. Tích hợp mã nguồn từ nhiều lập trình viên. NỘI DUNG Thường xuyên tích hợp mã Lập trình viên thường xuyên tích hợp mã và lưu trữ mã Tránh việc phân mảnh kết quả của công việc Tận dụng kết quả của tập thể NỘI DUNG Sở hữu mã tập thể Khuyến khích các thành viên đóng góp ý tưởng mới cho dự án. Bất cứ một thành viên nào cũng có thể thay đổi một dòng mã bất kỳ để thêm chức năng hay debug. NỘI DUNG Đừng vội lạc quan Đừng lạc quan cho đến khi kết thúc dự án Chỉ cần biết làm đúng cách và nhanh hơn. NỘI DUNG KIỂM THỬ TRONG LẬP TRÌNH CỰC ĐOAN NỘI DUNG Mọi đoạn mã phải qua tất cả kiểm thử đơn vị trước khi phát hành. Điều phải làm khi có bug xảy ra Quy tắc Kiểm thử chấp nhận. NỘI DUNG Mọi đoạn mã phải có kiểm thử đơn vị Kiểm thử đơn vị là một thành phần quan trọng nhất của Lập trình cực đoan Cần có một Unit Test Framework để sinh ra bộ kiểm thử một cách tự động. Tạo chương trình Kiểm thử trước khi viết chương trình chính Mã chương trình lưu trữ kèm với chương trinhg test. NỘI DUNG Khi có bug xảy ra Tạo ra Kiểm thử chấp nhận trước khi debug Giúp người dùng định nghĩa rõ ràng vấn đề của chương trình gặp phải Có Failed Test Case để kiểm tra bug đã được fix chưa. NỘI DUNG Thường xuyên kiểm thử chấp nhận và công khai điểm kiểm thử Kiểm thử chấp nhận là kiểm thử hộp đen Kiểm thử chấp nhận tạo ra từ sử ký người dùng Người dùng sử dụng điểm số kiểm thử để quyết định failed test hay mức độ ưu tiên Điểm test công khai cho đội phát triển. HƯỚNG DẪN SỬ DỤNG XP KHI NÀO NÊN SỬ DỤNG XP XP được tạo ra để giải quyết các bài toán mà yêu cầu luôn thay đổi: Khách hàng không tưởng tượng hết chức năng của hệ thống Yêu cầu các chức năng thay đổi theo từng tháng. XP giải quyết vấn đề rủi ro trong dự án. XP thích hợp với một đội nhỏ. Có khả năng tạo kiểm thử CHU KỲ PHÁT TRIỂN Một cặp lập trình viên làm việc cùng trên một chương trình. Phát triển được điều khiển bởi các kiểm thử. Cặp làm việc không làm các ca kiểm thử chạy. Cặp làm việc thêm giá trị để phân tích, thiết kế, ứng dụng, và kiểm thử hệ thống. Chúng thêm giá trị nơi mà hệ thống cần nó. Sự tích hợp phát triển sau, bao gồm tích hợp kiểm thử. VÒNG ĐỜI DỰ ÁN XP Vòng đời của dự án kiểu XP Khảo sát Lập kế hoạch Vòng lặp cho xuất phẩm đầu tiên Sản xuất Bảo trì Kết thúc Khảo sát Tạo ra niềm tin vào công cụ, công nghệ và kỹ năng để phát triển hệ thống. Lập trình viên luôn sử dụng tất cả các công nghệ mà họ sẽ sử dụng trong hệ thống sản xuất. Khảo sát những tiện ích của kiến trúc hệ thống. Xây dựng một hệ thống như những gì sẽ xây dựng cuối cùng theo ba hay bốn cách. Các cặp khác nhau có thể thử hệ thống bằng các cách khác nhau và so sánh với nhau và quan sát những khác nhau sẽ hiện ra. Khảo sát Thận trọng trong việc chấp nhận những đề nghị cho việc sử dụng công nghệ cuối cùng. Những lập trình viên đó có thể thử nghiệm với sự giới hạn thực thi của công nghệ mà họ sẽ sử dụng. Thí nghiệm với các ý tưởng kiến trúc. Thực hiện chúng theo ba cách khác nhau trong một ngày và xem cái nào là tốt nhất. Đánh giá tất cả các nhiệm vụ của việc lập trình mà họ làm trong suốt quá trình khảo sát. Lập kế hoạch Mục đích của giai đoạn lập kế hoạch là để cho các khách hàng và các lập trình viên cùng chấp nhận một thời điểm để những phản hồi nhỏ nhất và có giá trị nhất sẽ được hoàn thành. Kế hoạch cho lần đưa ra sản phẩm đầu tiên có thể trong vòng từ hai đến sáu tháng. Ngắn hơn khoảng thời gian đó, bạn gần như chắc chắn khó có thể giải quyết các vấn đề chuyên môn. Nhiều hơn vài tháng thì sẽ có thể có quá nhiều rủi ro Vòng lặp cho xuất phẩm đầu tiên Giai đoạn tiếp theo là các bước lặp kéo dài từ một đến bốn tuần. Mỗi bước lặp sẽ cho ra một tập các test case chức năng cho mỗi phản hồi trong bước lặp đó. Vòng lặp đầu tiên sẽ định vị kiến trúc hệ thống Thực hiện các thay đổi khi kế hoạch bị chệch hướng: Kế hoạch User stories Quá trình phát triển phần mềm Vòng lặp cho xuất phẩm đầu tiên Một cách hoàn thiện, tại cuối mỗi bước lặp, khách hàng sẽ được hoàn tất các tính năng kiểm thử và chúng đều có thể chạy. Hãy tổ chức một buổi vui vẻ để ăn mừng sự kiện này – bạn đã đạt được chất lượng phần mềm đúng tiến độ. Cuối vòng lặp cuối cùng, bạn đã sẵn sàng bước vào sản xuất. Sản xuất Chọn bước lặp 1 tuần. Chuẩn bị các kiểm thử để chứng minh sự phù hợp của hệ thốngSử dụng các kiểm thử song song. Thận trọng hơn với rủi ro. Thận trọng hơn với những thay đổi đưa ra. Bảo trì Cung cấp các chức năng mới. Đảm bảo hệ thống đang tồn tại hoạt động tốt. Thêm, bớt nhân lực dự án. Mỗi một xuất phẩm bắt đầu từ quá trình khảo sát Những lập trình viên đó có thể thử nghiệm với sự giới hạn thực thi của công nghệ mà họ sẽ sử dụng. Thí nghiệm với các ý tưởng kiến trúc. Thực hiện chúng theo ba cách khác nhau trong một ngày và xem cái nào là tốt nhất. Đánh giá tất cả các nhiệm vụ của việc lập trình mà họ làm trong suốt quá trình khảo sát. Kết thúc Khách hàng không đưa thêm các phản hồi mới. Viết các tài liệu hướng dẫn sử dụng. Các thảo thuận giữa khách hàng, người quản lý và đội phát triển khi không thể thêm vào hệ thống một yêu cầu chức năng nào đó. Cơ hội gây dựng một đội cốt cán. VAI TRÒ CỦA NHÂN TỐ CON NGƯỜI TRONG XP Nhân tố con người Lập trình viên Khách hàng Kiểm thử viên Người giám sát Người hướng dẫn Người tư vấn Ông chủ Lập trình viên Là trái tim của XP. Ở mặt ngoài, giống như là một lập trình viên trong môn phát triển phần mềm. Ở mặt trong, các sự tập trung là khá khác nhau. Công việc của bạn sẽ không hoàn thành khi máy tính hiểu nó phải làm gì. Giá trị đầu tiên của bạn là sự liên lạc với mọi người. Nếu chương trình chạy, nhưng lại có vài bộ phận tất yếu của bộ máy liên lạc chưa chạy, có nghĩa là bạn chưa hoàn thành công việc.  Lập trình viên  Nhiều kỹ năng phải có: Thói quen giản dị Khả năng lập trình Khả năng nâng cấp mã Khả năng thử nghiệm các đoạn mã Chia sẻ quyền sở hữu đoạn mã Khách hàng Là phần còn lại trong hai mặt của lập trình cực đoan Các kỹ năng cần thiết: Viết các phản hồi. Đưa ra các quyết định. Cách viết các kiểm thử chức năng Lòng dũng cảm để thực hiện thay đổi. Người kiểm thử Vai trò: của người kiểm thử trong một nhóm XP được tập trung vào khách hàng. Trách nhiệm: giúp đỡ khách hàng lựa chọn và viết ra các kiểm thử chức năng Nhiệm vụ: chạy tất cả các kiểm thử, thông báo các kết quả kiểm thử, và đảm bảo các công cụ kiểm thử vẫn chạy tốt Người giám sát Là lương tâm của cả nhóm làm việc. Đưa ra các ước lượng và sai số. Chịu trách nhiệm lưu giữ các số liệu kiểm thử chức năng, các báo cáo lỗi. Kỹ năng cần thiết: khả năng thu thập thông tin mà không làm ảnh hưởng đến hoạt động của cả đội.  Người hướng dẫn  Chịu trách nhiệm cho toàn bộ quá trình Giữ cho thành viên đi đúng hướng và giữ sự tập trung. Phải hiểu các ứng dụng của XP nhiều hơn, sâu hơn các thành viên khác. Làm việc tốt nhất khi làm việc gián tiếp Vai trò của người hướng dẫn sẽ giảm dần khi nhóm làm việc thành thạo hơn.  Người tư vấn  Có hiểu biết sâu sắc về kỹ thuật Không xuất hiện nhiều chuyên gia trong dự án XP Làm việc với mức độ nhẹ nhàng. Những gì bạn làm thường không được công nhận ! Ông chủ Lòng dũng cảm, sự tự tin và sự khẳng định vào đội phát triển. Liên tục hỏi và lắng nghe các giải thích. Củng cố lòng tin của đội. NHẬN XÉT VỀ XP Điều làm XP trở nên khó thực thi XP đơn giản trong các chi tiết nhưng nó lại khó để thực thi. Vấn đề: đưa tất cả các bộ phận vào đúng vị trí đồng thời và giữ chúng cân bằng. Thật khó để làm những thứ đơn giản. Thật khó để nhận ra những điều mà bạn không biết. Thật khó để phối hợp. Thật khó để phá bỏ hàng rào cảm xúc. ĐIỂM YẾU CÒN TỒN TẠI Phương pháp luận dựa trên việc phòng tránh sự rủi ro. Sự sợ hãi được nhấn mạnh: Làm các việc không trọng tâm Dự án bị hủy bỏ vì không tạo đủ các tiến trình kỹ thuật Gây ra các quyết định kinh doanh tồi Có các nhân viên kinh doanh tạo các quyết định kỹ thuật sai lầm Tiến tới kết thúc sự để ý đến xây dựng hệ thống và nhận ra rằng nên sử dụng thêm thời gian với nó. BẠN KHÔNG CẦN QUAN TÂM ĐẾN Mã hóa chương trình. Thay đổi suy nghĩ. Bắt đầu mà không có hiểu biết gì về tương lai. Phụ thuộc vào người khác. Thay đổi phân tích và thiết kế của hệ thống đang vận hành. Viết các kiểm thử.