Trong những năm gần đây Agile nổi lên như một Mô hình phát triển phần mềm mới được nhiều công ty và tổ chức áp dụng thay thế cho các mô hình phát triển phần mềm cũ như Waterfall, Spiral Model, V-Shaped Model...vv.

Dưới đây là biểu đồ thể hiện tỉ lệ các Phương pháp phát triển phần mềm trong Mô hình phát triển phần mềm Agile. Như các bạn có thể thấy, Extreme Programming (từ giờ mình thống nhất gọi là XP nhé!) chỉ chiếm vị trí tí hin tầm 1% ngay bên cạnh ông bạn Scrum to gấp 58 lần. Nhưng sự kết hợp giữa 2 ông bạn này mang tới một phương pháp có tỉ lệ sử dụng lên tới 10%.

Tại sao lại có tỉ lệ như vậy?

Vì Scrum là phương pháp không chỉ được áp dụng trong mỗi phát triển phần mềm, mà còn có thể ứng dụng trong nhiều lĩnh vực khác như tài chính, ngân hàng hay một số ngành sản xuất hiện đại khác như ô tô, máy bay...vv. Trong khi đó XP - đúng với cái tên của nó Xtreme Programming - dành riêng và tập trung cao độ cho lĩnh vực phát triển phần mềm. Theo đánh giá cá nhân của mình, XP có lẽ là phương pháp chuyên biệt và cũng khó áp dụng đầy đủ nhất trong họ Agile. Nhưng nếu áp dụng và tuân thủ đầy đủ, nó sẽ mang lại cho mỗi lập trình viên, khách hàng, team cho tới tổ chức những lợi ích mà thực sự chúng ta chưa từng nghĩ tới trước kia.

Vậy XP thực sự chuyên biệt và nghiêm ngặt và khó áp dụng tới mức nào. Các bạn hãy cùng mình tìm hiểu kĩ trong XP Series này nhé!

I. Các khái niệm trong phương pháp phát triển

Vaules (Giá trị) - Principles (Nguyên tắc) - Practices (Thực hành)

Hằng ngày bạn có thể cắm cơm, rán cá, nấu canh, luộc rau... bạn nấu ăn mỗi ngày nhưng chưa hẳn bạn đã là một đầu bếp.

Tương tự như vậy, hằng ngày nhiều người có lẽ đang thực hiện Daily Meeting, tổ chức Retrospective Meeting hằng tuần... nhưng chưa hẳn người đó có thể trở thành Scrum Master. Chúng ta có thể tạo một Team các member Sit Together, với một nơi làm việc đầy đủ thông tin khi mới chỉ lướt qua (Informative Workspace)... nhưng chưa hẳn chúng ta đã là một XPer.

Level này gọi là level Thực hành (Practices).

Khi gặp một món mặn, chúng ta biết rằng nên cho thêm chút nước rồi gạn đi. Một đầu bếp lại biết rằng nên chữa một chút bằng cách cho thêm một chút đường để trung hoà vị mặn. Đầu bếp Ẩm thực phân tử thậm chí biết rằng nên nhúng nguyên liệu vào Nitơ lỏng trước khi rán để cho lớp vỏ giòn hơn. Họ hiểu cách lưỡi chúng ta cảm nhận các hương vị, hiểu tính chất của mỗi nguyên liệu vào cách chỉnh sửa, chế biến chúng thế nào cho hợp lý.

Khi gặp lỗi, programmer thấy rằng mình cần phải bổ xung kiến thức về batch nhiều hơn. Tuy nhiên một XPer nhận thấy ảnh hưởng của sự thiếu Giao tiếp trong nội bộ team. Không một ai có thể có đầy đủ kiến thức để loại bỏ hoàn toàn các bug tiềm tàng. Nhưng hầu hết các vấn đề đều có ai đó có sẵn kiến thức liên quan và có thể đưa ra lời khuyên hợp lý cho bạn.

Chúng ta gọi level này gọi là hiểu được Giá trị (Values).

Mỗi phương pháp phát triển đều bắt nguồn từ việc xác định Giá trị mà phương pháp đó muốn đạt được. Sau đó đưa ra các bài Thực hành để cụ thể hoá nó. Tuy nhiên Giá trị là một khái niện gì đó rất mơ hồ, Thực hành lại rất cụ thể, chi tiết và rõ ràng. Đi trực tiếp từ một mong muốn mơ hồ tới một hành động cụ thể là một điều rất khó và dễ dẫn tới sai lệch. Để lấp đầy khoảng cách giữa Giá trị và Thực hành, chúng ta có các Nguyên tắc.

Nguyên tắc là cầu nối Giá trị và Thực hành.

Ví dụ đơn giản hơn nữa như này để dễ hình dung nhé.

