Lập trình cực đoan (XP) không dành cho những người yếu tim. XP dựa trên sự tương tác chặt chẽ của các lập trình viên với các kỹ năng và năng lực chung nhất.

Lập trình khắc nghiệt: Phát triển theo hướng thử nghiệm

Dành riêng cho Cindy: đôi cánh của tâm hồn tôi

Quyền xuất bản có được theo thỏa thuận với Addison-Wesley Longman. Đã đăng ký Bản quyền. Không một phần nào của cuốn sách này có thể được sao chép dưới bất kỳ hình thức nào mà không có sự cho phép bằng văn bản của chủ sở hữu bản quyền.

Thông tin trong cuốn sách này được lấy từ các nguồn được nhà xuất bản coi là đáng tin cậy. Tuy nhiên, do những sai sót về con người hoặc kỹ thuật có thể xảy ra, nhà xuất bản không thể đảm bảo tính chính xác và đầy đủ tuyệt đối của thông tin được cung cấp và không chịu trách nhiệm về những sai sót có thể xảy ra liên quan đến việc sử dụng sách.

ISBN 978-0321146533 Tiếng Anh.

ISBN 978-5-496-02570-6

© 2003 bởi Pearson Education, Inc.

© Bản dịch sang tiếng Nga bởi Piter Publishing House LLC, 2017

© Ấn bản bằng tiếng Nga, do Piter Publishing House LLC thiết kế, 2017

© Loạt bài "Thư viện của lập trình viên", 2017

Lời tựa

Mã sạch hoạt động(mã sạch hoạt động) - Dòng ngắn gọn nhưng hấp dẫn này, được đặt ra bởi Ron Jeffries, là toàn bộ điểm của Phát triển theo hướng thử nghiệm (TDD). Mã sạch hoạt động là một mục tiêu đáng phấn đấu vì

Đây là một cách phát triển chương trình có thể đoán trước được. Bạn biết khi nào công việc có thể được coi là hoàn thành và không phải lo lắng về một loạt sai lầm kéo dài;

Cho bạn cơ hội học những bài học mà mã dạy. Nếu bạn sử dụng ý tưởng đầu tiên nảy ra trong đầu, bạn sẽ không có cơ hội thực hiện ý tưởng thứ hai tốt hơn;

Cải thiện tuổi thọ của người dùng các chương trình của bạn;

Cho phép đồng nghiệp của bạn tin tưởng vào bạn và bạn tin tưởng vào họ;

Thật thú vị hơn khi viết mã như thế này.

Nhưng làm thế nào để bạn có được mã sạch hoạt động? Nhiều thế lực ngăn cản chúng ta nhận được mã sạch và đôi khi chúng ta thậm chí không thể nhận được mã hoạt động. Để loại bỏ nhiều vấn đề, chúng tôi sẽ phát triển mã dựa trên thử nghiệm tự động. Phong cách lập trình này được gọi là phát triển theo hướng thử nghiệm. Theo kỹ thuật này

Mã mới chỉ được viết sau khi kiểm tra tự động được viết và không thành công;

Mọi sự trùng lặp đều bị loại bỏ.

Hai quy tắc đơn giản, phải không? Tuy nhiên, chúng tạo ra hành vi cá nhân và nhóm phức tạp với nhiều hàm ý kỹ thuật:

Trong quá trình thiết kế, chúng tôi liên tục chạy mã và lấy ý tưởng về công việc của nó, điều này giúp đưa ra quyết định đúng đắn;

Chúng tôi tự viết bài kiểm tra, bởi vì chúng tôi không thể đợi người khác viết bài kiểm tra cho chúng tôi;

Môi trường phát triển của chúng tôi phải đáp ứng nhanh chóng với các sửa đổi mã nhỏ;

Thiết kế của chương trình nên dựa trên việc sử dụng nhiều thành phần khép kín, được ghép nối lỏng lẻo để giúp kiểm tra mã dễ dàng hơn.

Hai quy tắc TDD được đề cập xác định thứ tự của các bước lập trình.

1. Màu đỏ - viết một bài kiểm tra nhỏ không hoạt động, và thậm chí có thể không biên dịch.

2. Màu xanh lá cây - giúp chạy thử nghiệm càng nhanh càng tốt, mà không cần suy nghĩ về thiết kế chính xác và mã sạch. Viết mã vừa đủ để làm cho bài kiểm tra hoạt động.

3. Tái cấu trúc - loại bỏ bất kỳ sự trùng lặp nào từ mã đã viết.

Red - green - refactoring là câu thần chú của TDD.

Nếu chúng ta giả định rằng phong cách lập trình này là khả thi, chúng ta có thể cho rằng nhờ vào việc sử dụng nó, mã sẽ chứa ít lỗi hơn đáng kể, ngoài ra, mục đích của công việc sẽ rõ ràng cho tất cả những ai tham gia vào nó. Nếu vậy, thì việc chỉ phát triển mã cần thiết để vượt qua các bài kiểm tra cũng có ý nghĩa xã hội:

Với mật độ khuyết tật đủ thấp, nhóm Đảm bảo chất lượng (QA) sẽ có thể chuyển từ việc phản hồi lỗi sang ngăn ngừa chúng;

Bằng cách giảm thiểu số lần bất ngờ khó chịu, các nhà quản lý dự án sẽ có thể ước tính chính xác hơn chi phí lao động và đưa khách hàng tham gia vào quá trình phát triển;

Nếu chủ đề của các cuộc thảo luận kỹ thuật được xác định rõ ràng, các lập trình viên có thể tương tác với nhau một cách thường xuyên, thay vì một lần một ngày hoặc một lần một tuần;

Một lần nữa, với mật độ khuyết tật đủ thấp, chúng tôi sẽ có thể có một sản phẩm làm việc tích hợp mỗi ngày với chức năng mới được bổ sung vào đó, để chúng tôi có thể tham gia vào một kiểu quan hệ kinh doanh hoàn toàn mới với khách hàng của mình.

Vậy thì tưởng đơn giản nhưng chúng ta quan tâm đến điều gì? Tại sao một lập trình viên phải đảm nhận thêm trách nhiệm viết các bài kiểm tra tự động? Tại sao một lập trình viên lại có những bước tiến nhỏ trong khi bộ não của anh ta có thể suy nghĩ thông qua một cấu trúc thiết kế phức tạp hơn nhiều? Bản lĩnh.

TDD là một cách để quản lý nỗi sợ hãi trong quá trình lập trình. Ý tôi không phải là sợ ngã khỏi ghế hay sợ sếp. Ý tôi là nỗi sợ hãi về một vấn đề "khó đến nỗi tôi chưa biết giải quyết nó như thế nào." Đau đớn là khi thiên nhiên nói với chúng ta: “Hãy dừng lại!” Và sợ hãi là khi thiên nhiên nói với chúng ta: “Hãy cẩn thận! Thận trọng không phải là một điều xấu, nhưng bên cạnh lợi ích, nỗi sợ hãi còn có một số tác động tiêu cực đến chúng ta:

Nỗi sợ hãi buộc chúng ta phải suy nghĩ trước và cẩn thận về những gì điều này hoặc hành động đó có thể dẫn đến;

Sợ hãi khiến chúng ta ít giao tiếp hơn;

Sự sợ hãi khiến chúng ta bị đe dọa bởi những đánh giá về công việc của mình;

Sợ hãi khiến chúng ta trở nên cáu kỉnh.

Không điều nào trong số này hữu ích cho quá trình lập trình, đặc biệt nếu bạn đang giải quyết một vấn đề phức tạp. Vì vậy, chúng tôi phải đối mặt với câu hỏi làm thế nào để thoát khỏi một tình huống khó khăn và

Đừng cố gắng dự đoán tương lai, nhưng ngay lập tức bắt đầu nghiên cứu thực tế về vấn đề;

Không phải rào cản với phần còn lại của thế giới, nhưng tăng mức độ giao tiếp;

Không né tránh các phản hồi, nhưng ngược lại, thiết lập phản hồi đáng tin cậy và với sự giúp đỡ của nó, theo dõi cẩn thận kết quả của các hành động của bạn;

(bạn phải tự mình giải quyết sự khó chịu).

So sánh việc lập trình với việc nâng một cái thùng lên khỏi giếng. Thùng chứa đầy nước, bạn xoay cần, cuốn dây xích quanh cổng và nâng thùng lên. Nếu chiếc xô nhỏ, một chiếc cổ quay đều đặn, tự do là được. Nhưng nếu cái xô lớn và nặng, bạn sẽ cảm thấy mệt mỏi trước khi nhấc nó lên. Để có thể nghỉ giữa các lượt của cần, cần có một bánh cóc để giữ cho cần ở đúng vị trí. Gầu càng nặng thì các răng trên bánh cóc thường xuyên theo.

Các bài kiểm tra trong TDD là răng trên bánh răng bánh cóc. Bằng cách làm cho bài kiểm tra hoạt động, chúng tôi biết rằng bài kiểm tra hiện hoạt động, bây giờ và mãi mãi. Chúng tôi đang tiến gần hơn một bước để hoàn thành công việc so với trước khi thử nghiệm bắt đầu hoạt động. Sau đó, chúng tôi buộc bài kiểm tra thứ hai hoạt động, rồi đến bài kiểm tra thứ ba, thứ tư, v.v. Vấn đề mà lập trình viên phải đối mặt càng phức tạp, thì mỗi bài kiểm tra càng phải bao hàm ít chức năng hơn.

