Extreme Programming (XP): 5 Giá trị – 5 Quy tắc – 12 Practices và XP Lifecycle

extreme programming featured image

Cập nhật lần cuối vào 09/10/2023 bởi Phạm Mạnh Cường

Extreme Programming (XP) là một trong các phương pháp Agile nổi tiếng nhất, mặc dù XP không được ứng dụng rộng rãi như Scrum nhưng các kỹ thuật trong XP thì lại được áp dụng trong rất nhiều framework của Agile.

Extreme Programming có thể vận hành tốt nếu có đầy đủ 5 giá trị, có thể ứng dụng tốt qua 5 quy tắc và 12 practices. Vòng đời XP cũng khá đơn giản, nhưng cũng chính là tuân theo triêt lý của XP: Sự tối giản.

eXtreme Programming (XP) là gì?

eXtreme Programming (XP) là một phương pháp Agile được áp dụng cho việc phát triển phần mềm, nhằm mục đích tạo ra phần mềm chất lượng cao hơn và chất lượng môi trường làm việc của nhóm phát triển tốt hơn.

XP sử dụng các nhóm làm việc kết hợp gồm những người lập trình, khách hàng và các nhà quản trị để phát triển phần mềm có chất lượng cao trong thời gian nhanh chóng. Một chương trình chạy được là thước đo đầu tiên của tiến trình theo XP.

Ai đã tạo ra eXtreme Programming?

eXtreme Programming (XP) được tạo ra vào năm 1996 bởi Kent Beck, một trong những người đã tham gia trong việc đưa ra tuyên ngôn Agile.

XP đã ra đời trong bối cảnh Kent Beck tạo ra một phần mềm cho Chrysler tên là C3. Mục tiêu của XP là loại bỏ sự phản đối việc chỉnh sửa code trong các dự án phần mềm. 

Trong các phương pháp phát triển phần mềm truyền thống hơn, bạn chỉ viết code và không có thao tác gì (ngoại trừ lúc debug). Với XP, bạn xem xét kỹ lưỡng mã nguồn đến mức các nhà phát triển có thể quyết định viết lại toàn bộ mã đó sau một lần lặp.

Khi nào thì sử dụng eXtreme Programming?

eXtreme Programming (XP) thường chỉ sử dụng bởi các nhóm kỹ thuật. Để sử dụng XP một cách hiệu quả thì dự án của bạn nên có các đặc điểm:

  • Yêu cầu phần mềm phải biết thích ứng và có thể thay đổi linh hoạt
  • Dự án sử dụng công nghệ mới, có nhiều rủi ro
  • Team Dev có số lượng nhỏ, tốt nhất là 2-12 và có chung một trụ sở
  • Hệ thống kiểm thử tự động theo từng đơn vị chức năng
  • Có thể thường xuyên liên hệ với khách hàng

5 giá trị của eXtreme Programming

Extreme Programming là một phương thức value-driven. XP cho phép nhóm của bạn làm việc theo cách ít phức tạp hơn (tập trung vào sự đơn giản và cộng tác trên các thiết kế phức tạp), tất cả đều dựa trên năm giá trị này.

Simplicity (Đơn giản)

Đơn giản có nghĩa là “điều đơn giản nhất sẽ hiệu quả là gì?” Mục đích của việc này là để tránh lãng phí và chỉ làm những việc thực sự cần thiết như giữ cho thiết kế của hệ thống càng đơn giản càng tốt để dễ bảo trì, hỗ trợ và sửa đổi hơn. Đơn giản cũng có nghĩa là chỉ giải quyết những yêu cầu mà bạn biết; đừng cố gắng dự đoán tương lai.

Communication (Giao tiếp)

Phát triển phần mềm vốn là một môn thể thao đồng đội dựa vào giao tiếp để truyền đạt kiến ​​thức từ một thành viên trong nhóm sang những người khác trong nhóm. XP nhấn mạnh tầm quan trọng của loại hình giao tiếp thích hợp – thảo luận trực tiếp với sự hỗ trợ của bảng trắng hoặc cơ chế vẽ khác.

