DOCSLIB.ORG

Update on the Unified Process: Something Old, Something New, Something Borrowed, and Definitely Something Blue

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Update on the Unified Process: Something Old, Something New, Something Borrowed, and Definitely Something Blue ® IBM Software Group UPdate on the Unified Process: Something Old, Something New, Something Borrowed, and Definitely Something Blue Scott W. Ambler Practice Leader Agile Development, IBM © 2006 IBM Corporation IBM Software Group | Rational software Scott Ambler - Background .Practice Leader – Agile Development .Fellow – International Association of Software Architects .www.ibm.com/rational/bios/ambler.html IBM Software Group | Rational software Presentation Overview .Main “Take Away” Points .History of the Unified Process .The Rational Unified Process (RUP) .The Eclipse Process Framework (EPF) .Open Unified Process (Open UP) .Other The Agile Unified Process (AUP) The Essential Unified Process (Ess UP) The Enterprise Unified Process (EUP) .Parting Thoughts IBM Software Group | Rational software Main “Take Away” Points 1. The UP has a long and proven history 2. There are many flavors of the UP available to you 3. One process size doesn’t fit all 4. The UP can be extended to the entire IT lifecycle 5. The UP is clearly evolving Some History www.enterpriseunifiedprocess.com/essays/history.html IBM Software Group | Rational software 1988: Ob jectory v1.0 1995: O bjectory v3.8 June 1998: RUP 5.0 October 1999: Enhanced RUP lifecycle May 2003: RUP 2003 January 2004: EUP v2004 September 2005: AUP October 2005: EPF & BUP November 2005: RMC March 2006: Ess UP May 2006: Open UP IBM Software Group | Rational software Rational Unified Process (RUP) IBM Software Group | Rational software Universal Principles – The Basis of RUP These principles are the basis for RUP practices. IBM Software Group | Rational software RUP Practices .Manage risk .Leverage legacy systems .Execute your project in iterations .Build high-performance teams .Embrace and manage change .Organize around the architecture .Measure progress objectively .Manage versions .Test your own code .Leverage patterns .Leverage test automation appropriately .Architect with components and .Everyone owns the product services .Understand the domain .Actively promote reuse .Describe requirements from the user .Model key perspectives perspective .Rightsize your process .Prioritize requirements for .Continuously reevaluate what you do implementation ® IBM Software Group Open Unified Process (Open UP) OpenUP/Basic Key Artifacts Principles Base Process and Plug Ins Demo © 2006 IBM Corporation IBM Software Group | Rational software What Is OpenUP/Basic? An iterative software development process that is minimal, complete, and extensible. .Minimal - only fundamental content is included .Complete - can be manifested as an entire process to build a system .Extensible - can be used as a foundation on which process content can be added or tailored as needed IBM Software Group | Rational software OpenUP/Basic Management “Intent” / Req’s Management Development Collaboration IBM Software Group | Rational software OpenUP/Basic: Key artifacts Management “Intent” / Req’s Management Development Project Plan Iteration Plan Vision Work Item List Use Cases Build Developer Test Collaboration IBM Software Group | Rational software OpenUP/Basic Principles Management “Intent” / Req’s Evolve to continuously Management obtain feedback and Development improve Balance competing priorities to Focus on articulating the maximize stakeholder value architecture Collaboration Collaborate to align interests and share understanding IBM Software Group | Rational software OpenUP/Basic Management “Intent” / Req’s Example Process patterns .Plan iteration Management .Plan project Development .Manage iteration .Assess status Example Process patterns .Develop vision .Find and outline requirements Example Process patterns .Detail requirements .Develop trivial change .Agree on scope .Develop small change .Define the architecture .Develop large change .Determine arch. feasibility .Validate build Collaboration Example Process patterns .Maintain a common understanding .Foster a high trust environment .Share responsibility .Agree on scope .Learn continuously IBM Software Group | Rational software Base Processes and Process Plug-Ins JUnit SOA J2EE Financial Scrum Agile Services Database OpenUP/Basic IBM Software Group | Rational software Demo of OpenUP/Basic www.eclipse.org/epf/ ® IBM Software Group The Eclipse Process Framework (EPF) The EPF project Knowledge Base Process Patterns EPF Ecosystem Contributors Demo © 2006 IBM Corporation IBM Software Group | Rational software Eclipse Process Framework (EPF) Project Provide an open and collaborative ecosystem for evolving software development processes Provide sample process patterns, process tooling and a metamodel, that can be used as the foundation for a large variety of processes to address IT needs EPF: Process or Knowledge Base IBM Software Group | Rational software Traditional process mission Mandatory Guidance Tacit Knowledge H a r v e s t i n g r e b s e po s m t o Milestones and p C key artifacts r F a P c E t i Principles & practices c e Reusable process patterns s (Built from tasks, guidelines, artifacts, examples, templates, i … ik W Emerging practices … .) … EPF: Producing a Process IBM Software Group | Rational software Traditional process mission Mandatory Guidance Tacit Knowledge H a r v e s t i n g b e s G u i d aHigh n c e t p - r level process a c t i c Applicable process patterns e s IBM Software Group | Rational software Reuse Process Patterns across Project Types Type B Project Type A Project High-level process High-level process G u i d a n c e G u i d a n c e Applicable process patterns Applicable process patterns Type C Project Type D Project High-level process G u i d a n c e G u i d a n c e Applicable process patterns Applicable process patterns IBM Software Group | Rational software EPF Composer Capabilities .Create reusable process patterns .Create (high-level) processes for different project types .Link appropriate processes patterns to high-level processes .Create derivatives of process patterns, reference material, and processes .Provide easy upgrade to new versions of base set of process patterns, reference materials and high-level processes .Enable tool integration and instrumentation of process patterns and high-level processes (through IBM Software Group | Rational software EPF Ecosystem InhouseInhouse Free Process EXTENSIONS Content Free Process Content •• Project Mgmt. Plug--insins Content Plug-ins •• Oper.. Mgmt. Mgmt. Plug-ins •• Systems Mgmt. Open Unified Process (OpenUP) CommercialCommercial Process Value--Based Model-Driven Software Eng. Architecture ContentContent Plug--insins Other agile processes BasicOpenUP/Basic Unified Basic Unified • XP • DSDM Process OPEN Process • Scrum • AMDD Adapted from RUP Framework • ConsolidatedScrum Agile Framework Tool Extensions Extensible, Customizable, Flexible TOOLING (Authoring, Publishing) Common Language & Vocabulary META MODEL (Unified Method Architecture) Open Source Development ECLIPSE IBM Software Group | Rational software EPF: Growing Ecosystem Co-developers Supporters IBM Software Group | Rational software Looking to the Future: Several Frameworks With Increasingly Shared Content Consolidated OPEN Process Agile Framework Framework OpenUP Collaborative Use Case Practices Refactoring Network Agile Project Design Mgmt IBM Software Group | Rational software Demo of EPF www.eclipse.org/epf/ ® IBM Software Group Other Agile Unified Process (AUP) Essential Unified Process (Ess UP) Enterprise Unified Process (EUP) © 2006 IBM Corporation IBM Software Group | Rational software Agile UP www.ambysoft.com/unifiedprocess/agileUP.html IBM Software Group | Rational software The Essential Unified Process (Ess UP) www.ivarjacobson.com .Lightweight .Agile .Freely available .Easy to use .“Open source” process .Only the “essential” practices .“Next Generation Process” .Separation of Concerns .Delivered as a Set of Cards IBM Software Group | Rational software The Enterprise Unified Process (EUP) www.enterpriseunifiedprocess.com IBM Software Group | Rational software The EUP Wraps the UP IBM Software Group | Rational software Parting Thoughts .The UP has a long history and is well established within the IT community .There are many flavors of the UP available to you From very agile to “traditional evolutionary” From very sparse to very thorough .One process size doesn’t fit all You will likely need several instantiations You will need to provide guidance as to which flavor to follow .The UP can be extended to the entire IT lifecycle .The UP is clearly evolving IBM Software Group | Rational software Scott Ambler IBM Software Group | Rational software References and Recommended Reading .www.agilealliance.com .www.agilemodeling.com .www.agiledata.org .www.ambysoft.com .www.databaserefactoring.com .www.enterpriseunifiedprocess.com .Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York: John Wiley & Sons. .Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons. .Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York: Cambridge University Press. .Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc. .Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison Wesley .McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR..
Load more

Recommended publications
  • SSW555 Syllabus
    Stevens Institute of Technology WebCampus.Stevens Syllabus Course Number: SSW 555 Agile Methods for Software Development Professor Name: Mark Ardis Office Hours: Wednesdays 3-5 PM Office address: Babbio 517 Course Web Address: Office phone number: 201 216 5143 (on WebCT) E-mail address: [email protected] Overview In software problem areas that require exploratory development efforts, those with complex requirements and high levels of change, agile software development practices are highly effective when deployed in a collaborative, people-centered organizational culture. This course examines agile methods, including Extreme Programming (XP), Scrum, Lean, Crystal, Dynamic Systems Development Method and Feature-Driven Development to understand how rapid realization of software occurs most effectively. The ability of agile development teams to rapidly develop high quality, customer-valued software is examined and contrasted with teams following more traditional methodologies that emphasize planning and documentation. Students will learn agile development principles and techniques covering the entire software development process from problem conception through development, testing and deployment, and will be able to effectively participate in and manage agile software developments as a result of their successfully completing this course. Case studies and software development projects are used throughout. Prerequisites Programming experience in an object-oriented language, preferably Java. Cross-listed with: CS 555 Learning Goals After
    [Show full text]
  • 16 the Impact of Methods and Techniques on Outcomes from Agile Software Development Projects
    16 THE IMPACT OF METHODS AND TECHNIQUES ON OUTCOMES FROM AGILE SOFTWARE DEVELOPMENT PROJECTS David Parsons Hokyoung Ryu Ramesh Lai Massey University, Albany Auckland, New Zealand AbstrSCt Agile software development methods have become increasingly popular since the late 1990s, and may offer improved outcomes for software development projects when compared to more traditional approaches. However there has previously been little published empirical evidence to either prove or disprove this assertion. A survey carried out in March 2006 gathered responses from a large number of software development professionals who were using many different methods, both traditional and agile. A statistical analysis of this data reveals that agile methods do indeed improve outcomes from software development projects in terms of quality, satisfaction, and productivity, without a significant increase in cost. However, adoption of methods appears to involve a high degree of adaptivity, with many methods being used in com­ bination and sets of techniques being adopted on an ad hoc basis. In this con­ text, our analysis suggests that choosing specific combinations of methods can be particularly beneficial. However, we also find that successful adoption of an agile method is to some extent dependent on rigorous integration of certain core techniques. Keywords Agile method, technique, software development Please use the jbUowingjbrmat when citing this chapter: Parsons, D., Ryu, H., and Lai, R., 2007, in IFIP International Federation for Information Processing, Volume 235, Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda, eds. McMaster, T., Wastell, D., Femeley, E., and DeGross, J. (Boston: Springer), pp. 235-249. 236 Part 3: Software Process Improvement 1 INTRODUCTION This paper provides some statistical analyses of a data set originally gathered using an online survey to determine the level of adoption of agile approaches by software development organizations.
    [Show full text]
  • Disciplined Agile Delivery (DAD): the Foundation for Scaling Agile
    Disciplined Agile Delivery (DAD): The Foundation for Scaling Agile Scott W. Ambler Chief Methodologist for Agile and Lean, IBM Rational www.ibm.com/developerworks/blogs/page/ambler twitter.com/scottwambler © 2012 IBM Corporation We hope that you find these slides useful. If you would like to discuss this topic further, please contact IBM. 1 2 Agenda 1 Agile Fundamentals 2 Disciplined Agile Delivery (DAD) 3 Agility at Scale 4 Parting Thoughts 2 © 2012 IBM Corporation 2 What is agile? Agile is a highly collaborative, evolutionary, quality focused approach to software development. How agile is different: –Focus on collaboration –Focus on quality –Focus on working solutions –Agilists are generalizing specialists –Agile is based on practice, not theory 3 © 2012 IBM Corporation Focus on collaboration: Less paperwork and more conversation Stakeholders actively involved Focus on quality: Have a full regression test suite for your systems Develop loosely-coupled, highly cohesive architectures Refactor to keep them this way Focus on working solutions: Greater feedback makes agile projects easier to manage Less documentation is required Less bureaucracy Agilists are generalizing specialists: Fewer hand offs between people Fewer people required Specialists find it difficult at first to fit into the team Agile is based on practice, not theory: This is a significant change from traditional You need to see how agile works in practice to truly understand it 3 Why agile? Higher success rates Iterative Agile Lean Ad-Hoc Traditional 0% 20% 40% 60% 80% 100% Successful Challenged Failed Source: DDJ 2011 IT Project Success Survey 4 © 2012 IBM Corporation Detailed results online at www.ambysoft.com/surveys/ Success as defined by the respondent (this is the same for all slides in this deck).
    [Show full text]
  • Rational Unified Process with Scrum
    A HYBRID SOFTWARE DEVELOPMENT METHOD FOR LARGE-SCALE PROJECTS: RATIONAL UNIFIED PROCESS WITH SCRUM Juyun Cho, Colorado State University-Pueblo, [email protected] ABSTRACT mentioned that the conventional methods were not initially designed to respond to requirements change Conventional software development methods have occurring in the middle of the development process, gradually been replaced by lightweight agile and the ability to take action appropriate to the software development methods since the mid-1990s. change often determines the success or failure of a This phenomenon is mainly due to the conventional software product [37]. According to the Standish methods’ shortcomings, including a slow adaptation Group report [33], numerous projects with the to rapidly changing business requirements, and a conventional methods in various industry and tendency to be over budget and behind schedule. This government sectors were completed with fewer paper analyzes characteristics, strengths, and features and functionalities than specified in the user weaknesses of both conventional and agile methods. requirements. It is also a challenge for the This paper also explains the four major phases and conventional methods to create a complete set of nine disciplines of the Unified Process, and the requirements up front due to constant changes in the common elements of the Scrum process. Finally, this technology and business environments. paper suggests a new hybrid software development method that combines the Rational Unified Process Despite the existing shortcomings, the conventional with the Scrum process to accommodate the strengths methods are still widely used in industry, particularly, of both methods while suppressing their weaknesses. for large-scale projects.
    [Show full text]
  • Agile Unified Process
    Charles Edeki, International Journal of Computer Science and Mobile Applications, Vol.1 Issue. 3, September- 2013, pg. 13-17 ISSN: 2321-8363 INTERNATIONAL JOURNAL OF COMPUTER SCIENCE AND MOBILE APPLICATIONS - IJCSMA Agile Unified Process Charles Edeki Ph.D, American Intercontinental University, Department of Information Technology, 160 Parkside Ave, 9M, Brooklyn NY, 11226 [email protected] Abstract The Agile Unified Process (AUP) is based on a cut-down version of the Rational Unified Process (RUP). AUP uses an agile approach which focuses on both the larger life-cycle and the iterations within each step to deliver incremental releases over time. 1. Overview of the Rational Unified Process The Rational Unified Process (RUP) is a software engineering approach whose goal is to produce high-quality software that meets or exceeds the expectation of its users. RUP achieved this by providing a disciplined approach to the management of tasks and responsibilities within a software-development organization (Rational Unified Process, 2002). The Rational Unified Process is a descendent of the Rational Objectory Process which was the product of a 1995 merger between Rational Software Corporation and Objectory AB. Objectory provided the concept of use cases, and Rational provided the iterative process model (Kruchten, 2004). Objectory was developed by Dr. Ivar Jacobson, which centered on use-cases and object-oriented design methods. The Rational approach, which was developed by Rational staff, included Philippe Kruchten, Grady Booch, and Walker Royce, provided the iterative development approach which focused on software architecture (Jacobson, 1998). The combination of these two products created a process that covered the entire software-development life- cycle (Kruchten, 2004).
    [Show full text]
  • Software Development Methodologies
    Software Development Methodologies About this white paper: This paper was written by David C. Young, an employee of CSC. It was written as supplemental documentation for use by the HPC account holders at the Alabama Supercomputer Center (ASC). This was originally written in 2012, and updated in 2013. Software development methodologies have traditionally been covered little or not at all in some of the IT degree curriculums. However, individuals working for professional software development organizations find that it is a big part of their work environment. There is currently a trend of managing other types of work following the general scheme of a software development management practice. A software development methodology is a way of managing a software development project. This typically address issues like selecting features for inclusion in the current version, when software will be released, who works on what, and what testing is done. No one methodology is best for all situations. Even the much maligned waterfall method is appropriate for some organizations. In practice, every organization implements their software development project management in a different way, which is often slightly different from one project to the next. None the less, nearly all are using some subset or combination of the ones discussed here. Choosing an appropriate management structure can make a big difference in achieving a successful end result when measured in terms of cost, meeting deadlines, client happiness, robustness of software, or minimizing expenditures on failed projects. As such, it is worth your time to learn about a number of these and make your best effort to choose wisely.
    [Show full text]
  • An Overview of Agile Software Development and Future Scope
    IOSR Journal of Engineering (IOSR JEN) www.iosrjen.org ISSN (e): 2250-3021, ISSN (p): 2278-8719 PP 84-92 An overview of Agile Software Development and Future Scope Manishakaikadi1, Dhiraj Rane2 MCA 6thsem, Department Of Computerscience, GHRIIT, Nagpur Asst. Prof, Department Of Computer Science, GHRIIT, Nagpur Abstract: Agile software development has rapidly gained a lot of interest in the field of software engineering. Agile software development, despite its novelty, is an important domain of research within software engineering discipline. Agile software development methods have caught the attention of software engineers and researchers worldwide. Scientific research is yet scarce, there has been little detailed reporting of the usage, penetration and success of agile methodologies in traditional, professional software development organizations. Report on the results of an empirical study conducted at Microsoft to learn about agile development and its perception by people in development, testing, and management. This paper reports results from a study, which aims to organize, analyses and make sense out of the dispersed field of agile software development methods. Keywords: Agile, Scrum, Kanban, DSDM Atern, DAD, AUP. I. Introduction Agile is set of values and principles.Agile use to developing general’s specific software and tools. Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change. The term agile (Agile sometimes written) was popularized, in this context, by the ManifestoforAgileSoftwareDevelopment.
    [Show full text]
  • Overcoming the Limitations of Agile Software Development and Software Architecture
    Master Thesis Software Engineering Thesis no: MSE-2013-139 September 2013 Overcoming the Limitations of Agile Software Development and Software Architecture Carlos García Álvarez School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author(s): Carlos García Álvarez E-mail: [email protected] University advisor(s): Dr. Darja Šmite School of Computing School of Computing Internet : www.bth.se/com Blekinge Institute of Technology Phone : +46 455 38 50 00 SE-371 79 Karlskrona Fax : +46 455 38 50 57 Sweden ABSTRACT Context. Agile Software Development has provided a new concept of Software Development based in adaptation to changes, quick decisions, low high-level design and frequent deliveries. However, this approach ignores the value that Software Architecture provides in the long term for increasing the speed in delivery working software, which may have catastrophic consequences in the long term. Objectives. In this study, the combination of these two philosophies of Software Development is investigated. Firstly, the concept of Software Architecture in Agile Projects; then, the major challenges faced concerning Software Architecture in Agile Projects, the practices and approaches that can be used to overcome these challenges and the effects that these practices may cause on the project. Methods. The research methodologies used in this study are Systematic Literature Review for gathering the highest amount possible of contributions available in the Literature at this respect, and also the conduction of Semi-Structured Interviews with Agile Practitioners, in order to obtain empirical knowledge on the problem and support or deny the SLR findings.
    [Show full text]
  • Rational Unified Process with Scrum
    https://doi.org/10.48009/2_iis_2009_340-348 A HYBRID SOFTWARE DEVELOPMENT METHOD FOR LARGE-SCALE PROJECTS: RATIONAL UNIFIED PROCESS WITH SCRUM Juyun Cho, Colorado State University-Pueblo, [email protected] ABSTRACT mentioned that the conventional methods were not initially designed to respond to requirements change Conventional software development methods have occurring in the middle of the development process, gradually been replaced by lightweight agile and the ability to take action appropriate to the software development methods since the mid-1990s. change often determines the success or failure of a This phenomenon is mainly due to the conventional software product [37]. According to the Standish methods’ shortcomings, including a slow adaptation Group report [33], numerous projects with the to rapidly changing business requirements, and a conventional methods in various industry and tendency to be over budget and behind schedule. This government sectors were completed with fewer paper analyzes characteristics, strengths, and features and functionalities than specified in the user weaknesses of both conventional and agile methods. requirements. It is also a challenge for the This paper also explains the four major phases and conventional methods to create a complete set of nine disciplines of the Unified Process, and the requirements up front due to constant changes in the common elements of the Scrum process. Finally, this technology and business environments. paper suggests a new hybrid software development method that combines the Rational Unified Process Despite the existing shortcomings, the conventional with the Scrum process to accommodate the strengths methods are still widely used in industry, particularly, of both methods while suppressing their weaknesses.
    [Show full text]
  • A Manager's Introduction to the Rational Unified Process (RUP)
    A Manager’s Introduction to The Rational Unified Process (RUP) Scott W. Ambler This version: December 4, 2005 Copyright 1999-2005 Scott W. Ambler Executive Summary Software development is a complex endeavor, one which is fraught with peril if you do not follow a proven software method. The Rational Unified Process (RUP) is one such method. The RUP takes an evolutionary approach to development which has been shown in practice to be far more effective than the traditional, serial “waterfall” approach which is prevalent in many organizations. This white paper overviews the lifecycle, phases, disciplines, and best practices of the RUP. It also provides suggested web-based resources which you may find useful if you are looking for more detailed information. Although written for managers, IT practitioners will also find this paper a valuable introductory resource to the RUP. Acknowledgements I would like to thank Peter Alfvin, Rob Exley, Mark Lines, and Frank Schophuizen for their insightful feedback which I have incorporated into this paper. Table of Contents 1 Serial in the Large................................................................................... 2 1.1 The Inception Phase........................................................................ 3 1.2 The Elaboration Phase .................................................................... 3 1.3 The Construction Phase .................................................................. 4 1.4 The Transition Phase .....................................................................
    [Show full text]
  • Unified Process ● the Unified Software Development Process Or Unified Process Is a Popular Iterative and Incremental Software Development Process Framework
    Corso di Laurea Magistrale in Informatica, Università di Padova Tecnologie open-source, Anno accademico 2010/2011 Software development process ● A software development process is a structure imposed on the development of a software product Software development activities ● Requirements analysis The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect 2.5 Italy License Development Processes 1 / 51 Corso di Laurea Magistrale in Informatica, Università di Padova Tecnologie open-source, Anno accademico 2010/2011 Software development activities ● Specification Specification is the task of precisely describing the software to be written, possibly in a rigorous way. Specifications are most important for external interfaces that must remain stable. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound ● Architecture The architecture of a software system or software architecture refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the
    [Show full text]
  • Journey Through a Sprint
    Journey Through a Sprint A Hands-on Introduction to Agile and Scrum Thomas J. Poirier, PMP, CSM PMI-NH – 15 January 2014 Agenda • Agile & Scrum: History and Motivation • The Sprint: Scrum’s “Full Project” Component • Roles, Stories, and Sizing • Introduce the Sprint Game • Play Sprint Game • Retrospective – Q&A • Other Considerations and Surveys • Going Further & Digging Deeper Journey Through a Sprint - PMI-NH 2 A Slice of History: Agile • Software Development Roots – Has been expanded to many divergent fields since inception – Is an approach to project management, not a methodology* • Heavyweight vs. Lightweight Models – Structured (Formal Methods, Waterfall Methodologies) – Iterative Models (Extreme, Adaptive, Feature-Driven, etc.) • Snowbird, Utah; February 2001 – 17 Software Developers – Manifesto for Agile Software Development – Enlarged to Agile Project Management by Some Founders * Methodologies are prescriptive about process. Agile maintains that process should adjust to need Journey Through a Sprint - PMI-NH 3 Agile Manifesto* “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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.” * Statement from the creators can be found here: http://agilemanifesto.org/ Journey Through a Sprint - PMI-NH 4 Agile Principles* 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development.
    [Show full text]