Tuần trước, một người bạn có sở hữu một công ti phần mềm gọi điện thoại cho tôi: “Sau khi làm việc cho một công ti phần mềm trong sáu năm, tôi bắt đầu công ti riêng của tôi. Tôi tuyển những sinh viên tốt nghiệp hàng đầu và trả lương hậu cho họ, tôi có một số khách hàng và công ti của tôi phát triển nhanh chóng. Tuy nhiên, hiện thời chúng tôi có vấn đề với lỗi nhiều và trượt lịch biểu. Nếu những vấn đề này tiếp tục, công ti của tôi sẽ lâm vào rắc rối. Là người chủ, tôi thường dành hầu hết thời gian của mình với khách hàng để đưa vào việc kinh doanh mới cho nên làm sao tôi có thể sửa được những vấn đề này và tiếp tục phát triển công ti của tôi?”

Tôi nói với ông ấy: “Ông không thể bỏ qua các vấn đề bằng việc dành thời gian cho khách hàng và để mọi người làm việc mà không có giám sát nào. Việc sửa lỗi yêu cầu phần lớn thời gian của người phát triển và có lẽ nó là lí do chính cho việc trượt lịch biểu. Điều khẩn thiết cần làm bây giờ là hội tụ vào việc tìm và sửa lỗi. Tôi nghĩ ông cần tiến hành kiểm điểm thường xuyên hơn để nhận diện và sửa chúng sớm nhất có thể được. Trong các cuộc kiểm điểm này, ông phải để mọi người phát triển và người kiểm thử tới và biết cách lỗi đã bị phạm phải thế nào và làm sao sửa được chúng.”

Ông ta hỏi: “Sao lại mọi người? Tôi không để người không làm việc trong cùng dự án tham dự họp kiểm điểm được. Điều đó là phí thời gian.”

Tôi giải thích: “Về căn bản, những người phát triển trong dự án đều có kiểm điểm giữa họ để tìm và sửa lỗi. Đây là những lỗi ‘không biết” với người phát triển khác, người đã không tham dự buổi kiểm điểm và họ có thể phạm phải cùng sai lầm lần nữa. Lí do cho “kiểm điểm dành riêng” là người phát triển không muốn người khác tìm ra lỗi của họ. Tuy nhiên, là người chủ công ti, ông phải coi kiểm điểm như quá trình học tập cho nên mọi lỗi được tìm ra đều là cơ hội học tập. Người phát triển càng biết nhiều về nguyên nhân của lỗi, càng dễ tránh phạm phải chúng.

Ông ấy dường như thoả mãn: “Được, tôi có thể bắt đầu bằng kiểm điểm và để mọi người phát triển tới và học. Tôi có thể làm cái gì khác?”

Tôi tiếp tục: “Dự án phần mềm điển hình bắt đầu với ít người, rồi khi nó tiến triển, ông thêm người cho nó. Phần lớn các môn quản lí dự án bao giờ cũng dạy cách tiếp cận dần dần và nó có tác dụng tốt với doanh nghiệp xây dựng. Ông chỉ cần vài nhà kiến trúc lúc ban đầu nhưng khi các pha kiến trúc và thiết kế được thực hiện rồi, công ti đem nhiều công nhân vào xây dựng. Tuy nhiên, với dự án phần mềm cách tiếp cận này không có tác dụng tốt. Sẽ là tốt hơn nếu ông có thể bắt đầu với đầy đủ cán bộ từ đầu.”

Ông ấy ngạc nhiên: “Sao chúng tôi cần nhiều người hơn ngay từ những pha đầu? Điều đó sẽ tốn nhiều tiền hơn.”

Tôi giải thích: “Đó là lí do tại sao nhiều dự án phần mềm có vấn đề. Ông bắt đầu chỉ với ít người làm việc với yêu cầu của khách hàng và rồi họ hiểu điều gì phải làm. Rồi họ bắt đầu kiến trúc và thiết kế hệ thống. Vì họ làm việc trên dự án từ đầu, họ hoà hợp tốt. Khi ông thêm nhiều người vào dự án về sau, người mới không có thời gian  để biết lẫn nhau hay hình thành cách làm việc tổ hiệu quả. Xung đột cá nhân  có thể xảy ra trong thời gian này. Người mới không có thời gian hiểu yêu cầu nhưng họ phải thiết kế và viết mã ngay lập tức.”

