• Like
  • Save
UPMC Module NI514 - 2013/2014 - Topic 1 - Evolution de conduite de projets informatiques
Upcoming SlideShare
Loading in...5
×
 

UPMC Module NI514 - 2013/2014 - Topic 1 - Evolution de conduite de projets informatiques

on

  • 96 views

Evolution of the Enterprise Software Delivery

Evolution of the Enterprise Software Delivery

Statistics

Views

Total Views
96
Views on SlideShare
96
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    UPMC Module NI514 - 2013/2014 - Topic 1 - Evolution de conduite de projets informatiques UPMC Module NI514 - 2013/2014 - Topic 1 - Evolution de conduite de projets informatiques Presentation Transcript

    • Module NI514 Gestion de Projet - Evolution de conduite de projets informatiques Evolution of the Enterprise Software Delivery UPMC STL M2 – 2012/2013 Jean-Yves B. Rigolet, Rational Development IBM France Lab rigolet.j@fr.ibm.com © 2012 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum practises & smells – Agile pratices detailed - TDD & CI  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 2 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques ‘Software development is hard’ Grady Booch 3 March 4, 2014 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum & scrum smells – Agile pratices detailed - TDD & CI  Software development governance – Enterprise portfolio management – Continuous Integration with Agile DevOps – (Application portfolio management) 4 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Traditional/Waterfall Development Model Development proceeds sequentially through a series of phases  Models the development process as moving from one step to the next. Concept Definition Requirements Def Design Requirement Code & Unit Test Integration Test System Test Acceptance Test Deployment  Delays confirmation of critical risk resolution  Measures progress by assessing work-products that are poor predictors of time-to-completion  Delays and aggregates integration and testing  Frequently results in missing targets or unused features/products Maintenance Module NI514 2013 © 2013 IBM Corporation 5
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques V-Model  Extension of the Waterfall model  Coding is central Requirements Analysis Operational Testing High Level Design Integration Testing Detailed Specifications Coding Module NI514 Unit Testing  Meticulous design, development, and documentation  Often view as too simple, giving a false sense of security  Like the Waterfall model, It is inflexible, offering no way to respond to change  Testing comes late & too tight to design 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Realities can stall software delivery Complexities in software delivery compounded by market pressures Complex, Multi-platform Systems and Applications Increasing Mandates 62% of companies have agile projects requiring integration with legacy systems 2010 Spending in U.S. on governance, risk and compliance was $29.8 billion Globally Distributed Software and Product Supply Chains 50% of outsourced projects are expected to under perform Cost Reduction 70% budget locked in maintenance and 37% of projects go over budget Unpredictability in Software Delivery 62% of projects fail to meet intended schedule 7 Changing Requirements and Time to Market 30% of project costs are due to rework and poor execution of requirements Source: Numerous sources, see speaker notes for details Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques So, let's look at the V-Model again What if?... Requirement s Analysis Operational Testing High Level Design Integration Testing Detailed Specification s Unit Testing Coding Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques … We change the way we work Requirement s Analysis Operational Testing High Level Design Detailed Specifications Integration Testing Unit Testing Coding Goal is to reduce risks & costs while delivering better quality software Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agile Manifesto www.agilemanifesto.org February 11-13, 2001, The Lodge at Snowbird ski resort 10 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum & scrum smells – Agile pratices detailed - TDD & CI  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 11 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agile software development applied “Uses continuous stakeholder feedback to deliver high-quality, consumable code through use cases (user stories) and a series of short, stable, time-boxed iterations.” This figure shows the "Four S's" that describe agile in a nutshell. 12 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agile Basics  Agile value-add focuses on: – Delivering business value early and often in a project lifecycle – Being able to incorporate requirements as they emerge and are identified as valid – Providing frequent delivery of new deployable business value (workable code) – Leveraging tight, self-organizing teams – Incorporating customer feedback early in the development cycle  All of these create an environment that can sustain itself over time rather than experience the peaks and valleys of the traditional methods, which ultimately tire employees and lower overall quality. Change should not equal crisis! 13 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques What Agile software engineering is not...  A waterfall  A Big Bang with limited intermediate opportunities for stakeholder interaction, code convergence typically late  Rigid, with change requests often viewed as interruptions  Individualistic  Document, process, or design heavy  Plan driven  A trivial cultural transition for many teams  A fad  A silver bullet 14 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques What Agile software engineering is...  Iterative, typically time-boxed as short iterations  About frequent, sometimes constant, validation with stakeholders  Highly focused on mitigating risks  Adaptive; comfortable with-and even embracing-change and reprioritization  Open (communication, code, process, and so on); a team sport  Communication-intensive (for example, daily Scrums)  Suspicious of non-code artifacts  Aimed at making incremental progress: working software is the measure  Deliberate about reflecting on what works and what does not  Disciplined, scalable, and even workable across sites 15 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum & scrum smells – Agile pratices detailed - TDD & CI  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 16 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques What is Scrum?  An agile software development framework – Structured in cycles of work called Sprints • iterative work • team pull from prioritized customer requirements (User Stories) • produce a potentially shippable  A simple framework – 3 roles • Product Owner, • ScrumMaster, • and the self-organized team – 3 ceremonies • sprint planning meeting, • daily scrum meetings, • and sprint review meetings – 3 artifacts for prioritizing and tracking tasks • product backlog, • sprint backlog, • and a burndown chart 17 Module NI514 A piece of cake?... 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Scrum roles (1/2) Pigs are the ones committed to the project and the Scrum process  Product Owner – Represents the voice of the customer – Writes user stories, prioritizes them – Places stories in product backlog  ScrumMaster (or Facilitator) – Scrum is facilitated by a ScrumMaster, – Ensure team is functional – Remove all team impediments to deliver – Buffer between team and influencers – Ensure Scrum process is used as intended  Team – Self-organized – Responsible to deliver the product – Made up of 5-9 people with cross-functional skills to do the actual work 18 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Scrum roles (2/2) Chicken roles are not part of the actual Scrum process, but must be engaged and provide feedback  Users – Users of the software being built  Stakeholders (customers, vendors) – Enable the project & for whom the project will produce the agreed-upon benefit(s) which justify it – Provides feeback – Involved in reviews  Managers – People that will set up the environment for the product development organizations 19 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Product Backlog  Owned and Prioritized by the Product Owner  Created with Stakeholders and the Delivery Team  Contains the potential work for this release – Features, Development requirements, Exploratory work, Known bugs  Articulates the product vision  Ideally expressed such that each item shows value to the customers or users of the product  Contains user stories at both Epic and detailed levels  Is a living list, changes over the course of the release  Is assessed and reprioritized every iteration 20 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Dynamics of a Product Backlog  Each Sprint (or Iteration) is made up of small automatable chunks called User Stories  The Product Backlog holds all the User Stories until they are ready to be implemented in a Sprint  Once selected by the team to go in a Sprint, a User Story goes into a Sprint Backlog 21 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques User Stories detailed A concise, written description of a piece of functionality that will be valuable to a software stakeholder. As a <role>, I can <goal> so that <business value> 22 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Where User Stories Help  Value to stakeholders – Stories target functionality valuable to stakeholders – Story demos each iteration keeps stakeholders engaged  Simplified features – Stories enable light-weight requirements gathering, progressive discovery – Stories focus on feature essentials  Estimated by the team using story points  Release predictability – Stories by definition fit in time-boxed iteration – Stories that fail in an iteration provide early warning system – Cadence of story completion over multiple iterations will demonstrate release predictability 23 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Why use User Stories?  Right size for planning, works for iterative development  Defer detail until you have the best understanding you are going to have about what you really need  Focus on user goals rather than feature attributes  Emphasize verbal rather than written communication – Fixes many issues with “vague requirements”  Comprehensible by both you and the dev team  Stories support evolutionary development 24 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques User Story Roles As a <Role>, I want to <Goal> so that I can <Business value>  User role is a collection of defining attributes that characterize a population of users and their intended interactions with the system*. – Avoid “the user”; different stakeholders have different requirements – Mike Cohn recommends using roles so that you do not “miss” stories – Teams can develop a set of user roles (personas) to help define relevant stories  Examples – As a ClearCase CTO I want Access Control Lists on all my common objects to provide critical security to my confidential information. – As a Jazz Admin I want to bulk modify Access Control Lists for multiple objects to enable security updates for 1000 objects with 2 clicks. *Source: Software for Use by Constantine and Lockwood (1999) 25 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques User Story Goals As a <Role>, I want to <Goal> so that I can <Business value>  Goal is “what the user role can do” – Valuable to a stakeholder – Epics – less specific about the what – As stories are broken down, the details of what will be delivered becomes clearer  Examples – As a BuildForge Administrator I want BuildForge to be able to use virtual machines for running jobs so that I can maximize the use of my infrastructure – As a BF Admin I want to identify VMs in the server panel so that I can use existing VM servers – As a BF Admin I want a configuration for a static server manifest so that I can configure VM servers without starting them 26 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques User Story Business Value As a <Role>, I want to <Goal> so that I can <Business value>  Business value justifies the value of the story – Clarifies why a feature is useful – Can influence how a feature should function – Helps prioritize the story in the backlog  Why the “so that” Phrase Matters – As an IT manager I want my Enterprise Content Management system to be represented as a library in the Windows Explorer interface – …so that it works with existing Windows applications on my users desktops? – …so that it looks like another repository in the Explorer Interface? – …so that I do not have to train my users to use a new interface?  The real business value requested by the IT departments told us how to build the interface 27 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Overview of the Scrum process Product Owner provides prioritized Stories Product Owner sets Sprint goal Team estimates Stories Team moves Stories to Sprint Team exchanges progress in Daily Scrum Team reassesses estimates Team breaks Stories into Tasks Team produces shippable increment Team analyzes Sprint during Retrospective 28 Module NI514 ‘Chickens’ give feeback 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Sprint planning meeting *Planning Poker® Cards *image from http://store.mountaingoatsoftware.com/  Goal is to get everything ready for the Sprint  Team meeting – But stakeholders can silently assist  Filling the Sprint backlog – The Scrum team takes stories from the Product backlog – Break stories into tasks – Give estimates  The planning poker technique – All team members simultaneously provides estimates – High and low estimators briefly explain why – Repeat 3-5 times until estimates stop converging 29 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scaling using Scrum of Scrums  Scrum is a good fit for both large and small teams  Need to add a second level if: – Several interdependent Scrum teams that need to communicate – Several teams working together on a single product, with inter-dependencies. Are you about to put something in another team’s way?  Indefinitely scaled through multiple layers  Frequency & presence determined by the team – Technical contributor – No need of Product Owner or ScrumMaster, but they can assist 30 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Burndown Chart  Burndown charts quickly determine if an iteration is on track  Accessible to the team  Track work daily during iteration – Indicates whether or not iteration on track – Adjust if iteration off track – Useful in scrum meetings  In practice… – Burndown will not reach an ideal line • Work finishes sooner than planned, takes longer than planned • More tasks are added, some are removed,... – Goal is to handle deviations from the burndown line 31 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum preparation steps for success • Ready…     Get right people on board & the Scrum roles filled Fill product backlog & prioritize stories Development and test environment are ready Team knows how to transfom product stories into shippable product increments • Steady…  The team estimates the product backlog items  The product owner identifies a sprint goal and discusses the related product backlog items with the team  The team determines its availability  The ScrumMaster prepares the meeting • GO!  Project set-up for success  First sprint planning meeting can start now   32 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum projects can fail • Failure – From Wikipedia, the free encyclopedia « Failure (colloquially fail, phail or flop) in general refers to the state or condition of not meeting a desirable or intended objective. It may be viewed as the opposite of success. Product failure ranges from failure to sell the product to fracture of the product, in the worst cases leading to personal injury, the province of forensic engineering. » So you need to quickly identify Scrum Smells... 33 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum & scrum smells – Agile pratices detailed - TDD & CI  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 34 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Some reasons Scrum projects can fail (Scrum Smells)  We're Not Acting Like a Team  Specialized Job Roles  Talking Chickens  Testers will not integrate with Team  Missing Pigs  Team takes complete responsibility for testing  Status not clear from Daily Scrums  Lack of Progress  Is It Really Done?  Persistent Signatures  ScrumMaster Assigns Work  The Daily Scrum is for the ScrumMaster  No One Wants to Attend Retrospectives  Executive Pressure 35 Module NI514  Reluctance to estimate Backlog Items  Nothing Ever Gets Better Around Here  Consistently Missing Sprint Commitment  No Engineering Practices  Gorilla in the Room  Technical Debt Let's detail some smells... 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Not Acting Like a Team • Fixed Roles • Tasks are assigned • • Not helping each other • Stories aren't shared and all work is being done in parallel • No cooperation • Not listening to (and talking over) one and another during meetings No Laughter - a team that is working well together often laughs • 36 Module NI514 No mentoring is going on 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Not Acting Like a Team • Fixed Roles • Tasks are assigned • • Not helping each other Example Remedies No mentoring is going on •  Lead Stories aren'tmentor and help by example, shared and all work is being team done in paralleltheir tasks members with • No cooperation  Breakdown silos and fixed roles  Help Not listening to (and talking over) one and • change the Corporate  structure to reward team workmeetingsheros another during and not  Encourage pair programming, code • No Laughter - a team that is working well reviews and other practices that together often laughs increase co-operation and communication Scrum projects gain efficiency from the Team as a whole 37 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smells: Talking Chickens - animated  Stakeholders talk in Daily Scrums  Features selected outside of sprint planning meetings  Team cannot make purely technical decisions without an outsider’s blessing  Status reports are required outside sprint planning meetings  Executive sponsors try to influence the team  Product backlog languishes or is ignored 38 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smells: Talking Chickens - animated  Stakeholders talk in Daily Scrums Example Remedies  Features selected outside of sprint planning meetings Scrum member living the pain of a bad technical decision vs. outsiders who feel compelled to make decisions for a team 39 Module NI514  Consistently enforce the no talking rule  Team cannot make purely technical  Conduct training as part of project decisions without an outsider’s start blessing  Negotiate rules at project start  Use retrospectives to reinforcerequired outside  Status reports are expectations sprint planning meetings  Move chickens away from the pig pen  Changethe meeting time and place to influence Executive sponsors try  Maybe the chicken can lay an egg the team  Become a barnyard dog  Product backlog languishes or is ignored 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Missing Pigs • • Lack of commitment? • Supervisory interference? • Weariness? • Module NI514 Competing assignments? • 40 Unclear expectations? Fear? 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Missing Pigs • Unclear expectations? Example Remedies • Competing assignments?  Role model Lack of commitment?  Change•meeting time and location  Explanation, persuasion, and negotiation • Supervisory interference?  Embrace technology  Reorganize the team • Face-to-face meetings over paper systems 41 Module NI514 Weariness? • Fear? 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Loss of Rhythm  Inconsistent Daily Scrum ritual  Daily Scrums skipped  Meeting times vary  Inconsistent Sprint durations  Sprint duration changes arbitrarily midsprint  Inconsistent Sprint planning ritual  Skipping Sprint planning meetings 42 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Loss of Rhythm  Inconsistent Daily Scrum ritual Example Remedies  Daily Scrums skipped  Be consistent  Meeting times and  Avoid noise during Scrum varyfocus on delivery  Inconsistent Sprint durations  Clarify expectations  Conduct training  Sprint  Be consistent duration changes arbitrarily midsprint Rhythm helps make routine things routine  Resort to mommy rules  Inconsistent Sprint planning ritual  Skipping Sprint planning meetings 43 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Lack of Progress • • Features never get finished • The 90 percent complete syndrom • Revision or repair on “Completed” features • “Completed” features waiting on uncompleted features • Stakeholders complaining about lack of progress • Module NI514 Too much work in progress • 44 Backlog keeps growing instead of shrinking Missed deliveries 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Lack of Progress • Backlog keeps growing instead of shrinking Example Remedies • Good Sprint backlog management  A backlog with early visible progress, • Features never get finished early visible value, and on-time completion • The 90 percent complete syndrom  Features of great value to the customer that are easy to construct • Revision or  A “zero-defect” product repair on “Completed” features  Commitment at all times to a “potentially shippable product” • “Completed” features waiting on  A willingness to ask, “If it does not uncompleted features deliver useful working code, what good is it?” • Stakeholders complaining about lack of  Realization that bugs are not progress inevitable • 45 Module NI514 Too much work in progress Missed deliveries 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: ScrumMaster overdrives the work • • Module NI514 Team not in control of their work • 46 Work is assigned by the ScrumMaster rather than signed up for by developers The Daily Scrum feels like it is a status update from the team members to the ScrumMaster 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: ScrumMaster overdrives the work • Work is assigned by the Example ScrumMaster rather than signed Remedies up for by developers • Team not in control  Let the Team in control of work of their work  Team define assignments  Daily Scrum by Daily Scrum feels like it is a • The and for the team status update from the team members to the ScrumMaster Self-organization is one of the underlying principles of Scrum 47 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Specialized Job Roles • Project team has highly specialized job roles or descriptions such as: – Architect, – Designer, – DBA, – or Tester,… • • Module NI514 Scrum teams doesn’t show a “we’re all in this together” attitude • 48 Team includes dedicated “testers” Scrum team does not need to be comprised entirely of generalists 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Specialized Job Roles •     Example Project team has highly specialized job Remedies roles or descriptions such as: – Architect, – Designer, – DBA, Work assigned only by Team – or Tester,… Daily Scrum to re/assign work Each specialist must accept general • Team includes as a responsibility for the systemdedicated “testers” whole “I’m going to do whatever I can to • Scrum teams doesn’t show a “we’re all help” attitude in this together” attitude “We’re all in this together” attitude 49 Module NI514 • Scrum team does not need to be comprised entirely of generalists 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Reluctance to estimate Backlog • • Module NI514 No re-estimate during Daily Scrum • 50 Individuals guessimating Team refuses to play the planning poker technique 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Reluctance to estimate Backlog • • Missing releases or substantial feature reduction tracking 51 Module NI514 Individuals guessimating No re-estimate during Daily Scrum Example Remedies  (Re-) do release planning with whole planning • Team refuses to play the team poker technique  Make release burn-down visible  Retrospective focus on the difference release targets and estimation  Focus estimation on an area in which there is the clearest need for it  Use estimation to identify uncertainty  Plan spikes for areas of uncertainty  Retry estimation, review uncertainty  Make commitments based on estimates  Review how team met commitments 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Executive Pressure • • Module NI514 Executive's attend the team's meetings • 52 Executive's demand the team commit to releasing a set of "minimum" features by a certain date. Executive's communicate directly with team members to remind them of deadlines 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Executive Pressure • Executive's demand the team Example commit to releasing a set of Remedies "minimum" features by a certain date.  Speak privately with the Executive and suggest that their approach is • Executive's attend the team's likely to have the opposite of the meetings desired effect  Ask the Executive what they really need and use that to helpcommunicate directly • Executive's guide the team with team members to remind them  Get the Product Owner to negotiate of deadlines priorities with the Executive To support it, commitment has to come from the Team 53 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Gorilla in the Room • • Module NI514 People won't speak until the Gorilla has spoken • 54 One person (Sr Developer, Tech Lead, Executive) dominates conversations and meetings Team members defer to the Gorilla's opinion 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Scrum smell: Gorilla in the Room • The wisdom of the Team vs. the beliefs of a single person 55 Module NI514 One person (Sr Developer, Tech Lead, Example Executive) dominates conversations Remedies and meetings • People won't issue  Gorilla to speak last on anyspeak until the Gorilla has spoken  Ask the Gorilla to ask questions rather than making statements  Is the Gorilla a required attendee? • Team members defer to the Gorilla's Ask to be absent for a meeting or two opinion  In the case of stakeholder it may be necessary to ask to permanently leave meeting (since even without speaking they can have tremendous impact on the team) 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles – Scrum & scrum smells – Agile pratices detailed - TDD & CI  Scale & govern software delivery – Drinking our own champagne – Application portfolio management 56 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Test Driven Development (TDD)  Overview of the TDD practice Method to design software, not just a testing method.  2 simple rules* – Never write a single line of code unless you have a failing automated test. – Eliminate duplication. 1) Technique where a test case covering a code change or new functionality is written first. 2) Then just enough code to make the test pass is implemented.  TDD requires automated unit tests *From Kent Beck, author of the book Test Driven Development: By Example, Kent Beck, Addison-Wesley Longman, 2002 57 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Test-driven development cycle  TDD is a programming practice in which all production code is written in response to a test. The cycle is as follows: 1) Pick one of the requirements in your requirements list and write a test. 2) Run the test to make sure it fails. It's easy to inadvertently write a unit test that passes without putting the code in that implements the requirement. A best practice is to ensure the test fails before the implementation code is written. 3) Add or modify just enough code to make the new test and all previous tests pass. You will not run all of the tests in the project, but you will run all of the tests in the given class or package. 4) Once the new test and all the previous tests pass, refactor the code if necessary to "eliminate code smells" such as duplicated code. 5) Then, write another test. 6) Keep going until requirements are met. 7) When needed, refactor the code to “eliminate code smells”, like duplicated code, and fix any broken tests before adding any new functionality. 58 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Continuous Integration (CI) Main Characteristics  Set of software development practices, behaviours and principles  CI objectives: – For automating and improving the integration and validation of software continuously – Allowing engineers can detect and fix problems early – To deliver quality software  CI enables development teams to: – Reduce risk – Improve efficiency – Generate deployable deliverables at any time – Enable transparent view of project health – Establish greater confidence in the software product from the development team 59 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Walk-through of a Basic Continuous Integration Implementation 1) An engineer picks up a new piece of work (a defect or a new feature) 2) The engineer changes code and satisfies themselves that the code seems to work. 3) Once the engineer is satisfied that the code is unlikely to break any other code, the engineer is ready to commit/checkin/deliver their unit-tested code to the source code repository. 4) The engineer checks whether either they need to fix the broken build (a top priority) or they can move on to their next task/defect. 5) Builds can be scheduled to run a complete set of test suites against the latest set of changes. 60 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques All Continuous Integration Practices (1/2)  Build – The team can initiate a build ondemand – The team can initiate a build without human intervention – A build runs whenever code is integrated – The build fails if any test or inspection fails – Broken builds are fixed as soon as possible – The compilation and packaging of your build are automated* – Keep the build fast*  Code and Unit Test – Coding and design standards are enforced – Developers write automated unit tests* – Developers check-in unit tested code – Developers integrate code frequently * – Static analysis is part of the build  Deployment – Avoid getting broken code – Automated deployment is in the build* * Those practices above indicated by an asterisk are recommended by Martin Fowler in his paper on Continuous Integration. 61 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques A More Typical Continuous Integration Cycle 62 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery  Agility @ work – Agile principles & practises – Scrum & scrum smells – Test Driven Development  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 63 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7 Years Ago: Our Pain Points…        joining a team get my environment configured to be productive what is happening in my team Team collecting progress status awareness following the team’s process ad hoc collaboration/sharing of changes starting an ad hoc team      is the fix in the build? run a personal build Build tracking a broken build awareness why is this change in the build? reconstructing a context for a bug/build failure        interrupting development due to a high priority bug fix working on multiple releases concurrently tracking the code review of a fix referencing team artifacts in discussions Project awareness how healthy is a component? collecting project data/metrics? keeping plans up to date Module NI514 Boring and painful 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agility @ scale at IBM Pittsburg Poughkeepsie Princeton Somers Southbury NY, NY Andover Bedford, MA Bedford, NH Lexington Westborough Westford Cambridge Cork Dublin Galway Canada Toronto,Ottawa ,Montreal, Victoria London/Staines Milton Keynes Hursley Warwick York Stockholm  Over 150 Rational development projects (~2800 users) using Rational Team Concert  Plus an additional 700+ projects around IBM Paris -- hosting 8500+ users! Pornichet  Boarding time for new projects less than one day Kirkland Seattle Foster City San Francisco SVL/San Jose Almaden Agoura Hills El Segundo Costa Mesa Las Vegas Rochester Boulder Denver Lenexa,KA Tucson Pheonix Austin Dallas Lexington, KY Atlanta Boca Raton Tampa  Rational Delft Krakow Development Warsaw  Rational Customer Support China Boeblingen  WebSphere Development Beijing Cairo Rome Yamato Shang Hai  Lotus Haifa Development  Tivoli Development Fairfax  Applicable to agile/iterative andRaleigh Beaverton Charlotte waterfall projects Helsinki Taipei  IBM Research Division  IBM Global Business Services India  Bangalore IBM Systems and Pune Hyderabad Group Gurgaon Malaysia Technology Perth Singapore Gold Coast Sydney Canberra Sao Paulo El Salto Module NI514 2013 65 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agility @ scale within CLM development Teams & Products integration CLM (RRC, RTC & RQM) teams integration CDM 2011 RSA 3.0 CLM 2012 Enterprise teams (z&p) integration Enterprise teams (z&p) join Jazz Enterprise RTCz 2.0 RTCi 1.0 RTCp 2.0 RTCz 1.0 RTC & Enterprise teams (z&p) integration RRC 3.0 RQM 3.0 RTC 3.0 Enterprise RTC 1.0 2009 CLM 2011 RRC 3.0.1 RRC 4.0 RQM 3.0.1 RQM 4.0 RTC 3.0.1 RTC 4.0 Enterprise Enterprise RTC 2.0 Module NI5142008 RSA DM 4.0 Jazz 66 2010 2011 2012 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Organization of the CLM agile teams PIGS RRC dev team RTC dev team RQM dev team JFS dev team SVTests team UA team Tech Lead Tech Lead Tech Lead Tech Lead Tech Lead JumpStart team Tech Lead Release Engineering team CLM RelEng Lead CHICKEN CLM Technical Lead RRC Dev Mgr 67 Module NI514 RTC Dev Mgr RQM Dev Mgr RQM Dev Mgr CLM Development Manager JumpStart Mgr Rational Jazz ALM Director 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques RTC for System z development - back in 2007 Architect San Jose, US Mgt,Development Raleigh, US Development Paris, France Work Items SCM Build RTCz 68 68 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques RTC Enterprise Platforms development - today Subteam of the entire CLM development (RTC, RQM & RRC) Mgt, Arch, Dev Toronto, Canada UA, UX San Jose, US Mgt, Arch, UA, Dev Raleigh, US Mgt,Arch, Dev Paris, France Development Pornichet, France Development Haïfa, Israel Perf, Dev Beijing, China Work Items SCM Build CLM Arch, Dev Perth, Australia 69 69 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery – From Waterfall to Agile development – Reducing costs & risks  Agility @ work – Agile principles & practises – Scrum & scrum smells – Test Driven Development  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 70 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Organizations that effectively leverage software innovation outperform their competitors... yet few are able to deliver it effectively 86 % of companies believe software delivery is important or critical But only… 25 % of those who leverage software delivery today 69 % outperform those who don’t leverage software delivery effectively today Source: “The Software 71 Module NI514 Edge: How effective software development drives competitive advantage,” IBM Institute of Business Value, March 2013 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques And a lack of continuous delivery impacts the entire business CHALLENGES CHALLENGES Costly, error prone manual processes and efforts to deliver software across an enterprise Customers Software glitch costs trading firm Knight Capital $440 million in 45 minutes Module NI514 72 Slow deployment to development and test environments leave teams waiting and unproductive Business Owners Upgrade risk due to managing multiple application configurations and versions across servers Development/ Test New Zealand’s biggest phone company, Telecom paid out $2.7 million to some 47,000 customers who were overcharged after a software glitch Operations/ Production A bad software upgrade at RBS Bank left millions unable to access money for four days 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Patterns of challenges Differences in dev and ops environments cause failures Backlog of agile releases that Ops cannot handle Manual (tribal) processes for release lack repeatability/speed Who did this last time? Dev Daily Build Dave… Monthly Delivery Dave’s not here man… Prod Module NI514 Lack of feedback and quality metric leads to missed service level targets 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Multi-tier mobile apps present specific challenges Client Tier Devices Mobile-specific challenges: Lots of device targets Provisioning rules and artifacts Curated App Stores Dependent upon backend service versions Module NI514 Middle Tier Server Back-end Data & Services The Mobile-specific challenge in DevOps is mainly: 1.Dealing with the specific issues in the Mobile Client tier 2.And subsequently coordinating separate pipelines for each tier:  Mobile Client  Middleware  Back-end data and services 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps: The time is now Four key drivers are making DevOps an imperative for all organizations. Business Agility Cloud Computing DevOps Agile Development Operational Discipline Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Why DevOps?  Time to value – Deploy faster. Deploy Often – Reduce cost/time to deliver  Developer ‘Self-service’ – Allow Developers to Build and Test against ‘Production-like’ systems  Increase Quality – Reduce cost/time to test – Increase test coverage  Increase environment utilization – Virtualize Dev and Test Environments Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Why DevOps?  Deployment – Minimize deployment related downtime – Minimize roll-backs of deployed Apps  Defect Resolution – Increase the ability to reproduce and fix defects – Minimize ‘mean-time-to-resolution’ (MTTR) – Reduce defect cycle time  Collaboration – Reduce challenges related to Dev and Ops collaboration – Dev vs. Ops Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Stakeholders Development QA Operations – Dev and QA Environments – Production Environment Security, Data, Cloud, Enterprise Architecture… Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps definitions DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and Information Technology(IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services. -- Wikipedia Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps definitions …modern applications, running in the cloud, still need to be resilient and fault tolerant, still need monitoring, still need to adapt to huge swings in load, etc. But those features, formerly provided by the IT/operations infrastructures, now need to be part of the application, particularly in “platform as a service” environments. Operations doesn’t go away, it becomes part of the development. And rather than envision some sort of uber developer, who understands big data, web performance optimization, application middleware, and fault tolerance in a massively distributed environment, we need operations specialists on the development teams. The infrastructure doesn’t go away – it moves into the code; and the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as “DevOps. -- Mike Loukides, VP, Content Strategy for O'Reilly Media, Inc. Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques A blueprint for continuous delivery of software-driven innovation dev·ops noun 'dev-äps Enterprise capability for continuous software delivery that enables clients to seize market opportunities and reduce time to customer feedback. DevOps Lifecycle Customers Business Owners Development/Test Operations/Production Continuous Feedback and Improvements  Accelerated software delivery  Improved governance across the lifecycle  Reduced time to obtain and  Balanced quality, cost and speed respond to customer feedback 81 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps Principles and Values (the IBM view)  Develop and test against a production-like system  Iterative and frequent deployments using repeatable and reliable processes  Continuously monitor and validate operational quality characteristics  Amplify feedback loops Module NI௬௫ ௨ People Process Tools ௩௨ ௧௪ © ௩ ௨ IBM Corporation ௧௪
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Key Concepts The key technical Capabilities of DevOps 1. Continuous Integration 2. Continuous Delivery 3. Continuous Test 4. Continuous Monitoring 5. Infrastructure as Code 6. Build and Delivery Pipeline 7. Organizational Change Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 1. Continuous Integration http://bit.ly/PRQ4a7 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 2. Continuous Delivery http://bit.ly/PRQ4a7 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 3. Continuous Test http://bit.ly/PRQ9dQ Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 4. Continuous Monitoring http://bit.ly/PRQ9dQ Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 5. Infrastructure as Code/Software Defined Environment package "apache2" do   package_name node['apache']['package'] end service "apache2" do   case node['platform_family']   when "rhel", "fedora", "suse"     service_name "httpd"     # If restarted/reloaded too quickly httpd has a habit of failing.     # This may happen with multiple recipes notifying apache to restart - like     # during the initial bootstrap.     restart_command "/sbin/service httpd restart && sleep 1"     reload_command "/sbin/service httpd reload && sleep 1"    Rational Automation Framework (WAS, Commerce, MQ…) Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 6. Build & Delivery Pipeline Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Delivery Pipeline .jsp .html .java .sh Deploy chef recipes Source Artifacts Source Control Management Module NI514 Build, Package, & Unit Test Application Binaries & Platform Configuration Deployable Artifacts Environment Running System Library 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7. Organizational Change ‘Shift Left’ – Operational Concerns Build ‘Application aware’ Environments Environment Sprints NOT create a ‘DevOps Team’ Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Variants of Continuous Delivery Asset Library Asset Library Cloud Hosted Environments 1. Deploy to Dev, QA and Prod hosted on Private or Public Cloud Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Variants of Continuous Delivery Asset Library Asset Library 2. Deploy to Dev, QA and Prod hosted on Physical Servers (no Cloud) Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Variants of Continuous Delivery Asset Library Asset Library Cloud Hosted Environments 3. Deploy to Dev and QA hosted on Private or Public Cloud. Prod is on-prem physical servers (very common) Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques The Variants of Continuous Delivery Provider I Asset Library Provider II Asset Library Provider III 4. Full Software Supply Chain with in-house or outsourced providers. Each may or may not be Cloud Hosted Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps Adoption  Identify the Business Value  Build a Business Case  Create a DevOps Culture  People – Processes – Tools  Identify Capabilities to Adopt/Enhance Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps Adoption (1 of 2)  Requirements Management – Requirements Management and communication across Development and Operations  Versioning of all DevOps assets – Versioning of Deployment Scripts and Source Code  Access to Production-like Environments – Documentation of Production-like environments as Patterns – Developers have ability to launch and destroy production-like environments from these patterns  Deployment Automation – Pattern based reusable deployment scripts – Ability to deploy applications in One-step – Daily deployment and verification of applications to a production-like environment Source: 12 Steps to Better DevOps – Michael Elder Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques DevOps Adoption (2 of 2)  Change Management – Linking bugs, issues and work items to application changes – Linking production issues to associated deployment bugs  Automated Testing – Automated testing is used to validate application and platform function and characteristics  Monitoring – Monitoring Deployed applications to validate performance and reliability  Delivery Pipeline – Having a dashboard to track application stages thru the delivery pipeline and track deployment velocity Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Continuous Delivery Adoption Maturity Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Continuous Delivery flow Test Automation Execute tests Developer Tools Deliver changes Source Control and Change Management server Build Server Module NI514 Request cloud resources Provision resources Automation Agent (execute delivery process) Post results Post changes Cloud Platform Provider Publish packages Trigger delivery Retrieve packages Artifact Library Virtual System Publish packages 100 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Agenda  Evolution of software delivery – From Waterfall to Agile development – Reducing costs & risks  Agility @ work – Agile principles & practises – Scrum & scrum smells – Test Driven Development  Scale & govern software delivery – Drinking our own champagne – Continuous Integration with Agile DevOps – (Application portfolio management) 101 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Why APM Now? Insufficient strategic spend and lacking business agility  Cost – 80/20 budget trap – Maintenance and operations consumes a significant % of a declining IT budget, limiting funds available for new initiatives  Business agility – Brittle and tightly coupled architectures, unwarranted complexity, and technology proliferation  Risk / supportability – Skills erosion, baby boomer retirements, and aging technology  Strategic planning – Inability to actively plan strategic initiatives; Cloud, Mobile, Compliance, M&A, and Divestitures “A large UK bank initiated its APM effort to take a 90:10 ratio for run-the-bank / grow-the-bank down to a more reasonable 40:60 ratio. Dell shifted its maintenance-to-innovation ratio from 80:20 to 50:50.” – The Application Portfolio Management Landscape — Combine Process And Tools To Tame The Beast Phil Murphy, Forrester Research, Inc. April 15, 2011 102 Module NI514 2013 102 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Solving the problems requires a different approach “We can’t solve problems by using the same kind of thinking we used when we created them.” – Albert Einstein Addressing the problem requires an asset (application) portfolio approach to complement the traditional project portfolio approach Project Portfolio Management Application Portfolio Management  Commonly used in mature companies  Used effectively by only a few leaders  Provides executives (only)  Provides executives – Control over 20% of this year’s budget – Ability to affect this year’s project proposals – Multi-year control over 80% of the budget – Ability to generate new project proposals such as structural changes to address problems Many companies have the 80/20 rule wrong… Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Simplify IT to drive innovation and business agility Governance and collaborative decision making IT Strategy Increase strategic spend Consolidate applications to reduce maintenance and operations cost and shift funds to innovation Application Portfolio Management Delivery Management Improve business agility Reinvest savings in application modernization and effectively manage demand Demand Management Deliver and improve Deliver on projects and measure the result to improve future decision making Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques A definition of Application Portfolio Management Application portfolio management (APM) is a repeating process using information and analytics that produces objective and transparent decisions around investing, consolidating, modernizing, or replacing applications. Benefits:  Align the application portfolio with business strategies  Reduce costs and optimize value  Increase speed-to-deployment and speed-to-market  Reduce risk associated with technology or resources  Implement shared services “Making IT resource consumption transparent and understandable to business leaders enables healthy business discussions around how to shift resources to where they will do the most good for the whole business.” – Define “Application” Based On Your Content To Avoid False Starts In Your Rationalization Efforts, Forrester Research, Inc., January 26, 2011 105 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques IT optimization business outcomes APM-driven scenarios Consolidation Driver M&A, divestitures, silos Benefit Cost Payback time Short Right shore / Outsource Modernization Driver Globalization, cost Driver Brittle architectures, retention, age Benefit Cost, competency Benefit Cost, agility, reduced risk Payback time Short Payback time Medium Compliance Investment Management Driver Benefit Reduced risk Payback time Application Inventory Regulations Short Transparency, efficiency Benefit Cost, business alignment Payback time Mobile Driver Medium SLA Optimization Driver Customer demand Driver Operational complexity, cost, risk Benefit Business agility Benefit Operational cost, bus. alignment Payback time Short Payback time Short Cloud Driver Benefit Cost, flexibility Payback time Module NI514 Operational cost, fluctuations Short 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques Application Portfolio Management: Simplified workflow Yes Steering Committee Portfolio Analyst 1) Define high level goals No Review / Approve Yes 6) Analyze and set candidate dispositions 2) Create or augment application Inventory 4) Analyze and determine investigation targets Goals Yes reached? 8) Assemble proposal for reaching goals Enterprise Architect No Application Architect 3) Provide application information (wide and shallow) Application Business Owner 7) Recommend dispositions and rationalization projects 5) Provide detailed application information (narrow and deep) 9) Plan and execute rationalization projects Project Mgmt. Office Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 1) Define High Level Goals Steering Committee  High level goals established – Example: Reduce application costs by 20% by end of 2013  Explicit targets for accomplishing goals are established – Example 1: Reduce maintenance spend by 15% by end of next quarter – Example 2: Establish Goals for Decommissioning Applications, with the ability to track Plans and Actuals to those goals Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 2) Create or augment application inventory Portfolio Analyst Enterprise Architect  Rapidly import inventory from existing spreadsheets  Optionally leverage role-based Web interface for additional information entry 109 Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 3) Provide application information (wide and shallow) Application Architect Application Business Owner  Web-based entry through rolebased views  Provide filters to make data entry trivial  Increase data quality through choice selections and built in quality assurance steps Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 4) Analyze and determine investigation targets Identify applications to be further investigated Portfolio Analyst Enterprise Architect Sales Risk Control Modernize => High business score + low IT score Increase business agility through modernization Finance Discontinue => Low business score + low IT score Reduce cost through IT simplification Enterprise App Target-rich portfolio => High spend on non-strategic applications COST Reduce non-strategic spend Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 5) Provide detailed application information Focus on four dimensions Application Architect Application Business Owner  Web-based and role based information gathering  May optionally be informed by application analysis tools, such as IBM Rational Asset Analyzer or CAST Application Intelligence Platform Sample feed Rational System Architect Module NI514 Sample feed Rational Asset Analyzer  May optionally be informed by an Enterprise Architecture tool, such as IBM Rational System Architect 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 6) Analyze and set candidate dispositions Assess Business Value vs. Strategic Value to guide maintenance spend and dispositions Business Value Guidance Silver services IBM Example Gold services Gold services Application maintenance Application enhancements Decommission? Module NI514 Strategic Value Severity 1 and 2 errors only Bronze services Enhancements which impact revenue, profitability, customer satisfaction, or a demonstrable return on investment Severity 1 errors only Only enhancements bringing significant longterm value Blue services Bronze services All enhancements Silver services Blue services All errors No error corrections No enhancements Apply affordability driven Apply Portfolio Value demand management Management approach 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 6) Analyze and set candidate dispositions Assess Technical and Functional Quality to guide investments & dispositions Portfolio Analyst Enterprise Architect Low Business Value Low Strategic Value Low Business Value High Strategic Value Blue services High Business Value Low Strategic Value Bronze services High Business Value High Strategic Value Silver services Gold services Technical & Functional Quality Technical & Functional Quality Technical & Functional Quality Technical & Functional Quality H H H H TQ L 2 1 1. Retire 4 3 3. Retire L FQ 2. Retire 4. Retire H Most applications are candidates for retirements and should be frozen immediately. Module NI514 TQ L 2 4 1. Freeze 1 3 L FQ 2. Freeze / Enhance H 3. Freeze / Upgrade 4. Retire Most applications should be frozen. Consider replacement to more strategic applications. Newly introduced applications could be revalidated to stay as a target application. TQ L 2 4 1. Keep 1 3 L FQ 2. Freeze / Enhance H 3. Freeze / Upgrade 4. Replace / Upgrade Most applications could be frozen temporarily - until a need to Upgrade or Enhance has been aggregated. 2 1 1. Keep 4 3 3. Upgrade 2. Enhance TQ L L FQ 4. Replace H Many applications are likely to be in your wanted portfolio and part of your target solution. 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 6) Analyze and set candidate dispositions Propose disposition and understand savings potential Disposition Description Potential % Savings based on industry benchmarks Decommission (a.k.a. Retire) Discontinue the application. 70% of maintenance and production infrastructure cost Relocate Evaluate and select alternate sourcing for application hosting, maintenance and/or development. 40% of labor (enhancement and maintenance) + 3% of production infrastructure cost Reprioritize Reduce spend on maintenance or operations costs. 15% of maintenance labor Replace Replace current application(s) with new application / packaged application. 25% of total cost Reduce (a.k.a. Consolidate) Rationalize multiple applications with similar function into a single application. 60% of total cost Enhance Add additional functionality. Improve flexibility by using new principles, e.g. SOA, Web Services. No change Modernize (a.k.a. Rustproof) Modernize application by upgrading technology and improving architecture. 15% of labor (enhancement and maintenance) Retain Keep as-is. No change Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7) Recommend dispositions and projects Review and harden proposed dispositions Application Architect Application Business Owner  Bring together key stakeholders of this applications, and review impact of proposed disposition – What is impact of a freeze? – If we replace the application with an ERP, what is the business impact? – What risks are associated with relocating this application? – Knowing the details about the application and business context, is there a more sensible disposition?  For upgrades / modernizations => Conduct Feasibility Study – Drill down into details of the architecture and code base – Determine the appropriate modernization approach (re-factor, migrate, wrap, …) – Understand costs, benefits, and risks Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7) Recommend dispositions and rationalization projects Conduct feasibility study 1 3 Defect and Enhancement request Analysis 2 Application Complexity Analysis Module NI514 4 Business Processes and IT alignment Analysis Application Refactoring and Enhancement 2013 117 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7) Recommend dispositions and rationalization projects Define Future State architecture(s) Current Module NI514 Proposed 2013 118 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 7) Recommend dispositions and rationalization projects Produce project proposals for rationalization projects Application Architect Application Business Owner  Link Future State architectures to project proposals Expected Cost: $1.4 M Expected Benefits (accrued over 13 months after project completion: $1.9 M Net Present Value (28 months) Module NI514  Propose and establish business case for projects 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 8) Assemble proposal for reaching goals Evaluate and prioritize rationalization projects Steering Committee Project Mgmt. Office  Compare projects side by side using pair-wise comparison  Visualize project priority base on defined project criteria Module NI514 2013 © 2013 IBM Corporation
    • IBM & le développement logiciel d'entreprise Gestion de Projet - Evolution des conduites de projets informatiques 121 Module NI514 2013 © 2013 IBM Corporation