- Medium large size organizations will have a governance strategy.
- Businesses will determine their strategic objectives, leading to programs of work being identified which will enable the business to achieve its strategic objectives.
- these programs are intern broken down into projects.
Prerequisites
- Business case
- is very hard to do requirements gathering, and impossible to objectively prioritize the requirements just gathered, without a business case.
- List of stakeholders
- Most important stakeholder is the business sponsor.
- There should be only one for each project or any reasonably sized project will collapse from political infighting long before it is finished.
- Every project needs a steering committee of interested parties.
- Most important stakeholder is the business sponsor.
- The phase before production code is written.
- Requirements are gathered and analized
- Project is loosely scoped and planned
- Should be 3-6 months (with a preference for the lower limit)
- After inception phase, a go/no-go decision should be made based on
- Estimated value of the project
- Estimated costs
- Predicted risks
- The most important part of this phase is getting the shareholders together (devs, customers, ops, and management) to get a shared understanding of the problem to be solved and the way to solve it (which are the real deliverables)
- Detailed planning, estimation, or design at this stage is a waste of time and money. Broad-based decisions are the only kind of decisions durable at this stage
- The project scope will change so expect to refine and redfine the plans as you go.
Common Deliverables from the Inception Phase
- A business case, including estimated value of the project.
- List of high-level functional and nonfunctional requirements with just enough detail to be able to estimate the work involved and plan the project
- This list sohuld address: capacity, availability, service continuity, and security
- Release plan
- Schedule of work and cost associated with the project
- Estimate the relative size of the requirementes, coding effort required, risk associated with each requirement, and a staffing plan
- Testing strategy
- Release strategy
- An architectural evaluation, leading to a decision on the platform and frameworks to use
- A description of the development lifecycle
- A description of the plan to execute this list
- Duration: 2-3 weeks
Goals
- Make sure the team (analysts, managers, devs) have hardware and software to begin work
- Make sure basic infrastructure is in place - internet, whiteboard, office supplies
- Creating email accounts and assigning people permissions to access resources
- Setting up
- version control
- CI environment - basic build script and tests to get CI working
- A simle test environment and test data
- Agreeing upond roles, responsibilities, working hours, and meeting times (planning, standups, demos/showcases)
- Preparing the work for the first week and agreeing on targets (not deadlines)
- A slightly more detailed look at the intedned system design: exploring the possibilites is really the aim at this stage.
- Identify and mitigate any analysis, dev, and testing risks by doing spikes (throwaway PoCs)
- Developing store or requirement backlog
- Software is always working as demonstrated by an automated test suite including unit, component, and end-to-end acceptance tests that run every time you check in.
- You deploy working software at every iteration into a production-like environment to showcase it to users.
- Iterations are no longer than two weeks.
- By prioritizing features with highest`business value, you might find you get value quicker.
- Turn worry to excitment with early working features
- You get regular feedback from customer/sonser on what works and what requirements need clarifying or changing, which in turn means that what you are doing is considerably more likely to be useful.
- Nobody knows what they really want at the beginning of a project
- Things are only really done when the customer signs off on it.
- Having regular showcases where this happens is the only remotely reliable way to track progress.
- Having your software working at all times (because you have to showcase it) instills discipline in your team that prevents problems such as
- Long integration phases
- Refactoring exercises that break everything
- Experiments that lose focus and go nowhere.
- Iterative methods place an emphasis on having production-ready code at the end of each iteration.
- This is the only really useful measure of progress in software projects, and one that only iterative methods provide.
If you don't deploy a project iterativly, all measures of progress are subjective, and there is no way to quantify the project's actual progress. The charts are based on estimation s of time remaining and guesses at the risks and costs of later integration, deployment, and testing.