XP dựa vào khả năng phản ứng nhanh và giao tiếp hiệu quả. Để làm việc, nhóm cần phải cởi mở và trung thực với nhau. Khi có vấn đề phát sinh, bạn phải lên tiếng. Lý do cho điều này là các thành viên khác trong nhóm thường đã có sẵn giải pháp. Và nếu họ chưa có, bạn cũng có thể đưa ra giải pháp nhanh hơn với một nhóm thành viên hơn là việc bạn ngồi một mình.

Feedback (Phản hồi)

Giống như các phương pháp Agile khác, XP kết hợp trực tiếp các user story và phản hồi của người dùng vào quy trình. Trọng tâm của XP là tạo ra công việc một cách nhanh chóng và đơn giản, sau đó chia sẻ nó để nhận được phản hồi gần như ngay lập tức. Do đó, các lập trình viên gần như phải liên lạc thường xuyên với khách hàng trong suốt quá trình. 

Trong XP, bạn thường xuyên đưa ra các bản phát hành để nhận được phản hồi chi tiết và thường xuyên. Khi có phản hồi, bạn sẽ điều chỉnh chi tiết đó chứ không phải thay đổi toàn bộ dự án.

Ví dụ: Phản hồi về việc thời gian tải chậm, bạn sẽ giao cho các lập trình viên để họ cải thiện phần bị chậm trễ chứ không phải điều chỉnh toàn bộ dự án.

Courage (Dũng cảm)

Kent Beck định nghĩa lòng dũng cảm là “hành động hiệu quả khi đối mặt với nỗi sợ hãi” (Extreme Programming Explained –  Trang 20). 

Định nghĩa này thể hiện sự ưu tiên hành động dựa trên các nguyên tắc khác để kết quả không gây hại cho nhóm. Bạn cần can đảm để nêu ra những vấn đề về tổ chức làm giảm hiệu quả của nhóm bạn. Bạn cần can đảm để ngừng làm việc gì đó không hiệu quả và thử làm việc khác. Bạn cần can đảm để chấp nhận và hành động dựa trên phản hồi, ngay cả khi điều đó khó chấp nhận.

XP đòi hỏi một sự can đảm nhất định. Bạn luôn phải cung cấp thông tin cập nhật trung thực về tiến trình của mình, điều này có thể khiến bạn khá dễ bị tổn thương. 

Nếu bạn bỏ lỡ thời hạn trong XP, trưởng nhóm của bạn có thể sẽ không muốn thảo luận lý do. Thay vào đó, bạn sẽ nói với họ rằng bạn đã trễ hạn, tự chịu trách nhiệm và quay lại làm việc. 

Nếu bạn là trưởng nhóm, trách nhiệm của bạn khi bắt đầu quá trình XP là đặt ra kỳ vọng về sự thành công và xác định “hoàn thành”. 

Thường có rất ít kế hoạch cho thất bại vì nhóm tập trung vào thành công. Tuy nhiên, điều này có thể đáng sợ vì mọi thứ không phải lúc nào cũng diễn ra như dự kiến. Nhưng nếu mọi thứ thay đổi trong quá trình XP, nhóm của bạn phải thích ứng và thay đổi theo nó.

Respect (Tôn trọng)

Các thành viên trong nhóm của bạn cần tôn trọng lẫn nhau để giao tiếp với nhau, cung cấp và chấp nhận phản hồi nhằm tôn vinh mối quan hệ của bạn và làm việc cùng nhau để xác định các thiết kế và giải pháp đơn giản.

Để các nhóm giao tiếp và cộng tác hiệu quả, họ cần có khả năng không đồng tình. Nhưng có nhiều cách để làm điều đó một cách tử tế. 

Sự tôn trọng là nền tảng tốt dẫn đến lòng tốt và sự tin tưởng – ngay cả khi có rất nhiều sự trung thực. 

Đối với eXtreme Programming, kỳ vọng là: 

  • Sự tôn trọng lẫn nhau giữa khách hàng và nhóm phát triển. 
  • Sự tôn trọng lẫn nhau giữa các thành viên trong nhóm. 
  • Sự ghi nhận rằng mọi người trong nhóm đều mang lại điều gì đó có giá trị cho dự án.

5 quy tắc của phương pháp eXtreme Programming

Nếu nói 5 giá trị của XP khá triết học thì 5 quy tắc lại là  các quy tắc là những ứng dụng thực tế về cách thức thực hiện công việc. Bạn sẽ cần cả hai để điều hành một nhóm XP hiệu quả.

Lên kế hoạch

Trong các giai đoạn lập kế hoạch của XP, bạn đang xác định xem dự án có khả thi và phù hợp nhất với XP hay không. Để làm điều này, bạn sẽ xem xét:

  • User story để xem liệu chúng có phù hợp với giá trị đơn giản hay không và đăng ký để đảm bảo rằng khách hàng sẵn sàng tham gia quy trình. Nếu user story phức tạp hơn hoặc được tạo bởi một khách hàng ẩn danh, nó có thể sẽ không hoạt động đối với XP.
  • Giá trị kinh doanh và mức độ ưu tiên của dự án để đảm bảo rằng điều này phù hợp với việc “hoàn thành công việc quan trọng nhất trước tiên”.
  • Bạn đang ở giai đoạn phát triển nào. XP là tốt nhất cho quá trình phát triển ở giai đoạn đầu và sẽ không hoạt động tốt cho những lần lặp lại sau này.

Sau khi bạn đã xác nhận rằng dự án khả thi cho XP, hãy tạo lịch phát hành—nhưng hãy nhớ rằng bạn nên phát hành sớm và thường xuyên để nhận được phản hồi. Để làm điều này:

  • Chia dự án thành nhiều lần lặp lại và lập kế hoạch cho từng lần.
  • Đặt thời hạn thực tế và tốc độ bền vững.
  • Chia sẻ thông tin cập nhật khi chúng diễn ra, điều này giúp nhóm của bạn trở nên trung thực và minh bạch.
  • Chia sẻ thông tin cập nhật theo thời gian thực giúp nhóm xác định, thích ứng và thực hiện các thay đổi nhanh hơn.
  • Sử dụng công cụ quản lý dự án để tạo bảng Kanban hoặc dòng thời gian nhằm theo dõi tiến trình của bạn trong thời gian thực.

Quản lý

Một trong những yếu tố chính của XP là không gian vật lý. Những người theo chủ nghĩa thuần túy XP khuyên bạn nên sử dụng một không gian làm việc mở nơi tất cả các thành viên trong nhóm làm việc trong một phòng mở. Vì XP có tính cộng tác cao nên bạn sẽ được hưởng lợi từ việc có một không gian nơi các bạn có thể gặp nhau về mặt vật lý. 

Nhưng điều đó không phải lúc nào cũng thực tế trong thời đại ngày nay. Nếu bạn làm việc trong một nhóm từ xa, hãy cân nhắc sử dụng các nền tảng giao tiếp không đồng bộ (Asynchronous communication – nghĩa là bạn đưa ra một thông điệp và không cần được phản hồi ngay lập tức) để cộng tác từ xa. Bằng cách này, tất cả các thành viên có thể tiếp tục cùng nhau thực hiện dự án, ngay cả khi họ không ở cùng nhau.

Giống như các phương pháp Agile khác, hãy sử dụng các cuộc họp dự kiến hàng ngày để kiểm tra và khuyến khích giao tiếp cởi mở, liên tục. 

