CD.md

Project Lifecycle

Identification

• 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.

Inception

• 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

Initiation

• 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

Develop and Release

Basic conditions for an iterative process

• 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.

Reasons for using an iterative process

• 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.