vault backup: 2025-01-13 10:58:58
This commit is contained in:
@@ -610,8 +610,45 @@ The final preparations should be started when architecture design is nearly fini
|
||||
- perform ongoing planning activities
|
||||
|
||||
#### Project Estimates
|
||||
The goal is to estimate effort, cost and schedule. This should be done by the most experienced perso
|
||||
The goal is to estimate effort, cost and schedule. This should be done by the most experienced person doing similar work or an expert estimator.
|
||||
> [!NOTE]- Fibonacci based estimation of effort
|
||||
> [[Martin Albrecht|Martin]] told me about their estimation procedure, where they use fibonacci numbers for estimating efforts of features or user stories. It is difficult to say if something takes 8 or 9 days, but if something takes 1, 2, 3, 5, 8, 13, 21 days is much easier.
|
||||
|
||||
Apart from the obvious activities such as architecture, coding, general planning, user documentation, etc. there are less obvious activities that should be accounted for:
|
||||
- interaction with customers/end users
|
||||
- reviews
|
||||
- fixing problems during reviews
|
||||
- maintaining things like:
|
||||
- revision control systems
|
||||
- daily build scripts
|
||||
- technical training
|
||||
- holidays, vacations and sick days
|
||||
- answering questions from QA and documentation
|
||||
|
||||
Including those less obvious activities is important in order to be more accurate with your time planning. Because if the time plan is really far away from reality, the team stops taking the goal seriously which decreases productivity.
|
||||
Don't plan with the team doing overtime. This can be a reserve if the project falls behind or something similar.
|
||||
Oftentimes with troublesome projects the developers say that the estimates are unrealistic from the start. Lack of buy-in from developers is at best a warning sign that the goals are unachievable. At worst, it indicates an adversarial relationship between developers and management, which comes with many more problems.
|
||||
Redoing the estimation work is crucial. It shows flexibility and will be more accurate the more the team learns about its progress. Further it is important to keep estimates under change control.
|
||||
|
||||
#### Milestone Targets
|
||||
The team should use the estimates from above to put due dates for important milestones such as completing the architecture, completing the stages, and releasing the software.
|
||||
|
||||
#### Staged Delivery Plan
|
||||
The most important functionality is delivered first. The staged delivery approach doesn't reduce the actual development time, but it reduces the development time that is perceived. Every stage that is completed and celebrated makes people feel the success and thus the ultimate goal seems closer. The architecture needs to be build such that staged delivery is possible.
|
||||
Not every stage necessarily needs to be shipped to the customer. Maybe only the 4th stage will be shipped, because the stages before that are too simple. Nonetheless, the simpler stages help in having a good development approach.
|
||||
|
||||
|
||||
> [!question] Survival Check - Final Preparations
|
||||
> - 👍🏼 The project team creates its first estimate after preliminary requirements development is complete.
|
||||
> - 💣 Estimates do not account for normal activities such as holidays, weekends, and vacations.
|
||||
> - 💣 Developers don't believe the estimates are realistic.
|
||||
> - 👍🏼 Estimates are updated after detailed requirements development and again after architectural design.
|
||||
> - 👍🏼 The project has a Staged Delivery Plan that organizes the stages into theme releases.
|
||||
> - 💣 The stages are not defined in detail.
|
||||
> - 👍🏼 The project's risk-management, vision, decision-making, and personnel plans are up-to-date.
|
||||
> - 👍🏼 The project's Software Development Plan is up-to-date and is being followed.
|
||||
|
||||
### Beginning of Stage Planning
|
||||
|
||||
|
||||
---
|
||||
@@ -634,11 +671,25 @@ The goal is to estimate effort, cost and schedule. This should be done by the mo
|
||||
- Quality Assurance Plan
|
||||
- defect report template to be used to report defects (see page 130)
|
||||
- review checklists for different parts
|
||||
- Software architecture plan (less than 100 pages, diagram heavy)
|
||||
- Staged Delivery Plan
|
||||
## Tool list
|
||||
- Anonymous risk-reporting channel
|
||||
- time tracking (helps for future estimating practices)
|
||||
|
||||
## Review List
|
||||
- Review Top 10 Risks every 2 Weeks (see page 97)
|
||||
|
||||
## Checkpoints
|
||||
- reestimates of the schedule and cost
|
||||
- during preliminary requirements development
|
||||
- during detailed requirements development
|
||||
- during architectural design
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Software Project Survival Guide Steve McConnell
|
||||
|
||||
Reference in New Issue
Block a user