Bạn sẽ muốn sử dụng cả chu kỳ hàng tuần và chu kỳ hàng quý. Trong chu kỳ hàng quý, bạn và nhóm của mình sẽ xem xét các user story sẽ định hướng cho công việc của bạn. 

Bạn cũng sẽ nghiên cứu quy trình XP của mình, tìm kiếm những khoảng trống hoặc cơ hội để thực hiện thay đổi. Sau đó, bạn sẽ làm việc theo chu kỳ hàng tuần, mỗi chu kỳ bắt đầu bằng cuộc gặp gỡ khách hàng. Khách hàng chọn user story mà họ muốn lập trình viên làm việc trong tuần đó.

Với tư cách là người quản lý hoặc trưởng nhóm, trọng tâm của bạn sẽ là duy trì tiến độ công việc, đo lường tốc độ, luân chuyển các thành viên trong nhóm để giải quyết các lỗi hoặc vấn đề khi chúng phát sinh hoặc thay đổi quy trình XP để phù hợp với dự án hiện tại và quá trình lặp lại của bạn. 

Hãy nhớ rằng mục tiêu của XP là linh hoạt và hành động, vì vậy công việc của bạn sẽ tập trung cao độ vào công việc hiện tại của nhóm và phản ứng nhanh với mọi thay đổi.

Thiết kế

Khi bạn mới bắt đầu với eXtreme Programming, hãy bắt đầu với thiết kế đơn giản nhất có thể, bạn nên biết rằng những lần lặp lại sau này sẽ khiến chúng trở nên phức tạp hơn. Ở giai đoạn đầu, hãy giữ cho nó càng đơn giản càng tốt.

Các nhóm phương pháp XP thường sẽ sử dụng thẻ class-responsibility-collaboration (CRC) để hiển thị cách mỗi đối tượng trong thiết kế tương tác với nhau. Bằng cách điền vào từng trường trong thẻ, bạn sẽ có được sự tương tác trực quan về tất cả các chức năng khi chúng liên quan và tương tác. Thẻ CRC bao gồm:

  • Class (tập hợp các đối tượng tương tự)
  • Responsibilities (liên quan đến lớp học)
  • Collaborations (lớp tương tác với lớp này)

CRC rất hữu ích trong việc thúc đẩy quá trình và phát hiện các vấn đề tiềm ẩn. Bất kể bạn thiết kế như thế nào, bạn sẽ muốn sử dụng một hệ thống giúp giảm thiểu các tắc nghẽn tiềm ẩn. Để làm được điều này, hãy chắc chắn rằng bạn đang chủ động tìm kiếm rủi ro. Ngay khi mối đe dọa tiềm ẩn xuất hiện, hãy chỉ định một đến hai thành viên trong nhóm tìm giải pháp trong trường hợp mối đe dọa đó xảy ra.

Viết mã (code)

Một trong những khía cạnh độc đáo hơn của XP là bạn sẽ giữ liên lạc thường xuyên với khách hàng trong suốt quá trình viết mã. Sự hợp tác này cho phép bạn kiểm tra và kết hợp phản hồi trong mỗi lần lặp lại, thay vì đợi cho đến khi kết thúc một lần chạy nước rút. Nhưng các quy tắc mã hóa khá nghiêm ngặt trong XP. Một số quy tắc này bao gồm:

  • Tất cả các mã phải đáp ứng các tiêu chuẩn viết mã.
  • Sử dụng bài kiểm tra đơn vị để xác định các yêu cầu và phát triển tất cả các khía cạnh của dự án.
  • Lập trình theo cặp—hai nhà phát triển làm việc cùng nhau đồng thời trên cùng một máy tính. Điều này không tốn thêm thời gian mà sử dụng gấp đôi tiêu điểm để tạo ra kết quả chất lượng cao nhất.
  • Sử dụng tích hợp liên tục để thêm mã mới và kiểm tra mã đó ngay lập tức.
  • Chỉ một cặp có thể cập nhật mã tại bất kỳ thời điểm nào để giảm lỗi.
  • Quyền sở hữu mã chung—bất kỳ thành viên nào trong nhóm đều có thể thay đổi mã của bạn bất kỳ lúc nào.

