Report on Project XI have heard of this project since the second half of 2005. It is a large-scale project involving more than 10 cities in total, includes the data conversion of legacy systems, the survey of new system requirements, system design, system development, system testing, system implementation, and other processes. I officially entered this project in March 2006. At the beginning, I was working on the functional part of a business system. Later, I made the Interface part of the business system and other systems, during which I made two or three projects. The system architecture basically copies the systems in other places and adds some of its own things. After one year of development in, the system has been launched in two cities since the beginning, there are many and varied problems, which make people very tired. The background is introduced here. The following lists some problems and ideas in the projects I have seen. Rankings are not sequential. If there are similarities, it is a coincidence. :) Symptom 1: iterative waterfall development. At the beginning of the project, it is clearly required to adopt the RUP method and implement iteration. Each iteration can also be seen in the plan, but there are only four iteration cycles in one year. For example, if there are 100 modules, there are 25 modules in each iteration, And the integration test and performance test are performed in the last iteration. So I call it "iterative waterfall development ", this laid the groundwork for functional and performance problems in some later functions. The power of iteration is not reflected. Fierce Medicine 1: brainwashing + money deduction, brainwashing from top to bottom in the project, and pay attention to regular checks to prevent returning to the old road. Symptom 2: castle in the air. The database structure of this system is dug from other places, and there is little compromise on the needs of this project after the digging. Let's talk about the demand. There is only one requirement in this project. The research time is short, but it needs to adapt to various situations in multiple cities. So the final result is plausible, this is extremely obvious when the system goes online. demand volatility changes and Requirement documents are garbage-based. Mengyao 2, demand research is the system direction, and the direction is incorrect. How can we achieve a good result. The diversity of requirements is directly proportional to the complexity of the system. To meet the needs of various cities, it is necessary to have a thorough understanding of the differences between different cities and conduct comparative screening. I have always had a point of view on demand research. The demand research personnel should not just be in a meeting, hoping to get the user's needs from the meeting and dream about it. If you do not really participate in the daily work of the user, how can you know what the user really needs and give him some professional advice. Symptom 3: crossing the river with stones and walking steel wires. Such a large project has many functions and is not guaranteed by unit tests. In response to frequent changes, developers often submit the project to the site after completing a simple test, you can imagine. Fierce medicine 3, real iterations + daily build. Symptom 4: communication or communication. The developed system is implemented by dedicated personnel, but the problem arises, and the implementer's understanding of the system is even inferior to the user's. As a result, developers are stuck in the field. Mengyao 4: Training with assessment + Responsibility Education + stress education. Symptom 5: attack in groups. This system is very large, and there are more than 10 interfaces with other external organizations, but these interfaces follow only one specification, which is naturally easy to develop, however, in the passive work situation, different places and different organizations will not unify this unique interface solution. Fierce drug 5 should not shy away from demands, but avoid the real needs of users. There are no universal demands, unless they are not explained in other words. It is better to take the initiative to attack the enemy. Symptom 6: A building built on the sand. Data is a sufficient condition for the legacy transformation system to run happily. When data is inaccurate or even exposed, the program will bear the brunt of being a victim. The data conversion of this system lasted for one year, and the effective conversion time was one to two months. No complete test was conducted until the system was launched. Meng Yao 6, test it. What else can I say. Symptom 7: We are comrades-in-arms, not enemies. Each component and user in the project are mutually beneficial and should not be an enemy. They are always honored and damaged. The components of the project come from all over the world, and people are floating in the rivers and lakes. How can this problem be avoided. Mengyao 7 strengthens team spirit and creates a "Frozen team ". Some of my own experiences have been mentioned above, and some other symptoms will not be nonsense here. Different projects should have different necessary and sufficient conditions, but they should include the following items (I wrote them as I thought, and there is no sequence ): l Goals recognized by everyone l build a strong sense of honor and responsibility L Culture and Core Spirit of the project team l excellent processes and methods L execution ability wonder 2007-6-1 wish all the children and will soon become children happy little babies! Hope that each of you can have your own gift.