Đối với bạn Gia đình là giá trị quan trọng nhất trong cuộc sống, những thứ khác "có hay không không quan trọng". Bạn muốn giữ cho gia đình mình luôn ấm êm hạnh phúc, cơ mà vợ bạn lại hơi sư tử hà đông một chút. Nên bạn nhận ra (thậm chí vợ không sư tử đi chăng nữa vẫn nhận ra) rằng phải tuân theo Nguyên tắc "Vợ luôn đúng (okay)". Để tuân theo nguyên tắc này, bạn phải đưa ra các bài Thực hành cho bản thân mình như là: Lúc vợ nói không được ngắt lời, không được cãi; vợ bảo rửa bát thì phải rửa bát, bảo quyét nhà thì quyét nhà, bảo cho con bú thì cũng phải cho con bú (lol)

Đùa vậy thôi, nhưng ví dụ đó giúp chúng ta thấy được rõ hơn mối liên hệ giữa Giá trị - Nguyên tắc - và các bài Thực hành.

Để thực sự hiểu được XP, vận dụng nó trong thực tế một cách linh hoạt chúng ta cần hiểu được Giá trị cốt lõi mà XP hướng tới. Chứ không chỉ thực hành theo các bài thực hành mà người khác đưa ra. Chỉ thực hành mà không hiểu giá trị dễ dẫn tới mất phương hướng, từ bỏ giữa chừng vì không hiểu mình làm thế để làm gì và có ý nghĩa gì. Hiểu được giá trị cũng giúp ta thực hành được đầy đủ và trọn vẹn hơn, đồng thời nhận được giá trị gia tăng từ sự tương tác giữa các bài thực hành.

Nào cùng nhau tìm hiểu các Giá trị cốt lõi trong XP.

II. Các giá trị cốt lõi của XP

1. Giao tiếp (Communication)

Có thể khẳng định rằng nguyên nhân chủ yếu dẫn tới vấn đề xuất hiện trong quá trình phát triển phần mềm là Giao tiếp và trao đổi. Như đã nói ở trên, khi một vấn đề xảy ra, hầu như vốn đã có người có khả năng giải quyết vấn đề hoặc chí ít biết cách tìm ra lời giải cho vấn đề. Tuy nhiên vì vấn đề trong giao tiếp mà lời giải cho vấn đề không tới được người có nhiệm vụ giải quyết vấn đề đó, cụ thể là người làm task.

Giao tiếp và trao đổi hiệu quả sẽ giúp luồng thông tin trong team được thông suốt, các members biết được công việc của nhau và chia sẻ kiến thức hiệu quả hơn. Quá trình thảo luận thẳng thắn đảm bảo các vấn đề và lỗi đã xảy ra không còn lắp lại trong tương lai nữa.

Ngay cả việc Giao tiếp cũng cần phải được bổ xung và nâng cấp trong quá trình phát triển phần mềm. Khi một vấn đề hay lỗi xảy ra chúng ta cần đặt ra các câu hỏi và hành động phù hợp.

1. Lỗi xảy ra có phải vì thiếu giao tiếp hay không?
2. Nếu phải thì cần trao đổi thế nào để xác định rõ nguyên nhân và cách khắc phục nó?
3. Cần phải cải thiện, bổ xung cách thức trao đổi như thế nào để đảm bảo lỗi đó không xảy ra trong tương lai?

2. Tính đơn giản (Simplicity)

Tính đơn giản là giá trị mang lại sự khác biệt nhiều cảm xúc nhất cho XP. Để tạo ra một hệ thống hoạt động hiệu quả nhưng lại đủ đơn giản để xử lý các vấn đề phát sinh trong một thời gian ngắn (1 ngày) thực sự là một công việc khó. Giống như việc chia sẻ kiến thức, bạn càng diễn đạt sao cho người khác thấy đơn giản, dễ hiểu thì càng chứng tỏ là bạn càng hiểu sâu sắc về kiến thức mà mình muốn chia sẻ hơn.

Một số người có thể nguỵ biện rằng vì muốn hệ thống có tính bảo mật và đáng tin cậy hơn nên chúng tôi cần phải làm nó phức tạp hơn. Tuy nhiên bất cứ hệ thống nào cũng có cách để làm cho nó trông đơn giản và hiệu quả hơn. Hơn nữa không nên hiểu cực đoan rằng tính đơn giản là phải cố gắng làm cho nó đơn giản nhất có thể với tất cả mọi người. Hệ thống chỉ cần đủ đơn giản với những thành viên trong team là được, mặc dù với những người không chuyên nó có thể trông khá phức tạp.

Mặt khác hệ thống có thể trông đủ đơn giản ngày hôm nay, nhưng lại trở nên phức tạp hơn trong tương lai khi mà nhiều chức năng mới được thêm vào. Đó là khi chúng ta cần tới giá trị thứ 3. Phản hồi.

3. Phản hồi (Feedback)

Không bao giờ có một con đường thẳng dẫn tới mục tiêu, không có team nào làm đúng hướng và không gặp sai lầm nào từ đầu tới cuối. Bug xảy ra, vấn đề hiểu sai spec thường xuyên làm chúng ta chệch hướng. Chính vì vậy vai trò của sự Phản hồi thường xuyên liên tục trong quá trình phát triển phần mềm là hết sức quan trọng. Sự thay đổi là không thể tránh khỏi vì:

