CPrime -Agile Processes For Hardware Development

3y ago
51 Views
2 Downloads
2.31 MB
66 Pages
Last View : 15d ago
Last Download : 6m ago
Upload by : Axel Lin
Transcription

Agile Processes forHardware DevelopmentKevin Thompson, Ph.D., PMP, ACP, CSPAgile Practice LeadcPrime, Inc.4100 E. Third Avenue, # 205Foster City, CA 944042015 cPrime. All Rights Reserved.www.cprime.com1

AbstractHardware and software development are quite different, in terms of the concrete developmentalactivities. Thus it might seem that Scrum, the Agile process often used for software development, wouldnot be appropriate for hardware development. However, most of the obvious differences betweenhardware and software development have to do with the nature and sequencing of deliverables, ratherthan unique attributes of the work that constrain the process. The research conducted for this paperindicates that a Scrum process is quite appropriate for hardware development. Thus this paperdescribes a practical Agile process for Agile hardware development, which is almost identical to theScrum process as it is commonly used for developing software.AcknowledgmentsThe author would like to thank John Carter (of TCGen) and Dr. Scott Elliott (of TechZecs LLC) for theircritical contributions in the areas of hardware development and survey design. This document would nothave been possible without their continued participation in every aspect of the research and writing overthe last year and a half, including designs for various figures, textual revisions, and numerous proofreadings.Contents1Introduction . 62The Agile Hardware Research Project . 63Processes for Software Development . 7453.1The Waterfall Process for Software Development. 83.2The Adaptive Spectrum . 93.3Agile Processes for Software Development. 93.4Scrum Time Horizons and Cycles. 10Hardware vs. Software: Similarities and Differences . 124.1Similarities between Hardware and Software Development . 124.2Differences between Hardware and Software Development. 12Scrum-Process Customizations for Hardware Development . 145.1.1Story Types . 145.1.2Sprint Length . 152

65.1.3Release Planning . 165.1.4Variation in Sprint Focus during a Release Cycle . 16Agile Process for Hardware Development . 176.1Overview . 186.2Velocity . 196.3Levels of Governance . 196.4Roles . 206.4.1Project-Level Roles . 206.4.2Program-Level Roles . 216.5Artifacts . 226.5.1Product Backlog Items . 226.5.1.1User Stories . 226.5.1.2Technical Stories . 236.5.1.3Defects . 256.5.2Epics . 256.5.3Product Backlog . 266.5.4Sprint Backlog . 276.5.5Definition of Done. 276.6Ceremonies . 286.6.16.6.1.1Estimation Concepts . 28Units for PBI Estimation . 286.6.1.1.1Relative Sizing. 286.6.1.1.2Absolute Sizing . 296.6.1.2How to Estimate Team Velocity . 306.6.1.3How to Estimate PBIs with Planning Poker . 306.6.1.4How to Estimate Tasks . 316.6.2Ceremonies for Sprints . 326.6.2.1Backlog Grooming Meeting . 336.6.2.2Sprint Planning Meeting . 346.6.2.2.1Sprint Planning, Part 1 . 346.6.2.2.2Sprint Planning, Part 2 . 356.6.2.2.3How to Allocate Team Members to PBIs . 363

6.6.2.3Daily Stand-Up Meeting . 366.6.2.4Sprint Review . 376.6.2.5Retrospective . 386.6.3Ceremonies for Releases . 396.6.3.16.6.3.1.1Single Release Planning Meeting . 426.6.3.1.2Incremental Release Planning . 446.6.3.1.2.1Scope Development and Estimation. 446.6.3.1.2.2Release Plan Development . 446.6.3.1.3Units for Estimation in Release Planning . 446.6.3.1.4How to Estimate PBIs and Epics for Release Planning: Affinity Estimation . 456.6.4Scrum-of-Scrums Meeting . 466.6.5Product Owner Scrum of Scrums Meeting . 466.6.6Release Review . 476.6.7Release Retrospective . 476.7Tracking and Metrics . 476.7.1Tracking Progress for a Sprint . 486.7.2Tracking Progress for a Release . 496.87Release Planning . 41How Requirements are Developed . 50Practical Example of an Agile Hardware Project . 517.1The Project and Product Definition . 517.2The Team Definitions . 527.3Developing High-Level Specifications . 547.4Developing Detailed Specifications . 577.5Release Planning . 587.5.1Developing the Release Plan . 597.5.2The Structure of the Release . 597.6Regulatory Issues . 617.7How Scope and Work Evolve during the Release Cycle . 628Conclusions . 629Glossary . 634

