< On-going document: I have more and more to document as I am writing along the way. It maybe worth to expand to a paper> Please feel free to comment by leaving me a private message.
Your project is due to delivery, the development team is still struggling with the last minute requirement change, or some technical issues they never considered before. Under the high pressure from either top management or account team, the R&D department has to put more engineers from other team to help. But how to help? One pregnant woman can deliver a baby in 10 months does not mean 10 women can deliver a baby in one month, :-0
Have you ever encountered this kind of scenario? Never, or you ran into this situation for every project in your past?
There is a Chinese saying: 幸福的家庭都是相似的，但不幸的家庭各不相同 (All happy families are alike, but each unhappy family is unhappy in its own way). Software development is similiar, all success projects are alike, but each failed project has its own reason for the failure.
What could be the success and failure factors for the projects I experienced or heard of? There could be many. I am listing those common one I can think of for reference.
1. People expertise management;
Jack Ganssle mentioned that the best quartile engineer was 300% more productive than the lowest 25%. In fact, thinking about the investment your company has made on system integration test, post-release support, and think about the potential profit if your company win the next contract because you made good impression to your customer, the impact is not just 300%. There are plenty of talks on this, I don't need to explain any further. All I want to say is it is important to select the right people, assign them to do the right thing, and have the right process to build up expertise in short time.
Well, it is easy to say but difficult to achieve. ??!! In reality most of the project will start with a several key members, who usually have certain years of industry experience, but may or may not have the domain knowledge. While the rest of the team members may just have average programming skills.
Given the fact that most software development teams have 5 to 25 Engineers, I would assume a success project team needs to have 2 or 3 senior level members. They need to lead the project planning/execution, risk analysis and be the contact points of the project team. The project managers should have the technical expertise to do the estimation and interview new comers. In general, these 2 or 3 senior member of the team, including the project manager, would need to predict and handle potential risks also. BTW: this does not mean that more than 25 Engineers cannot work on the same product. Some giant software product team has thousands of software Engineers, like in those telecom vendors working on CDMA or GSM system. This is called project scalability. We will talk about this later.
Interview is one of the important process to find the right team members. Ask the candidates to explain what he has done in the past. The methodology is similar every where, so if the candidates can explain his past project well, there is a high chance he can do this well in the future too. Relevant experience will be helpful, but it does not mean candidates without relevant experience cannot contribute. In the software industry, C programming skill, Object oriented methodology is unique, ask him about some questions like pointer manipulation, or explain the concept of OO will do.
It will be good if the senior members of the team have the domain expertise in advance. The reality is sometimes all of the team members are new to the domain. The domain expertise build up has to be through regular brainstorming, especially at the early stage. I would suggest to reserve 10% of the project team time to do this, and 50% of the project team time during the requirement gathering and design stage. My personal preference is to start with a presentation on what is going to be done. My personal experience is after every-time I explain to others, or others explain to me, then we got some new understanding.
Software Engineers are human beings, they will need their social life. Project manager and architect have the responsibility to partition the logic and timeline, predict the risk, and communicate to the team members. If the project team members are over-relax at the beginning, work against with each other implicitly and have to work 14 hours a day, 7 days per week (actually with low productivity) at the late stage of the project, it means the project manager and architects are not qualified for their job!
2. Requirement Flow - Requirement Integrity.
What is the biggest project delay factor after the project kick-off? It is requirement integrity in my opinion. In many cases, the developers are not developing what the marketing team wants, or the testers are not testing what the development team released. In other words, marketing/development/testing team all have different understanding of the requirement.
Reserve your team bandwidth for requirement brainstorming. Setup a process for the team to discuss ideas/status regularly. I found the most efficient way is to create an online requirement management database. DOORS is a great tool, but if it is too expensive, find a cheaper one, or simply setup a Wiki page or webpage for it.
Breakdown your requirement into itemized items, and define it as specific as possible. For example, "the system can be boot fast" is not a good requirement, while "the system can be boot in 2 minutes" is the one Engineers and Testers can understand.
3. Software Architect scalability;
The philosophy of distributed development environment has no difference with distributed computing system. Let each computing node to handle computing load they can handle, all the computing nodes follow the same rule to achieve a bigger scope target. Define a scalable architect through modularity.
The success of a small project (A team with less than 5 developers) will be mainly on the team members technical expertise. As the team size grows, the success of the project will be more and more depend on architecture scalability. For example, a well defined communication system will have OS layer, device driver layer, protocol handling layer and application layer. The architecture scalability will enable difference team members to build their own expertise and work on their respective module/component independently. As the result, it is not only related to architect, but also related to project management. A poor scalable design will make the increasing of head count less efficient or useless.
It is better to support the scalable architect with certain level of modeling (like UML/FSM). Personally I like SDL-RT. The criteria is to keep your diagram active, which means you can use your diagram to do some level of code generation/verification. A model diagram with no link to code is a dead diagram. engineers will have various reasons to stop updating it and eventually the model will become useless.
4. Setup a collaborative process/make project management predictable;
When a highway is build with 3600 cars/hour (assume 1 car per second for simplicity reason) as the target throughput, the actual throughput can go up nearly linearly from 1car/hour to 3600 cars/hour, then the incremental of throughput will drop down as more cars enter the highway, eventually drop to below 3600 cars/hour and even to 0 (totally stuck), WHY? Those cars started to impact each other. If everyone follows the same rule, the traffic still can move, but if many drivers going to different direction on the road and blocked each other (unfortunately it did happen in many cities), then the road could become a big parking area.
Amazingly, there is no difference with software development. A software team with 10 Engineers seems worked fine, both the top management and internal or external customer feel happy with what they got. Subsequently, the team is expanded 3 to 4 times (sounds good business, not bad), and they must handle a codebase 3 or 4 times large scale wise, whether the scale is measured by total lines of code (poor measurement), or number of product handled, weighted number of features (anything else). but are you sure the total productivity can increase 3 to 4 times, or these 3 or 4 times more Engineer won't work against each other, instead of work with each other. With the codebase skill increase dramatically, will the defects increased exponentially as well. This is just like the highway throughput can grow up linearly as the number of cars increases to some extent, but when the car number reach certain limit, the traffic jam will happen. The government has to think about various process to handle this (ERP, COE, ...).
Setup a good coding guidelines, not only on how to indent, but also on how to define good naming convention, and deploy a tool to make automatic check. Separate your project build into build and link stage, make sure each module can be build into an object independently. It will maintain your modularity and save a lot of your Engineers build time. Setup a good SCM system (We will talk about this later).
CMMi is a common term for software process. Is CMMI too much or too simple? In my humble opinion, a success project comes 40% from technical expertise, 40% from how to make the architecture scalable, and 20% from software process. Please refer to A Light weight CMMi deployment on my comments on CMMi.
5. Software Configuration Management;
Are you release what you suppose to release? How to support parallel development? These are the questions SCM should answer.
Just as there’s more to driving than knowing how to operate a car, there’s more to
SCM than knowing how to use an SCM tool. Mastering SCM starts with understanding
how software evolves and recognizing how team collaboration, defect management,
parallel releases, and distributed development affect the software life cycle. For
just as road maps and rules of the road are the bigger part of driving, the software life
cycle is the bigger part of SCM.
In reality, a project team can only afford less than 10% effort go to SCM. Maybe it is good to start with some light SCM resources.
No comments:
Post a Comment