Viết riêng cho các GV đồng nghiệp ở FAT.

Tuần vừa rồi tôi có thực hiện một buổi seminar tương đối thú vị về project-based learning để cùng các giảng viên thảo luận về các ngóc ngách của việc huấn luyện các lập trình viên non tay nghề, bằng việc cho họ trải nghiệm thực tế phát triển phần mềm một cách gần gũi và tiêu chuẩn thông qua các “dự án”. Thực tế đây là một reflection về quá trình chuyển đổi phương pháp luận, một số vấn đề, giải pháp và cải tiến liên quan. Tuy nhiên có một điều tôi vẫn muốn nói thêm về một số vấn đề mang tính “lịch sử”, có lẽ đây cũng là dữ liệu bổ ích nên tôi chép lại nội dung đó ra đây.

Đầu năm 2009, tôi có được giao nhiệm vụ tái thiết lại phương pháp luận triển khai môn dự án (Project) cho sinh viên năm cuối tai các trung tâm  tại Hà Nội do một số vấn đề tồn tại dai dẳng trong quá trình triển khai môn học thú vị này suốt nhiều năm trước. Đơn cử một vài mắc mớ như:

  • Các giảng viên hầu như không thống nhất trong phương pháp luận, mỗi người mỗi phách trong hướng dẫn sinh viên thực hiện dự án cũng như đánh giá kết quả. Phần nhiều do sự đa dạng về phương pháp và nền tảng của các giảng viên (người xuất thân từ công ty làm phần mềm khác nhau, người xuất thân từ trường học); lại thiếu tài liệu hướng dẫn chi tiết.
  • Mô hình waterfall như mô tả “phương pháp” lúc đó gần như không có hiệu lực trong thực tiễn. Mặc cho đây là cách tiếp cận dễ hiểu, và … dễ dạy, cái “quy trình” ấy gần như không bao giờ hiện diện trong thực tế. Theo mô hình này, sinh viên phải phân tích chi tiết bài toán, thiết kế rồi mới code và test; từng bước một.  Nhưng thường thì sản phẩm cuối cùng rất ít khi khớp với mô tả trong SRS lúc ban đầu. Điều này rất dễ lí giải vì vấn đề đặt ra trong các project thường phức tạp nên sinh viên chỉ có thể hiểu thấu đáo trong quá trình hoàn thiện sản phẩm, chứ không thể ngay lúc đầu planning. Do vậy thực tế này dẫn đến hầu hết các documentation chỉ mang tính “báo cáo”, làm cho đầy đủ quy trình chứ ít khi phản ảnh những gì thực sự đang có trong sản phẩm. Một số giảng viên nhìn ra vấn đề đó từ sớm và có nhiều nỗ lực để làm “chính xác hóa” cái mớ tài liệu ấy bằng các cơ chế review liên tục, trợ giúp kĩ thuật về viết lách, OOAD v.v.; nhưng kết quả chỉ tốt hơn chút đỉnh, chứ không giải quyết được nguồn ngọn vấn đề.
  • Học trò cuối cùng vẫn không hiểu được thế nào là “quy trình phát triển phần mềm”, không thực sự làm chủ được một quy trình do thực tế không được trải nghiệm một quy trình nào cả. Sách dạy waterfall, thầy ép theo waterfall, nhưng thực tế sinh viên luôn thực hiện theo một “cách khác”. Ví dụ như: đọc xong đề tài, thay vì viết SRS, phân tích các use case, rồi thảo luận các class diagram, sequence diagrame (SV quan niệm đó chỉ là các “tài liệu để báo cáo”-không hơn) v.v., thì sinh viên sẽ thực hiện theo trình tự kiểu như: tạo GUI, làm DB, rồi sau đó vừa làm vừa viết “tài liệu”; hoặc theo một cách khác nữa  cũng phổ biến không kém: đọc đề bài > phân tích rất sơ sài> làm DB > code > tài liệu.
  • Không có một môi trường thực sự  cho việc cộng tác nhóm phát triển do thiếu đầu tư vào công cụ bên cạnh quy trình.