Người đọc sách Explaine lập trình cực đoan chắc hẳn đã nhận thấy sự khác biệt về giai điệu giữa Lập trình cực đoan (XP) và Phát triển theo hướng thử nghiệm (TDD). Không giống như XP, TDD không phải là tuyệt đối. XP nói rằng "bạn phải thành thạo điều này và điều kia để tiến về phía trước." TDD là một kỹ thuật ít cụ thể hơn. TDD giả định rằng có một khoảng thời gian giữa việc ra quyết định và kết quả, và đưa ra các công cụ để kiểm soát độ dài của khoảng thời gian này. “Điều gì sẽ xảy ra nếu, trong một tuần, tôi thiết kế một thuật toán trên giấy và sau đó viết mã bằng cách tiếp cận thử nghiệm đầu tiên? Điều này có tuân thủ TDD không? " Tất nhiên là sẽ có. Bạn biết khoảng thời gian giữa việc đưa ra quyết định và đánh giá kết quả và kiểm soát khoảng thời gian này một cách có ý thức.

Hầu hết những người đã thành thạo TDD đều khẳng định rằng thực hành lập trình của họ đã thay đổi theo hướng tốt hơn. Bị nhiễm bởi các xét nghiệm(xét nghiệm bị nhiễm) là định nghĩa mà Erich Gamma đặt ra để mô tả sự thay đổi này. Khi bạn đã thành thạo TDD, bạn sẽ thấy mình viết nhiều bài kiểm tra hơn đáng kể so với trước đây và tiến về phía trước theo những bước nhỏ mà trước đây bạn có vẻ vô nghĩa. Mặt khác, một số lập trình viên, khi đã quen với TDD, quyết định quay lại các phương thức cũ, dành TDD cho những trường hợp đặc biệt khi lập trình thông thường không dẫn đến tiến độ mong muốn.

Chắc chắn, có những vấn đề không thể (ít nhất là vào lúc này) không thể được giải quyết chỉ với các bài kiểm tra. Đặc biệt, TDD không cho phép chứng minh một cách máy móc tính đầy đủ của mã đã phát triển về bảo mật dữ liệu và độ tin cậy của các hoạt động song song. Tất nhiên, bảo mật dựa trên mã không có lỗi, nhưng nó cũng dựa trên sự tham gia của con người vào các quy trình bảo vệ dữ liệu. Các vấn đề tinh vi của đồng thời không thể được tái tạo một cách chắc chắn bằng cách chỉ đơn giản là chạy một số mã.

Lập trình cực đoan (XP) là một trong những phương pháp luận phát triển phần mềm linh hoạt. Các tác giả của phương pháp này là Kent Beck, Ward Cunningham, Martin Fowler và những người khác.

Trò chơi lập kế hoạch

Kế hoạch phát hành

Lập kế hoạch lặp lại

Thường vụ cuộc họp

Sự đơn giản

Hệ thống ẩn dụ

Khách hàng trên trang web

Kiểm tra trước khi phát triển

Lập trình cặp

Thay đổi vị trí

Quyền sở hữu mã tập thể

Quy ước mã hóa

Tích hợp thường xuyên

Bốn mươi giờ làm việc tuần

Phần kết luận

Thư mục:

Theo các tác giả của XP, kỹ thuật này không tuân theo một số sơ đồ hành động chung mà sử dụng kết hợp các kỹ thuật sau. Tuy nhiên, mỗi kỹ thuật đều quan trọng, và nếu không có nó, sự phát triển được coi là không XP, theo Kent Beck, một trong những tác giả của phương pháp này cùng với Ward Cunningham và Ron Jeffries.

• Lập kế hoạch trò chơi

  Nhiệm vụ của anh ta là xác định càng nhanh càng tốt khối lượng công việc cần phải thực hiện trước phiên bản tiếp theo của phần mềm. Quyết định được đưa ra, trước hết, trên cơ sở các ưu tiên của khách hàng (tức là nhu cầu của họ, những gì họ cần từ hệ thống để vận hành doanh nghiệp của mình thành công hơn) và thứ hai, trên cơ sở các đánh giá kỹ thuật (tức là các ước tính về mức độ phức tạp của quá trình phát triển, khả năng tương thích với các yếu tố khác của hệ thống, v.v.). Các kế hoạch thay đổi ngay khi chúng bắt đầu không phù hợp với thực tế hoặc mong muốn của khách hàng.

• Thay đổi phiên bản thường xuyên (bản phát hành nhỏ)

  Phiên bản làm việc đầu tiên sẽ xuất hiện càng sớm càng tốt và phải được sử dụng ngay lập tức. Các phiên bản tiếp theo được chuẩn bị trong khoảng thời gian khá ngắn (từ vài giờ với những thay đổi nhỏ trong một chương trình nhỏ, đến một hoặc hai tháng với một cuộc đại tu lớn của một hệ thống lớn).

• Ẩn dụ (ẩn dụ) của hệ thống

  Ẩn dụ ở dạng khá đơn giản và dễ hiểu cho câu lệnh sẽ mô tả cơ chế chính của hệ thống. Khái niệm này tương tự như kiến ​​trúc, nhưng nó sẽ đơn giản hơn nhiều, chỉ dưới dạng một hoặc hai cụm từ, mô tả bản chất chính của các giải pháp kỹ thuật được áp dụng.

• Giải pháp thiết kế đơn giản

  Tại bất kỳ thời điểm nào, hệ thống phải được thiết kế đơn giản nhất có thể. Không cần thêm chức năng trước - chỉ sau khi yêu cầu rõ ràng. Tất cả sự phức tạp không cần thiết được loại bỏ ngay sau khi nó được tìm thấy.

• Hướng phát triển thử nghiệm

  Đầu tiên các nhà phát triển viết các bài kiểm tra, sau đó họ cố gắng triển khai các mô-đun của mình để các bài kiểm tra hoạt động. Khách hàng viết trước các bài kiểm tra chứng minh các khả năng cơ bản của hệ thống để họ có thể thấy rằng hệ thống thực sự hoạt động.

• Tái cấu trúc

  Các lập trình viên liên tục làm lại hệ thống để loại bỏ sự phức tạp không cần thiết, tăng khả năng hiểu mã, tăng tính linh hoạt của nó, nhưng không có thay đổi trong hành vi của nó, được kiểm tra bằng cách chạy sau mỗi lần thử nghiệm lại. Đồng thời, ưu tiên được đưa ra cho các giải pháp thanh lịch và linh hoạt hơn, so với việc chỉ đơn giản là đưa ra kết quả mong muốn. Các thành phần được làm lại không thành công phải được xác định trong quá trình thực thi thử nghiệm và quay trở lại trạng thái nhất quán cuối cùng (cùng với các thành phần phụ thuộc của chúng).

• Lập trình cặp

  Việc mã hóa được thực hiện bởi hai lập trình viên trên một máy tính. Việc ghép nối là tùy ý và thay đổi theo từng nhiệm vụ. Người có bàn phím đang cố gắng giải quyết vấn đề hiện tại theo cách tốt nhất. Lập trình viên thứ hai phân tích công việc của người thứ nhất và đưa ra lời khuyên, cân nhắc hậu quả của một số quyết định nhất định, các thử nghiệm mới, các giải pháp ít trực tiếp hơn nhưng linh hoạt hơn.

• Sở hữu tập thể

  Bất kỳ thành viên nào trong nhóm đều có thể thay đổi bất kỳ phần nào của mã bất kỳ lúc nào. Không ai nên có lĩnh vực trách nhiệm riêng của họ, toàn bộ nhóm thường chịu trách nhiệm về tất cả các mã.

• Hội nhập liên tục

  Hệ thống được lắp ráp và kiểm tra để tích hợp thường xuyên nhất có thể, vài lần một ngày, mỗi khi một vài lập trình viên hoàn thành việc triển khai chức năng tiếp theo.

• 40 giờ làm việc tuần

  Tăng ca được xem là dấu hiệu của những vấn đề lớn trong dự án. Không được phép làm thêm giờ trong 2 tuần liên tiếp - điều này khiến các lập trình viên kiệt sức và khiến công việc của họ kém hiệu quả hơn rất nhiều.

• Bao gồm khách hàng trong nhóm (khách hàng tại chỗ)

  Nhóm phát triển luôn bao gồm một đại diện khách hàng, người luôn sẵn sàng trong ngày làm việc và có thể trả lời tất cả các câu hỏi về hệ thống. Trách nhiệm của anh ta là cung cấp câu trả lời nhanh chóng cho bất kỳ câu hỏi nào liên quan đến chức năng của hệ thống, giao diện của nó, hiệu suất cần thiết, hoạt động chính xác của hệ thống trong các tình huống khó khăn, nhu cầu duy trì giao tiếp với các ứng dụng khác, v.v.

• Sử dụng mã làm phương tiện giao tiếp

  Mã được coi là phương tiện giao tiếp quan trọng nhất trong nhóm. Mã rõ ràng là một trong những ưu tiên hàng đầu của chúng tôi. Việc tuân thủ các tiêu chuẩn mã hóa cung cấp sự rõ ràng này là bắt buộc. Các tiêu chuẩn như vậy, ngoài sự rõ ràng của mã, cần đảm bảo rằng các biểu thức được giữ ở mức tối thiểu (không trùng lặp mã và thông tin) và phải được tất cả các thành viên trong nhóm chấp nhận.

