Most software developers instinctively believe that the project manager wants to ensure that the project is completed on time is at odds with achieving high-quality software. It's not because project managers don't want high-quality software, they just want to implement it on time and under or under budget based on quality. Their efforts can be successful in reducing cost and development time without compromising quality, however, they may overuse these techniques.
While the following project management techniques are at least meaningful, and in some cases even respected, they all have the potential to be catastrophic.
Time boxing
On the list of events that destroy software quality, the application of timeboxing comes first, when you tell someone how much time he has to complete a task before it has to be handed over, I say "handover" instead of "done" ”, because in extreme cases that often means that the code isn’t perfect, and it’s just a matter of getting the job done.
In most cases, timeboxing works because it does four things:
1. It forces developers to be creative in finding solutions within their budget.
2. It eliminates unnecessary frills that are often added to software that often do not add value to the software.
3. It prevents developers from over-testing.
4. The purpose is just to get this product. There will be detailed tests in the complete quality assessment (QA) stage, hoping to find problems in the code during this stage.
When there are unknown problems, or the technology has not been tested, or there is no correct way to test the results, the time box is powerless; when the time box is small and there is no possible way to achieve the goal within the allotted time , this method is also invalid. In other words, time-boxing works well for some problems, such as fully understanding, carefully evaluating, and performing tasks; however, there are also problems that time-boxing methods do not do well, such as research and development, and problem solving etc.
If timeboxing is used correctly, it shouldn't result in testing bad code that can lead to hundreds of hours of diagnostics and rework. Timeboxing should be used in moderation to ensure the lowest cost, fastest and highest quality software.
delayed
All have goals to strive for, and milestones are a respected method of motivating people toward the same goal, a drive that can lead to significant results in a very short period of time. However, everyone must acknowledge that milestones are not achieved every time, and new decisions must be made.
Project managers must set milestones on the team to motivate them to move forward, but when milestone dates are unrealistic and team members keep making mistakes, it's time to reevaluate the plan. If a special circumstance can make the date no longer important, then when the important date does come, the whole team will have little incentive to achieve the milestone date. When the entire team misses 10 dates in a row, does the 11th date matter? It's like a child shouting "The wolf is coming".
If there is no penalty after the set timeline, then the entire timeline should be enforced or moved when that time is missed.
Creating a constantly stressful and confusing environment doesn't make good software in the long run, developers need environments where they can concentrate on their work. Project completion dates and confusion about whether milestone dates are real often lead developers to skip key steps in the development process or create hard-to-find issues.
Pretend there are no mistakes
In project management, neglect is not a blessing. In order to successfully complete the project, in addition to unstoppable political pressure, it is necessary to introduce the risk of the project to other employees of the company. Almost every software development project is at risk of being delayed or over budget or both.
The problem is that at some point at the end of the day, when these risks actually materialize, there will be panic, everyone is assembling the rest of the project in chaos, and the quality of the entire project will suffer from the eventual rash assembly. .
Of course, this problem will not be fully exposed until the entire project is not behind schedule, however, most projects have a way of leaving only parts of the project behind by a little bit, and almost every project is too hasty risk because management knows the true state of the project for a long period of time after the project is free of any problems.
ignoring relevance
In software development there are many tricks we can use to delay dependencies, we can disable some functions, move connected infrastructure, or bypass numerous error handling, all of these tricks can help when used correctly Moving forward with a project, however, sows the seeds of trouble when the cost of these techniques is not factored into the overall plan in order to complete the project.
A lot of times, arranging the order of software development in a project is very challenging, the correlation is not easy to find, so it is inevitable that many related factors are not arranged in the plan. Scheduling these unforeseen dependencies can get crazy, so methods of suppressing dependencies are often used, but if these techniques are overused, these costs can often become a significant part of the total project cost. part of it and will not be discovered until the end of the project.
So be confident that what you're doing now is necessary to manage dependencies, doesn't add undue cost, and is an integral part of the overall software development project. When project managers cannot balance cost with the convenience of reducing relevance, the code they sloppily assemble will exhibit quality problems.