Hôm qua, một sinh viên đã tốt nghiệp vài năm trước tới gặp tôi. Anh ta nói: “Em đã đi làm cho một công ti phần mềm lớn trong vài năm, bây giờ em muốn bắt đầu công ti riêng của em. Em có đủ kinh nghiệm và một số tiền mà em đã tiết kiệm trong những năm qua. Em cũng có một vài người phát triển người sẵn lòng làm việc cho em. Em lập kế hoạch bắt đầu công ti của em bằng việc làm các dự án nhỏ và dần dần phát triển công ti. Em cần lời khuyên của thầy để thiết lập qui trình tốt để phát triển phần mềm có chất lượng với chi phí thấp nhất có thể được. Vì em chỉ có “vốn giới hạn”, em không muốn phí hoài nói. Thầy nghĩ điều đó có thể được thực hiện không?”

Sau khi suy nghĩ một chốc, tôi bảo anh ta: “Điều tốt là bắt đầu từ các dự án nhỏ. Nếu bạn có người phát triển có kĩ năng, bạn có cơ hội tốt hơn để thành công và xây dựng danh tiếng cho công ti của bạn. Bắt đầu từ những cái nhỏ cũng có thể tiết kiệm được tiền bạc bởi vì nếu bạn phạm sai lầm nó sẽ không là thảm hoạ và bạn có thể phục hồi được. Phần lớn mọi người thường bắt đầu công ti bằng việc hội tụ vào khía cạnh kĩ thuật. Đó KHÔNG phải là ý tưởng hay. Là người chủ công ti, bạn phải hội tụ vào khách hàng đầu tiên. Ưu tiên của bạn phải bắt đầu với việc có khách hàng và hiểu yêu cầu của họ. Đây là việc của bạn bởi vì không hiểu nhu cầu của khách hàng và không đáp ứng mong đợi của khách hàng là nguyên nhân chính cho thất bại doanh nghiệp. Bạn phải tiếp xúc với khách hàng, thu được yêu cầu, phân tích và làm tài liệu chúng cẩn thận. Bạn phải trắc nghiệm với khách hàng để chắc rằng bạn hiểu rõ yêu cầu và mong đợi của họ. Khách hàng phải chấp thuận tài liệu yêu cầu trước khi bạn bắt đầu làm bất kì việc nào. Trong khi có nhiều công cụ làm yêu cầu có tính thương mại bán sẵn trên thị trường, để tiết kiệm tiền, tôi gợi ý rằng bạn dùng Microsoft Word hay Excel cho việc làm tài liệu yêu cầu của bạn.”

Anh ta đồng ý: “Điều đó là dễ dàng, phần lớn các máy tính đều tới với Window 7 và Microsoft Office nạp sẵn cho nêm em sẽ không phải chi thêm tiền phụ.”

Tôi tiếp tục: “Nếu khách hàng chấp thuận yêu cầu và kí hợp đồng thì bạn có thể bắt đầu dự án. Với những dự án nhỏ bạn nên dùng cách tiếp cận phát triển Agile bởi vì nó ít rủi ro hơn các phương pháp khác. Bạn có thể tránh rủi ro của thay đổi yêu cầu thường xuyên điều thường xảy ra trong công nghiệp.”

Anh ta gật đầu: “Một ý hay là dùng cách tiếp cận Agile, em biết “Phương pháp Scrum.”

Tôi bảo anh ta: “Trong trường hợp đó, bạn phải chia yêu cầu thành những nhiệm vụ nhỏ hơn dùng kĩ thuật Cấu trúc phân việc (WBS). Bạn cần ước lượng công việc cần được thực hiện, phân công chúng cho người phát triển của bạn và xác định ngày chuyển giao. Với cách tiếp cận Agile dùng Scrum, bạn phải xác định công việc được yêu cầu cho từng đợt nước rút Sprint (2-4 tuần). Bạn có thể dùng Microsoft’s Excel để lập kế hoạch công việc và làm tài liệu cho mọi nhiệm vụ. Nếu bạn có dự án lớn hơn, bạn có thể dùng công cụ “Project” của Microsoft. Điều này sẽ cho phép bạn làm một số việc lập kế hoạch lại trong trường hợp thay đổi yêu cầu hay nếu khách hàng quyết định thay đổi một số chức năng vào phút chót. Bạn cũng có thể dùng công cụ “Bugzilla” để theo dõi và ghi lại các lỗi, những nâng cao, hay thay đổi yêu cầu. Bugzilla là chọn lựa phổ biến trong những người phát triển phần mềm và nó dễ dùng với đào tạo tối thiểu.

Anh ta đồng ý: “Em có thể kiếm những công cụ này và để cho người phát triển của em bắt đầu dùng chúng.”

