Several headaches of software development projects:
1. unstable demand !! (Top headache killer)
The customer's requirements are extremely unstable, and the customer's research methods also lead to the effectiveness and accuracy of the acquisition requirements. However, there are still relatively stable demands. According to philosophical theories, the movement is absolute and static is relative, these requirements are stable compared to a certain stage of a customer, especially when they are close to the current stage. Therefore, shortening the R & D cycle as much as possible is a very effective way to avoid demand changes. Generally, a R & D cycle is less than two months. It is best to complete an agile cycle in one month (difficult to understand ~~).
Disadvantages: if you do not have a good grasp of large projects (business framework and technical framework), it is likely to increase the workload of reconstruction, or even start from scratch! (Dual-sided blade Selection !). Perhaps: The overall planning and step-by-step implementation can alleviate this shortcoming, but in the initial stage of a project that does not have sufficient information, it's difficult (it's easy for an integrated team of industry experts and technical experts to do it ~~)??
Therefore, we need a "Short Cycle", but it does not seem suitable for large projects ~~
2. Knowledge Upgrading is fast !!
The high-speed update of technology is also very time-consuming in the Technical Selection of the project. In principle: the application is good. Maybe this technology is not advanced, but it can solve the problem well, just like using a mobile phone, as an ordinary person (non-commercial people), I only need its good call functions. As for those functions on the Internet, mobile office, games, and so on, it seems to be a top priority, however, I will choose a very common mobile phone with a good call function. This means that the above principle is used: application is good.
On the other hand, the leader in technology also has its own competitiveness (some people may say: customers do not care what technology you use, as long as they can meet the needs well, it will be OK, but it is not, if you sell a mobile phone that was produced five years ago to the customer, will it be required? Unless you give it to him. I'm afraid you won't be stupid enough to do this). Which of the following systems is more attractive to customers for Web Systems and desktop systems that offer the same functions at the same price, however, this assumption is often not true, and the cost of web system development is relatively high, so his price will also rise as appropriate.
This section does not seem to be my topic !~~~
A short period of time can also reduce the difficulty of selecting project technologies.
3. high turnover rate !!
The software R & D team, due to external reasons (too many temptations) and internal reasons (lack of management methods, no cohesion), has a non-stable structure, and the flow of personnel is a problem to face, the main way to improve this situation is scientific management methods and attractive corporate culture/prospects ..., however, a short period of time can also avoid the flow of personnel. If the stability of the person cannot be determined within two months, you may not consider using it as a project manager, however, after a long period of time (for example, half a year), there will be more variables. The so-called long-night dream, and common sense.
On the other hand, short-cycle projects can quickly see the results (the birth of a series of small versions), so that the team can continue to have a sense of accomplishment, a sense of accomplishment at the highest level of Maslow's needs. Therefore, the R & D team naturally has a considerable cohesion because it can be sustained. Isn't that what the team wants? But there will also be failures. What is the relationship? Failure is the mother of success.
Description of the minor version: the size of a software project is determined by the customer. In terms of the overall project, we must complete all the features in the contract, but in terms of project management, in order to avoid/reduce risks and respect the clear iterative nature of the project, you can divide the project into several small versions for iteration.
4. Difficult communication: thinking works !!
Communication is not easy: software products are the crystallization of thinking, and thinking is the most unpredictable. At this time, I had a very proud idea that at night, suddenly there is another very creative solution, and I will instinctively transfer my energy to the new method... Thinking is so casual and unpredictable. A person is still the same, how a team will be, how a team will be for a long time, and the variability is really hard to grasp (it is precisely because of the Infinite Creativity of thinking, will make the product more and more excellent and easy to use ). Every person in the team has an important idea, but it is almost impossible to achieve a team-less communication (I proposed the concept of extreme communication. J ). From the perspective of risk management, we can change our practices to reduce the impact of low risks. A minor version is a method. The minor version does not involve too many features, so a few or more features (two months, I can't do it anymore ~~), Complexity/difficulty is much lower, and the most difficult to communicate is the complexity/difficulty. For a small version without many features, communication reduces many obstacles. A small team is also another solution. The team's team size expansion is an enemy of communication. A team of Excellent Teams (no more than 10 members, preferably 5 to 5 ~ 7 persons) control the expansion of the communication path, and work with roles to efficiently promote the project.
Therefore, we need "small teams", "Short Cycle", and "small version ".
5 ,...
Summary:
Based on the characteristics of the software development process and the above derivation, for small (medium, small) projects, the use of "small teams, short cycle, small version" can improve the success rate of software development.