Trong năm cuối cùng của chương trình, tớ đã quyết định đăng ký theo học môn “dự án” của bộ môn Khoa Học Máy Tính kéo dài liên tục hai học kỳ. Đây cũng là môn bắt buộc ở đại học Calgary nếu bạn chọn tốt nghiệp với thêm cái nhãn “Software Engineering Concentration” trong tấm bằng. Để được học môn này, thường là bạn sẽ phải đang ở năm cuối và cần phải đáp ứng một số yêu cầu tối thiểu nhất định (chủ yếu là yêu cầu phải đã/đang theo học một vài môn liên quan làm tiền đề). Đây là một khoá học đặc biệt, không phải chỉ ở độ dài của nó (kéo dài liên tục trong 2 học kỳ dài 8 tháng) mà còn ở nội dung – và phải nói rằng tớ đã thật sự học được rất nhiều từ nó.

Thật sự thì cũng chẳng rõ nên dịch Software Engineering như thế nào. Khác với bên Khoa học máy tính vốn nghiêng về những kỹ thuật lập trình (ở Việt Nam được gọi là bộ môn Tin), Software Engineering chú trọng dạy về các kỹ năng cần thiết để quản lý một dự án phần mềm. Nó bao gồm từ những kỹ năng nhóm, quản lý và lên kế hoạch cụ thể cho quá trình phát triển cho đến việc đánh giá các nguy cơ rủi ro. Tớ vốn không thích Software Engineering lắm vì nó liên quan quá nhiều đến giấy tờ (gần như bạn chỉ viết báo cáo chứ chẳng phải đụng vào một dòng mã nào cả) và đã từng có ý định bỏ tuỳ chọn này (giữ lại nó cũng chỉ vì tự nhiên cái bằng của mình có thêm cái nhãn đó nghe cũng “giá trị” hơn một chút :)

Mặc dù không thể tóm tắt được hết những gì đã diễn ra trong quá trình làm dự án (báo cáo cuối kỳ của tớ dài 5 trang mà cũng chỉ tóm tắt được vài khía cạnh của nó), trong bài viết này tớ sẽ mô tả những công cụ mà tớ cho rằng thật sự hỗ trợ đắc lực trong một quá trình dự án nhóm cỡ vừa và nhỏ (lớn thì chưa biết được :)

Tóm tắt về dự án

Như tên gọi của môn học, trong môn này sẽ không có bài giảng, bạn không phải đến lớp mà “đơn giản” là bạn sẽ phải thực hiện một dự án phần mềm thật sự, và khách hàng của bạn là những khách hàng thật sự chứ không phải chỉ là những bài tập mang tính thực hành do thầy đưa ra. Dự án mà tớ chọn tham gia là để viết một phần mềm cho phép xử lý tự động các tài liệu lịch sử. Thử tưởng tượng bạn là một nhà nghiên cứu lịch sử với một đống tài liệu lịch sử trong tay. Trong tài liệu X có đề cập đến một nhân vật có tên là “Mr. A” cùng với một vài thông tin liên quan kiểu như ngày MM.DD.YYYY nhân vật này có mặt ở sự kiện E. Ở một tài liệu khác, cũng có đề cập đến một nhân vật tên là “Nguyễn Văn A” và người này cũng có mặt ở sự kiện E ngày hôm đó. Phần mềm sẽ cho phép bạn:

1. Đánh dấu một hoặc nhiều thông tin trong đoạn văn bản là của một người nào đó, phân loại theo kiểu thông tin (ngày tháng, tên, địa điểm,…)
2. Một khi các thông tin đã được người dùng đánh dấu xong, mục đích cuối cùng là phần mềm sẽ có khả năng tự động đối chiếu và gợi ý về những trường hợp mà các thông tin cho thấy rằng 2 hoặc nhiều “cá thể” đề cập ở các tài liệu khác nhau thật ra là một người duy nhất.
3. Người dùng sẽ là người cuối cùng được xác nhận/bác bỏ các gợi ý này và một khi được xác nhận, các thông tin này sẽ được tổng hợp để làm cơ sở cho các so sánh kế tiếp.
4. Phần mềm cũng sẽ có các tính năng phụ khác, ví dụ như quản lý các tài liệu (hình ảnh scan, video,…), bản đánh máy của tài liệu, các văn bản đã được đánh dấu của mỗi tài liệu,…