Tôi tiếp tục: “Làm việc tổ trong Agile là rất quan trọng. Trước khi bắt đầu dự án bạn phải đào tạo mọi người phát triển về cách làm việc trong tổ. Cho dù họ có thể đã biết “Scrum”, bạn vẫn cần nhắc nhở họ về cách tiếp cận này và vai trò của họ để chắc không có hiểu lầm nào. Với dự án Scrum, có ba vai trò: Người chủ sản phẩm là người chịu trách nhiệm cho khía cạnh doanh nghiệp của dự án và ra quyết định về sản phẩm. Thầy Scrum người quản lí qui trình phát triển, giúp người phát triển làm việc cùng nhau, tạo điều kiện họp và theo dõi tiến độ và vấn đề. Tổ phát triển người xây dựng ra sản phẩm bằng làm việc cùng nhau để đạt tới mục đích của dự án. Vì dự án của bạn là nhỏ, bạn nên giả định giữ cả vai trò người chủ sản phẩm và thầy Scrum.”

Anh ta gật đầu: “Vâng, em không thể đảm đương được việc có nhiều người chừng nào em còn chưa thể phát triển công ti lên. Gợi ý của thầy rất hợp lí.”

Tôi tiếp tục: “Điều quan trọng là thiết lập việc tách bạch môi trường phát triển, môi trường kiểm thử, và môi trường sản xuất sớm để tránh việc trộn lẫn công việc. Đây là khái niệm đơn giản nhưng tôi đã thấy nhiều công ti nhỏ phạm sai lầm và trộn lẫn công việc của họ với những phiên bản sai, phần mềm đã kiểm thử để cùng phần mềm chưa kiểm thử, cho nên tôi nghĩa đáng nhắc bạn. Bạn phải thiết lập hệ thống kiểm soát nguồn để tạo điều kiện cho qui trình phát triển và lưu trữ mọi công việc đầy đủ. Quản lí cấu hình phần mềm là quan trọng bởi vì là công ti nhỏ, bạn có thể không có qui trình kiểm soát mạnh và những người được chỉ định để thực hiện vai trò quản lí cấu hình. Mọi người phát triển phải hiểu cơ sở về làm sao “Kiểm vào” công việc của họ và “Kiểm ra” khi chúng được thực hiện để tránh dư thừa, khi nào họ làm thay đổi cho phần mềm. Trong khi có một số công cụ sẵn có, bạn vẫn có thể dùng phương pháp thủ công bằng việc để những người phát triển gõ vào tình trạng số hiệu nhiệm vụ như “Mở”, “Đóng” và “Đã phân công” để cho mọi người có thể theo dõi thay đổi một cách dễ dàng. Để tiết kiệm tiền, bạn có thể xem xét dùng công cụ “nguồn mở” như CVS cho quản lí cấu hình. Là công ti nhỏ, bạn không cần phải mua những công cụ đắt tiền nhưng ĐỪNG BAO GIỜ thử tiết kiệm tiền bằng việc giảm đào tạo. Để thành công bạn phải hội tụ vào việc cải tiến kĩ năng của những người phát triển của bạn bằng những đào tạo phụ vì công nghệ thường xuyên thay đổi.”

Anh ta nói: “Em bao giờ cũng nhớ việc dạy của thầy từ nhiều năm trước, học liên tục là chìa khoá cho thành công trong khu vực này.”

Tôi kết luận: “Tôi vui là bạn nhớ điều đó. Phần còn lại của qui trình phát triển là đơn giản. Với từng dự án, bạn sẽ có cuộc họp hàng ngày để phân công công việc cho người phát triển vì bạn xây dựng phần mềm trên cơ sở hàng ngày. Bạn sẽ có những người phát triển viết mã, thực hiện kiểm thử đơn vị, tạo ra trường hợp kiểm thử và các kiểm thử tự động để chạy mọi đêm sau khi phần mềm được dựng ban ngày và kiểm tra các lỗi. Là thầy Scrum, bạn phải giám sát tiến độ trên cơ sở hàng ngày, kiểm tra các lỗi và để chúng được sửa và phải chắc mọi người đang làm nhiệm vụ được phân công của họ một cách tương ứng. Nếu bạn kiểm soát qui trình phát triển đơn giản này tốt thì bạn có thể mong đợi sản phẩm chất lượng cao. Bạn KHÔNG cần mua nhiều công cụ, bạn KHÔNG cần chi tiền vào bất kì cái gì phụ thêm, yếu tố quan trọng là có qui trình đơn giản mà mọi người hiểu và cam kết tuân theo nó cho công việc của họ. Một qui trình có chất lượng KHÔNG phải phức tạp, hay tinh vi mà nó phải được mọi người phát triển hiểu. Chìa khoá để thành công trong cách tiếp cận Agile KHÔNG phải là kĩ thuật mà là làm việc tổ và trao đổi. Bạn phải động viên mọi người thảo luận vấn đề, hỗ trợ lẫn nhau và sẵn lòng giải quyết vấn đề khi chúng tới. Tổ phải có mục đích chung, biết vai trò và trách nhiệm của họ và tuân theo qui trình chất lượng và đạo đức để hỗ trợ cho công ti đạt tới việc thoả mãn khách hàng.

