Thời Gian, Chất Lượng Và XP (Lập Trình Cực Độ) (Bài 1)

copyright from: http://cmu.duytan.edu.vn

Theo nghiên cứu của Tiến sĩ Barry Boehm của Đại học Nam Calif. (USC), năng lực của nhân công (bao gồm kỹ năng và kiến thức) là thành tố quan trọng nhất đối với năng suất trong phát triển phần mềm. Một người làm phần mềm được huấn luyện tốt có thể có năng suất 353% cao hơn một người làm phần mềm không có kỹ năng cao. Một nghiên cứu nữa của Tiến sĩ Capers Jones đã phát hiện ra là kinh nghiệm của đội ngũ quản lý và hỗ trợ đóng góp 120% vào năng suất trong khi công cụ chỉ góp chừng 35%. Tiến sĩ Jones còn nghiên cứu tiếp và phát hiện ra những tác động ngược: sự thiếu kinh nghiệm của đội ngũ sẽ làm năng suất giảm 177% trong khi các phương pháp và công cụ không hữu ích sẽ làm giảm 41%. Nói cách khác, sự thành công của dự án trực tiếp tùy thuộc vào kỹ năng và kiến thức của đội ngũ và cách thức họ làm việc với nhau.

 

Dựa vào những kết quả nghiên cứu này, năng lực (bao gồm kỹ năng và kiến thức) phải là điểm nhấn trong mọi chương trình đào tạo phần mềm ở bậc đại học. Theo phương pháp “Học qua Làm”, cách tốt nhất để cải thiện kỹ năng lập trình là “Viết code và học từ những lỗi mắc phải!”, và sinh viên phải học mọi thứ ít nhất là ba lần. Lần đầu tiên, sinh viên học cách áp dụng những khái niệm đã học bằng cách cố gắng mô phỏng sản phẩm phần mềm vì nếu không có việc mô phỏng này, thì sinh viên sẽ không biết được các ứng dụng của họ chạy tốt đến mức độ nào và họ biết được bao nhiêu (kiến thức). Trong lần học đầu tiên, sinh viên sẽ thí nghiệm với (các) khái niệm lý thuyết và tự học từ các hiểu biết của mình liệu họ đã đúng hay sai. Lần thứ hai, (trước tiên,) họ cần hiệu chỉnh lại các hiểu biết trên của họ bằng cách tự hỏi: “Chúng ta đã học được gì? Cái gì được và cái gì chưa được? Tại sao mọi chuyện lại diễn ra như hiện nay?” Chỉ khi trả lời được những câu hỏi này thì họ mới (bắt đầu) làm lại (sản phẩm) lần thứ hai. Họ sẽ sửa được nhiều lỗi và chương trình thường hoạt động tốt hơn sau lần thứ hai. Họ vẫn phải làm lại một lần nữa bằng cách tự hỏi: “Có giải pháp nào tốt hơn không? Chúng ta có thể làm gì tốt hơn?” Sau khi trả lời được những câu hỏi này, sinh viên sẽ có thể cải thiện cách làm việc của họ để có chất lượng tốt hơn. Nói cách khác, trong lần đầu tiên, họ học các khái niệm và lý thuyết; lần thứ nhì họ học áp dụng kiến thức đúng cách; và lần thứ ba họ học cách cải thiện chất lượng làm việc của chính họ. Đây là lý do vì sao những nhân công có tay nghề cao giỏi hơn và có năng suất cao hơn những nhân công không có tay nghề cao vì những nhân công giỏi này không chỉ tập trung làm cho đúng việc mà còn tập trung cho một chất lượng cao hơn.

 

Hãy làm việc theo cặp trong phát triển phần mềm!

 

