Bài thuyết trình Lập trình cực đoan eXtreme Programming (XP)

92 trang ngocly 2270

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài thuyết trình Lập trình cực đoan eXtreme Programming (XP)", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_thuyet_trinh_lap_trinh_cuc_doan_extreme_programming_xp.ppt

Nội dung text: Bài thuyết trình Lập trình cực đoan eXtreme Programming (XP)

Nhóm 3: SPAKD LẬPLẬP TRÌNHTRÌNH CỰCCỰC ĐOANĐOAN eXtremeeXtreme ProgrammingProgramming (XP)(XP) Nhóm 3: Trương Minh Sáng Phạm Công Phan Nguyễn Đức Anh Phùng Đức Kiên Nguyễn Quang Dũng
NỘI DUNG vTổng quan về XP. vCách giải quyết của XP. vCác quy tắc và luật lệ trong XP. vBắt đầu với XP như thế nào? vMột dự án XP lý tưởng. vVai trò của con người trong XP. vXP và các nhận xét. vKết luận.
Nhóm 3: SPAKD TỔNGTỔNG QUANQUAN VỀVỀ XPXP
TỔNG QUAN vXP là gì? vĐối tượng của XP? vMột phương pháp luận mới vSự cải tiến của XP
ĐẶT VẤN ĐỀ vLậ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. vNgười viết code: nghĩ cụ thể về đoạn code đang viết vNgườ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 vCode được viết ra nhanh hơn, ít lỗi hơn vCó ít nhất hai người hiểu thấu đáo về các đoạn code đã viết
LẬP TRÌNH ĐÔI vCó ít nhất hai người hiểu thấu đáo về các đoạn code đã viết. vKhuyến khích các ý tưởng mới. vCỗ vũ tinh thần làm việc nhóm. vLà một phương tiện để các lập trình viên học hỏi lẫn nhau. vTạ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 vLà 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 vLà 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 v Phản hồi sớm, cụ thể và liên tục từ các chu kỳ ngắn. v Cách tiếp cận lập kế hoạch tăng trưởng v 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. v 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 v 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. v Quá trình thiết kế tiến hóa không ngừng. v Sự cộng tác chặt chẽ của các lập trình viên. v 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 vDự án phát triển bởi đội từ 2-10 người. vPhâ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 vHầu hết các ý tưởng của XP là cũ vĐặt tất cả các quy tắc vào một khung. vĐảm bảo các quy tắc được thực hiện triệt để nhất có thể. vĐả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 vNhấn mạnh vào việc thỏa mãn yêu cầu khách hàng. vTrao quyền cho lập trình viên thay đổi yêu cầu khách hàng. vTập trung vào làm việc theo nhóm vXP 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 vTập trung vào vấn đề con người. vSo 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. vTập trung vào kiểm thử, phát hiện sớm các lỗi. vLậ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 vLập trình viên giao tiếp với khách hàng và đồng đội. vGiữ thiết kế đơn giản và rõ ràng. vThu được phản hồi từ kiểm thử phần mềm. vPhâ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.
Nhóm 3: SPAKD CÁCHCÁCH GIẢIGIẢI QUYẾTQUYẾT CỦACỦA XPXP
ĐẶT VẤN ĐỀ vVấn đề cơ bản của phát triển phần mềm là rủi ro vCá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 ĐỀ vCá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Ì? vSai lệch với lịch trình. vDự án bị hủy bỏ . vKhông tương thích với hệ thống vTỉ lệ lỗi vHiểu sai yêu cầu vThay đổi yêu cầu vLàm tăng tính chất lỗi vNhân viên nghỉ việc
Nhóm 3: SPAKD CÁCCÁC QUYQUY TẮCTẮC VÀVÀ LUẬTLUẬT LỆLỆ TRONGTRONG XPXP
Lên kế hoạch vLập User stories vLập kế hoạch xuất phẩm vĐịnh kỳ tạo các sản phẩm nhỏ vĐo tiến độ dự án vChia dự án thành các bước lặp vLên kế hoạch bắt đầu mỗi bước lặp vLuân chuyển nhân lực vTổ chức họp đứng hàng ngày vSửa XP khi nó sụp
Lập User Stories vĐượ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. vĐược sử dụng để ước lượng thời gian cho kế hoạch xuất phẩm. vUser stories còn hướng đến việc tạo ra các test chấp nhận.
Lập User Stories vĐ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. vMộ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 vLê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. vĐ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 vCó 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 vLê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 vKhi 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 vTiế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 vĐể đ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 vTrong 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. vTrong 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 vMộ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 đó. vUser 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 vLuâ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. vĐà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 vĐ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. vLậ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 vMộ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. vKhi 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ế v Tính đơn giản v Chọn một ẩn dụ hệ thống v Sử dụng thẻ CRC v Sử dụng Spike Solution v Không chèn các chức năng vào quá sớm v 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 vDù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. vBản thân những thẻ CRC được dùng để đại diện cho những đối tượng.
Sử dụng thẻ CRC vMộ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 vTạ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. vKhi độ 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 vKhi 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. vRefactor 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 vBạ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. vHã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 vLẬ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 vLẬ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 v 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 v 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 v 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 v 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 v 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 v 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 v 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 v Đừ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 v Mọi đoạn mã phải qua tất cả kiểm thử đơn vị trước khi phát hành. v Điều phải làm khi có bug xảy ra v Quy tắc Kiểm thử chấp nhận.
NỘI DUNG v 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 v 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 v 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.
Nhóm 3: SPAKD HƯỚNGHƯỚNG DẪNDẪN SỬSỬ DỤNGDỤNG XPXP
KHI NÀO NÊN SỬ DỤNG XP vXP đượ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. vXP giải quyết vấn đề rủi ro trong dự án. vXP thích hợp với một đội nhỏ. vCó khả năng tạo kiểm thử
CHU KỲ PHÁT TRIỂN vMột cặp lập trình viên làm việc cùng trên một chương trình. vPhát triển được điều khiển bởi các kiểm thử. vCặp làm việc không làm các ca kiểm thử chạy. vCặ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ó. vSự tích hợp phát triển sau, bao gồm tích hợp kiểm thử.
Nhóm 3: SPAKD VÒNGVÒNG ĐỜIĐỜI DỰDỰ ÁNÁN XPXP
Vòng đời của dự án kiểu XP vKhảo sát vLập kế hoạch vVòng lặp cho xuất phẩm đầu tiên vSản xuất vBảo trì vKết thúc
Khảo sát vTạo ra niềm tin vào công cụ, công nghệ và kỹ năng để phát triển hệ thống. vLậ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. vKhảo sát những tiện ích của kiến trúc hệ thống. vXâ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. vCá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 vThậ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. vNhữ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. vThí 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. vĐá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 vMụ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. vKế 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 vGiai đ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 đó. vVòng lặp đầu tiên sẽ định vị kiến trúc hệ thống vThự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 vMộ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 độ. vCuố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 vChọn bước lặp 1 tuần. vChuẩ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. vThận trọng hơn với rủi ro. vThận trọng hơn với những thay đổi đưa ra.
Bảo trì v Cung cấp các chức năng mới. v Đảm bảo hệ thống đang tồn tại hoạt động tốt. v Thêm, bớt nhân lực dự án. v Mỗi một xuất phẩm bắt đầu từ quá trình khảo sát v 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. v 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. v Đá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 vKhách hàng không đưa thêm các phản hồi mới. vViết các tài liệu hướng dẫn sử dụng. vCá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 đó. vCơ hội gây dựng một đội cốt cán.
Nhóm 3: SPAKD VAIVAI TRÒTRÒ CỦACỦA NHÂNNHÂN TỐTỐ CONCON NGƯỜINGƯỜI TRONGTRONG XPXP
Nhân tố con người vLập trình viên vKhách hàng vKiểm thử viên vNgười giám sát vNgười hướng dẫn vNgười tư vấn vÔng chủ
Lập trình viên vLà trái tim của XP. vỞ 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. vỞ 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 vNhiều kỹ năng phải có: vThói quen giản dị vKhả năng lập trình vKhả năng nâng cấp mã vKhả năng thử nghiệm các đoạn mã vChia sẻ quyền sở hữu đoạn mã
Khách hàng vLà phần còn lại trong hai mặt của lập trình cực đoan vCá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ử vVai trò: của người kiểm thử trong một nhóm XP được tập trung vào khách hàng. vTrá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 vNhiệ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 vLà lương tâm của cả nhóm làm việc. vĐưa ra các ước lượng và sai số. vChị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. vKỹ 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 vChịu trách nhiệm cho toàn bộ quá trình vGiữ cho thành viên đi đúng hướng và giữ sự tập trung. vPhả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. vLàm việc tốt nhất khi làm việc gián tiếp vVai 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 vCó hiểu biết sâu sắc về kỹ thuật vKhông xuất hiện nhiều chuyên gia trong dự án XP vLàm việc với mức độ nhẹ nhàng. vNhững gì bạn làm thường không được công nhận !
Ông chủ vLòng dũng cảm, sự tự tin và sự khẳng định vào đội phát triển. vLiên tục hỏi và lắng nghe các giải thích. vCủng cố lòng tin của đội.
Nhóm 3: SPAKD NHẬNNHẬN XÉTXÉT VỀVỀ XPXP
Điều làm XP trở nên khó thực thi vXP đơn giản trong các chi tiết nhưng nó lại khó để thực thi. vVấ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. vThật khó để làm những thứ đơn giản. vThật khó để nhận ra những điều mà bạn không biết. vThật khó để phối hợp. vThật khó để phá bỏ hàng rào cảm xúc.
ĐIỂM YẾU CÒN TỒN TẠI vPhương pháp luận dựa trên việc phòng tránh sự rủi ro. vSự 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 vMã hóa chương trình. vThay đổi suy nghĩ. vBắt đầu mà không có hiểu biết gì về tương lai. vPhụ thuộc vào người khác. vThay đổi phân tích và thiết kế của hệ thống đang vận hành. vViết các kiểm thử.
Nhóm 3: SPAKD