Hệ thống sẽ phải sử dụng nền tảng cấu trúc UIMA¹ của IBM để làm cơ sở cho quá trình phân loại tự động. Tớ chủ động tham gia dự án này chủ yếu vì nó nghe có vẻ “thách đố” hơn về mặt lập trình (một dự án tuỳ chọn khác là phát triển một hệ thống website – vốn đã là sở trường). Và mặc dù những tính năng cuối cùng của phần mềm vẫn chưa được hoàn thiện ở cuối dự án (một điều đã được dự đoán từ trước, và phía khách hàng đồng ý sẽ tiếp tục phát triển nó), những gì tớ học được từ quá trình phát triển dự án này không chỉ là những kiến thức về kỹ năng và công nghệ, mà còn là ở việc ứng dụng những bài học về quản lý dự án vào thực tiễn.

Từ trước đến nay, khi học về những thứ như Extreme Programming (XP), Project Management – tớ không khỏi có cảm giác tất cả chỉ là những lý thuyết sách vở. Một cách tương tự, tớ cũng đã từng biết về hệ thống quản lý lỗi (”bug tracking”) nhưng lâu nay chẳng thèm sử dụng nó bởi theo cách nghĩ của tớ, thời gian để viết một báo cáo về một lỗi đôi khi còn mất thời gian hơn là tự mình ngồi sửa nó. Tuy nhiên, độ phức tạp của dự án, và đặc biệt là độ dài của của nó đã khiến tớ thay đổi những suy nghĩ của mình về những gì mình đã học trong chuyên ngành Software Engineering.

Khi công cụ trở thành một yếu tố quyết định

Nhóm thực hiện chỉ gồm 5 người, có lẽ tương đối nhỏ so với các dự án ngoài thực tế nhưng vẫn đã đặt ra nhiều vấn đề về việc phối hợp trong suốt dự án:

• Quản lý mã: Làm thế nào để mọi thành viên đều có thể cùng lúc truy cập vào phiên bản mới nhất của mã nguồn. Nhóm chúng tớ quyết định không chia nhỏ dự án mà để tất cả mọi thành viên tham gia thực hiện tất cả các thành phần khác nhau của dự án. Điều này đặt ra nguy cơ là những sửa đổi của một thành viên có thể “đụng độ” với mã của thành viên khác.
• Liên lạc giữa các thành viên: cách thông thường là các thành viên email qua lại lẫn nhau (hoặc thậm chí chat) để trao đổi. Tuy nhiên, cách này có nhiều bất tiện. Ví dụ như những trao đổi email giữa 2 thành viên về cách giải quyết một vấn đề cụ thể thì chỉ 2 thành viên đó với nhau biết mà thôi – những thành viên khác không thể học gì từ kết quả của cuộc trao đổi đó. Mặc khác, không có cách nào để hệ thống hoá và lưu giữ tập trung những email trao đổi này. Để việc phối hợp có hiệu quả, cần có một giải pháp tập trung giúp các thành viên liên lạc và trao đổi với nhau.
• Hệ thống chia sẽ kiến thức: Tớ đảm nhận vai trò “kiến trúc hệ thống” (”System Architect”). Làm thế nào để mô tả những quyết định trong kiến trúc của hệ thống, giúp những thành viên khác có thể tham khảo trong suốt quá trính phát triển, cũng như tham gia thảo luận về những quyết định đó là một yêu cầu bắt buộc.
• Quản lý chất lượng mã: Càng về sau, khi mà số lượng dòng mã đã đạt đến mức mà không có bất kỳ thành viên nào trong dự án có khả năng hiểu rõ cách toàn bộ hệ thống hoạt động cùng nhau – việc có một hệ thống cho phép các thành viên nhanh chóng và thuận tiện theo dõi những vấn đề phát sinh là yếu tố quyết định trong việc đảm bảo chất lượng của sản phẩm. Hệ thống này cũng đóng vai trò quan trọng trong việc xác định mục tiêu trước cho mỗi phiên bản.

Thành công của dự án vì vậy có lẽ phụ thuộc một phần không nhỏ vào những lựa chọn của nhóm về những dịch vụ/sản phẩm để giải quyết những nhu cầu trên. Trong phần kế tiếp của bài viết, tớ sẽ giới thiệu những dịch vụ/công cụ hỗ trợ mà bọn tớ đã sử dụng khá thành công, với hi vọng sẽ giúp các bạn phần nào trong việc bắt đầu phát triển một dự án phần mềm nhóm của riêng mình.

