Scope and feature creep – Here is an example: Let’s say the client agrees to a requirement for a Logon page. The requirement specifies that the client will enter their userid/password, it will be validated and will allow entry upon successful validation. Simple enough. Then in a meeting just before coding is commencing, the client says to your project manager "I was working with another system last week and they send the client a report each day that shows how many people log in each day. Since you have that information already anyway, I’m sure it will only take a couple of minutes to automate a report for me that does this." Although this sounds simple to the client, it requires many different things to happen. First, the project manager has to amend the requirement document. Then the programmer has understand the new requirement. The testing team must build test scenarios for this. The documentation team must now include this report in the documentation. The user acceptance team must plan to test this. So as you can see, a simple request can add days of additional project time, increasing risk.
Gold Plating – Similar to scope and feature creep, programmers can also incur risk by making the feature more robust than is necessary. For example, the specification for the Logon page contained a screen shot that showed very few graphics, it was just a simple logon process. However, the programmer decides that it would be really cool to add a FLASH based movie on the page that fades in the names of all the programmers and a documentary on security. This new movie (while cool in the programmer’s eyes), takes 4 hours of additional work, put their follow-on tasks are n jeopardy because they are now behind schedule.
Substandard Quality – The opposite of Gold Plating is substandard quality. In the gold plating example, the programmer got behind schedule and desperately needed to catch up. To catch up, the programmer decided to quickly code the next feature and not spend the time testing the feature as they should have. Once the feature went to the testing team, a lot of bugs were found, causing the testing / fix cycle to extend far beyond what was originally expected.
Unrealistic Project Schedules – Many new team members fall into this trap. Project members (project managers, developers, testers, etc), all get pressure from customers and management to complete things in a certain time frame, within a certain budget. When the timeframes are unrealistic based on the feature set dictated, some unseasoned team members will bow to the pressure and create their estimates based on what they think their managers want to hear, knowing that the estimates are not feasible. They would rather delay the pain until later, when the schedule spirals out of control.
Poor Designs – Many developers and architects rush the design stage in favor of getting the design behind them so the "real" work can begin. A solid design can save hundreds of programming hours. A design that is reusable, allows changes to made quickly and lessens testing. So the design stage should not be rushed.
Мислех тук да преведа някои неща относно управлението на риска в софтуерните проекти и по-точно да опиша най-често срещаните рискове. След проучването и при опита да превеждам думи като schedule и estimation реших, че е по добре просто да оставя списъка на английски. Списъка го направих за мое собствено ползване, но ще се радвам ако имате какво да добавите.
Risk 1: Inherent schedule flaws
Explanation: Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule.
Waltzing…Solution: Get the team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders.
Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP’s planning game and Wideband Delphi workshops. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, the true progress is hard to hide and quickly revealed, giving feedback to the stakeholders.
Risk 2: Requirements Inflation
Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines.
Waltzing…Solution: Constant involvement of customers and developers.
Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilising change-suppression mechanisms, prioritisation sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorisation. It has never been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages.
Risk 3: Employee Turnover
Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project.
Waltzing…Solution: Increased collaboration and information sharing on the team.
Agile Practice: Agile projects practice information sharing techniques such as pair programming, common code ownership, and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small. Also, often overlooked, is the fact that when working in an engaging, rewarding, empowered, collaborative environment such as agile projects, people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced.
Risk 4: Specification Breakdown
Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.
Waltzing…Solution: Use a dedicated Product Manager to make critical trade off decisions.
Agile Practice: Agile projects utilise the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion.
Risk 5: Poor Productivity
Explanation: Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained.
Waltzing…Solution: Short iterations, right people on team, coaching and team development.
Agile Practice: Agile methods recognise Parkinson’s Law and the Student Syndrome apply to software projects. Parkinson’s Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly here before starting work." By having short iterations, work is timeboxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on team, coaching and team development, but these are core leadership roles applicable to both agile and traditional projects.
5 most common scheduling risks in a software development project: