Project Charter and Visual Control in Scrum and DevOps projects | World Of Agile
Determining Project Scope
The most important part of creating a Project Scope is for the application stakeholders to meet up during the project planning process. The point of stakeholder discussion should be working out a common understanding concerning the deployment and maintenance of the application throughout its lifecycle. This shared understanding is then captured as a release strategy. This document will be updated and maintained by the stakeholders throughout the application life. This document is called Release Strategy which forms the fundamental element of the Project Charter. When creating the first version of your release strategy at the beginning of the project you should consider including the following :
· Parties in charge of deployment to each environment as well as in charge of the release
· Asset and configuration management strategy
· Technology descriptions
· Plan for the implement deployment pipeline
· Enumeration of the environments available for integration, acceptance, capacity, etc
· Processes to be followed for deployment into various environments.
· Requirements for monitoring
· Management of Runtime configuration
· Integration with internal and external systems
· Details of Logging
· Disaster Recovery Plan
· SLA structure
· Production sizing and capacity planning
· Archiving strategy
· Initial deployment strategy
· Applying patches
· Applying Upgrades
· Managing application support
The art of creating a release strategy is useful. It will usually be a source of both functional and non-functional requirements for both software development, design, configuration and commissioning of hardware environments.
Let’s talk about the Release Plan
The first release is usually the one that carries the highest risk. It needs careful planning. The results of this planning may be automated scripts, documentation or other procedures needed to reliably and repeatedly deploy the application into the production environment.
Visual Controls (Very Important for tracking)
Visual Controls are used for transparency purposes in DevOps. A term commonly known for Visual Controls is Information Radiators. They are meant to display information at a public place so that the information can be noticed by as many people as possible without making a conscious effort to do so. Visual Controls should display the current information about the project whatever is critical for the team to learn. It could include Schedule, tasks, issues, progress, etc.
The most common forms of Visual Controls are
· Task Boards or Kanban Boards
· Big Visible Charts such as BurnDown Charts
· Street Lights and Lava Lamps
· Characteristics of Visual Controls which make them work:
Simplicity: They should be simple to read and understand
Stark: Should display the progress and expose problems. Errors should not be masked, instead, they should be used to improve performance.
Current: Information should always be current. The artifacts should be updated frequently.
Transient: The information should not be there on the chart for too long. Once the problem is rectified, it should be removed from the chart or board.
Influential: The information displayed should help the team to take actions and decisions.
Visible: The information should be easily visible. There should be no special effort to see the information.
Minimal Information: The information should be sufficient but minimalistic.
Task boards or Kanban Boards
In its most basic form, a task board can be drawn on a whiteboard or even a section of the wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.
The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each sprint to reflect the sprint plan. point in showing a truckload of information.
Cumulative Flow Diagram
Cumulative Flow Diagrams are a wonderful tool to see trends and find bottlenecks in your delivery process. They are often used in DevOps environments.
Consider the example of a Website Development Project below. You will see a graph below. It shows the number of user stories in each of your status categories, for the time period you have selected. If you draw a horizontal line at any point on this graph you will see a snapshot of your User Stories on a given date (how many with status “Done,” “TO-DO,” “Testing,” etc.). So the CFD is really just a picture of your user stories by status over time. But this picture can tell you a lot about your development process.
Burndown chart
Burndown chart is a good information Radiator which represents data quickly in a chart format. A sample burn-down chart for a completed sprint, showing remaining effort and tasks for each of the sprint is shown above. The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.
There are different types of burndown, for example
· The release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple sprints) and the alternative release burndown chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
· The Sprint burndown chart that shows the amount of work left in a Sprint to achieve a Sprint goal.
