“Nhóm em đang làm một dự án phần mềm theo quy trình eXtreme Programming. Sau khi tham khảo ở một số tài liệu, nhóm em còn mơ hồ về quy trình phát triển cần những bước nào và tài liệu cho từng bước là những tài liệu gì. Mong được giúp đỡ! Em cảm ơn.”

Đáp: Lập trình cực đoan eXtreme Programming (XP) là một phương pháp của cách tiếp cận Agile. Nó chia sẻ cùng các nguyên lí của Agile hội tụ vào phát triển liên tục và đưa ra phần mềm theo từng mảnh nhỏ vào mỗi lúc. Thay vì chuyển giao mọi thứ theo ngày lịch cố định, qui trình XP hội tụ vào chuyển giao phần mềm cho khách hàng từng mảnh khi họ cần nó.

Giống như hầu hết các phương pháp Agile, XP yêu cầu sự tham gia của khách hàng vào trong qui trình này. (Nếu khách hàng của bạn không thể tham gia được, bạn không nên dùng XP). Trong XP, tổ tổ chức công việc của họ dựa trên câu chuyện của người dùng hay vấn đề cần giải quyết dựa trên cái vào của khách hàng. Tổ thường xuyên trao đổi với khách hàng để có cái vào và phản hồi bằng việc kiểm thử phần mềm của họ sớm nhất có thể được.

Bước đầu tiên trong XP là lập kế hoạch nơi tổ thảo luận các yêu cầu với khách hàng và bắt đầu viết câu chuyện của người dùng. (Trong phương pháp XP, cả tổ và khách hàng cùng làm việc với nhau để viết ra mọi thứ mà phần mềm phải làm dựa trên cách nhìn của khách hàng). Từ các câu chuyện của người dùng, tổ bắt đầu phát triển kiểm thử chấp nhận để thẩm tra rằng câu chuyện của người dùng được thực hiện đúng. Tổ cũng bắt đầu lập kế hoạch lịch biểu đưa ra bằng việc làm nhiều đưa ra tăng dần nhỏ. Dự án XP được chia thành nhiều lần lặp nhỏ. (Tương tự như từng chặng nước rút Sprint trong SCRUM). Tổ và khách hàng làm việc cùng nhau để lập kế hoạch cho từng lần lặp.

Với mỗi lần lặp, tổ bắt đầu từng ngày với cuộc họp đứng hàng ngày. Lí do cho từ “đứng” là nó phải ngắn nơi mọi thường thường đứng để nói về điều họ đã làm ngày hôm trước, điều họ lập kế hoạch làm ngày hôm nay và vấn đề gì họ gặp phải. Phần lớn các cuộc họp đứng kéo dài năm tới mười phút để mọi người trong tổ biết về tiến độ của dự án.

Một qui tắc chính của XP là “Kiểm thử trước, viết mã sau.” Trước khi viết mã, người lập trình phải viết kiểm thử đơn vị trước hết. Logic là nếu họ phát triển kiểm thử đơn vị trước hết, họ sẽ ý thức hơn về cách họ viết mã, do đó họ sẽ không phạm nhiều sai lầm và toàn thể dự án sẽ có chất lượng tốt hơn. Theo Ken Beck tác giả của XP, thời gian tổ hợp dành cho việc tạo ra một kiểm thử đơn vị và viết mã là quãng như viết mã trước rồi viết kiểm thử sau. Phát triển kiểm thử đơn vị trước giúp cho người lập trình hiểu cái gì phải được làm vào ngày đó.

Tính năng duy nhất của XP là lập trình cặp đôi. Mọi công việc trong XP đều được thực hiện bởi hai người lập trình làm việc cạnh nhau. Người này viết mã, người kia theo logic viết mã và đoan chắc rằng không có lỗi nào phạm phải. Sau một chốc, họ đổi vai trò. Theo Ken Beck, tác giả của XP, lập trình cặp đôi làm tăng chất lượng phần mềm và có hai người làm việc cùng nhau sẽ thêm nhiều tính năng như hai người làm việc tách rời ngoại trừ rằng điều đó sẽ có chất lượng cao hơn nhiều. Tuy nhiên, tôi thấy rằng đây là kĩ năng khó làm chủ. Nó yêu cầu cả hai người làm việc cùng nhau theo cách cộng tác trên cơ sở bình đẳng. Điều này cũng tạo điều kiện cho nhiều trao đổi hơn giữa những người lập trình vì họ có thể thảo luận nhiều ý tưởng và thử xem cái nào là tốt hơn. Xin lưu ý rằng để lập trình cặp đôi thành công, cả hai người phải có kĩ năng và kinh nghiệm tương đương. Đây KHÔNG phải là kèm cặp hay dạy dỗ nơi người có kinh nghiệm dạy cho người ít kinh nghiệm hơn. Cả hai phải làm việc cùng nhau để đảm bảo rằng công việc được thực hiện theo cách hiệu quả và năng suất nhất. Tôi đã thử kĩ thuật này nhiều lần nhưng không làm tốt. Nhiều người lập trình cũng bảo tôi rằng phải mất thời gian lâu để làm nó tốt.