Đứng trước bài tập khó nhằn này, tôi đã cố gắng tìm kiếm một mô hình làm dự án phù hợp với đối tượng và vấn đề đặc thù tại trung tâm. Một phương pháp được đề xuất phải thỏa mãn một số tiêu chí cơ bản như:

  • Thực dụng và khả thi: nó phải thực sự thực thi (khả thi) được, thống nhất giữa phương pháp luận và thực tiễn. Để khả thi, nó phải dễ hiểu, và dễ làm.
  • Hướng ngoại: tức nó phải tương thích với một quy trình ở “ngoài kia” (“các công ty”), thay vì tự mình đề xuất theo sách vở. Điều này hữu ích trong động viên bản thân sinh viên, vì họ cảm thấy có được cái cảm giác trải nghiệm một quy trình thật trong một môi trường phát triển phần mềm đầy đủ.
  • Có tính giáo dục: dù gì thì mục đích của dự án ở đây cũng là để sinh viên được trải nghiệm và học hỏi các kĩ năng cần thiết trong phát triển phần mềm, không phải để sản xuất phần mềm. Nó phải đưa sinh viên tới các ngóc ngách, đối mặt với các thử thách cần thiết để học được các kĩ năng cần thiết cho việc hành nghề của họ.

Lúc ấy có vài gợi ý: 1.cải tiến waterfall với các practices và tài liệu hóa đầy đủ việc hướng dẫn triển khai môn học; 2. Scrum  (khi đó tại trung tâm tôi cũng đã run hai dự án dùng Scrum: một với nhóm giảng viên, một với nhóm sinh viên); 3. Sử dụng tư tưởng iterative và RUP best practices với các tài liệu trợ giúp đầy đủ; 4. CMMI .

Do lúc đó tôi bị áp lực phải đưa nội dung OOAD vào chương trình (do chương trình chính quy thiếu sót mục này), nên tôi đã lựa chọn phương án (3). Các sự thay đổi quan trọng là:

  • Định nghĩa quy trình phát triển phần mềm với định hướng Iterative, RUP-based approaches.
  • Viết tài liệu hướng dẫn triển khai project cho các giảng viên, cùng với các lecture notes, evaluation form tương ứng và cả case study dưới dạng “showcase” để giảng viên dễ hình dung.
  • Làm template cho các artifacts (plan, SRS, use case spec templates, design template, verification checklist v.v.) để định hướng cũng như trợ giúp cả sinh viên lẫn giảng viên hướng dẫn dễ dàng cộng tác cũng như quản lí. Lúc này các tài liệu không còn là “tài liệu báo cáo” thuần túy, mà là các artifacts trong quá trình phát triển, nó động và hữu ích.
  • Cài đặt hệ quản trị dự án (PMS) với cái lõi Redmine và SVN server, kèm theo các test server cho từng kì để thiết lập môi trường cộng tác chuyên nghiệp.
  • Vậy là xong phương pháp luận, tài liệu triển khai, quy trình và công cụ. Tôi đã có buổi báo cáo với các group leader để thảo luận về phương pháp mới. Sau một vài ý kiến góp ý nho nhỏ, tôi mang nội dung quy trình mới ra thảo luận với hầu hết các giảng viên trong khuôn khổ một seminar. Đồng thuận tuyệt đối. Bước đầu như thế là thuận lợi.

Tuy vậy, khó khăn chỉ phát sinh lúc ta thực sự bắt tay vào công việc chứ thường chưa phải là lúc chuẩn bị.  Hơn một năm triển khai mang lại những tín hiệu không vui mừng lắm. Bên cạnh một số report thuận lợi từ các giảng viên có kinh nghiệm và cộng tác chặt chẽ với người đề xướng phương pháp, còn ra thì hầu hết vẫn không cải thiện triệt để. Các vấn đề được đề cập ở đầu bài viết này vẫn hiện hữu như những cái gai chọc thẳng vào mắt.