Kiểm thử

Bạn nên thử nghiệm trong suốt quá trình XP. Tất cả mã sẽ phải vượt qua các bài kiểm tra đơn vị trước khi được phát hành. Nếu phát hiện ra lỗi trong quá trình kiểm tra này, bạn sẽ tạo các kiểm thử mới, bổ sung để khắc phục chúng. 

Sau đó‌, bạn sẽ định cấu hình user story người dùng tương tự mà bạn đang thực hiện trong quá trình kiểm tra chấp nhận. Trong quá trình thử nghiệm này, khách hàng sẽ đánh giá kết quả để xem bạn đã đưa user story vào sản phẩm tốt như thế nào.

Vòng đời của XP

4 vai trò thường thấy trong eXtreme Programming

Mặc dù eXtreme Programming (XP) chỉ định các phương pháp cụ thể để nhóm của bạn tuân theo nhưng nó không thực sự thiết lập vai trò cụ thể cho những người trong nhóm của bạn.

Dưới đây là bốn vai trò phổ biến nhất liên quan đến  eXtreme Programming (XP):

Customer

Vai trò Customer (Khách hàng) chịu trách nhiệm đưa ra tất cả các quyết định kinh doanh liên quan đến dự án, bao gồm:

  • Hệ thống nên làm gì (Những tính năng nào được bao gồm và chúng thực hiện được những gì)?
  • Làm sao chúng tôi biết khi nào hệ thống được hoàn thành (tiêu chí chấp nhận của chúng tôi là gì)?
  • Chúng ta phải chi bao nhiêu (nguồn vốn hiện có là bao nhiêu, business case là gì)?
  • Chúng tôi nên làm gì tiếp theo (chúng tôi cung cấp các tính năng này theo thứ tự nào)?

Khách hàng XP dự kiến ​​​​sẽ tích cực tham gia vào dự án và lý tưởng nhất là trở thành một phần của nhóm.

Khách hàng XP được giả định là một người duy nhất, tuy nhiên, kinh nghiệm cho thấy rằng một người không thể cung cấp đầy đủ tất cả thông tin liên quan đến kinh doanh về một dự án. 

Nhóm của bạn cần đảm bảo rằng bạn có được bức tranh hoàn chỉnh về quan điểm kinh doanh, nhưng có một số phương tiện giải quyết xung đột trong thông tin đó để bạn có thể có được định hướng rõ ràng.

Programmers

Programmers (Lập trình viên) là các thành viên trong đội ngũ phát triển, có trách nhiệm viết code và viết nhưng kiểm thử sơ khai nhất cho các code đó.

Testers

Testers (Kiểm thử viên) là một trong các thành viên của đội ngũ, họ là người có kinh nghiệm trong lĩnh vực bảo đảm chất lượng (QA – Quality Assurance).

Testers chịu trách nhiệm giúp Customer các bài kiểm thử nào nên được thực hiện. Testers thường tập trung vào chất lượng sản phẩm, chất lượng bàn giao.

Coach

Coach là người phụ trách huấn luyện cho toàn bộ đội ngũ và phổ biến cho Customer về phương pháp eXtreme Programming. Do đó, họ phải là những người đã từng tự mình trải nghiệm phương pháp XP.

Coach còn là người giúp đội ngũ duy trì tính kỷ luật và tự giác khi thực hiện phương pháp XP.

XP Lifecycle

extreme programming lifecycle
Inforgraphic eXtreme Programming Lifecycle

