Problems in current project development management

The first problem is the project development schedule.

The time schedule for detailed design documents and codes is too short. It is obvious that the software only uses the design and code of the previous version for some porting work, so it is a little time. In this case, there is really little time left for refactoring, the code is too bad, and you want to refactor it, but the progress is so tight, it forces developers to fail to use an old framework that has been patched for thousands of times, rather than rewrite it completely.

 

The second problem is agility.

I learned only frequently-released documents, drive developers to frequently publish versions, and do not assign a relatively long time for developers to refactor.

 

The third problem is the original source code management method.

The source code management tools used are popular SVN, but they do not have the basic spirit of source code management tools: collaboration, source code change management, and branch management. It is simply the most primitive and simple management method, where the source code is constantly copied to a version number. Problem 1 the code of each part of the system is stored on different servers. The code checkout from a single server is incomplete and cannot be compiled. This is a small problem, I can't go through the checkout of each part separately. What's worse is that problem 2 developers only have the access permission on the server where the part is in charge. You can't go out of other part of the code in checkout; question 3: only one to two times of commit code is given each month. One or two days each time, except for the past few days, developers can only manage their own code. Where is the tmd svn, it is better to discard SVN and use the original copy code method. Of course, developers have their own countermeasures and establish code management services for themselves or groups. This problem has greatly promoted the source code management capabilities of some developers, SVN, git, bazaar, and other tools are easy to use. (TIPS: If SVN is used in the project, you can use two tools for the same set of code using a non-SVN tool at the same time)

 

The fourth problem is change management.

The change management tool is the best combination with the source code management tool, but the company's change management tool (simply copied by CQ itself) cannot be associated with SVN. To manage the changes, you can only manually enter the information for contact on different systems. For example, you can manually enter the details of the change implementation activities in the comments when submitting code, at the end of the change implementation activity, manually enter the svn revision number at the time of code submission and other details. This is not a project issue. It is a company issue. It is a copy of the fur, and there is no copy of the soul of the configuration management tool. CQ is associated with CC. You copied CQ, but it cannot be associated with your SVN. Isn't it a tough task? Why are you copying CQ, instead of copying Bugzilla (which can be integrated with SVN), Bugzilla is not called plagiarism. People are open-source and called secondary development. If you don't sell or release the product, you just use it for your own use. You don't have to pay too much attention to the copyright agreement, is it because you need to respect the protocol? Are you afraid of open source? What's terrible about this? Your development of Bugzilla can only be called non-verbal localization work. People may not necessarily look at the features you developed again.

But you can do it manually. You pay for my time (unfortunately, my time can be more useful ). Because of the third question mentioned above, the project can only submit code once or twice a month. The typical change management process cannot be completed, verification of change implementation activities is carried out on the servers of individual developers or groups. Wait until the TMD change activity is completed and the code is submitted once a month. However, if there is a problem, some people who are not familiar with the change management will complain about the change management process. You have not been able to fully implement the change management process. The third question is intolerable.

 

Fifth problem: blind platform of software projects

If we think that platformization is an artifact or something, at least we are complaining about it now. Product Development is delayed. (fortunately, our software developers are all gods, and we are still working in such a bad environment ). If you provide a software platform, our product department is willing or unwilling to do so. In fact, there is a good ecosystem for reference here. There are a wide variety of Linux and release versions. The software platform code you developed is just a product (similar to the Linux release version, such as Debian) if my products are willing to use your things, I will use them. If I do not want to use them, I will not use them. This is like Debian using the Linux kernel released by Linus, the BSD kernel, and even the Hurd kernel. For example, for the desktop, Kde and gnome are the most commonly used desktop systems in Linux distributions, and xfce also exists on the desktop. The forthcoming Ubuntu 11.04 version will adopt the unity shell, it should be developed based on gnome.

With these references, the relationship between the software platform and the final product is actually very good. After the software platform project delivers the code, the product project can decide to use the specific version of the platform code, then, you can freely modify the platform code. Unless the product is unwilling to follow the platform upgrade, the product project generally does not significantly modify the platform code. However, the product maintenance team must be given the right to decide the platform code of a specific version, which modules of the platform code should be used, and any modifications to the delivered platform code should be made.

To understand this, we can tentatively set the platform code to the main branch, and the code of each product is also another branch that is derived from the main branch and is constantly evolving. Similar to the release method of the Linux release.