• Mở không gian làm việc

  Nhóm được đặt trong một phòng duy nhất đủ lớn để tạo điều kiện giao tiếp và động não khi lập kế hoạch và đưa ra các quyết định kỹ thuật quan trọng.

• Thay đổi các quy tắc khi cần thiết (chỉ là các quy tắc)

  Mỗi thành viên trong nhóm phải chấp nhận các quy tắc được liệt kê, nhưng nếu có nhu cầu, nhóm có thể thay đổi chúng nếu tất cả các thành viên đồng ý về sự thay đổi này.

Như bạn có thể thấy từ các kỹ thuật được sử dụng, XP được thiết kế để sử dụng trong các nhóm nhỏ (không quá 10 lập trình viên), điều này cũng được các tác giả của kỹ thuật này nhấn mạnh. Quy mô nhóm lớn hơn phá hủy sự dễ dàng giao tiếp cần thiết để thành công và khiến cho việc áp dụng nhiều kỹ thuật này không thể được thực hiện.

Điểm mạnh của XP, nếu được áp dụng, là tính linh hoạt cao, khả năng thay đổi phần mềm một cách nhanh chóng và chính xác để đáp ứng các yêu cầu thay đổi và mong muốn của từng khách hàng, chất lượng cao của mã kết quả và thiếu nhu cầu thuyết phục khách hàng. rằng kết quả đáp ứng mong đợi của họ.

Nhược điểm của cách tiếp cận này là không thể thực hiện được các dự án khá lớn và phức tạp theo kiểu này, không thể hoạch định thời gian và cường độ lao động của dự án trong thời gian đủ dài và dự đoán rõ ràng kết quả của một dự án dài theo tỷ lệ chất lượng của kết quả và chi phí thời gian và nguồn lực. Cũng có thể lưu ý rằng XP không phù hợp với những trường hợp mà các giải pháp khả thi không được tìm thấy ngay lập tức trên cơ sở kinh nghiệm trước đó, mà cần phải nghiên cứu sơ bộ.

XP là tập hợp các kỹ thuật được mô tả lần đầu tiên được sử dụng trong quá trình thực hiện dự án C3 (Hệ thống trả thưởng toàn diện của Chrysler, sự phát triển của hệ thống tính toán lợi ích của nhân viên cho Daimler Chrysler). Trong số 20 người tham gia dự án này, 5 người (bao gồm 3 tác giả chính của XP đã đề cập ở trên) đã xuất bản 3 cuốn sách và một số lượng lớn các bài báo về XP trong chính dự án và sau này. Dự án này được đề cập nhiều lần trong nhiều nguồn khác nhau như một ví dụ về việc sử dụng kỹ thuật này,. Dữ liệu dưới đây được tổng hợp từ các bài báo đã tham khảo, loại trừ thông tin không nhất quán và minh họa các vấn đề của một số kỹ thuật XP khi áp dụng cho các dự án khá phức tạp.

Dự án bắt đầu vào tháng 1 năm 1995. Từ tháng 3 năm 1996, sau khi có Kent Beck, nó chạy bằng XP. Vào thời điểm này, ông đã vượt quá ngân sách và kế hoạch cho việc thực hiện các chức năng theo từng giai đoạn. Nhóm phát triển đã được thu hẹp lại, và trong khoảng nửa năm sau đó, dự án đã phát triển khá thành công. Vào tháng 8 năm 1998, một nguyên mẫu xuất hiện có thể phục vụ khoảng 10.000 nhân viên. Ban đầu, dự án dự kiến ​​sẽ hoàn thành vào giữa năm 1999 và phần mềm thu được sẽ được sử dụng để quản lý các khoản thanh toán cho 87.000 nhân viên của công ty. Nó đã ngừng hoạt động vào tháng 2 năm 2000 sau 4 năm chạy XP do hoàn toàn không tuân thủ các mốc thời gian và ngân sách. Phần mềm được tạo ra chưa bao giờ được sử dụng để làm việc với dữ liệu của hơn 10.000 nhân viên, mặc dù nó đã được chứng minh là có thể xử lý dữ liệu của 30.000 nhân viên của công ty. Người đóng vai khách hàng trong nhóm của dự án đã nghỉ việc sau nhiều tháng làm việc như vậy, không thể chịu được tải và không nhận được sự thay thế thích hợp cho đến khi kết thúc dự án.

Lập trình cực đoan là một phương pháp luận để phát triển phần mềm nhanh chóng. Bao gồm một tập hợp các kỹ thuật và nguyên tắc cho phép, cả riêng lẻ và phức hợp, tối ưu hóa quá trình phát triển. Cách tiếp cận này cũng điều chỉnh các quyền của nhà phát triển và khách hàng.

Quyền và vai trò

Trong lập trình cực đoan, tất cả các vai trò đều được mô tả rõ ràng. Mỗi vai trò có một bộ quyền và trách nhiệm riêng biệt. Có hai vai trò chính ở đây: khách hàng và nhà phát triển.

Khách hàng

Một người hoặc một nhóm người quan tâm đến việc tạo ra một sản phẩm phần mềm cụ thể. Anh ta có các quyền và nghĩa vụ sau đây:

• ấn định ngày phát hành cho các phiên bản sản phẩm;
• đưa ra quyết định về các thành phần dự kiến ​​của chương trình;
• biết chi phí ước tính của từng thành phần chức năng;
• đưa ra các quyết định kinh doanh quan trọng;
• biết trạng thái hiện tại của hệ thống;
• thay đổi các yêu cầu hệ thống khi nó thực sự quan trọng.

Để thực hiện thành công các quyền của mình, khách hàng phải dựa vào dữ liệu do các nhà phát triển cung cấp.

Người sản xuất

Một hoặc một nhóm từ hai đến mười người liên quan trực tiếp đến lập trình và các vấn đề kỹ thuật liên quan. Nhà phát triển có các quyền và nghĩa vụ sau:

• có đủ kiến ​​thức về các vấn đề cần lập trình;
• có thể làm rõ các chi tiết trong quá trình phát triển;
• cung cấp các ước tính rõ ràng nhưng rõ ràng về chi phí lao động cho từng bộ phận chức năng hoặc câu chuyện của người dùng;
• điều chỉnh các ước tính có lợi cho những ước tính chính xác hơn trong quá trình phát triển;
• cung cấp đánh giá về các rủi ro liên quan đến việc sử dụng các công nghệ cụ thể.

Các vai trò trong một vai trò

Mỗi vai trò cơ bản của lập trình cực đoan có thể được tinh chỉnh bằng các vai trò nhỏ hơn. Trong XP, nó được phép kết hợp các vai trò trong cùng một người.

Phía khách hàng

Người tạo câu chuyện- một chuyên gia trong lĩnh vực chủ đề, người có khả năng dễ dàng nêu và mô tả các yêu cầu đối với hệ thống đang được phát triển. Người hoặc nhóm người này chịu trách nhiệm viết các câu chuyện của người dùng và giải tỏa những hiểu lầm từ các lập trình viên.

Người nhận- người điều khiển hoạt động chính xác của hệ thống. Có chỉ huy tốt về lĩnh vực chủ đề. Các trách nhiệm bao gồm viết các bài kiểm tra chấp nhận.

Sếp lớn- giám sát công việc của tất cả các liên kết, từ nhà phát triển đến người dùng cuối. Ông giám sát việc thực hiện hệ thống và các vấn đề liên quan của tổ chức. Cũng có thể là nhà đầu tư trong một dự án.

Phía nhà phát triển

Người lập trình- một người tham gia viết mã và thiết kế ở trình độ thấp. Anh ta đủ năng lực để giải quyết các vấn đề phát triển hiện tại và cung cấp các ước tính thực sự về các nhiệm vụ đã được lên kế hoạch.

Người hướng dẫn- một nhà phát triển có kinh nghiệm, người có khả năng chỉ huy tốt toàn bộ quá trình phát triển và các phương pháp của nó. Chịu trách nhiệm giảng dạy các khía cạnh của nhóm trong quá trình phát triển. Thực hiện và kiểm soát tính đúng đắn của việc thực hiện các phương pháp của quy trình đã sử dụng. Thu hút sự chú ý của nhóm đến các điểm quan trọng nhưng vì lý do nào đó đã bỏ lỡ các điểm phát triển. Đồng thời, người hướng dẫn, giống như bất kỳ người nào khác, không toàn trí và chú ý đến ý tưởng của các thành viên khác trong nhóm.

Người quan sát là thành viên của nhóm phát triển được cả nhóm tin tưởng và giám sát tiến trình phát triển. Nó so sánh các ước tính sơ bộ về chi phí lao động và chi phí thực tế, hiển thị các chỉ số định lượng về công việc của nhóm. Đây là tốc độ trung bình và tỷ lệ phần trăm nhiệm vụ đã hoàn thành và theo lịch trình. Thông tin này được cung cấp cho khách hàng để kịp thời kiểm soát tình hình. Một số thông tin này cũng được cung cấp một cách kín đáo cho các nhà phát triển, để biết tình trạng của dự án, những nơi phát sinh khó khăn và những gì khác có thể được thực hiện.