“Họ có thể không biết cách tích hợp công việc của họ với kiến trúc hệ thống. Họ có thể không hiểu chức năng chi tiết của hệ thống nhưng họ phải làm cho việc của mình được thực hiện trong lịch biểu bị giới hạn. Đây là chỗ nhiều sai lầm bị phạm phải. Người mới được mong đợi hình dung ra mọi thứ theo cách riêng của họ trong thời gian rất ngắn. Tất nhiên, họ có những câu hỏi và họ phải hỏi người khác, nhưng người có đó từ lúc bắt đầu để giúp. Điều này có thể làm gián đoạn công việc dự án bởi vì thời gian để dạy người mới về dự án bao giờ cũng mất lâu hơn mong đợi, cho nên dự án có thể bị chậm. Do sức ép lịch biểu, mọi người phải vội vàng làm cho việc của mình được thực hiện và nhiều lỗi bị phạm phải.”

Ông ấy gật đầu: “Tôi chưa bao giờ nghĩ về điều đó, ông có thể đúng. Có những vấn đề giữa người mới và người cũ, họ tranh cãi mọi lúc. Tôi cần làm gì khác?”

Tôi bảo ông ấy: “Vòng đời phần mềm truyền thống là cách tiếp cận tuần tự giống như dây chuyên lắp ráp trong công nghiệp. Trước hết, kĩ sư yêu cầu làm việc với khách hàng để làm tài liệu cho tất cả các yêu cầu. Kiến trúc sư hệ thống sẽ hình dung ra cách hệ thống làm việc dựa trên các yêu cầu này. Thế rồi người phát triển sẽ thiết kế và rồi viết mã. Tiếp đó, người kiểm thử sẽ kiểm thử chúng. Sau khi tất cả kiểm thử đã được hoàn thành, sản phẩm phần mềm được đưa ra cho khách hàng. Chúng ta hãy nhìn lại cách tiếp cận này. Kĩ sư yêu cầu chỉ quan tâm tới điều khách hàng cần và hội tụ vào việc làm tài liệu cho chúng. Kiến trúc sư đặt mọi thứ dựa trên tài liệu yêu cầu và thiết kế hệ thống. Người phát triển hội tụ phần lớn vào viết mã dựa trên thiết kế. Người kiểm thử không chăm nom tới cách toàn thể hệ thống được thiết kế mà chỉ vào các trường hợp kiểm thử, nơi kiểm xem mã có qua được kiểm thử hay không. Điều gì sẽ xảy ra khi yêu cầu sai? Điều gì sẽ xảy ra nếu thiết kế bị thiếu chức năng nào đó? Điều gì sẽ xảy ra khi người kiểm thử kiểm vào các mã mà không được làm tài liệu trong tài liệu yêu cầu? Điều gì sẽ xảy ra nếu có những chức năng mới được thêm vào trong các phút cuối. Nếu người kiểm thử không biết về chức năng mới, họ không thể kiểm thử được nó. Đó là lí do cho cách tiếp cận kiểu dây chuyền lắp ráp này thực sự không có tác dụng tốt với phần mềm. Vòng đời thác đổ là tốt cho giảng dạy, nó dễ hiểu nhưng nó không có tác dụng tốt trong công nghiệp.

Bạn tôi ngần ngại một chốc: “Đó là điều chúng tôi vẫn làm sao? Ông gợi ý gì để chúng tôi làm khác đi?”