1. Chúng ta có thể không biết được rằng làm thế nào là "đúng" ngay từ đầu
2. Cách làm đúng ngày hôm nay, có thể sẽ sai ngày mai
3. Cố gắng làm mọi việc "đúng" ngày hôm này có thể tốn rất nhiều thời gian và trì hoãn sự bắt đầu của cả team

Phản hồi đảm bảo cho team điều chỉnh lại đúng hướng khi team gặp nhiều vấn đề và lỗi. Phản hồi càng thường xuyên, thời gian và công sức cho sự điều chỉnh càng được giảm thiểu. Khi nhận được phản hồi mà team không có đủ thời gian chỉnh sửa cho tới lần release tiếp theo, thì chúng ta nên gia hạn lịch release để đảm bảo team có đủ thời gian và sự tập trung để điều chỉnh cho đúng hướng.

4. Sự dũng cảm (Courage)

Mới nghe qua chúng ta sẽ có cảm giác như là sự dũng cảm của một chiến sĩ trên chiến trường. Nhưng phát triển phần mềm cũng không hề ngoại lệ, rất cần một sự dũng cảm. Mỗi member hằng ngày đều phải đối mặt với khả năng mình gây ra lỗi, bị chỉ trích, nỗi sợ hãi không dám thừa nhận sai lầm hay là sự thừa nhận bản thân còn thiếu kiến thức và năng lực...vv. Ngay cả việc nói ra khi mình cảm thấy sẽ có lỗi tiềm tàng xảy ra khi thực hiện theo một phương án mà người khác đưa ra cũng cần nhiều sự dũng cảm hơn chúng ta tưởng.

Thiếu đi sự dũng cảm ấy, các thành viên rất khó có thể chấp nhận bản thân và hoà vào cùng với các member khác để tạo thành một team thống nhất, tin tưởng lẫn nhau được.

5. Sự tôn trọng (Respect)

Nếu các members trong team không quan tâm và tôn trọng những việc mà các thành viên khác làm, XP sẽ không thể hoạt động. Nếu members không quan tâm tới project mình đang làm, không có bài thực hành nào đảm bảo source code có thể vận hành một cách chính xác và an toàn.

Ngoài là một members trong một team thống nhất, mỗi thành viên cũng là một con người độc lập trong xã hội, do đó họ cần có sự tôn trọng để nâng cao cả địa vị xã hội lẫn hiệu quả công việc của mình. Sự cống hiến của mỗi thành viên trong team đều cần được tôn trọng và đánh giá xứng đáng.

5 Giá trị mình đã liệt kê trên đây là 5 giá trị thiết yếu định hướng cho XP. Tuy nhiên nó không bắt buộc cho tất cả các project và không bị giới hạn. Team các bạn có thể chọn lấy hay thêm vào các Giá trị cho riêng mình để đảm bảo team hoạt động hiệu quả nhất có thể.

Nhưng sẽ tuyệt vời hơn nếu các bạn chọn được các Giá trị thích hợp và tạo ra được mối tương tác giữa các Giá trị đó để các giá trị đó nâng tầm lẫn nhau đưa project tới thành công.

III. Sự cân bằng và hỗ trợ lẫn nhau giữa các giá trị

Các Giá trị trong XP không tồn tại độc lập. Chúng có sự cân bằng, sự tương tác qua lại với nhau.

Ví dụ việc nâng cao Giao tiếp giúp chúng ta hạn chế được thời gian lãng phí cho việc cố gắng viết doc và update doc khi đã outdate. Từ đó giúp project có Tính đơn giản cần thiết.

Việc nâng cao Tính đơn giản khiến members trong team cảm thấy nhẹ nhàng dễ hiểu hơn, thoải mái suy nghĩ và đưa ra ý kiến mà bản thân thực sự nghĩ. Từ đó nâng cao hiệu quả Giao tiếp

Phản hồi bản thân nó là phần chỉ trích trong Giao tiếp và trao đổi. Phản hồi thường xuyên giúp hệ thống đi đúng hướng, tránh và loại bỏ được sự rườm rà, các chức năng không cần thiết, qua đó làm hệ thống có Tính đơn giản hơn.

Sự Dũng cảm mà không đi kèm với sự Tôn trọng sẽ dẫn tới việc nói quá thẳng thừng gây tổn thương cho người khác và phá vỡ các mối quan hệ trong team.

Tạm kết

Như các bạn đã thấy, sự cân bằng và tương tác giữa các giá trị trong XP không hề đơn giản và dễ nhận ra mặc dù cấu trúc của XP thực sự đơn giản.

Chúng ta cần hiểu rõ để có thể đưa ra các Nguyên tắc và các bài Thực hành phù hợp nhất cho Team của mình.

Hẹn gặp lại các bạn trong Phần 2: Những Nguyên tắc trong XP nhé! (bye)