List of FiguresFigure 1: Winston Royce's original Waterfall Diagram . 8Figure 2: The Five Cycles of Planning in Scrum . 11Figure 3: Release-Level View of Concurrent Hardware and Software Development . 19Figure 4: Sample User Story . 23Figure 5: Sample Technical Story for Software Development . 24Figure 6: Sample Technical Story for Hardware Development . 25Figure 7: Decomposition of an Epic into PBIs . 26Figure 8: A Typical Definition of Done for a Software Team's PBIs . 27Figure 9: A Typical Definition of Done for a Hardware Team's PBIs . 28Figure 10: Typical Sprint Schedule. 33Figure 11: Typical Release Schedule . 41Figure 12: A Release Plan, as it Appears in the Release Planning Meeting . 43Figure 13: An Example of Affinity Estimation . 46Figure 14: Scrum Taskboard with Burndown Chart. 49Figure 15: A Typical Burn-Up Chart . 50Figure 16: Scrum Teams for Cardiac Monitor Development . 54Figure 17: Network Diagram for Cardiac Monitor Development . 56Figure 18: A Typical Epic for a Major User-Facing Product Capability . 56Figure 19: A Typical Decomposition of Epics into Stories . 58Figure 20: Structure of the Release Cycle for the Cardiac-Monitor Development . 615

1 IntroductionThe introduction of Agile processes for software development has brought many advantages toorganizations that develop software. Relative to the preceding “Waterfall” approach, these advantagesinclude Visibility: Status of work and plans is highly visible, on an hour-by-hour basis Adaptability: The practice of breaking large scope into many small, testable deliverables hasprovided tremendous flexibility to plan, control, and change scope (sometimes dramatically) onshort notice Minimum time to market: Small, high-value requests can be developed and delivered morequickly, in as little as a few weeks in some cases Higher probability of meeting customer needs: More frequent customer testing and feedbackallows a better shot at a moving targetAgile processes are not limited to the world of software development. They can be applied in othercontexts, such as IT Operations and Production support, where they provide benefits similar to thoselisted above.This paper addresses how to apply Agile process concepts to the world of hardware development, andintegration of hardware and software. “Hardware development” here refers to the development ofspecifications for devices that are intended to be manufactured. The goal of this paper is to identifypractical Agile processes for hardware development.2 The Agile Hardware Research ProjectThe discoveries presented in this paper derive from a study performed by Dr. Kevin Thompson (cPrime),John Carter (TCGen), and Dr. Scott Elliott (TechZecs) in 2014. The researchers conducted interviewswith people at fourteen companies that make hardware, software, or combined products.While none of the companies had a standardized, end-to-end Agile process for hardware developmentas such, many used some techniques borrowed from the world of Agile software development. Forexample, we discovered that companies engaged in rapid development of circuit boards throughiterative prototyping, division of product-development cycles into time-boxed Sprints, tracking withBurndown charts, and frequent integration and integration testing of components.Our analysis of the research data, including impacts and constraints due to the inherent characteristicsof hardware product development, has yielded the insights presented in this paper.6

