1 / 4

Project Charter and Visual Control in Scrum and DevOps projects | World Of Agile

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. DevOps is a set of practices that automates the processes between development team and operations team, so as to build, test, and release software or product faster.

Download Presentation

Project Charter and Visual Control in Scrum and DevOps projects | World Of Agile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. 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 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​.    For More Information, Follow the Links below-    Website - ​https://worldofagile.com/  Facebook - ​https://www.facebook.com/Fascinating.World.Of.Agile/  Twitter -​ https://twitter.com/WorldOfAgile  LinkedIn - ​https://www.linkedin.com/company/world-of-agile/  YouTube - ​https://www.youtube.com/c/WorldOfAgile      Tags - ​Scrum Master Certification​, ​Scrum Master Certification Mumbai​, ​Scrum Master  Certification Pune​, ​Certified Scrum Master Training in Delhi​, ​Scrum Master Certification  Kolkata​, ​CSPO Certification​, ​Agile Scrum Master Certification Online​, ​Advanced Certified  Scrum Master Training​, ​DevOps Training​, ​Prince2 Certification​, ​PMP Certification​,​ ITIL  Certification 

More Related