Nhà ngoại giao- tính cách giao tiếp, khơi mào giao tiếp giữa các thành viên trong nhóm. Vì quy trình làm việc được giảm thiểu, nên việc liên lạc thường xuyên và chuyển giao kinh nghiệm trong nhóm là rất quan trọng, cũng như hiểu rõ hơn về các yêu cầu của hệ thống. Nhà ngoại giao điều chỉnh và đơn giản hóa giao tiếp giữa khách hàng và nhà phát triển. Nó là một mắt xích quan trọng trong các cuộc họp. Anh ấy ngăn chặn những hiểu lầm, đỉnh cao của những đam mê và những cuộc cãi vã không cần thiết. Một nhà ngoại giao không thể áp đặt ý kiến ​​của mình lên người tranh luận.

Vai trò bên ngoài

Tư vấn- một chuyên gia với các kỹ năng kỹ thuật cụ thể để giúp các nhà phát triển với các nhiệm vụ khó khăn. Thường bị thu hút từ bên ngoài.

Quy tắc lập trình cực đoan

Quy ước mã hóa

Bạn đang ở trong một nhóm đã làm việc trong dự án này trong một thời gian dài. Người đến và đi. Không ai mã một mình và mã thuộc về tất cả mọi người. Sẽ luôn có lúc cần phải hiểu và sửa mã của người khác. Các nhà phát triển sẽ xóa hoặc thay đổi mã trùng lặp, phân tích và cải thiện các lớp của người khác, v.v. Theo thời gian, sẽ không thể nói tác giả của một lớp cụ thể là ai.

Do đó, mọi người phải tuân theo các tiêu chuẩn mã hóa chung - định dạng mã, đặt tên cho các lớp, biến, hằng số, kiểu bình luận. Vì vậy, chúng tôi sẽ chắc chắn rằng bằng cách thực hiện các thay đổi đối với mã của người khác (cần thiết cho việc di chuyển mạnh mẽ và cực đoan về phía trước), chúng tôi sẽ không biến nó thành Babel Babel.

Điều trên có nghĩa là tất cả các thành viên trong nhóm phải đồng ý về các tiêu chuẩn mã hóa chung. Không quan trọng cái nào. Quy tắc là tất cả mọi người tuân theo chúng. Những người không muốn tuân thủ họ rời khỏi đội.

Quyền sở hữu mã tập thể

Quyền sở hữu mã được chia sẻ khuyến khích các nhà phát triển gửi ý tưởng cho tất cả các phần của dự án, không chỉ các mô-đun của họ. Bất kỳ nhà phát triển nào cũng có thể thay đổi bất kỳ mã nào để mở rộng chức năng, sửa lỗi hoặc tái cấu trúc.

Thoạt nhìn giống như hỗn loạn. Tuy nhiên, có tính đến việc ít nhất bất kỳ mã nào đã được tạo bởi một vài nhà phát triển, bài kiểm tra Đơn vị đó cho phép bạn kiểm tra tính đúng đắn của các thay đổi được thực hiện và trong cuộc sống thực, bạn vẫn phải hiểu mã của người khác theo cách này hay cách khác, Rõ ràng là quyền sở hữu tập thể đối với mã giúp đơn giản hóa đáng kể việc thực hiện các thay đổi và giảm rủi ro liên quan đến chuyên môn hóa cao của một hoặc một thành viên khác trong nhóm.

Phiên CRC

Sử dụng thẻ Lớp, Trách nhiệm, Cộng tác (CRC) để thiết kế hệ thống như một nhóm. Sử dụng thẻ giúp bạn dễ dàng làm quen với việc suy nghĩ trong các đối tượng hơn là các hàm và thủ tục. Ngoài ra, thẻ cho phép nhiều người tham gia vào quá trình thiết kế (lý tưởng nhất là cả nhóm), và càng nhiều người thực hiện thiết kế, thì càng có nhiều ý tưởng thú vị.

Mỗi thẻ CRC là một cá thể đối tượng. Lớp đối tượng có thể được viết ở trên cùng, các trách nhiệm ở bên trái, các tương tác ở bên phải. Chúng tôi nói "có thể được viết" bởi vì khi một phiên CRC đang diễn ra, những người tham gia thường cần một số lượng nhỏ thẻ tên lớp và không cần phải điền đầy đủ.

Phiên CRC diễn ra như thế này: mỗi người tham gia tái tạo hệ thống cho biết anh ta sẽ gửi thông điệp nào đến đối tượng nào. Xem qua toàn bộ quy trình bằng tin nhắn. Điểm yếu và vấn đề được xác định ngay lập tức. Các lựa chọn thay thế thiết kế cũng có thể nhìn thấy rõ ràng khi mô phỏng quy trình.

Để sắp xếp mọi thứ theo thứ tự, giới hạn của số lần tương tác đồng thời hai thường được sử dụng.

Khách hàng

Một trong những yêu cầu của XP là khách hàng luôn sẵn sàng. Anh ta không nên chỉ giúp đỡ nhóm phát triển mà còn phải là một thành viên của nhóm phát triển. Tất cả các giai đoạn của một dự án XP đều yêu cầu giao tiếp với khách hàng, tốt nhất là mặt đối mặt - tại chỗ. Tốt hơn hết, chỉ cần chỉ định một hoặc nhiều khách hàng cho nhóm phát triển. Hãy lưu ý, khách hàng sẽ mất nhiều thời gian và văn phòng khách hàng có thể cố gắng cung cấp cho bạn một thực tập sinh với tư cách là một chuyên gia. Bạn cần một chuyên gia.

Câu chuyện của người dùngđược viết bởi khách hàng với sự giúp đỡ của các nhà phát triển. Khách hàng giúp đảm bảo rằng hầu hết các chức năng hệ thống mong muốn được bao phủ bởi Câu chuyện người dùng.

Khi lập kế hoạch phát hành, khách hàng cần thảo luận về việc lựa chọn Câu chuyện của người dùng sẽ được đưa vào bản phát hành dự kiến. Cũng có thể cần phải đồng ý về khoảng thời gian phát hành. Khách hàng đưa ra các quyết định liên quan đến mục tiêu của doanh nghiệp.

Chọn giải pháp đơn giản nhất

Những thiết kế đơn giản luôn dễ thực hiện hơn những thiết kế phức tạp. Vì vậy, hãy luôn đưa ra giải pháp đơn giản nhất có thể hoạt động. Nếu bạn thấy điều gì đó khó khăn, hãy thay thế nó bằng một thứ gì đó đơn giản. Thay thế mã phức tạp bằng mã đơn giản luôn nhanh hơn và rẻ hơn trước khi bạn bắt đầu hiểu mã phức tạp.

Cấu trúc lại mã của người khác nếu nó có vẻ phức tạp với bạn. Nếu điều gì đó trông phức tạp, đây là dấu hiệu chắc chắn về sự cố trong mã của bạn.

Giữ các giải pháp càng đơn giản càng tốt càng lâu càng tốt. Không bao giờ thêm chức năng cho tương lai - trước khi nhu cầu phát sinh. Tuy nhiên, hãy nhớ rằng: giữ cho thiết kế đơn giản là một công việc khó khăn.

Kiểm tra chức năng

Các bài kiểm tra chấp nhận (trước đây còn được gọi là Kiểm thử chức năng) được viết dựa trên Câu chuyện của người dùng. Họ xem hệ thống như một hộp đen. Khách hàng có trách nhiệm kiểm tra tính đúng đắn của các thử nghiệm chức năng. Các bài kiểm tra này được sử dụng để xác minh rằng hệ thống đang hoạt động bình thường trước khi nó được đưa vào sản xuất. Các bài kiểm tra chức năng được tự động hóa để bạn có thể chạy chúng thường xuyên. Kết quả được thông báo cho nhóm và nhóm chịu trách nhiệm lên lịch cho các bản sửa lỗi kiểm tra chức năng.

Tích hợp thường xuyên

Các nhà phát triển nên tích hợp và phát hành mã của họ vài giờ một lần bất cứ khi nào có thể. Trong mọi trường hợp, các thay đổi không bao giờ được giữ lâu hơn một ngày. Việc tích hợp thường xuyên sẽ tránh được sự xa lánh và phân mảnh trong quá trình phát triển, nơi các nhà phát triển không thể giao tiếp theo cách chia sẻ ý tưởng hoặc sử dụng lại mã. Mọi người nên làm việc với phiên bản mới nhất.

Mỗi cặp nhà phát triển nên phát hành mã của họ ngay khi có cơ hội hợp lý để làm như vậy. Nó có thể là khi tất cả các UnitTest vượt qua 100%. Bằng cách gửi các thay đổi nhiều lần trong ngày, bạn giảm các vấn đề tích hợp xuống gần như bằng không. Tích hợp là một hoạt động trả ngay hoặc trả sau. Do đó, bằng cách tích hợp các thay đổi hàng ngày theo từng phần nhỏ, bạn sẽ không phải mất một tuần để liên kết hệ thống thành một tổng thể ngay lập tức trước khi giao dự án. Luôn làm việc trên phiên bản mới nhất của hệ thống.

Đối với người quản lý. Nếu một nhà phát triển không gửi các thay đổi trong hơn một ngày, đây là một dấu hiệu rõ ràng về một vấn đề nghiêm trọng. Bạn phải ngay lập tức tìm ra vấn đề là gì. Tất cả kinh nghiệm của các đội XP đều nói rằng lý do của sự chậm trễ luôn là do thiết kế xấu và nó luôn phải được làm lại sau đó.