Qua thảo luận chi tiết và phản tỉnh tôi hiểu ra rằng tài liệu đầy đủ không giúp được mấy, việc training cũng sẽ không có tác dụng gì nhiều khi mà cái approach ngay từ đầu đã không đúng. Cái bọn tôi cần là một cách tiếp cận đơn giản, xuyên suốt, có khả năng thích nghi và tùy biến cao. Một phần do sự phức tạp trong việc triển khai đồng loạt, một phần do sự biến động không đoán được trong kĩ năng của sinh viên từng thời kì, việc cố định một quy trình cứng nhắc không có khả năng thích nghi sẽ dẫn đến hiệu lực kém và khó kiểm soát. Nhất là khi một quy trình đó lại đòi hỏi kĩ năng đặc thù tương đối toàn diện ở một đội ngũ thực thi (sinh viên) ít kĩ năng (vì họ đang luyện mà). Cách tiếp cận kiểu RUP hay waterfall đó đòi hỏi sinh viên phải “‘phân thân” do yêu cầu chuyên môn hóa (manager, architect, designer, coder, tester), và đòi hỏi nó phải “đạt” tại tất cả các kĩ năng đó (vì nếu không đạt phần design thì lấy gì mà code?) để đi đến đích là một sản phẩm đem đi bảo vệ trước hội đồng. Cách tiếp cận engineering như vậy về cơ bản là đổ vỡ ngay từ đầu, xét theo khía cạnh khả thi. Thế nên, dù nỗ lực nhiều nhưng kết quả không thể nói là hài lòng được.

Năm 2011 cũng là năm tôi có cơ hội để nhìn nhận sâu sắc hơn về agile và Scrum nhờ vào các hoạt động diện rộng cũng như chuyên sâu để tìm lời giải cho mình: tham gia khóa học của Scrum Alliance để hệ thống hóa những hiểu biết về Scrum, gặp gỡ các employers để hiểu requirement về developers, khởi xướng HanoiScrum, cộng tác chặt chẽ với AgileVietnam và tham gia AgileTour  để học hỏi từ cộng đồng chuyên nghiệp, thành lập ScrumLab để đi sâu vào các ngóc ngách thực hành Scrum\XP và thử nghiệm trên các đối tượng khác nhau; tiếp tục đọc, thử nghiệm và thuyết trình và huấn luyện Agile, TDD, Simple Design, Testing, Scrum v.v. Những trải nghiệm đa dạng đó không chỉ tiếp thêm sinh lực cho công cuộc phổ biến agile\Scrum ra cộng đồng cùng với các bạn cùng chí hướng, mà còn tạo thêm niềm tin và xung lực mạnh mẽ cho phép tôi mạnh tay đề xuất tiếp cận mới cho các môn project tại các trung tâm: phải linh hoạt hóa triệt để công tác giáo dục. Và project là xuất phát điểm.

Lần “nâng cấp” về phương pháp luận này có mấy điểm mấu chốt:

  • Đặt Project-Based Learning và Experimental Learning làm nền tảng giáo dục cho việc triển khai các khóa học project. Cần phải có lý thuyết giáo dục dẫn đường, vì đây là một nhiệm vụ giáo dục.
  • Tái thiết các mục tiêu cốt lõi của các khóa học Project của từng kì, theo hướng rèn luyên khả năng tích hợp các kĩ năng thành phần (component skills) quan trọng đối với software developer. Định hướng hoạt động theo objective-oriented (huấn luyện, thực hành, đánh giá dựa vào mục tiêu).
  • Tái thiết quy trình với cái lõi là agile\Scrum
  • Đề cao tính thích nghi, tương tác, liên tục học hỏi và cải tiến trong thực tiễn triển khai. Liên tục cập nhật các tài liệu, best practices quan trọng.
  • Tiếp tục hoàn thiện môi trường phát triển, nhấn mạnh các khâu phân vai, hạ tầng, và công cụ cho luyện tập.

Tiến trình này được khởi xướng được hơn nửa năm, và vẫn đang trong quá trình học hỏi (thực tế là đang rất lộn xộn). Nhưng tôi tin tưởng hướng tiếp cận mới rất đúng đắn, phù hợp với thực tiễn và xu thế chung. Hơn thế nữa, qua các thực tiễn sử dụng tư duy linh hoạt vào hoạt động không thuộc lĩnh vực phát triển phần mềm (như cung cấp dịch vụ, marketing, giáo dục chẳng hạn) được báo cáo tại Scrum Alliance, Agile Conference thì các giá trị agile rất phù hợp với các nguyên lý căn bản của giáo dục hiện đại như  tính cá nhân hóa, tính tương tác, tính thích nghi, tính tùy biến, sự phát triển bền vững v.v. Có thể nói các giá trị và nguyên lí agile hỗ trợ thúc đẩy mạnh mẽ  hiệu quả của các tiến trình giáo dục.

Cỗ xe tiếp tục lăn bánh, và tôi đang háo hức mong đợi các kết quả tốt vượt bậc từ phía triển khai. Đây quả là chặng đường thử thách và thú vị.