1 Debunking “Bleeding Edge” Methodologies A to Z: Agile – RUP – Scrum – XP David M....
-
Upload
quentin-bailey -
Category
Documents
-
view
215 -
download
1
Transcript of 1 Debunking “Bleeding Edge” Methodologies A to Z: Agile – RUP – Scrum – XP David M....
1
Debunking “Bleeding Edge” Methodologies A to Z:
Agile – RUP – Scrum – XP
www.us.sogeti.com
David M. Sides, PMP, OPM3, ITIL
Vice President, Sogeti
Project Consulting Practice
Introduction & Caveats
Change is hard. True leadership is rare. There is no “Silver Bullet”. There are no perfect People, Processes, or Tools. Corporate cultures are full of “Organizational Inhibitors”.
2
Expectations? Agile – RUP – Scrum – XP – To use or not? You decide. My premise and bias: Traditional methods for 20+
years…maybe there is a better way? You tell me.
And now…Agile
with David Sides
Dave’s “Top 10” Stupid Agile Tricks
1. Never look back. What’s done is done.
2. Matrix manage me.
3. Make it really complex so everyone will be impressed.
4. Pay me by the pound.
5. Close your door and send an email. 6. Micro-manage me.
7. Stay in your silos.
8. They’ll get it when we’re done.
9. Stick your head in the sand. 10. We in IT know what’s best for our customer.
4
Agile
Manifesto History Values How do you know? TDD & Refactoring SDLC AUP Change Management Simple Definition
5
The Agile Manifesto
1. Never look back. What’s done is done. [At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.]
2. Matrix manage me. [The best architectures, requirements, and designs emerge from self-organizing teams.]
3. Make it really complex so everyone will be impressed. [Simplicity--the art of maximizing the amount of work not done--is essential.]
4. Pay me by the pound. [Working software is the primary measure of progress.]
5. Close your door. Send an email. [The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.]
6. Micro-manage me. [Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.]
7. Stay in your silos. [Business people and developers must work together daily throughout the project.]
8. They’ll get it when we’re done. [Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.]
9. Stick your head in the sand. [Welcome changing requirements, even late in development. Agile processes harness change for competitive advantage.]
10. We in IT know what’s best for our customer. [Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.]
6
History of Agile
Who? 17 independent thinkers, competitors and anarchists from XP, Scrum, DSDM, ASD, et al
What? Met to try to find common ground on software development
When? February 11-13, 2001
Where? The Lodge at Snowbird, Utah
Why? They felt the need for an alternative to “documentation-driven, heavyweight software
development processes”
How? They skied, ate, drank, and came to terms, naming themselves “The Agile Alliance”
Output? The Agile Software Development Manifesto
7
In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old and new ideas, but all emphasized:
• Close collaboration between the programmer team and business experts• Face-to-face communication (as more efficient than written documentation)• Frequent delivery of new deployable business value• Tight, self-organizing teams• Ways to craft the code and the team so the inevitable requirements churn was not a crisis
Agile Values
1. Individuals and interactions over processes and tools. Teams of people build software they need to work together effectively.
2. Working software over comprehensive documentation. Provide benefits and value early and often. Don’t get paid by the pound for your documentation; be concise.
3. Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they will change their minds and won’t get it right the first time. Communicate, understand their needs, and educate your customers along the way.
4. Responding to change over following a plan. People change, priorities change, and the business environment changes. Technology changes over time, although not always for the better. A Project Plan is good, but stuff happens and there must be room to change it as your situation changes.
8
How do you know if you are Agile?
1. Is the team taking a test-driven approach to development?With Test-driven Development (TDD) you write a single test before writing just
enough code to fulfill that test. Review the test suite, see it run, and view the actual source code. Look for a 50-50 split between testing code and production code. A 20-80 split is clearly a problem.
2. Are stakeholders active participants in development?Minimally stakeholders should be available and involved on a daily basis, provide
information and make decisions in a timely manner. The team should be able to introduce me to their stakeholder(s) immediately.
3. Is the team regularly producing high-quality, working software?Within a few weeks, the team should be able to show the working software that
they've built to date as well as the source code. The code should be consistent because it will have been written to conform to a common set of guidelines and the team will refactor when appropriate to ensure that it remains of high quality.
4. Is the team self-organizing and highly collaborative?Agile teams employ the most effective communication strategies available. Detailed
specifications may be sparse, but all should know and understand them. Team members should be motivated and self-directed instead of having a project manager do their planning for them.
9
Ask yourself these questions…
Test-driven Design/Development (TDD)
10
Test–driven Design/Development (“test first”):
1.Add a test with just enough code to fail.
2.Run your tests to fail; either a subset, or if time allows, the complete test suite.
3.Update your functional code to make it pass the new tests.
4.Run your tests again. If they fail, update your functional code and retest.
5.Once the tests pass, start over (you may first need to refactor any duplication out of your design as needed).
Refactor – Restructure your code by making small changes to improve your design, making it easier to understand and modify. Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach to programming.
Agile SDLC
11
Agile Unified Process (AUP)
12
Agile Change Management
13
Key CM Factors:
1.Embrace change.
2.Accept the idea that requirements will evolve throughout a project.
3.Understand that because requirements evolve over time that any early investment in detailed documentation will be wasted.
4.Do just enough initial requirements envisioning to identify project scope and develop a high-level schedule and estimate.
5.“Model Storm” (JIT modeling) continually during development to explore each requirement in the necessary detail.
A Simple Agile Definition
Agile is an iterative and incremental (evolutionary) approach to software development
performed in a highly collaborative manner
by self-organizing teams
with “just enough process” (JEP)
that produces high quality software
in a cost effective and timely manner
which meets the changing needs of its stakeholders.
14
Agile Quiz
What is it? History When to use it?
15
16
The Rational Unified Process
You Might Be A Texan If...
1. You can properly pronounce Corsicana, Palestine, Waxahachie, Bexar, Mexia, Waco, Beaumont and Amarillo.
2. A tornado warning siren is your signal to go out in the yard and look for a funnel.
3. You've ever had to switch from "heat" to "A/C" in the same day.
4. You measure distance in minutes or hours.
5. You know cowpies are not made of beef.
6. Someone you know has used a football schedule to plan a wedding date.
7. You are 100% Texan if you have ever had this conversation:
"You wanna coke?""Yeah.""What kind?""Dr. Pepper."
17
The RUP?
RUP is and not? ABCDEF History Why? Profile Use Cases PM
18
What is RUP? What is it not?
19
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation.
The RUP is not a single concrete prescriptive process, but rather an adaptable process framework.
The RUP does not have to be used as-is, all the time, but should be tailored by the development organizations and software project teams that select the elements appropriate for their needs.
The RUP is also a software process product, including a hyperlinked knowledge base with sample artifacts and and detailed descriptions for many different types of activities.
The RUP is included in IBM’s Rational Method Composer (RMC) which allows customization of the process.
IBM Rational Method Composer (RMC) 7.2 Plug-ins
IBM Rational Method for SOA Governance Plug-in V1.0 RUP for WebSphere Business Modeler Plug-in V1.0 (beta) IBM Rational Method for Portfolio Management (for Initiatives) Plug-in V1.0 RUP for Microsoft .NET Plug-in V3.0 RUP for COTS Package Delivery Plug-in V2.1.1 IBM Rational Method for Program Mobilization Plug-in V1.02 RUP for Practical Software and Systems Measurement (PSM) V3.0 RUP for Maintenance Projects Plug-in V1.0 RUP for DoDAF Plug-in V1.0 RUP for Compliance Management Plug-in V1.0 The IBM Rational Unified Process for System z V1.0 The IBM Rational Unified Process with ITSM/ITUP Connection V1.0 RUP with CMMI Compliance Support V1.0 Beta 2 RUP for Asset-Based Development V3.0 and Asset-Based Dev. Governance Plug-in V1.0 The IBM Rational Unified Process for Global Dev. and Delivery Maintenance V1.0 Beta RUP for Model-Driven Systems Development Plug-in V4.0
20
RUP = ABCDEF
Adapt the process - A project or organization must “right-size” the process to their needs. RUP provides pre-configured process templates for small, medium, and large projects.
Balance stakeholder priorities - This includes often conflicting business goals and stakeholder needs that compete for time and money.
Collaborate across teams - Software engineering in a globally distributed environment and executed in an iterative-incremental approach is truly a team effort with all stakeholders being heard.
Demonstrate value iteratively – Each delivered increment, which includes the value of the past iteration, is used to measure the progress of the project and to encourage feedback from stakeholders about the direction of the project. Stakeholders influence the shape of the development effort while the project is executed.
Elevate the level of abstraction – This practice motivates the use of reusable assets and prevents software engineers going directly from requirements to custom code.
Focus continuously on quality - Quality checks are an ongoing activity, often performed daily, supported by the entire team. Automating test scenarios (scripts) helps in dealing with the increasing amount of tests due to iterative development.
21
6 Key Principles of Business-Driven Development
History of RUP
22
The roots of Rational Process go back to the original spiral model (combination of prototyping and waterfall models) of Barry Boehm.
The Rational Approach was developed at Rational Software in in the 1980s and 1990s.
The RUP was the result of the merger of the Rational Approach and the Objectory process (Ivar Jacobson) following Rational’s 1995 acquisition of the Swedish Company Objectory AB.
The first version of the RUP (v5.0) was released in 1998 (chief architect Philippe Kruchten).
The latest version of the RUP (v7.0) was released with the announcement of the IBM Rational Method Composer (RMC) in November 2005.
Why a RUP?
Problem: The developers of the RUP focused on diagnosing and analyzing the root causes of failed software projects. They also looked at existing software engineering processes for solutions to these symptoms. Findings:
Ad hoc requirements management Ambiguous and imprecise communication Brittle architecture (architecture that does not work well under "stress") Overwhelming complexity Undetected inconsistencies in requirements, designs, and implementations Insufficient testing Subjective assessment of project status Failure to attack risks Uncontrolled change propagation Insufficient automation
Conclusion: Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of this study was a system of software best practices they named the Rational Unified Process.
23
RUP Project Profile
24
Performed in iterations – Elaboration-Construction-Transition
Rational Unified Process
25
Look familiar?
Defining What When
RUP
• Prioritize use cases
• By stakeholder priority
• And by architectural coverage
26
Components of a Use Case Diagram
27
Actor:Someone/something outside the system that interacts with the system
Use Case:Defines a piece of functionality of the system
Communication – Association:Shows the Actor and the Use Case communicate
Use Case Specification:Basic flow of events,alternate flows, error flows and sub-flows as appropriate
Architecture What is architecture?• High-level components and their connections• How key elements will work together to support the system• Sweeping mechanisms that impact much of the system• Common patterns applied within the design
Design can be “as-is”
Architecture always implied “to-be”
An architecture-centric process• Attacks risk with an early emphasis on architecture• Architecturally-significant requirements elicited earlier• Early builds exercise architecture
28
What about Project Management?
Project planning in the RUP occurs at two levels. There is a high-level Phase Plan (software development plan) which describes the entire project, and a series of detailed Iteration Plans which describe the iterations.
The RUP PM discipline focuses mainly on the following aspects of an iterative development process:
Risk management Planning an iterative project, through the lifecycle and for a particular iteration Monitoring progress of an iterative project, metrics for quality and performance
However, this discipline of the RUP does not attempt to cover all aspects of project management. For example, it does not cover:
Managing resources: hiring, training, coaching Managing cost/budget: defining, allocating Managing procurement: contracts with suppliers, vendors, and customers
29
PM gaps to be filled: Integration, Scope (Change Mgt), Cost, Resource Team Building, Communications, Procurement
The RUP Quiz
What is it? History When to use it?
30
31
Scrum
Scrum
What is it? History Process Scrum compared to a Pressure Cooker
32
What is Scrum?
Scrum is an iterative, incremental process for developing any product or managing any work. It has been used from simple projects to complex software. It produces a potentially shippable set of functionality at the end of every iteration. Scrum attributes:
An agile process to manage and control development work. A wrapper for existing engineering practices. A team-based approach to iteratively and incrementally develop systems and
products when requirements are rapidly changing. A process that controls the chaos of conflicting interests and needs. A way to improve communications and maximize co-operation. A way to detect and cause the removal of anything that gets in the way of
developing and delivering products. A way to maximize productivity. Scalable from single projects to entire organizations. Scrum has controlled and
organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
33
History of Scrum
34
The approach was first described by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986).
They noted that projects using small, cross-functional teams historically produce the best results, and likened these high-performing teams to the scrum formation in Rugby.
In 1990’s Ken Schwaber, Jeff Sutherland, John Scumuniotales, and Jeff McKenna used the approach and called it Scrum.
Although Scrum was intended to be for management of software development projects, it can be used in running maintenance teams, or as a program management approach: Scrum of Scrums.
Scrum Process Flow
35
Scrum focuses an entire organization on building successful products. Without major changes - often within thirty days - teams are building useful, demonstrable product functionality.
Scrum can be implemented at the beginning, in the middle, or anytime in a product development effort that is in trouble.
A Scrum project is controlled by establishing, measuring and trackng key controls (backlog and risk). Controls are critical when a software development has uncertainty, unpredictability, and chaos.
Backlog should start relatively high, get higher during planning, and then get whittled away as the project proceeds - either by being solved or removed, until the software is completed.Risk rises with the identification of backlog, issues, and problems, and falls to acceptable levels as the software is changed.
Scrum Development as a Pressure Cooker
36
The Planning and System Architecture phases prepare the input that is placed in the pressure cooker. The input consists of:
• Ingredients – backlog, objects, packets, problems, issues• Recipe – system architecture, design, and prototypes• Cooking sequence – infrastructure, top priority functions, next priority
The Closure phase removes the final product (executable and documentation) and prepares it for shipment.
The Consolidation Phase cleans up the pressure cooker and ingredients for the next batch.
Scrum Quiz
What is it? History When to use it?
37
38
Extreme Programming
Extreme Programming
What is it? Best Practices History Take it to the Extreme
39
Extreme Programming (XP)
A deliberate and disciplined approach to software development that stresses customer satisfaction by delivering software your customer needs when it is needed.
Empowers developers to confidently respond to changing customer requirements, even late in the life cycle.
Emphasizes team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software.
XP improves a software project in four essential ways1. Communication – Programmers talk to their customers and team members.2. Simplicity – They keep their design simple and clean.3. Feedback – Testing and feedback starts on day one.4. Courage – They respond to changing requirements and technology often to
delver the system as early as possible. XP essentially takes existing "best practices" to extreme levels. For
example, the practice of TDD was used as early as NASA's Project Mercury, in the early 1960s. Refactoring, modularity, bottom-up and incremental design were described by Leo Brodie in his book published in 1984.
40
XP Best Practices Planning
User stories (use cases) are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity (amount of work
getting done) is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around (cross train). A stand-up meeting starts each day. Fix XP (improve the process) when it
breaks.
Designing Simplicity. Choose a system metaphor (naming
standards) . Use CRC cards (Class, Responsibilities,
Collaboration) for design sessions. Create spike solutions (simple programs
to explore potential solutions) to reduce risk.
No functionality is added early (focus on today’s needs).
Refactor (let it go; rejuvenate obsolete designs) whenever and wherever possible.
41
Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed
(code in twos at the same computer). Integrate often but only one pair integrates
code at a time (version control). Use collective code ownership (everyone
contributes). Leave optimization (make it work, make
it right, then make it fast) till last. No overtime (great idea if management
and customers agree!).
Testing All code must have and pass all unit tests
before it can be released. When a bug is found tests are created. Acceptance tests are run often and the
score is published.
XP History
XP was created by Kent Beck in 1996 during his work as project leader on the C3 payroll project at Chrysler.
In 1999, Beck wrote a book on the method: Extreme Programming Explained.
Chrysler canceled the C3 project in 2000, and although some see that initial failure as a problem with XP, the method had caught on in the software engineering field.
As of 2007, a number of software-development projects continue to use XP as their method.
42
Take it to the Extreme: Make Your Customers Notice…
Keep it simple. Don’t be slick and clever. Software engineered to be simple and elegant is more valuable than software that is complex and hard to maintain. A typical project will spend about 20x more on people than hardware.
A project spending $2M/yr on programmers will spend about $100k on technology. Say we save 20% of the hardware costs by some very clever programming tricks. The source code will be harder to understand and maintain, but we are saving 20% or $20k/yr.
If instead, we wrote our programs such that they were easy to understand and extend, we could expect to save no less than 10% of our people costs = $200k, significantly more.
Really listen to your customers and act on their feedback. Too often a customer will see a real opportunity for making a system useful after it has been delivered. Use customer feedback while there is still time to change functionality or improve user acceptance.
Co-locate and collaborate to improve communications and velocity. Buddy-up (pairs) to reduce risk and increase quality. Two heads are
better than one. Write and execute tests early and often. Automate tests so bugs don’t
get through twice. Live with change, embrace change, no…Seek Change!
43
Change the way we program.
Extreme Programming
What is it? History When to use it?
44
Recap
So…is there anything really new under the sun? Agile The RUP Scrum XP Waterfall
Is Deming still relevant? How do I do it? People: Education, training, and certification Process:
Set and manage expectations. Prepare for change
Technology: Is it about Tools? Agile – Version One, Serena, Axosoft RUP – Rational Method Composer, ClearCase Scrum – ScrumWorks, ScrumZ, Serena, Axosoft XP – Version One, XPWeb
45
PlanAct Do Check
Organizational Project Management
46
Project Portfolio ManagementStrategic Alignment & Selection
Approval & FundingPrioritization
Project Team Meetings
•Tracking of Progress, Status, Forecast•Risks & Issues
Steering GroupMeetings
•Reporting of Progress, Status, Forecast•Risks & Issues Escalation
Weekly
Knowledge Management•Project Files•Best Practices•Lessons Learned
Regular
Enterprise Governance: Leadership, Organizational Structures and Enablers, Policies
Traditional System Life Cycle: Planning – Requirements – Analysis & Design – Development – Implementation – Maintenance
Project Governance: Step Gate Reviews, Milestones, Risk & Quality Management
Responsibility:•Accountability•Approvals•SignoffsProject Management Initiation – Planning – Execution (Monitor & Control) – Closing
Program Management: PMO, Methodology, Standards, Processes, Tools, Stakeholder Management, Performance Metrics & Measurement, Benefits Realization
Quality
CommunicationsRisks & IssuesScope
SOW
Time
Cost
Resources ProcurementIntegration
Iterative System Life Cycle: Inception – Elaboration – Construction – Transition – Maintenance
Closing & Caveats
Change is hard. True leadership is rare. There is no “Silver Bullet”. There are no perfect People, Processes, or Tools. Corporate cultures are full of “Organizational Inhibitors”.
47
Expectations? Q&A? Bs&Cs? Evaluations? PDUs? Agile – RUP – Scrum – XP – Waterfall explained? To use or not? You decide. My premise and bias: Traditional methods for 20+
years…maybe there is a better way?
Who & Why Sogeti?
We work with clients to develop and deploy unique solutions to help them achieve their strategic business objectives.
40+ years of global experience – global reach, local touch
Comprehensive service offerings to solve client business & IT challenges
Complemented by our alliance relationships with Microsoft, IBM and others
Leveraging our global delivery capabilities to keep client costs down
Quality delivery always
Industry-leading, knowledgeable, experienced and certified professionals in Project Management and IT development (150+ PMPs)
David M. Sides, PMP [email protected]
Global expertise & local proximity
United States Southern Europe
France
Benelux
Central Europe
Nordic
UK
A multi-national, premier provider of IT
and project management servicesGlobal reach, local touch
India
2000 in USA
16,000 worldwide
Sogeti USA locations
Houston
Dallas
New York
Baltimore
Minneapolis
Des Moines
Omaha
Chicago
St. Louis
Indianapolis
Detroit
Columbus
Cleveland
Dayton
Seattle
Cincinnati Washington DCKansas City
Phoenix
Ft. Collins
Tampa
Ft. Lauderdale
Denver
2000 IT Professionals in 23 locations across
the country