Tôi giải thích: “Đó là lí do tại sao đào tạo kĩ nghệ phần mềm yêu cầu rằng công ti phải xác định qui trình phát triển tích hợp đầy đủ mọi thành viên tổ sớm nhất có thể được. Qui trình được xác định không phải là một hoạt động theo chuỗi mà là tăng dần với mọi vai trò được tích hợp đầy đủ. Nó rất quan trọng để bắt đầu với đầy đủ cán bộ hay ít nhất với đa số người lúc ban đầu. Người quản lí dự án phải thảo luận về vai trò, trách nhiệm của từng thành viên tổ và điều từng người cần làm để thành công. Đào tạo làm việc theo tổ lúc bắt đầu sẽ tạo ra một số các thảo luận, nơi các thành viên tổ có thể nói về điều họ cần từ nhau. Rồi tổ trình bày nhu cầu của họ, quan điểm của họ với người quản lí dự án. Sau vài tuần đầu trong dự án, tổ có thể đi tới qui trình mà mọi người đều biết nhiệm vụ của họ là gì, và cách để làm việc với chúng. Thông tin này nên được làm tài liệu như một phần của qui trình tổ dự án nơi mọi người đều biết ưu tiên dự án là gì, và cách ra quyết định để thoả mãn nhu cầu dự án.

Bạn tôi hỏi: “Sao ông cần vài tuần đầu để xây dựng dự án? Có quá nhiều không?”

Tôi trả lời: “Làm việc theo tổ là hoạt động quan trọng nhất trong dự án phần mềm. Ông không thể mong đợi rằng những người không biết lẫn nhau sẽ hài hoà với nhau trong vài ngày. Họ cần thời gian để biết lẫn nhau và đi tới qui trình được xác định mà mọi người sẽ đồng ý tuân theo. Thay vì qui trình tuần tự, ông nên yêu cầu tổ phát triển một qui trình song hành để xây dựng phần mềm. Chẳng hạn, kiến trúc sư xác địnhg kiến trúc tổng thể của sản phẩm phần mềm, xác định các tính năng cho từng bản đưa ra và tiến hành kiểm điểm ban đầu nơi mọi thành viên tổ cần phải tham dự. Đây là lúc mọi người nên thực sự học về khía cạnh kĩ thuật và hỏi các câu hỏi nếu cần. Sau kiểm điểm ban đầu, nhóm những người phát triển sẽ bắt đầu thiết kế ngay lập tức khi nhóm khác làm việc trên kiểm thử hệ thống. Sau thiết kế, tổ phải tiến hành kiểm điểm thiết kế cùng với toàn tổ và nhóm kiểm thử phải chắc chắn rằng kiểm thử hệ thống của họ sẽ làm việc tốt với thiết kế này. Nếu mọi sự tốt lành, thì tổ có thể bắt đầu thiết kế chi tiết và thực hiện, đồng thời nhóm kiểm thử sẽ làm việc trên việc phát triển các kiểm thử chức năng. Mọi pha đều phải có kiểm điểm với sự tham dự của toàn tổ để chắc chắn họ phối hợp các hoạt động của mình và công việc của họ được tích hợp đầy đủ. Đến lúc mã được viết ra và kiểm thử (đơn vị được kiểm thử), mọi người sẽ sẵn sàng cho kiểm điểm mã. Mọi mã đều phải trải qua kiểm điểm trước khi được đưa vào hệ thống quản lí cấu hình. Sau khi mã được kiểm, người kiểm thử sẽ bắt đầu kiểm và bất kì lỗi nào được nhận diện đều phải được sửa theo qui trình thay đổi. Về căn bản, mọi thứ trong dự án đều phải tuân theo qui trình song hành được xác định tốt và người quản lí dự án phải dùng độ đo để trắc nghiệm mọi thứ. Lịch biểu dự án nên được dõi vết theo ước lượng gốc, mọi yêu cầu đều phải được quản lí, cũng như mọi lỗi. Bằng việc để mọi người tham gia sớm và giúp xác định qui trình, các thành viên tổ hiểu công việc của họ và những cột mốc chính. Họ biết điều họ cần làm từng tuần và trắc nghiệm công việc của họ lẫn nhau. Trong nỗ lực cộng tác này, các thành viên tổ có thể lưu ý khi vấn đề xuất hiện và có hành động sửa chữa thay vì chờ đợi cho tới pha sau. Nếu tổ tuân theo qui trình được xác định tốt, họ có thể cải tiến cách họ giải quyết các lỗi và việc trượt lịch, và cuối cùng mọi dự án sẽ được cải tiến.