Đầu tiên, hãy bắt đầu bằng việc mô tả kết quả mong muốn của dự án bằng cách yêu cầu khách hàng xác định một loạt user story. Khi những user story này được tạo ra, nhóm sẽ ước tính quy mô của mỗi user story. Ước tính kích thước, cùng với lợi ích tương đối do khách hàng ước tính, có thể cung cấp dấu hiệu về giá trị tương đối mà khách hàng có thể sử dụng để xác định mức độ ưu tiên của user story.

Nếu nhóm xác định một số user story mà họ không thể ước tính vì không hiểu tất cả các cân nhắc kỹ thuật liên quan, họ có thể đưa ra một đột biến để thực hiện một số nghiên cứu tập trung về user story cụ thể đó hoặc khía cạnh chung của nhiều user story. Spike là những khung thời gian ngắn, có giới hạn thời gian dành cho mục đích nghiên cứu về một khía cạnh cụ thể của dự án. Sự tăng đột biến có thể xảy ra trước khi các lần lặp thông thường bắt đầu hoặc cùng với các lần lặp đang diễn ra.

Tiếp theo, cả nhóm cùng nhau lập một kế hoạch phát hành mà mọi người đều cảm thấy hợp lý. Kế hoạch phát hành này là bước đầu tiên để biết những user story nào sẽ được phân phối trong một quý hoặc một bản phát hành cụ thể. Các user story được truyền tải phải dựa trên giá trị mà chúng mang lại và những cân nhắc về cách các user story khác nhau hỗ trợ lẫn nhau.

Sau đó, nhóm bắt đầu thực hiện một loạt các chu kỳ hàng tuần. Vào đầu mỗi chu kỳ hàng tuần, nhóm (bao gồm cả khách hàng) cùng nhau quyết định những user story nào sẽ được thực hiện trong tuần đó. Sau đó, nhóm chia những user story đó thành các nhiệm vụ cần hoàn thành trong tuần đó.

Vào cuối tuần, nhóm và khách hàng sẽ xem xét tiến độ cho đến nay và khách hàng có thể quyết định xem dự án có nên tiếp tục hay không hoặc liệu đã giao đủ giá trị hay chưa.

12 eXtreme Programming Practices phổ biến

Individual Level

Simple Design: Hệ thống XP được thiết kế đơn giản—bạn sẽ chỉ sản xuất những gì cần thiết và không làm gì thêm nữa

Test Driven Development (TDD): Sự phụ thuộc vào phản hồi của XP đòi hỏi phải kiểm tra kỹ lưỡng. Thông qua các chu kỳ ngắn, các lập trình viên đưa ra các bài kiểm tra tự động và sau đó phản ứng ngay lập tức.

Refactor: Đây là nơi bạn sẽ chú ý đến các chi tiết tốt hơn của cơ sở mã, loại bỏ các bản sao và đảm bảo rằng mã được gắn kết. Điều này dẫn đến các thiết kế tốt, đơn giản.

Pair Programming: Tất cả việc lập trình đều đến từ một cặp nhà phát triển ngồi cạnh nhau. Không có công việc làm một mình trong eXtreme Programming.

Team Level

Metaphor: Phép ẩn dụ, theo đúng nghĩa đen, là một phép ẩn dụ. Nó được quyết định với tư cách là một nhóm và sử dụng ngôn ngữ để mô tả cách thức hoạt động của nhóm. Ví dụ, chúng ta là những con kiến ​​làm việc tập thể để xây tổ kiến.

Collective Code Ownership: Bất kỳ cặp mã hóa nào cũng có thể thay đổi mã bất kỳ lúc nào, cho dù họ có phát triển nó hay không. XP tạo mã theo nhóm và công việc của mọi người được tuân theo các tiêu chuẩn tập thể cao hơn.

Code Standard: Các đội XP tuân theo một tiêu chuẩn. Tương tự như cách mà người viết cần thể hiện tiếng nói của thương hiệu để nghe giống như cùng một người luôn viết, các nhà phát triển XP viết mã theo cùng một cách thống nhất để nó đọc giống như một nhà phát triển.