Subversion – Quản lý mã

Subversion thật ra là một hệ thống “nâng cấp” từ CVS (viết tắt của Concurrent Version Control) với một vài thay đổi quan trọng khiến nó hữu ích hơn CVS. Giống như CVS, Subversion cho phép nhiều thành viên có thể cùng lúc truy cập/thay đổi mã nguồn với các tính năng quan trọng sau:

1. Quản lý phiên bản: đây là tính năng quan trọng nhất bởi nó cho phép bạn quay lại bất kỳ phiên bản nào của mã nguồn trước đó nếu vì một lý do nào đó những thay đổi trong mã nguồn ở một thời điểm gây vấn đề cho toàn bộ hệ thống. Tính năng cũng khiến cho Subversion đóng vai trò như một hệ thống sao lưu dự phòng cho toàn bộ hệ thống (subversion thường được cài đặt trên máy chủ trên Internet)
2. Cho phép nhiều thành viên truy cập vào cùng một hệ thống mã. Sẽ thật là nhức đầu nếu mỗi thành viên viết mã trên máy của mình rồi sau đó phải ngồi lại với nhau để đồng bộ các thay đổi trên máy mỗi thành viên. Subversion cho phép tất cả các thành viên ở thời điểm bất kỳ truy cập vào phiên bản mới nhất của mã nguồn, tải về trên máy cục bộ, thực hiện thay đổi và sao đó gửi lên lại để các thành viên khác có thể tiếp tục làm việc với phiên bản đó.

Mặc dù bạn hoàn toàn có thể cài đặt máy chủ subversion trên máy tính cục bộ và sử dụng nó, để nhiều thành viên có thể truy cập vào bạn sẽ cần cài đặt nó trên máy chủ của riêng mình trên Internet. Hiện có khá nhiều dịch vụ cung cấp miễn phí dịch vụ này (chủ yếu dành cho mã nguồn mở) như SourceForge.net, Google Code hay Beanstalk. Ngoài ra, nếu bạn có nhu cầu bảo vệ hệ thống mã của mình thì cũng có các dịch vụ thương mại, hoặc nếu bạn có thuê máy chủ của riêng mình thì bạn hoàn toàn có thể tự mình cài đặt một hệ thống của riêng mình (Dreamhost² thậm chí hỗ trợ quá trình với hệ thống quản lý có sẵn của họ).

Nếu sử dụng Eclipse, bạn có thể tích hợp Subversive để có thể kết nối trực tiếp vào hệ thống Subversion. Nếu bạn sử dụng Visual Studio, AnkhSVN là một plugin miễn phí tích hợp trực tiếp với giao diện của Visual Studio. Ngoài ra, bạn cũng có thể cài đặt TortoiseSVN để truy cập vào Subversion trực tiếp trong Windows Explorer.

Tất nhiên, để Subversion hoạt động thật sự có hiệu quả, nhóm sẽ cần phải đặt ra một vài nguyên tắc mà các thành viên phải theo khi làm việc với mã nguồn:

• Trước khi bắt đầu mỗi phiên làm việc, phải cập nhật lại mã nguồn từ máy chủ (”update”)
• Chỉ được gửi các thay đổi của mình lên máy chủ nếu những thay đổi không khiến toàn bộ hệ thống bị tê liệt hoặc khiến những tính năng đã hoạt động trước đó ngừng hoạt động.
• Nếu có thể, chỉ gửi những thay đổi sau khi những tính năng mà bạn đang làm đã tương đối hoàn thiện. Ví dụ bạn nên gửi những thay đổi của mình lên máy chủ sau khi đã sửa xong một lỗi (”bug”), nhưng tránh gửi phiên bản mới chỉ vì bạn mới xoá một dòng ghi chú.
• Mỗi thành viên có trách nhiệm giải quyết những tương thích nảy sinh do mã của mình gây ra (Subversion sẽ tự động giải quyết những xung đột đơn giản giữa các phiên bản, nhưng những thay đổi phức tạp hơn sẽ đòi hỏi người phát triển phải xem xét để giải quyết).
• Mỗi phiên bản mới phải đi kèm với ghi chú về những gì đã được thay đổi.

Basecamp – Hệ thống quản lý dự án