Vì phần lớn dự án XP đều nhỏ (2 tới 8 người), thời gian để hoàn thành dự án là ngắn (vài tuần tới vài tháng). Giá trị của XP là nó có thể đáp ứng nhu cầu của khách hàng nhanh chóng. Cho dù yêu cầu không được xác định tốt, nó vẫn có thể chuyển giao cái gì đó cho khách hàng theo từng mảnh nhỏ. Nếu khách hàng có thể không biết điều họ cần, vẫn có thể làm dự án XP do bản chất của qui trình lặp và thay đổi nhanh. Mã XP phần lớn có chất lượng cao vì mọi mã đều phải qua kiểm thử đơn vị trước khi nó có thể được đưa ra. Nếu lỗi bị tìm ra, kiểm thử phải được tạo ra và tổ phải làm việc trên nó ngay lập tức để đảm bảo rằng phần mềm được đưa ra có chất lượng cao. Như với mọi cách tiếp cận Agile, XP yêu cầu người lập trình rất có kinh nghiệm để làm việc cùng nhau. Đây không phải là dự án cho người mới bắt đầu vì làm việc tổ, kinh nghiệm, kĩ năng, trao đổi, và cam kết là được cần tới.

Sau đây là các website mà bạn có thể kiểm tra để biết thêm thông tin:

http://en.wikipedia.org/wiki/Extreme_Programming

http://www.informit.com/articles/article.aspx?p=20972

http://xprogramming.com/index.php

http://c2.com/cgi/wiki?ExtremeProgrammingImplementationIssues

—-Enlish version—-

Extreme Programming

“My group is developing a software project under the eXtreme Programming process. After referencing some materials, our group is still confusing about which steps we need in the development process and what are documents for each steps. We hope to have your help! Thank you.”

Answer: eXtreme Programming (XP) is one method of the Agile approach. It shares the same principles of Agile which focuses on continuous development and release software in small piece at a time. Instead of delivering everything according to a fixed schedule date, XP process focuses on deliver the software to customers in pieces as they need it.

Like most Agile methods, XP requires customer involvement in the process. (If your customer cannot participate, you should not use XP). In XP, the team organizes their works based on User stories or the problem to be solved based on customer’s inputs. The team constantly communicates with customers to get inputs and feedback by testing their software as early as possible.

The first step in XP is planning where the team discusses the requirements with customers and begins to write the User stories. (In XP method, both the team and customer are working together to write things that the software must do based on the customers’ view). From the user stories, the team begins to develop the Acceptance tests to verify that the Users story is done correctly. The team also starts to plan for the release schedule by making several small incremental releases. The XP project is divided into several small iterations. (Similar to each Sprint in SCRUM). The team and customer work together to plan each iteration.

For each iteration, the team begins each day with a daily standup meeting. The reason of the word “Standup” is it must be short where people often stand up to talk about what they did on previous day, what they are planning to do today and what problem that they have. Most standup meeting lasts five to ten minutes so everybody on the team knows about the progress of the project.

One major rule of XP is “Test first, code later”. Before coding, programmer must write the unit test first. The logic is if they develop the unit tests first, they will be more conscious of the way they code, therefore they will not make many mistakes and overall the project will have better quality. According to Ken Beck the author of XP, the combined time it takes to create a unit test and to code is about the same as code first then write unit test later. By develop a unit test first, helps programmer to understand what must be done for that day.

The unique feature of XP is pair programming. All works in XP is done by two programmers working side by side. One person code, the other follows the coding logic and make sure that there is no mistake or error is made. After a while, they switch roles. According to Ken Beck, the author of XP, Pair programming increases software quality and having two people working together will add as much functionality as two working separately except that it will be much higher in quality. However, I found that this is a difficult skill to master. It requires both people to work together in a cooperative way on an equal basis. This also facilitates more communication among programmers as they can discuss several ideas and try on to see which is better. Please note that for pair programming to be successful, both people should have equal skills and experience. This is NOT a mentoring or teaching where an experienced person teaching a less experienced person. Both must work together to ensure that the work is done in a most efficient and productive way. I have tried this technique many times but did not do well. Many programmers also told me that it takes a long time to do it well.

Since most XP projects are small (2 to 8 persons), the time to complete the project is short (Few weeks to few months). The value of XP is it can meet customers’ needs quickly. Even if requirements are not well defined, it can still deliver something to customers in small pieces. If the customer may not know what they need, it is still possible to do an XP project due to the nature of fast changing and iterative process. The XP code is mostly of high quality because all code must pass unit tests before it can be released. If a bug is found, a test must be created and the team must work on it immediately to ensure that the software is released with high quality. As with all Agile approach, XP requires very experienced programmers to work together. This is not a project for beginners because teamwork, experience, skills, communication, and commitment are required.

Following are websites that you can check for more information:

http://en.wikipedia.org/wiki/Extreme_Programming

http://www.informit.com/articles/article.aspx?p=20972

http://xprogramming.com/index.php

http://c2.com/cgi/wiki?ExtremeProgrammingImplementationIssues