Lập kế hoạch lặp lại

Một cuộc họp lập kế hoạch lặp lại được gọi trước khi bắt đầu mỗi lần lặp để lên lịch các nhiệm vụ cần thực hiện trong lần lặp đó. Để lặp lại, các Câu chuyện của người dùng được chọn mà khách hàng đã chọn kế hoạch phát hành bắt đầu với điều quan trọng nhất đối với khách hàng và điều tồi tệ nhất (đi kèm với rủi ro) đối với nhà phát triển. Kiểm tra chức năng không hoạt động cũng được bao gồm trong quá trình lặp lại.

Câu chuyện của người dùng và Kiểm tra chức năng không thành công được chia thành các nhiệm vụ. Nhiệm vụ được ghi trên thẻ. Các thẻ này là kế hoạch chi tiết cho việc lặp lại. Mỗi nhiệm vụ nên dài từ 1 đến 3 ngày lý tưởng.

Các nhà phát triển tách rời các nhiệm vụ và ước tính khoảng thời gian cần thiết để hoàn thành chúng. Do đó, mỗi nhà phát triển ước tính thời gian thực hiện nhiệm vụ của mình. Điều quan trọng là nhà phát triển phải tự mình đưa ra ước tính cuối cùng về phạm vi công việc.

Tốc độ dự án xác định xem nhiệm vụ của bạn có phù hợp với lặp đi lặp lại hay không. Tổng thời lượng của các tác vụ được lên lịch cho một lần lặp không được vượt quá tốc độ đạt được trong lần lặp trước đó. Nếu bạn đã nhập quá nhiều, thì khách hàng phải quyết định hoãn Câu chuyện người dùng nào để chuyển sang lần lặp tiếp theo. Nếu bạn nhập quá ít, thì bạn cần thêm Câu chuyện người dùng sau. Trong một số trường hợp, bạn có thể yêu cầu khách hàng chia một trong các Câu chuyện của người dùng thành hai để đưa phần này vào lần lặp hiện tại.

Việc trì hoãn User Story cho lần lặp tiếp theo có thể trông đáng sợ, nhưng đừng cho phép bản thân hy sinh việc tái cấu trúc và Unit Test để hoàn thành nhiều việc hơn. Nợ trong các danh mục này sẽ nhanh chóng làm chậm tốc độ của bạn. Không làm những gì bạn nghĩ là cần thiết trong các lần lặp tiếp theo - chỉ làm những gì cần thiết để hoàn thành Câu chuyện người dùng hiện tại.

Theo dõi tốc độ dự án và các Câu chuyện người dùng đang chờ xử lý. Có thể kế hoạch phát hành sẽ phải được thực hiện lại sau mỗi ba đến năm lần lặp lại. Điều này là tốt. Rốt cuộc, kế hoạch phát hành là một cái nhìn về tương lai và điều tự nhiên là dự đoán của bạn sẽ phải được điều chỉnh.

Sự lặp lại

Sự phát triển lặp đi lặp lại làm tăng tính linh hoạt của quy trình. Chia kế hoạch của bạn thành các lần lặp trong thời gian từ 2 đến 3 tuần. Duy trì thời lượng lặp lại không đổi trong suốt thời gian của dự án. Hãy để sự lặp lại là nhịp đập trong dự án của bạn. Đây là nhịp điệu sẽ giúp việc đo lường tiến độ và lập kế hoạch trở nên đơn giản và đáng tin cậy.

Đừng lên lịch nhiệm vụ trước. Thu thập thay thế Lập kế hoạch lặp lại vào đầu mỗi lần lặp để lập kế hoạch những gì sẽ được thực hiện. Việc chạy trước và làm những gì không được lên kế hoạch trong lần lặp này cũng được coi là vi phạm các quy tắc. Do đó, có thể kiểm soát được các yêu cầu thay đổi của khách hàng.

Thực hiện các thời hạn hoàn thành lặp lại một cách nghiêm túc. Đo lường tiến độ khi bạn làm việc. Nếu bạn có thể thấy rằng bạn không thể hoàn thành tất cả các nhiệm vụ đã lên lịch trước thời hạn, hãy thu thập Lập kế hoạch lặp lại một lần nữa và đánh giá lại các nhiệm vụ và hoãn một số nhiệm vụ.

Tập trung nỗ lực của bạn để hoàn thành các nhiệm vụ quan trọng nhất do Khách hàng lựa chọn, thay vì có một vài nhiệm vụ chưa hoàn thành do nhà phát triển lựa chọn.

Thay đổi nhiệm vụ

Cần phải thay đổi nhiệm vụ định kỳ cho các nhà phát triển để giảm nguy cơ tập trung kiến ​​thức và tắc nghẽn trong mã. Nếu chỉ một người trong nhóm của bạn có thể làm việc trong một khu vực nhất định và người đó rời đi, hoặc bạn chỉ có nhiều việc phải làm trong phân đoạn này của chương trình, bạn sẽ thấy rằng dự án của mình hầu như không tiến triển được.

Đào tạo chéo thường là một khía cạnh quan trọng trong các công ty cố gắng tránh tập trung kiến ​​thức vào một người. Di chuyển mọi người xung quanh mã kết hợp với lập trình cặp kín đáo làm cho Cross Training cho bạn. Thay vì một người biết mọi thứ về một đoạn mã nhất định, mọi người trong nhóm của bạn biết rất nhiều về mã trong mỗi mô-đun.

Nhóm sẽ trở nên linh hoạt hơn nhiều nếu mọi người đều biết đủ về từng phần của hệ thống để bắt đầu làm việc với nó. Thay vì đợi "guru" hoàn thành công việc trên một đoạn mã quan trọng, nhiều lập trình viên có thể làm việc trên nó cùng một lúc.

Khi bắt đầu một sự lặp lại mọi nhà phát triển phải chuyển sang một nhiệm vụ mới. Lập trình cặp giúp khắc phục vấn đề thích ứng (có nghĩa là một nhà phát triển mới có thể bắt cặp với một nhà phát triển có kinh nghiệm trong lĩnh vực này).

Thực hành này cũng kích thích các ý tưởng mới và cải tiến mã.

Lưu tối ưu hóa cho sau này

Không bao giờ tối ưu hóa bất kỳ thứ gì trước khi bạn hoàn thành mã hóa. Đừng bao giờ cố gắng đoán xem các nút thắt hiệu suất sẽ ở đâu. Đo lường!

Làm cho nó hoạt động, sau đó làm cho nó đúng, sau đó làm cho nó nhanh chóng.

Lập trình cặp

Tất cả mã cho một hệ thống sản xuất (có nghĩa là không bao gồm các giải pháp thử nghiệm) được viết theo cặp. Hai nhà phát triển ngồi cạnh nhau. Một mặt số, mặt khác trông. Chúng thay đổi theo thời gian. Nó không được phép làm việc một mình. Nếu vì lý do nào đó mà người thứ hai trong cặp bỏ lỡ điều gì đó (bị ốm, bỏ đi, v.v.), anh ta có nghĩa vụ xem xét tất cả các thay đổi của người thứ nhất.

Nghe có vẻ bất thường, nhưng XP khẳng định rằng sau một thời gian ngắn thích nghi, hầu hết mọi người đều làm việc tốt theo từng cặp. Họ thậm chí còn thích nó, vì công việc được hoàn thành nhanh hơn nhiều. Nguyên tắc "Một cái đầu là tốt, nhưng hai cái còn tốt hơn" được áp dụng. Các cặp đôi thường tìm ra các giải pháp tốt hơn. Ngoài ra, chất lượng của mã được tăng lên đáng kể, số lượng lỗi được giảm thiểu và việc trao đổi kiến ​​thức giữa các nhà phát triển được đẩy mạnh.

Refactor tàn nhẫn!

Các lập trình viên của chúng tôi có xu hướng gắn bó với một thiết kế rất lâu sau khi nó trở nên khó xử. Chúng tôi tiếp tục sử dụng lại đoạn mã khó sử dụng vì bằng cách nào đó nó vẫn hoạt động và chúng tôi sợ sẽ làm rối tung nó. Nhưng nó có thực sự mang lại lợi ích? XP có quan điểm rằng nó không mang lại lợi nhuận. Khi chúng tôi loại bỏ phần dư thừa, cải thiện thiết kế lỗi thời, loại bỏ phần không sử dụng - chúng tôi tái cấu trúc. Tái cấu trúc cuối cùng tiết kiệm thời gian và cải thiện chất lượng sản phẩm.

Sửa đổi tàn nhẫn bất kỳ mã nào để giữ cho thiết kế đơn giản khi bạn phát triển. Giữ cho mã rõ ràng và dễ hiểu để dễ hiểu, dễ sửa đổi và mở rộng. Hãy chắc chắn rằng mọi thứ được viết một lần và chỉ một lần. Cuối cùng, nó mất ít thời gian hơn so với việc dọn dẹp một hệ thống phức tạp.

Kế hoạch phát hành

Kế hoạch Phát hành được phát triển tại Cuộc họp Lập kế hoạch Phát hành. Kế hoạch phát hành mô tả chế độ xem của toàn bộ dự án và được sử dụng sau đó để lập kế hoạch lặp lại.