Bạn tôi nói: “Vậy ông nghĩ làm việc tổ và qui trình là nhân tố mấu chốt cho cải tiến dự án à?”

Tôi bảo ông ấy: “Vâng, dứt khoát rồi. Qui trình phần mềm có thể có vẻ đơn giản nhưng chúng biểu thị cho thay đổi mạnh mẽ trong cách mọi người làm công việc của họ. Với làm việc theo tổ, mọi người nhận ra rằng công việc của họ là nỗ lực cộng tác nơi mọi thứ đều phải được tích hợp. Đây là chìa khoá cho thành công của mọi công việc phát triển, không ai làm việc một mình. Với kỉ luật kĩ nghệ phần mềm, họ sẽ biết phải làm gì và làm gì tiếp. Có kỉ luật là bước đầu tiên để phát triển công ti của ông. Bên cạnh những qui trình kĩ thuật này, ông có thể cải tiến qui trình quản lí của ông nữa. Chừng nào chưa có qui trình phát triển được được xác định tốt, sẽ khó mà biết ai đang làm gì hay ai là tốt và ai không tốt. Qui trình được xác định tốt cho phép người quản lí dự án hiểu công việc phát triển và vai trò, trách nhiệm của từng thành viên tổ. Điều này cho người quản lí cơ hội làm việc với những người có công việc không chấp chấp nhận được, và thưởng cho những người hoàn thành công việc xuất sắc.

—-English version—-

Process for software project

Last week, a friend who owns a software company called me: “After working for a software company for six years, I started my own company. I hired top graduated students and paid them well, I had several customers and my company grew fast. However, currently we are having problems with high defects and schedule slippages. If these problems continue, my company will be in trouble. As the owner, I usually spent most of my time with customers to bring in new business so how could I fix these problems and continue to grow my company?

I told him: “You can not ignore problems by spending time with customers and let people work without any supervising. Defect correction requires most of developers’ time and it is probably the main reason for schedule slippage. The urgent thing to do now is focusing on finding and fixing defects. I think you need to conduct more reviews to identify defects and correct them as soon as possible. In these reviews, you must have all developers and testers come and learn how defects were made and how to fix them.

He asked: “Why everybody? I can not have people who do not work in the same project to attend the reviews. It is a waste of time”.

I explained: “Typically, developers in project always have reviews among themselves to find and fix defects. These defects are “unknown” to other developers who did not attend reviews and they could make the same mistakes again. The reason for “exclusive reviews” is developers do not want others to find out about their mistakes. However, as the company owner, you should consider reviews as learning process so every defect found is a learning opportunity. The more developers know about the cause of defects, the easier it is to avoid making them.

He seemed satisfy: “OK, I could start with reviews and have all developers to come and learn. What else could I do?

I continued: “Typical software project starts with few people then as it progresses, you add more people to it. Most project management courses always teach this gradual approach and it works well with construction business. You only need few architects in the beginning but when architect and design phases are done, company brings in more workers to do construction. However, with software project this approach does not work well. It would be better if you could start with a full staff in the beginning.

He was surprised: “Why do we need more people in the early phases? That will cost more money”.

I explained: “That is why many software projects are having problems. You start with only few people to work with customers’ requirements and they understand what to do. Then they begin to architect and design the system. Because they work on the project from the beginning, they get along well. When you add more people to the project later, new people do not have time to know each others or form an effective teamwork. Personal conflicts may happen during this time. New people do not have time to understand requirements but they have to design and write code immediately.

They may not know how to integrate their works with the system architect. They may not understand the functional detailed of the system but they have to get their works done within limited schedules. This is where many mistakes are made. The new people are expected to figure out everything on their own in a very short time. Of course, they have questions and they have to ask others who are there in the beginning to help. This may disrupt project works because the time to teach new people about the project always take longer than expected, so the project may be late. Due to schedule pressure, people must hurry to get their works done and more defects are made.