—-English version—-

A simple process for small project

Yesterday, a student who graduated few years ago came to see me. He said: “I have worked for a large software company for several years, now I would like to start my own company. I have enough experiences and some money that I saved in the past few years. I also have several developers who are willing to work for me. I plan to start my company by doing small projects and gradually grow the company. I need your advice to set up a good process to develop quality software at the lowest cost possible. Since I only have “limited capital”, I do not want to waste it. Do you think it could be done?”.

After thinking for awhile, I told him: “It is good to start with small projects. If you have skilled developers, you have better chance to succeed and build the reputation for your company. Starting small can also save money because if you make mistakes it will not be disastrous and you could recover. Most people often start companies by focus on the technical aspect. That is NOT a good idea. As the owner of the company, you must focus on the customer first. Your priority must start with having customers and understand their requirements. This is your job because failing to understand customer’s needs and not meeting customer’s expectation are the main causes for business failure. You must contact customers, obtain requirements, analyze and document them carefully. You must verify with customers to make sure that you understand the requirements and their expectations well. The customer must approve the requirements document before you start to do any work. While there are many commercial off-the-shelf requirements tools available, to save money, I suggest that you use Microsoft Word or Excel for your requirements document”.

He agreed: “That is easy, most computers came with pre-loaded Window 7 and Microsoft Office so I would not have to spend extra money”.

I continued: “If the customer approves the requirements and signs contract then you can start the project. For small projects you should use Agile development approach because it is less riskier than other methods. You can avoid the risk of frequent requirements change that often happen in the industry.”

He nodded: “It is a good idea to use the Agile approach, I know the “Scrum method”.

I told him: “In that case, you must breakdown requirements into smaller tasks using the Work Breakdown Structure (WBS) technique. You need to estimate the work to be done, assign them to your developers and determine the delivery date. For Agile approach using Scrum, you must determine the works required for each Sprint (2-4 weeks). You can use Microsoft’s Excel to plan the works and document all tasks. If you have larger project, you may use Microsoft’s “Project” tool. This will allow you to do some re-planning in case of requirements change or if the customer decides to change some functionalities at the last minute. You also can use the “Bugzilla” tool to track and record defects, enhancements, or requirements changes. Bugzilla is a popular choice among software developers and it is easy to use with minimum training.

He agreed: “I can get those tools and have my developers start to use them”.

I continued: “Teamwork in Agile is very important. Before starting the project you must train all developers on how to work in team. Even they may already know “Scrum”, you still need to remind them about the approach and their roles to make sure there is no misunderstanding. On Scrum project, there are three roles: The product owner who is responsible for the business aspects of the project and make decisions about the product. The Scrum Master who manages the development process, helping developers work together, facilitating meetings and tracking progress and issues. The development team who build the product by working together to achieve the project’s goals. Since your projects are small, you should assume both the Product owner and Scrum master roles”.

He nodded: “Yes, I cannot afford to have more people until I can grow the company. Your suggestion is very reasonable”.

I continued: “It is important to set up the separation of development environment, testing environment, and production environment early to avoid any mix up of works. This is a simple concept but I have seen many small companies made mistakes and mixed up their works with wrong versions, tested software with untested software, so I think it is worth mentioning to you. You must establish a source control system to facilitate the development process and archive all complete works. Software Configuration Management is important because as small company, you may not have strong control process and designated people to perform the role of configuration management. All developers must understand the basic of how to “Check-in” their works and “Check-out” when they are done to avoid redundancy,  when they make change to the software. While there are several tools available, you can still use manual method by have developers type in task number status such as “Open”, “Close” and “Assigned” so people can track changes easily. To save money, you may consider to use “open source” tool like CVS for configuration management. As small company, you do not want to buy expensive tools but NEVER try to save money by reducing trainings. To succeed you must focus on improving the skills of your developers with additional trainings as technology often changes”.

He said: “I always remember your teaching from many years ago, continuous learning is the key to success in this area”.

I concluded: “I am glad that you remember that. The rest of the development process is simple. For each project, you will have daily meeting to assign works to developers as you build the software on a daily basis. You will have your developers code, perform unit tests, create test cases and automated tests to run every night after the daily software built and check for defects. As Scrum Master, you must monitor progress on daily basis, check for defects and have them fixed and make sure everybody is doing their assigned tasks accordingly. If you control this simple development process well than you can expect high quality product. You do NOT need to buy a lot of tools, you do NOT need to spend money on anything extra, the important factor is having a simple process that everybody understand and commit to follow it for their works. A quality process does NOT have to be complex, or sophisticated but it must be understood by all developers. The key to succeed in Agile approach is NOT technical but teamwork and communication. You must encourage people to discuss issues, support each other and willing to solve problems when they come. The team must have shared goals, know their roles and responsibilities and follow an ethical and quality process to support the company to achieve customer’s satisfaction.