Điều quan trọng là người kỹ thuật đưa ra quyết định kỹ thuật và người kinh doanh đưa ra quyết định kinh doanh. Lập kế hoạch phát hành xác định một bộ quy tắc cho phép mọi người đưa ra quyết định của riêng mình. Những quy tắc này xác định phương pháp phát triển một kế hoạch làm việc thỏa mãn tất cả.

Bản chất của cuộc họp lập kế hoạch phát hành cho nhóm phát triển là đánh giá từng Câu chuyện người dùng trong những tuần lý tưởng. Một tuần lý tưởng là khoảng thời gian bạn nghĩ sẽ hoàn thành nhiệm vụ nếu không có điều gì khiến bạn phân tâm nữa. Không có phụ thuộc, không có nhiệm vụ bổ sung, nhưng bao gồm các bài kiểm tra. Sau đó, khách hàng quyết định nhiệm vụ nào là quan trọng nhất hoặc có mức độ ưu tiên cao hơn.

Câu chuyện của người dùng được ghi lại trên thẻ. Nhà phát triển và Khách hàng xáo trộn các thẻ với nhau trên bàn cho đến khi họ nhận được một tập hợp Câu chuyện của người dùng, cùng nhau sẽ tạo nên Bản phát hành đầu tiên (hoặc tiếp theo). Mọi người đều muốn phát hành càng sớm càng tốt một hệ thống hữu ích có thể được thử nghiệm.

Một bản phát hành có thể được lên lịch theo thời gian hoặc theo số lượng. Để xác định có bao nhiêu Câu chuyện người dùng có thể được triển khai vào một ngày cụ thể hoặc một tập hợp nhiệm vụ nhất định sẽ mất bao lâu trong thời gian thực, tốc độ của dự án được sử dụng. Nếu bạn lập kế hoạch đúng giờ, hãy nhân số lần lặp lại với tốc độ của dự án để tìm ra bao nhiêu Câu chuyện người dùng có thể được triển khai. Khi lập kế hoạch theo khối lượng, hãy chia tổng số tuần lý tưởng cần thiết cho tất cả các Câu chuyện của người dùng cho tốc độ của dự án và bạn sẽ nhận được số lần lặp lại cần thiết để hoàn thành bản phát hành.

Nếu ban giám đốc không hài lòng với ngày hoàn thành, có thể dẫn đến việc giảm ước tính phạm vi. Bạn không bao giờ nên làm điều này. Xếp hạng thấp nhất định sẽ tạo ra rất nhiều vấn đề sau này. Thay vào đó, hãy thương lượng với người quản lý, nhà phát triển và khách hàng cho đến khi bạn có một kế hoạch phát hành có thể chấp nhận được cho mọi người.

Bản phát hành thường xuyên

Các nhà phát triển nên phát hành các phiên bản của hệ thống cho người dùng (hoặc người thử nghiệm beta) thường xuyên nhất có thể.

Lập kế hoạch phát hànhđược sử dụng để tìm các phân đoạn chức năng nhỏ có ý nghĩa kinh doanh quan trọng và có thể được phát hành vào môi trường thực ở giai đoạn đầu của quá trình phát triển. Điều này rất quan trọng để nhận được phản hồi hữu ích kịp thời để bạn có thể ảnh hưởng đến quá trình phát triển. Bạn càng trì hoãn việc phát hành một phần quan trọng của hệ thống, bạn càng có ít thời gian để sửa chữa nó.

Giải pháp thử nghiệm

Tạo các giải pháp thử nghiệm để trả lời các câu hỏi kỹ thuật phức tạp, để biện minh cho các giải pháp công nghệ nhất định. Có rủi ro trong bất kỳ quyết định công nghệ nào và các quyết định thử nghiệm được thiết kế để giảm thiểu rủi ro đó.

Tạo một chương trình tái tạo vấn đề đang được điều tra và bỏ qua mọi thứ khác. Hầu hết các giải pháp thử nghiệm không nhằm mục đích sử dụng trong tương lai, vì vậy hãy mong đợi chúng được vứt bỏ. Mục đích của việc tạo ra họ là để giảm nguy cơ đưa ra quyết định kỹ thuật sai hoặc ước tính chính xác hơn về thời gian thực hiện Câu chuyện người dùng.

Thường vụ cuộc họp

Mỗi buổi sáng, một cuộc họp được tổ chức để thảo luận về các vấn đề, giải pháp của họ và để tăng sự tập trung của cả nhóm. Cuộc họp được tổ chức đứng để tránh các cuộc thảo luận dài dòng không gây hứng thú cho tất cả các thành viên trong nhóm.

Trong một cuộc họp thông thường, hầu hết những người tham gia không đóng góp gì, họ chỉ tham gia để nghe những gì người khác nói. Rất nhiều người dành thời gian để có được một lượng nhỏ giao tiếp. Do đó, sự tham gia của tất cả mọi người trong các cuộc họp sẽ lấy đi nguồn lực của dự án và tạo ra sự hỗn loạn trong quy hoạch.

Đối với loại giao tiếp này, cần có một cuộc họp thường trực. Sẽ tốt hơn nhiều nếu có một cuộc họp ngắn, bắt buộc hơn nhiều cuộc họp dài mà hầu hết các nhà phát triển phải tham dự.

Nếu bạn có các cuộc họp thường trực hàng ngày, thì tất cả các cuộc họp khác chỉ nên có sự tham gia của những người cần thiết và sẽ mang theo thứ gì đó. Hơn nữa, thậm chí có thể tránh một số cuộc họp. Với số lượng người tham dự hạn chế, hầu hết các cuộc họp có thể được tổ chức tự phát trước màn hình, nơi mà việc trao đổi ý kiến ​​diễn ra gay gắt hơn nhiều.

Cuộc họp buổi sáng hàng ngày không phải là một sự lãng phí thời gian nữa. Nó sẽ giúp bạn tiết kiệm được nhiều cuộc họp khác và sẽ giúp bạn tiết kiệm thời gian hơn là lãng phí.

Ẩn dụ về hệ thống

Luôn chọn Ẩn dụ hệ thống - một khái niệm đơn giản và dễ hiểu để các thành viên trong nhóm gọi tất cả mọi thứ cùng một tên. Để hiểu hệ thống và tránh trùng lặp mã, cách bạn đặt tên cho các đối tượng là vô cùng quan trọng. Nếu bạn có thể đoán được tên của bất kỳ đối tượng nào trong hệ thống (nếu bạn biết nó làm gì) và nó thực sự được gọi như vậy - bạn sẽ tiết kiệm được rất nhiều thời gian và công sức. Tạo hệ thống đặt tên cho các đối tượng của bạn để mọi người trong nhóm có thể sử dụng nó mà không cần kiến ​​thức đặc biệt về hệ thống.

Kiểm tra đơn vị

Bài kiểm tra đơn vị đóng một vai trò quan trọng trong XP. Chúng cho phép bạn nhanh chóng thay đổi mã mà không sợ mắc lỗi mới. Bài kiểm tra đơn vị được viết cho mỗi lớp, bài kiểm tra nên kiểm tra tất cả các khía cạnh của lớp - kiểm tra mọi thứ có thể không hoạt động.

Bí quyết ở đây là bài kiểm tra cho lớp phải được viết trước chính lớp đó. Điều này có nghĩa là ngay sau khi bạn phát hành kết quả làm việc đầu tiên, nó sẽ được hỗ trợ bởi hệ thống thử nghiệm. Để tiến hành các bài kiểm tra, một hệ thống kiểm tra đặc biệt được viết với giao diện riêng của nó.

Bài kiểm tra đơn vị cho một lớp được lưu trữ trong một kho lưu trữ chung cùng với mã lớp. Không có mã nào có thể được phát hành nếu không có bài kiểm tra Đơn vị. Trước khi gửi mã, nhà phát triển phải đảm bảo rằng tất cả các bài kiểm tra đều vượt qua mà không có lỗi. Không ai có thể đưa ra mã nếu mọi người chưa vượt qua 100%. Nói cách khác, vì tất cả các bài kiểm tra đã vượt qua trước khi bạn thay đổi, nếu bạn có lỗi, thì đây là kết quả của những thay đổi của bạn. Bạn và chính xác. Đôi khi mã kiểm tra không chính xác hoặc không đầy đủ. Trong trường hợp này, bạn cần phải sửa lại.

Tiết kiệm tiền cho các bài kiểm tra Unit khi có ít thời gian là một sự cám dỗ rất lớn. Nhưng bằng cách này, bạn chỉ đang lừa dối chính mình. Bài kiểm tra càng khó viết thì càng tiết kiệm thời gian về sau. Điều này đã được thực tế chứng minh.

Kiểm tra đơn vị cho phép quyền sở hữu tập thể đối với mã. Họ làm cho nó tương đối dễ dàng để sửa đổi mã xấu. Ngoài ra Unit tests cho phép bạn có một hệ thống hoạt động ổn định bất cứ lúc nào.

Câu chuyện người dùng

Câu chuyện người dùng (một cái gì đó giống như câu chuyện người dùng) là một mô tả về cách hệ thống sẽ hoạt động. Mỗi Câu chuyện Người dùng được viết trên một thẻ và đại diện cho một phần chức năng của hệ thống có ý nghĩa hợp lý theo quan điểm của Khách hàng. Hình thức - một hoặc hai đoạn văn bản có thể hiểu được đối với người dùng (không phải là kỹ thuật cho lắm).