Ken Beck, người tạo ra phương pháp Lập trình Cực độ (XP) đã áp dụng cách nghĩ trên cho XP và gọi nó là “Lập trình theo Cặp”: theo XP, hai lập trình viên cùng làm việc với nhau bằng cách liên tục tráo các vai trò (trong phát triển phần mềm) với nhau. Khi một người lập trình thì người kia kiểm tra lại code của họ. Thực tế cho thấy hai người thì sẽ tốt hơn là một, thay vì để một người làm mọi việc cả ba lần, có thêm một người nữa sẽ giúp rút ngắn thời gian. Một người thực hiện việc phát triển (gồm thiết kế, code, và kiểm thử) trong khi người kia suy nghĩ và quan sát xem cách tiếp cận đang được sử dụng có đúng hay không. Khi kiểm tra lại (chương trình phần mềm), người giữ vai trò quan sát kiểm tra lỗi và đề xướng những ý tưởng giúp cải thiện chất lượng chương trình. Sau đó họ tráo vai trò cho nhau, người lập trình chuyển sang thành người quan sát và người quan sát chuyển sang cải thiện chương trình bằng cách viết lại một số code và cải thiện nó. Bằng cách cùng làm việc với nhau, họ chia sẻ thông tin, giải pháp và cùng hợp tác để cải thiện chất lượng phần mềm. Kỹ thuật này có tác động to lớn lên sản phẩm cuối cùng, giúp giảm thiểu các thiếu sót và lỗi cũng như chi phí phát triển. Nó còn giúp cải thiện việc học và huấn luyện (trong nhóm) vì kiến thức được chia sẻ (thoải mái) giữa các lập trình viên. Những người mới (vào nghề) sẽ nhanh chóng học được từ cách làm của những người có nhiều kinh nghiệm hơn qua quan sát và làm theo. Ken từng viết trong quyển “Lập trình Cực độ” của ông như sau: “Nếu việc kiểm tra lại code là cần thiết (cho chất lượng sản phẩm), thì hãy tiến hành việc kiểm tra lại code nhiều lần bằng cách phân cho một người khác cùng làm việc với bạn và kiểm lại phần việc bạn làm ra. Nếu kiểm thử là cần thiết, thì viết kế hoạch kiểm thử trước và rồi kiểm thử mỗi khi bạn triển khai một chức năng mới, và nếu việc tích hợp là cần thiết, thì hãy liên tục tích hợp để hệ thống luôn hoạt động tốt.” Hình thức cộng tác làm việc nhóm này còn có thể áp dụng vào những mảng khác: Một người hỏi khách hàng về những yêu cầu chức năng cụ thể trong khi một người khác đánh giá phần trả lời của khách hàng và lập ra kế hoạch. Tương tự, một cặp (cùng phát triển phần mềm) thì sẽ luôn năng động tìm kiếm thông tin, có óc phân tích, và dễ có sáng tạo trong phân tích và tìm hiểu các vấn đề của khách hàng, và rồi đoàn kết lại thành một tổ áp dụng những phân tích đó để tạo ra phần mềm đáp ứng được các nhu cầu cao về chất lượng của khách hàng.

 

Phương pháp XP gồm có 5 giá trị: Liên lạc, Phản hồi, Đơn giản, Táo bạo và Tôn trọng. Từ 5 giá trị này, Ken chi tiết hóa chúng thành 14 nguyên lý và 24 phương thức hay kỹ năng. Ý tưởng là các phương thức và kỹ năng là những điều cụ thể mà nhóm phát triển làm hàng ngày trong khi giá trị (và nguyên lý) là các kiến thức nền tảng. Khi kết hợp kiến thức và kỹ năng với nhau, bạn có được năng lực của một Kỹ sư Phần mềm. Tiến sĩ Laurie Williams của Đại học Utah ở thành phố Salt Lake đã nêu lên rằng hai lập trình viên làm chung theo cặp làm chậm hơn 15% so với hai lập trình viên làm việc độc lập với nhau vì (cặp lập trình viên) mất nhiều thời gian (cho liên lạc và trao đổi qua lại), nhưng kết quả công việc thì lại có ít hơn đến 50% số lượng lỗi. Vì việc kiểm thử và gỡ lỗi thường tốn nhiều thời gian và tiền bạc hơn, nên sau hết, XP là một phương pháp tốt, cho kết quả đáng ấn tượng trong việc cải thiện chất lượng và thời gian phát triển.

 

Ngày nay, hầu hết các phát triển phần mềm đòi hỏi người ta phải làm việc trong nhóm nhưng câu hỏi đặt ra là: “Khi nào thì các đại học sẽ dạy về làm việc nhóm và ủng hộ việc sinh viên cùng hợp tác và trao đổi với nhau?”