Continuos Integration: Các nhóm XP không chờ đợi quá trình lặp lại hoàn tất mà họ tích hợp liên tục. Thông thường, nhóm XP sẽ tích hợp nhiều lần trong ngày.

Substainable Pace: Cường độ làm việc của XP đòi hỏi bạn phải đặt ra một nhịp độ bền vững. Các nhóm nên quyết định số lượng công việc họ có thể thực hiện theo cách này mỗi ngày và mỗi tuần, đồng thời sử dụng số lượng đó để đặt ra thời hạn làm việc.

Business Level

Customer Tests: Khi bạn hoàn thành một tính năng mới, khách hàng sẽ phát triển một bài kiểm tra chấp nhận để xác định mức độ gần gũi của nó với user story người dùng ban đầu của họ.

Planning Game: Lập kế hoạch XP được sử dụng để hướng dẫn công việc. Kết quả của việc lập kế hoạch phải là những gì bạn hy vọng đạt được, thời điểm và những gì bạn sẽ làm tiếp theo.

Small Releases: XP sử dụng các bản phát hành nhỏ, thường xuyên để hiểu rõ hơn trong suốt quá trình. Thông thường, việc phát hành được chuyển thẳng đến khách hàng, mặc dù chúng có thể được thực hiện nội bộ.

12 extreme programming pracetices
12 eXtreme Programming Practices theo vòng đời của XP

eXtreme Programming vs Scrum

Scrum thường được gắn với các nhóm tự tổ chức. Nó cũng thường có các lần chạy nước rút kéo dài từ 2 đến 4 tuần, trong khi các lần lặp XP ngắn hơn, mất từ ​​1 đến 2 tuần. 

Ngoài ra, XP linh hoạt hơn nhiều với những thay đổi có thể xảy ra trong các vòng lặp, trong khi Scrum không cho phép bất kỳ sửa đổi nào sau khi thiết lập sprint backlog. 

Một điểm khác biệt nữa là trong XP, khách hàng ưu tiên các tính năng và quyết định thứ tự phát triển của chúng, nhưng trong Scrum, chính nhóm sẽ xác định những gì cần làm trước tiên. 

Các vai trò chính của Scrum là Product Owner, Scrum Master và Team Dev, khác với các vai trò trong XP. 

Tuy nhiên, không cần phải lựa chọn giữa XP và Scrum. Việc kết hợp các thực hành XP và kỹ thuật Scrum được coi là khá hiệu quả khi XP tập trung vào các khía cạnh kỹ thuật và Scrum tổ chức quy trình.

Tổng kết

XP không phải là ít được sử dụng mà là người ta thường áp dụng XP vào mặt kỹ thuật trong khi vẫn sử dụng các phương pháp Agile khác để tổ chức đội ngũ.

Để mà nói trọn vẹn về XP thì một bài viết thực sự chưa đủ, nếu bạn quan tâm XP thì có thể tham khảo khoá học Agile Essentials tại PMA, gói XP chỉ có 599.000 VND.

Ngoài ra thì XP là một phần kiến thức thuộc chứng chỉ PMI-ACP, bạn hoàn toàn có thể học toàn bộ khoá PMI-ACP thay vì chỉ học một phần eXtreme Programming.

Xem thêm: Khoá học PMI-ACP Online, Khoá học PMI-ACP E-learning

PMA luôn trân trọng sự tin tưởng và ủng hộ từ cựu học viên. Chính vì vậy, chúng tôi triển khai chính sách referral hấp dẫn dành cho tất cả các khóa học tại PMA
– Tặng ngay 300k cho cựu học viên giới thiệu thành công 1 khách hàng mới.
– Giảm ngay 300k cho học viên đăng ký học mà được cựu học viên giới thiệu.
Chia sẻ cơ hội học tập tuyệt vời này với bạn bè và đồng nghiệp của bạn ngay hôm nay!