Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Agile Technology Delivery Process Mr
Similar a Agile Technology Delivery Process Mr (20)
Agile Technology Delivery Process Mr
- 1. Agile Development By Murray Robinsonwww.linkedin.com/in/murrayrobinson Copyright and Intellectual Property retained by Murray Robinson. 1
- 2. Copyright and Intellectual Property retained by Murray Robinson. 2 What is Agile Development? Agile development is a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between cross-functional teams Agile development is a well defined delivery process that has been proven to reduce time to market, delivery risk and costs for many organisations and projects. Agile development applies “Lean Production” principles and techniques to software development Agile development can give us a sustainable competitive advantage by allowing us to deliver quality IT systems faster than our competitors at a lower cost 2
- 3. Copyright and Intellectual Property retained by Murray Robinson. 3 Agile Development is a family of lean, iterative software development methodologies Lean Production RUP Scrum FDD Iterative OOD TDD Design Patterns Continuous Integration XP
- 4. Copyright and Intellectual Property retained by Murray Robinson. 4 In Agile projects requirements are delivered in priority order in a series of small fixed iterations Iteration 4 Iteration 3 Iteration 2 Iteration 1 System Component A 4
- 5. Copyright and Intellectual Property retained by Murray Robinson. 5 Agile projects deliver high value features early! 75% Business Value Release Iteration 5
- 6. Copyright and Intellectual Property retained by Murray Robinson. 6 Agile project progress is clear and predictable Velocity Iteration 6
- 7. Copyright and Intellectual Property retained by Murray Robinson. 7 Agile implementation plan Seek Executive support and funding for an Agile change Management Project Define Agile processes and deliverables in detail Apply Agile in a trial project Seek Quality Group endorsement for Agile Develop an Agile training program Launch Agile 7
- 8. Problems with a traditional sequential system engineering process
- 9. Copyright and Intellectual Property retained by Murray Robinson. 9 The problem from the business point of view IT projects take much longer than the business want IT projects cost much more than the business expect IT can’t commit to budgets and delivery dates until the start of build IT don’t understand the user experience The business are expected to sign off requirements and design when they’re not sure their completely right IT make it very hard to make changes during the project Fixed price, time and cost projects are anything but IT Projects often have major cost and schedule blow outs which require major scope reductions or budget and time increases to bring them back on track IT infrastructure seems to be a major source of project delays and problems 9
- 10. Copyright and Intellectual Property retained by Murray Robinson. 10 10 The problem from the IT point of view Business set unrealistic budget and schedule targets up front before IT know how long things will take and how much they will cost Funding approval is a very slow process Business take a long time to sign off requirements and design Business constantly change requirements Business wont prioritise requirements unless project goes off track Business don’t understand that IT projects are complex and high risk Vendors and infrastructure groups need very close management to ensure delivery Major IT project blowouts are often caused by infrastructure delays IT projects are dependent on infrastructure and other projects which may run very late
- 11. Copyright and Intellectual Property retained by Murray Robinson. 11 A sequential system development process has many handoff’s 11
- 12. Copyright and Intellectual Property retained by Murray Robinson. 12 Handoff’s between groups cause a lot of wasted time and effort 12
- 13. Copyright and Intellectual Property retained by Murray Robinson. 13 A sequential project wrongly assumes that the business knows all the requirements in detail up front 13
- 14. Copyright and Intellectual Property retained by Murray Robinson. 14 14 A traditional sequential project can take a long time to deliver business benefit
- 15. Copyright and Intellectual Property retained by Murray Robinson. 15 Sequential Projects deliver value at the end.Agile projects deliver value earlier
- 16. Copyright and Intellectual Property retained by Murray Robinson. 16 Waterfall project assumptions are not realistic
- 17. The Agile Development Process in More Detail
- 18. Copyright and Intellectual Property retained by Murray Robinson. 18 Agile Assumptions Systems grow and evolve over time Stakeholders can’t fully define what they want until they see it Business requirements change as the market changes All IT projects have to trade off scope against time, budget and quality The risk of project failure increases linearly as the size of the project increases There are always a lot of unexpected business and technical issues that must be resolved as you go along Most delays and waste are caused by handoffs from one group to another There are substantial communication delays and costs when teams are separated by organization, location and culture Co-located, Cross functional project teams resolve issues much faster than specialized functional teams in separate locations The best way to reduce delivery risk is to integrate and deliver as often as possible 18
- 19. Copyright and Intellectual Property retained by Murray Robinson. 19 The Agile Manifesto In Agile projects we value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 19
- 20. Copyright and Intellectual Property retained by Murray Robinson. 20 Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Working software is the primary measure of progress.
- 21. Copyright and Intellectual Property retained by Murray Robinson. 21 Agile Principles The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
- 22. Copyright and Intellectual Property retained by Murray Robinson. 22 Agile Development applies the principles of Lean Production to software development Eliminate waste Amplify learning Keep your options open Deliver as fast as possible Empower the team Build integrity in Optimize the Whole Put the customer first Continually Improve the Process 22
- 23. Copyright and Intellectual Property retained by Murray Robinson. 23 Agile uses the Plan, Do, Check, Act cycle in every iteration
- 25. UserID
- 26. First Name
- 27. Last Name
- 28. …
- 29. Methods
- 30. View
- 31. Edit
- 33. UserID
- 34. ProductID
- 35. Status
- 36. …
- 37. Methods
- 38. View
- 39. Edit
- 41. User Name
- 42. …
- 43. Methods
- 44. Validate
- 45. Create User View
- 47. User name
- 48. …
- 49. Methods
- 50. Display
- 51. Validate
- 52. Update
- 54. ProductID
- 55. Product Name
- 56. Setup price
- 57. Annual price…
- 58. Methods
- 59. View
- 60. Edit
- 61. …24
- 62. Copyright and Intellectual Property retained by Murray Robinson. 25 Agile Projects use co-located cross functional teams to minimize handoff delays Team Lead / Scrum Master SME / Business Analyst Architect / System Designer Team members play multiple roles Test Analyst UI / Component Developer DBA / Sys Admin / Network Eng 25
- 63. Copyright and Intellectual Property retained by Murray Robinson. 26 Overall Agile Funding Process Fund Solution Delivery Fund Solution Vision 26
- 64. Copyright and Intellectual Property retained by Murray Robinson. 27 Solution Vision Solution Vision Plan Initial Use Case Model Initial Object Model Initial System Model Initial UI Design Concepts Product Roadmap Initial Prioritised Feature List Project Estimate Business Case Initial Project Plan Solution Vision Lessons Learned Solution Vision Process Changes
- 65. Copyright and Intellectual Property retained by Murray Robinson. 28 Solution Delivery Iteration 1 Iteration 2 Iteration 3 Iteration 4 Analysis & Design Analysis & Design Analysis & Design Analysis & Design Design, Build & Test Design, Build & Test Design, Build & Test Design, Build & Test UAT & Deploy UAT UAT & Deploy UAT Release 1 Release 2 Agile projects deliver batches of features in short, regular iterations 28
- 66. Copyright and Intellectual Property retained by Murray Robinson. 29 Iteration Analysis & Design Iteration Plan Iteration Use Cases Iteration Activity Diagrams Detailed Feature List Iteration Graphic Design Iteration Class Diagrams Iteration System Model Iteration Wireframes Iteration System and Acceptance Test Cases Iteration Test Plan Iteration Lessons Learned Iteration Process Changes
- 67. Copyright and Intellectual Property retained by Murray Robinson. 30 Iteration Design & Build Updated Iteration Plan Updated Feature List Automated Xunit Tests Automated Regression Tests UML Sequence Diagrams UI Code Object Oriented Code Technical Proof of Concept Test Results Progress Charts Iteration Lessons Learned Iteration Process Changes
- 68. Copyright and Intellectual Property retained by Murray Robinson. 31 Each iteration each agile team pulls the top priority items off the feature list High level features Detailed features Built & tested features Deployed features Component team 1 Deployment team Analysis & Design team Component team 2 31
- 69. Copyright and Intellectual Property retained by Murray Robinson. 32 The Feature list 32
- 70. Copyright and Intellectual Property retained by Murray Robinson. 33 Agile Teams have a Daily Cycle 33
- 71. Copyright and Intellectual Property retained by Murray Robinson. 34 Agile Change management is fast and efficient If a change is a top priority it can be analyzed in one iteration and delivered the one after. 34
- 72. Copyright and Intellectual Property retained by Murray Robinson. 35 Agile deliverables are lean, visual and iterative Project Management Business Analysis Product Management Design and Build UI Design Testing Use Case Model UML Object Model UML System Model Product Roadmap Release Plan UI Concepts Test Plan Prioritised Feature List Project Budget Business Case Graphic Design UML Class Diagrams List of Test Cases Technical Proof of Concept Use Cases UML Sequence Diagrams Project Plan System and Acceptance Test Cases Automated Xunit Tests Comm’s Plan Wireframes Automated Regression Tests UI Code Object Oriented Code Technical Proof of Concept UML Activity Diagrams Progress Charts Training Package Test Results Deployment Package Comm’s Package 35
- 73. Copyright and Intellectual Property retained by Murray Robinson. 36 Senior Management play a critical role A fast moving agile project will reveal many blockages in the organisation that are slowing progress for all teams Senior management need to ask their agile teams everyday “what blockers are you having that you can’t resolve yourself” Management should focus on removing these blockers as soon as possible at the root cause level Often the best way to solve these problems is to move specialists from different groups and organizations into co-located, cross functional project teams And to streamline business processes to minimize queues of work
- 74. Copyright and Intellectual Property retained by Murray Robinson. 37 Business Benefits of Agile Delivers high priority requirements to market in months Removes a lot of delays and overhead from the process Allows us to commit to a fixed budget and schedule early Projects can get to a funded business case sooner Allows lots of early feedback from users Doesn't require the business to sign off everything up front Easy to make high priority changes during the project Provides a predictable delivery speed and cost 37
- 75. Copyright and Intellectual Property retained by Murray Robinson. 38 IT Benefits of Agile Allows IT to commit to a fixed budget and schedule early Funding is quicker and easier to manage Ensures signoffs are done quickly and regularly Handles requirement changes quickly and easily Ensures requirements are prioritized properly every month Ensures that issues are found and resolved early Cross functional teams bring the different groups much closer together Reduces project dependency issues 38
- 76. Copyright and Intellectual Property retained by Murray Robinson. 39 Criteria for Agile projects Use an Agile scorecard to determine if projects are suitable for Agile development Implement strategies to address issues that might block Agile development. For example if the team has no Agile experience, the vendors methods are hostile to agile processes and the customer is largely unavailable then it would not be a good candidate for Agile development We can address these issues by bringing on an experienced Agile coach, changing to a vendor whose methods support agile development and getting the customer to appoint a full time product manager/ BA 39
- 77. Copyright and Intellectual Property retained by Murray Robinson. 40 Agile Scorecard
- 78. Copyright and Intellectual Property retained by Murray Robinson. 41 A Documented Agile Process can be Methodology compliant Compliant with PMBOK v4 Compliant with TQM processes Compliant with ITIL 3.0 Compliant with CMMI 41
- 79. Copyright and Intellectual Property retained by Murray Robinson. 42 Agile Definitions
- 80. Copyright and Intellectual Property retained by Murray Robinson. 43 Agile Definitions
- 81. Copyright and Intellectual Property retained by Murray Robinson. 44 Scrum Process Summary
- 82. Copyright and Intellectual Property retained by Murray Robinson. 45 Acceptance Test Driven Design & Development Automated Unit Tests Add a unit test Run test Pass Fail Refactor code Change code Automated UI Tests Automated Acceptance Tests User Story Acceptance Criteria Automated Performance Tests Exploratory Testing
- 83. Agile Structure for Large Projects with Offshore Vendors
- 84. Copyright and Intellectual Property retained by Murray Robinson. 47 Large projects are divided up into components which are delivered by small agile teams of 7 people Component team 1 Component team 7 Component team 2 Management team Analysis team Onsite team Product team Testing team Design team Component team 3 Component team 6 Common Component team Infrastructure team Component team 5 Component team 4 Agile component teams synchronize by contributing members to cross functional project teams.
- 85. Copyright and Intellectual Property retained by Murray Robinson. 48 A large project team is organized by feature set and function 48
- 86. Copyright and Intellectual Property retained by Murray Robinson. 49 Agile projects have a stable resource profile Vendor Build & Test Team Vendor design team IT project team Business project team 49
- 87. Copyright and Intellectual Property retained by Murray Robinson. 50 Offshore teams have onshore representatives who liaise with other onshore teams on their behalf 50
- 88. Copyright and Intellectual Property retained by Murray Robinson. 51 Vendors are engaged on a capped T&M with a constant resource plan and fixed price per month 51 51
- 89. Copyright and Intellectual Property retained by Murray Robinson. 52 Related Agile projects are synchronized by a fixed release calendar Project 1 Project 2 Project 3 Synchronized release 52
- 90. Appendix
- 91. Copyright and Intellectual Property retained by Murray Robinson. 54 Strengths and weaknesses of a well defined systems engineering process Strengths Weaknesses Well defined process Enforces that a consistent system development process is followed Can be tailored Provides deliverable templates Provides a training program Has a Quality Governance framework Regular quality audits Agreed and understood by most users Most projects that use the standard process deliver something Sequential process that takes much longer and costs far more than the business want Heavy documentation overhead Very resistant to change Lots of delays for reviews and approvals Requires a big up front design effort when our knowledge is poorest Many projects have major cost or schedule blow outs and have to reduce scope to get back on track Lot of wasted time and effort designing things that are changed or de-scoped The critical build process is often a black box 54
- 92. Copyright and Intellectual Property retained by Murray Robinson. 55 Agile development is based on an iterative development process. Iteration 1 Iteration 2 Iteration 3 Iteration 4 In an ideal process the agile team does all SDLC activities during one iteration Requires a very experienced, co-located, cross functional team onsite Analysis & Design Analysis & Design Analysis & Design Analysis & Design Build & Test Build & Test Build & Test Build & Test UAT & Deploy UAT UAT & Deploy UAT Release 1 Release 2 High priority scope changes can be implemented in 1 iteration 55
- 93. Copyright and Intellectual Property retained by Murray Robinson. 56 Solution Delivery Iteration 1 Iteration 2 Iteration 3 Iteration 4 Analysis & Design Analysis & Design Analysis & Design Analysis & Design Build & Test Build & Test Build & Test Build & Test UAT & Deploy UAT UAT & Deploy UAT Release 1 Release 2 Agile projects deliver batches of features in regular, short iterations 56
- 94. Copyright and Intellectual Property retained by Murray Robinson. 57 Sometimes the testing is done one iteration afterwards Iteration 1 Iteration 2 Iteration 3 Iteration 4 A slower more cautious approach Analysis & Design Analysis & Design Analysis & Design Analysis & Design Build & Test Build & Test Build & Test Build & Test UAT & Deploy UAT UAT & Deploy UAT Release 1 Release 2 High priority scope changes can be implemented in 3 iterations 57
Notas del editor
- System Components grow each iteration until all the priority requirements are deliveredThe core enabling requirements are built first then the critical high priority requirements, then the medium priority requirements etc.It is important not to over engineer the component to meet all possible needs as the medium and low priority requirements may never be delivered.
- You can rank the requirements in a software project in order of priority. Often a project does not know all the requirements or their business value at the start of a projectIf a high value requirement is discovered during a project it can be quite hard to fit in.Sequential projects deliver all the requirements in one big bangAgile projects deliver the high value requirements in order of priority each release until the business decides to stop the project or funds run out.Scope is flexible in Agile projects.
- Initially teams may over or underestimate the amount of work they can do in an iteration but over time they become accurate.
- A sequential process requires us to define the solution in detail, up front, when our knowledge of the requirements and solution is poorest. In reality many requirements change during the course of the project as the business discovers what they really want.This same is true for the architectural solution. While it may seem that we can define the full technical solution up front typically many major technical issues arise during the project which must be solved at the time. This is also true if you are deploying a software package. Often the team software package is a much poorer fit to the requirements than expected at purchase leading to a much larger amount of customization than expected. Also the vendor team often has much less experience with the software package than expected leading to a lot of problems later on.We would be much better off if we defined a guiding architecture and deferred detailed solution decisions until the last possible, responsible moment.Because of all these unknowns software development is more like designing a new car model than like building one in a factory. Software development is a product design and engineering process not a manufacturing process.
- A component team is a group of up to 5 to 10 people who analyze, design, build and test a whole group of related requirements that are delivered. This leads to a high performance team that can focus on and resolve issues quickly.Team members wear multiple hats. For instance the team lead may be the system designer and lead developer and the onsite rep may be the lead tester and system analyst. One of the developers may focus on automating tests. Another developer may specialize in developing or using common components. Testing should be separate to development to provide greater accountability and rigor and to allow for a different point of view on the requirements.Each team provides representatives to cross functional teams that are responsible for developing and integrating cross functional plans, requirements, designs, components and tests.This is the vendor development team.Circulate offshore team members into onsite rep to increase knowledge sharing.
- Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
- Requirements are broken down into things that can be developed and deployed during an iteration. They can include non functional requirements and enabling tasks like set up test environment and deploy build or user guide or operations manual. Each requirements goes through the following statuses:NewAnalysisDesignBuildTestAcceptanceDeployCompleted
- Each component team runs the daily SCRUM process defined here.In a scrum meeting the team lead goes through the requirements / task list and asks each person how they are going, when they will finish, what issues they are facing and what they will do next.The issues are left until the end of the meeting for further discussion by all interested parties.Developers are expected to take turns managing the daily build. Whoever breaks the daily build becomes the new build manager with responsibility for fixing it.Each cross functional team will run a similar meeting every couple of days with one representative from each component team.The business team could also run a similar process and report back through one representative to the design team.
- Changes are easy to manage. They are simply identified, added to the requirements list and analyzed and designed in the next planning iterationIf a change is a top priority it can be analyzed next month and delivered the month after.All changes are prioritized according to business value.
- Each component team contributes specialist members to cross functional teams to co-ordinate and develop common plans, requirements, designs, tests and components.For large projects the cross functional team lead is a full time role. For medium or small projects the cross functional team lead is a member of a function team
- Larger agile teams are formed by structuring the teams into cross functional component teams. Each team contributes specialist members to cross functional teams to co-ordinate and develop common plans, requirements, designs, tests and components.Each team members primary reporting relationship is to their component team lead with a secondary reporting line to the cross functional team leads.For outsourced projects the component teams report to the vendor development manager and the functional leads report to the project manager. Would be good to have Agile coach and training to help teams transition to this approach.
- Management and planning overhead is reduced by reducing effort wasted developing long detailed documents which quickly become outdated and arguing about changes.A stable resource model provides greater predictability for the vendor and for the customer.It allows knowledge retention, continuity of resources and enhanced learning over time.This provides faster response through greater knowledge.
- Each offshore component team has an onsite representative who forms part of the onsite design team. The onsite rep is responsible for communicating with the offshore team. The offshore team members will take turns being the onsite rep to improve communication and knowledge transfer.
- A fixed release calendar makes it much easier to synchronize interdependent projects
- Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
- Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
- Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.