The following sections describe the characteristics of hardware development that influence or constrainprocess definition, and propose an Agile process for hardware development. We begin by looking firstat Agile techniques for Software Development, and then identify how hardware development resemblesor differs from software development.3 Processes for Software DevelopmentThe dominant process for software development, up through roughly the year 2000, was the Waterfallprocess, which was first described by Winston Royce in 1970.1 Although Royce did not coin the term“Waterfall,” he did describe a process whose characteristic stair-step structure and flow inspired theterm. Agile processes were developed and introduced in the 1990s, starting with Extreme Programming,and followed a few years later by Scrum. We look at both approaches below.7

3.1 The Waterfall Process for Software DevelopmentThe basic concept of a Waterfall process is that the project scope (in this case, the feature set of asoftware product) is first defined, and then moves through a sequence of stages until the completeproduct is delivered at the end. Royce diagrammed the process in this SISPROGRAM DESIGNCODINGTESTINGOPERATIONSFigure 1: Winston Royce's original Waterfall DiagramRoyce’s own commentary on this diagram foreshadows the difficulties to come:“I believe in this concept, but the implementation described above is risky and invites failure.The problem is illustrated in [Royce’s] Figure 4 [Figure 1 above]. The testing phase whichoccurs at the end of the development cycle is the first event for which timing, storage,input/output transfers, etc., are experienced as distinguished from analyzed. These phenomenaare not precisely analyzable. They are not the solutions to the standard partial differential8

equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the variousexternal constraints, then invariably a major redesign is required. A simple octal patch or redo ofsome isolated code will not fix these kinds of difficulties. The required design changes are likelyto be so disruptive that the software requirements upon which the design is based and whichprovides the rationale for everything are violated. Either the requirements must be modified, or asubstantial change in the design is required. In effect the development process has returned tothe origin and one can expect up to a 100-percent overrun in schedule and/or costs.”2Royce correctly identified the key problem: It is not possible to get the requirements, design, andimplementation of a product done exactly the right way in a single pass. Every aspect of softwaredevelopment is subject to such high uncertainty that one cannot simply lay out a plan and follow it,because reality diverges swiftly from the plan. Attempts to reduce uncertainty to the point where one cancreate a Waterfall-style plan that works are doomed to failure, because the uncertainty cannot bereduced to low levels.The solution to this problem lay almost thirty years in the future, with the development of Agileprocesses. A core component of this solution is the practice of defining and implementing scope in verysmall pieces, sequentially, and providing frequent opportunities to correct errors and change directionas understanding of the true needs emerges over time.3.2 The Adaptive Spectrum3.3 Agile Processes for Software DevelopmentAn Agile process is one that incorporates the principles of the Manifesto for Agile Software Development(commonly referr

Thus it might seem that Scrum, the Agile process often used for software development, would not be appropriate for hardware development. However, most of the obvious differences between hardware and software development have to do with the nature and sequencing of deliverables, rather than unique attributes of the work that constrain the process. The research conducted for this paper indicates .

Related Documents:

4 THE ENGAGED ENTERPRISE'S GUIDE TO SCALING AGILE WITH JIRA AND JIRA ALIGN - WWW.CPRIME.COM P 1 TT P AGILE PRINCIPLES THAT SCALE WITH YOU In practice, this means moving from individual Scrum or Kanban teams to coordinated efforts across multiple teams and products. It means expanding Agile practices to other teams throughout the organization .

1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18

TH TIMA O REPORTING IN JIRA ALIGN www.cprime.c arn@cprime.c 8777532760 e eserved 3 QUICK GUIDE: JIRA ALIGN REPORT TYPES Team Room Report - The optimal "homebase" for product managers and Scrum Masters in Jira Align Sprint Metrics Report - Offers grid-based view of all teams' performance across any sprint within PI

Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original

Scaled Agile Partners. in 50 countries. 250,000. SAFe-trained professionals. in 110 countries. SAFe cited as preferred solution for scaling Agile: 2017 Agile in the Enterprise survey by Gartner Research 12. th. Annual State of Agile Report by VersionOne 2017 Scaling Agile Report by cPrime. Configurable. SAFe is able to accommodate .

1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma

Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .

Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.