Basecamp là hệ thống quản lý dự án của 37Signals và là một trong những ứng dụng nổi tiếng nhất sử dụng Ruby On Rails (cũng không quá ngạc nhiên vì 37Signals chính là công ty sáng tạo ra Rails). Nó là hệ thống quản lý được yêu thích nhất hiện nay bởi sự những tính năng hữu ích, tiện dụng cũng như thiết kế cực kỳ đơn giản mà hiệu quả. Biết đến Basecamp đã khá lâu và cũng đã từng sử dụng nó cho khá nhiều những dự án trước đây, một lần nữa tớ giới thiệu Basecamp cho nhóm và nó đã chứng tỏ được sự hữu ích của mình.

Những tính năng quan trọng mà Basecamp cung cấp bao gồm:

• Liên lạc giữa các thành viên thông qua hệ thống Message (”Thông điệp”). Đây là giải pháp hiệu quả giải quyết vấn đề liên lạc bằng email qua lại giữa các thành viên. Bạn có thể gửi một tin nhắn mới vào hệ thống và để hệ thống email nó đến một hoặc tất cả các thành viên còn lại. Các thành viên có thể gửi trả lời cho mỗi thông điệp vào hệ thống giống theo cách mà các diễn đàn hoạt động.
• Quản lý danh sách tác vụ cũng như các mốc (”milestone”) trong quá trình phát triển. Bạn có thể xác định những cột mốc trong quá trình phát triển, tạo ra danh sách những tính năng cần hoàn thiện cho mỗi cột mốc cũng như giao mỗi tính năng đó cho mỗi thành viên của dự án.
• Hệ thống quản lý file³ Trong mỗi dự án không nhất thiết chĩ có mã. Đôi khi, các thành viên cần trao đổi các tài liệu khác. Basecamp cho phép bạn đưa những tài liệu như vậy lên chia sẽ với các thành viên. Hệ thống cũng hoạt động giống như Subversion cho phép quản lý các phiên bản khác nhau của một tài liệu.

Vấn đề khó khăn duy nhất có lẽ là thuyết phục mọi người thống nhất sử dụng nó cho mọi liên lạc liên quan đến dự án. Rất nhiều trường hợp các thành viên tiếp tục thói quen email lẫn nhau để trao đổi về một vấn đề nào đó thay vì sử dụng hệ thống thông điệp cung cấp bởi Basecamp. Điều này tất nhiên có thể được khắc phục sau một thời gian và sẽ rất hữu ích nếu những thành viên chủ chốt sử dụng nó thường xuyên – bởi nó sẽ khiến những thành viên khác cũng phải sử dụng hệ thống.

Kết thúc phần 1

Vì bài viết đã quá dài, tớ tạm thời kết thúc phần 1 của chủ đề này ở đây và sẽ tiếp tục đưa phần 2 của chủ đề này lên vào ngày mai. Trong phần đầu của bài viết, tớ đã giới thiệu đến các bạn 2 phần không thể thiếu trợ giúp cho quá trình quản lý dự án phần mềm, bao gồm hệ thống quản lý mã (Subversion) và hệ thống quản lý thông tin dự án sử dụng dịch vụ của Basecamp. Có thể nói, việc sử dụng hệ thống quản lý mã là không thể thiếu nếu nhóm của bạn có từ 2 người phát triển trở lên, nhưng ngay cả khi bạn là người duy nhất trong dự án thì việc sử dụng một hệ thống quản lý mã như Subversion còn đóng vai trò sao lưu dự phòng dự án và đồng thời cho phép bạn truy cập vào mã của mình ở bất kỳ máy tính nào có nối Internet. Còn đối với Basecamp, là một hệ thống quản lý thông tin dự án, nếu được sử dụng đúng cách sẽ có thể có ích rất nhiều ngay cả với trường hợp bạn là người duy nhất trong dự án đó.

Trong phần hai của bài viết, tớ sẽ giới thiệu đến các bạn giải pháp chia sẽ kiến thức giữa các thành viên trong dự án, hệ thống quản lý chất lượng mã và cuối cùng sẽ giới thiệu đến các bạn một dịch vụ miễn phí tích hợp tất cả các tính năng được đề cập đến trong bài viết.

Chú thích trong bài:

1. Unstructured Information Management Architecture [↩]
2. đăng ký ở Dreamhost với mã NGUOITAPVIET để được giảm $30 [↩]
3. tính năng này đòi hỏi bạn phải đăng ký dịch vụ trả tiền [↩]