He nodded: “I never think of that, you may be right. There are problems between new people and old people, they argued all the time” What else do I need to do?.

I told him: “The traditional software life cycle is a serial approach similar to the assembly line in industry. First, requirements engineer works with customers to document all requirements. The system architect would figure out how the system works based on these requirements. Then developers would designs and then write code. Next, testers would test them. After all tests are completed, the software product is released to customers. Let’s look at this approach. The requirements engineer only concerns about what customer needs and focuses on document them. The architect based everything on the requirements document and designs the system. The developers focus mostly on writing code based on the design. Testers do not care how the whole system is designed but only on their test cases whether the code passes tests or not. What would happen when the requirements are wrong? What would happen if the design is missing some functions? What would happen when testers checked in code that is not documented in the requirements document? What would happen if there are new functions added at the last minute. If the testers do not know about the new functionality, they can’t test it. That is the reason this assembly line approach really does not work well with software. The waterfall life cycle is good for teaching, it is easy to understand but it does not work well in the industry.

My friend hesitated for awhile: “That is what we always do? What do you suggest that we do differently?”

I explained: “That is why software engineering training requires that company must define the development process that fully integrate all team members as early as possible. The defined process is not a serial activity but an incremental with all roles fully integrated. It is very important to start with a full staff or at least a majority of people in the beginning. The project manager must discussed each team member’s role, responsibilities and what each person needed to do to be successful. The teamwork training in the beginning will create a number of discussions, where team members can talk about what they need from each other. The team then present their needs, their views to the project manager. After the first few weeks on the project, the team can come up with a process that everyone know what their tasks are, and how to work them. This information should be documented as part of the project team process where everyone know what the project priorities are, and how to make decisions to satisfy the project needs.

My friend asked: “Why do you need few weeks to build team? Is it too much?

I answered: “Teamwork is the most important activity in software project. You can not expect that people who do not know each other will get along well in a few days. They need time to know each others and come up with a defined process that everyone would agree to follow. Instead of a serial process, you should ask the team to developed a concurrent process to build software. For example, the architect defines an overall architecture of the software product, specifying features for each release and conducts an initial review where every team members should attend. This is the time where everybody should really learn about the technical aspects and ask questions if needed. After the initial review, a group of developers will start the design immediately when another group is working on the system tests. After the design, the team must conduct a design review with the entire team and the test group must make sure that their system tests will work well with the design. If everything is fine, then the team can start the detailed design and implementation, at the same time the test group will work on the development of functional tests. Every phase must have review attend by the entire team to make sure they coordinate their activities and their works are fully integrated. By the time the code was written and tested (unit tested), everyone will be ready for code reviews. All code must go through reviews before being placed in configuration management system. After the code is checked in, testers will start testing and any defects identified must be fixed according to a change process. Basically, everything in the project must follow a well-defined concurrent process and project manager must use metrics to verify everything. Project schedules should be tracked against original estimates, all requirements must be managed, as well as any defects. By having everybody participate early and help define the process, team members understand their works and major milestones. They know what they need to do each week and verify their works with each others. In this collaborative efforts, team members could notice when a problem happens and take corrective action rather than wait until later phase. If the team is following a well defined process, they can improve the way they deal with defects and schedule slippages, and eventually all projects will be improved.

My friend said: “So you think teamwork and process are critical factors for project improvement?”

I told him: “Yes, definitely. Software process may sound simple but they represent a dramatic change in the way people do their works. With teamwork, people recognized that their work is a collaboration efforts where everything must be integrated. This is the key to the success of all development works, no one works alone. With software engineering disciplines, they will know what to do and what to do next. Having discipline is the first step to grow your company. In addition to these technical processes, you can improve your management processes too. Until there is a well-defined development process, it is difficult to know who are doing what or who are good and who are not. The well-defined process allows project managers to understand development works and role, responsibility of each team members. This give managers the opportunity to work with people whose works are not acceptable, and reward people who do outstanding work.