Câu chuyện Người dùng được viết bởi Khách hàng. Chúng tương tự như các trường hợp sử dụng hệ thống, nhưng không giới hạn ở giao diện người dùng. Đối với mỗi câu chuyện, các bài kiểm tra chức năng được viết để xác nhận rằng câu chuyện được triển khai chính xác - chúng còn được gọi là các bài kiểm tra Chấp nhận.

Mỗi Câu chuyện người dùng được ưu tiên bởi doanh nghiệp (người dùng, khách hàng, tiếp thị) và ước tính thời gian thực hiện bởi các nhà phát triển. Mỗi câu chuyện được chia thành các nhiệm vụ và thời gian được ấn định cho nó khi nó sẽ bắt đầu được thực hiện.

Câu chuyện người dùng được sử dụng trong XP thay vì các yêu cầu truyền thống. Sự khác biệt chính giữa Câu chuyện người dùng và các yêu cầu là mức độ chi tiết. Câu chuyện người dùng chứa thông tin tối thiểu cần thiết để ước tính hợp lý về thời gian thực hiện nó.

Một câu chuyện người dùng điển hình mất khoảng thời gian lý tưởng từ 1-3 tuần. Một câu chuyện yêu cầu dưới 1 tuần là quá chi tiết. Một câu chuyện cần hơn 3 tuần có thể được chia thành nhiều phần - những câu chuyện riêng biệt.

Tốc độ dự án

Tốc độ dự án (hay đơn giản là tốc độ) là thước đo tốc độ hoàn thành công việc trong dự án của bạn.

Để đo tốc độ của một dự án, bạn chỉ cần tính quy mô của Câu chuyện người dùng hoặc có bao nhiêu nhiệm vụ (trong thời gian) đã được hoàn thành trong một lần lặp. Chỉ cần tính tổng thời gian để ước tính khối lượng công việc (thời gian lý tưởng).

Trong quá trình lập kế hoạch phát hành, tốc độ dự án được sử dụng để ước tính số lượng Câu chuyện người dùng có thể được tạo ra.

Trong quá trình lập lịch lặp, tốc độ dự án trong lần lặp trước được sử dụng để xác định số lượng Câu chuyện người dùng cần lập kế hoạch trong lần lặp hiện tại.

Cơ chế đơn giản này cho phép các nhà phát triển khôi phục sau một lần lặp lại khó khăn. Nếu bạn có thời gian rảnh sau khi khôi phục, hãy đến gặp khách hàng và hỏi thêm về User Story. Kết quả là, tốc độ sẽ tăng trở lại.

Không sử dụng tham số này là tuyệt đối. Nó không phù hợp để so sánh năng suất của hai dự án, vì mỗi nhóm có những đặc điểm riêng. Thông số này chỉ quan trọng đối với nhóm nghiên cứu để giữ cho nó ở trạng thái "chẵn lẻ".

Bạn nên mong đợi những thay đổi nhỏ về tốc độ dự án khi bạn làm việc. Nhưng nếu tốc độ thay đổi nhiều, bạn cần lên lịch phát hành lại. Ngay sau khi hệ thống mới đến tay người dùng, hãy mong đợi tốc độ của dự án sẽ thay đổi khi bạn có các tác vụ hỗ trợ.

Khi một lỗi được tìm thấy

Nếu một lỗi được tìm thấy, một bài kiểm tra sẽ được tạo ra để ngăn nó tái diễn. Một lỗi xảy ra trên hệ thống sản xuất (đã được cài đặt) yêu cầu viết một bài kiểm tra chức năng. Tạo một bài kiểm tra chức năng ngay trước khi chẩn đoán lỗi cho phép khách hàng mô tả rõ ràng vấn đề và thông báo vấn đề với nhà phát triển.

Kiểm tra chức năng không thành công yêu cầu tạo Kiểm tra đơn vị... Điều này giúp tập trung các nỗ lực gỡ lỗi và hiển thị rõ ràng khi lỗi đã được sửa.

Bạn không cần nó

Hạn chế lấp đầy hệ thống bằng những thứ bạn sẽ cần trong tương lai. Chỉ 10% những gì bạn mong đợi sẽ thực sự cần thiết ở dạng ban đầu, tức là 90% thời gian của bạn sẽ bị lãng phí.

Luôn có sự cám dỗ để thêm chức năng ngay bây giờ và không phải sau này, bởi vì chúng tôi thấy cách thêm nó ngay bây giờ và cảm thấy rằng hệ thống sẽ tốt hơn nhiều. Nhưng chúng ta phải luôn nhắc nhở bản thân rằng chúng ta sẽ không bao giờ cần đến nó. Chức năng bổ sung chỉ làm chậm tiến độ và ngốn tài nguyên. Quên các yêu cầu trong tương lai và tính linh hoạt bổ sung. Tập trung vào những gì cần phải làm ngay bây giờ.

Thủ thuật XP cơ bản

Mười hai kỹ thuật lập trình cực đoan cơ bản (dựa trên ấn bản đầu tiên của cuốn sách Giải thích về lập trình cực đoan) có thể được kết hợp thành bốn nhóm:

• Phản hồi quy mô tốt
  • Hướng phát triển thử nghiệm
  • Lập kế hoạch trò chơi
  • Khách hàng luôn ở đó (Toàn bộ nhóm, Khách hàng tại chỗ)
  • Lập trình cặp
• Quy trình liên tục, không phải hàng loạt
  • Hội nhập liên tục
  • Refactoring (Cải tiến thiết kế, Refactor)
  • Bản phát hành nhỏ thường xuyên
• Sự hiểu biết được chia sẻ bởi tất cả
  • Tính đơn giản (Thiết kế đơn giản)
  • Ẩn dụ hệ thống
  • Quyền sở hữu mã tập thể hoặc quyền sở hữu các mẫu đã chọn
  • Tiêu chuẩn mã hóa hoặc các quy ước mã hóa
• Phúc lợi của lập trình viên:
  • Tuần làm việc 40 giờ (Tốc độ bền vững, Bốn mươi giờ một tuần)

Thử nghiệm

XP tập trung vào hai loại thử nghiệm:

• kiểm tra đơn vị;
• kiểm tra chấp nhận

Một nhà phát triển không thể chắc chắn về tính chính xác của mã mà anh ta đã viết cho đến khi hoàn toàn tất cả các thử nghiệm của các mô-đun của hệ thống mà anh ta đang phát triển đã hoạt động. Các bài kiểm tra đơn vị cho phép các nhà phát triển xác minh rằng mã của họ đang hoạt động chính xác. Chúng cũng giúp các nhà phát triển khác hiểu tại sao cần một đoạn mã cụ thể và cách nó hoạt động. Các bài kiểm tra đơn vị cũng cho phép nhà phát triển tái cấu trúc mà không sợ hãi.

Kiểm tra chấp nhận đảm bảo rằng hệ thống thực sự hoạt động như quảng cáo. Ngoài ra, các bài kiểm tra chấp nhận cho phép bạn kiểm tra hoạt động chính xác của sản phẩm đang được phát triển.

Đối với XP, cách tiếp cận được gọi là TDD (Phát triển theo hướng kiểm tra) là ưu tiên cao hơn - trước tiên, một bài kiểm tra được viết không đạt, sau đó mã được viết để làm cho bài kiểm tra vượt qua và sau đó mã được cấu trúc lại.

Trò chơi lập kế hoạch

Mục tiêu chính của trò chơi lập kế hoạch là nhanh chóng hình thành một kế hoạch công việc thô và liên tục cập nhật nó khi các điều khoản của vấn đề trở nên rõ ràng hơn. Các hiện vật của trò chơi lập kế hoạch là một bộ thẻ giấy trên đó viết các câu chuyện của khách hàng và một kế hoạch làm việc gần đúng cho một hoặc nhiều phiên bản nhỏ tiếp theo của sản phẩm. Yếu tố quan trọng làm nên hiệu quả của phong cách lập kế hoạch này là khách hàng chịu trách nhiệm đưa ra các quyết định kinh doanh và nhóm phát triển chịu trách nhiệm đưa ra các quyết định kỹ thuật. Nếu quy tắc này không được tuân thủ, toàn bộ quá trình sẽ sụp đổ.

Khách hàng luôn ở đó

“Khách hàng” trong XP không phải là người thanh toán hóa đơn, mà là người dùng cuối của sản phẩm phần mềm. XP tuyên bố rằng khách hàng phải luôn liên lạc và sẵn sàng giải đáp thắc mắc.

Lập trình cặp

Lập trình cặp giả định rằng tất cả mã được tạo bởi các cặp lập trình viên làm việc trên cùng một máy tính. Một trong số họ làm việc trực tiếp với văn bản của chương trình, người kia xem xét công việc của mình và theo dõi bức tranh tổng thể về những gì đang xảy ra. Nếu cần, bàn phím được chuyển tự do từ bàn phím này sang bàn phím khác. Trong quá trình làm việc trên dự án, các cặp không cố định: nên trộn chúng để mỗi lập trình viên trong nhóm hiểu rõ về toàn bộ hệ thống. Bằng cách này, lập trình cặp giúp tăng cường giao tiếp trong nhóm.

Hội nhập liên tục

Nếu bạn tích hợp hệ thống đang được phát triển đủ thường xuyên, bạn có thể tránh được hầu hết các vấn đề liên quan. Trong các phương pháp truyền thống, tích hợp thường được thực hiện vào cuối công việc trên sản phẩm, khi được coi là tất cả các bộ phận cấu thành của hệ thống đang được phát triển đã hoàn toàn sẵn sàng. Trong XP, tích hợp mã trên toàn hệ thống được thực hiện nhiều lần trong ngày, sau khi các nhà phát triển đã đảm bảo rằng tất cả các bài kiểm tra đơn vị đều hoạt động chính xác.

Tái cấu trúc

Tái cấu trúc là một kỹ thuật để cải thiện mã mà không thay đổi chức năng của nó. XP ngụ ý rằng một khi được viết, mã gần như chắc chắn sẽ được viết lại nhiều lần trong suốt quá trình của một dự án. Các nhà phát triển XP không ngừng nghiên cứu mã đã viết trước đó để cải thiện nó. Quá trình này được gọi là tái cấu trúc. Việc thiếu phạm vi kiểm tra dẫn đến việc từ chối cấu trúc lại do sợ phá vỡ hệ thống, dẫn đến sự suy thoái dần dần của mã.

Bản phát hành nhỏ thường xuyên

Các bản phát hành của sản phẩm nên được phát hành thường xuyên nhất có thể. Làm việc trên mỗi phiên bản sẽ mất ít thời gian nhất có thể. Hơn nữa, mỗi phiên bản phải đủ ý nghĩa trên quan điểm hữu ích cho doanh nghiệp.

Chúng tôi phát hành phiên bản làm việc đầu tiên của sản phẩm càng sớm, khách hàng sẽ bắt đầu nhận được thêm lợi nhuận từ nó. Hãy nhớ rằng số tiền kiếm được ngày hôm nay đáng giá hơn số tiền kiếm được vào ngày mai. Khách hàng bắt đầu sử dụng sản phẩm càng sớm, các nhà phát triển càng sớm nhận được thông tin từ anh ta về những gì đáp ứng yêu cầu của khách hàng. Thông tin này có thể cực kỳ hữu ích khi lập kế hoạch phát hành tiếp theo của bạn.

Sự đơn giản của thiết kế

XP thu được từ thực tế là trong quá trình làm việc, các điều kiện của vấn đề có thể thay đổi nhiều lần, có nghĩa là sản phẩm đang được phát triển không được thiết kế trước một cách đầy đủ và hoàn chỉnh. Nếu ngay từ đầu công việc của bạn, bạn đang cố gắng thiết kế một hệ thống chi tiết từ đầu đến cuối, bạn đang lãng phí thời gian. XP giả định rằng thiết kế là một quá trình quan trọng đến mức nó phải được thực hiện liên tục trong suốt thời gian của dự án. Thiết kế nên được thực hiện theo từng bước nhỏ, có tính đến các yêu cầu thay đổi liên tục. Tại mọi thời điểm, chúng tôi đang cố gắng sử dụng thiết kế đơn giản nhất phù hợp với nhiệm vụ hiện tại. Đồng thời, chúng tôi thay đổi nó khi các điều kiện của vấn đề thay đổi.

Ẩn dụ hệ thống

Kiến trúc là một cái nhìn về các thành phần của một hệ thống và mối quan hệ qua lại giữa chúng. Các nhà phát triển cần phân tích kiến ​​trúc phần mềm để hiểu được vị trí cần bổ sung chức năng mới trong hệ thống và thành phần mới sẽ tương tác với cái gì.

Phép ẩn dụ hệ thống tương tự như cái mà hầu hết các kỹ thuật gọi là kiến ​​trúc. Phép ẩn dụ hệ thống cung cấp cho nhóm ý tưởng về cách hệ thống hiện đang hoạt động, nơi các thành phần mới đang được thêm vào và chúng sẽ ở dạng nào.

Chọn một phép ẩn dụ tốt sẽ giúp nhóm phát triển dễ dàng hiểu cách hệ thống hoạt động hơn. Đôi khi điều này không dễ thực hiện.

Tiêu chuẩn mã hóa

Tất cả các thành viên trong nhóm trong quá trình làm việc phải tuân thủ các yêu cầu của tiêu chuẩn mã hóa chung. Bằng cách ấy:

• các thành viên trong nhóm không lãng phí thời gian vào những lập luận ngớ ngẩn về những thứ thực sự không ảnh hưởng đến tốc độ làm việc trong dự án theo bất kỳ cách nào;
• thực hiện hiệu quả các thực hành khác được đảm bảo.

Nếu nhóm không sử dụng các tiêu chuẩn mã hóa thống nhất, các nhà phát triển sẽ khó tái cấu trúc hơn; khi thay đổi đối tác theo cặp, nhiều khó khăn nảy sinh hơn; Nhìn chung, tiến độ của dự án gặp nhiều khó khăn. Là một phần của XP, cần phải làm cho khó hiểu ai là tác giả của một đoạn mã cụ thể - cả nhóm làm việc theo một cách thống nhất, như một người. Nhóm phải hình thành một bộ quy tắc, và sau đó mỗi thành viên trong nhóm phải tuân theo các quy tắc này trong quá trình viết mã. Danh sách các quy tắc không được đầy đủ hoặc quá dài. Thách thức là cung cấp các hướng dẫn chung để làm cho mã dễ hiểu đối với mọi người trong nhóm. Ban đầu, một tiêu chuẩn mã hóa nên đơn giản, sau đó nó có thể trở nên phức tạp hơn khi nhóm phát triển tích lũy kinh nghiệm. Bạn không cần mất quá nhiều thời gian để phát triển trước tiêu chuẩn.

Sở hữu tập thể

Sở hữu tập thể có nghĩa là mỗi thành viên trong nhóm chịu trách nhiệm về toàn bộ mã nguồn. Do đó, mọi người đều có quyền thay đổi bất kỳ phần nào của chương trình. Lập trình cặp hỗ trợ thực hành này: làm việc theo các cặp khác nhau, tất cả các lập trình viên trở nên quen thuộc với tất cả các phần mã của hệ thống. Một lợi thế quan trọng của quyền sở hữu mã được chia sẻ là nó tăng tốc quá trình phát triển, vì khi lỗi xảy ra, bất kỳ lập trình viên nào cũng có thể sửa chữa nó.

Bằng cách trao cho mọi lập trình viên quyền thay đổi mã, chúng tôi có nguy cơ mắc lỗi do các lập trình viên nghĩ rằng họ biết họ đang làm gì, nhưng không xem xét một số phụ thuộc. Các bài kiểm tra UNIT được xác định rõ ràng sẽ giải quyết vấn đề này: nếu các phần phụ thuộc chưa được giải quyết tạo ra lỗi, thì lần chạy tiếp theo của các bài kiểm tra UNIT sẽ không thành công.

Văn học

• Kent Beck: Lập trình cực đoan- Peter, 2002, ISBN 5-94723-032-1.
• Kent Beck, Martin Fowler: Lập trình cực đoan: lập kế hoạch- Peter, 2003, ISBN 5-318-00111-4.
• Kent Beck: Lập trình khắc nghiệt: Phát triển theo hướng thử nghiệm- Peter, 2003, ISBN 5-8046-0051-6.
• Ken Auer, Roy Miller: "Lập trình cực đoan: Thiết lập quy trình từ những bước đầu tiên đến kết thúc" - Peter, 2003, ISBN 5-318-00132-7.

Xem thêm

Liên kết

• Ward Cunningham Wiki là "tiên tiến" của XP.
• XProgramming.com - trang của Ron Jeffries: các bài báo và tài nguyên về XP và các chủ đề liên quan, đánh giá sách.
• Lập trình cực đoan: Lời giới thiệu nhẹ nhàng của Don Wells.
• MAXKIR.COM (tiếng Nga) - bản dịch các bài báo của những người cha sáng lập và các nhà tư tưởng của XP
• www.agiledev.ru (rus.) - Trang web của các phương pháp phát triển nhanh
• TopCoder (tiếng Anh) - cuộc thi lập trình thể thao
• Thư viện sách điện tử về lập trình cực đoan (rus.)
• Lập trình cực đoan - thực tế và huyền thoại (rus.)
• Thử nghiệm dưới ánh sáng của Lập trình cực đoan. Phần 1 (tiếng Nga)
• CNTT và tâm lý học. Yếu tố con người trong lập trình cặp: tại sao nhiều người không đạt được những gì họ muốn từ việc triển khai nó? (Tiếng Nga)

Quỹ Wikimedia. Năm 2010.

Xem "Lập trình cực đoan" là gì trong các từ điển khác:

lập trình cực đoan- Một trong những phương pháp luận phát triển phần mềm. Các chủ đề công nghệ thông tin nói chung EN cực lập trìnhXP ... Hướng dẫn của người phiên dịch kỹ thuật

Bài viết này cần được viết lại hoàn toàn. Có thể có giải thích trên trang thảo luận. Thuật ngữ này có các nghĩa khác, xem Chương trình ... Wikipedia

Quản lý dự án cực đoan (XPM) là một phương pháp quản lý các dự án rất phức tạp hoặc không xác định. XPM khác với các phương pháp quản lý dự án truyền thống ở chỗ mở, linh hoạt và ... ... Wikipedia