• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Aborder la transition vers l'agilité
 

Aborder la transition vers l'agilité

on

  • 1,010 views

Présentation faite chez Valtech au moment où la transition vers l'agilité était à l'ordre du jour

Présentation faite chez Valtech au moment où la transition vers l'agilité était à l'ordre du jour

Statistics

Views

Total Views
1,010
Views on SlideShare
763
Embed Views
247

Actions

Likes
0
Downloads
0
Comments
1

3 Embeds 247

http://addinquy.tumblr.com 149
http://freethinker.addinq.uy 93
http://www.linkedin.com 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Présentation sur la transition vers l'agilité:
    - Pourquoi aller vers l'agilité ?
    - Qu'est-ce que c'est ?
    Présentation assez ancienne (2006) faite alors que j'étais chez Valtech.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Aborder la transition vers l'agilité Aborder la transition vers l'agilité Presentation Transcript

    • Transition vers l’agilité5 & 18 Octobre 2006Greg Hutchings & Christophe Addinquy
    • Pourquoi l’agilité ?Pourquoi l’ancien modèle est-ilinadapté… « La logique est l’art de s’enfoncer dans l’erreur avec confiance » Joseph Wood Krutch
    • L’ancien modèle: un paradigme inadapté Production de masse • Processus en cascade • Plan détaillé • Etapes prédéfinies Développements de Préparer nouveaux produits • Approche empirique et Faire expérimentale • Processus évolutif et adaptatif Adapter 3
    • Caractéristiques d’un projet classique Projet classique Ces caractéristiques peuvent Etablir et suivre un plan s’appliquer (et s’appliquent souvent !) à des développements itératifs Avancement défini par des livrables intermédiaires Assignement des tâches Solution imposée 4
    • Des fonctions inutiles Taux d’utilisation des fonctionnalités développées sur les projets classiques [Johnson02] 5
    • Pourquoi l’agilité ?Pourquoi elle est une réponse « La logique est l’art de s’enfoncer dans l’erreur avec confiance » Joseph Wood Krutch
    • Critères de succès des projets Les facteurs de succès principaux [Standish98], sur 23000 projets! • Implication fréquente des utilisateurs • Jalonnement fréquent • Objets métier clairs • Chef de projet expérimenté • Support du management 7
    • Une recette magique ?Q: What are the most exciting, promising software engineering idea techniques on the horizon ?R: « I don’t think that the promising ideas are on the horizon. They are already here, and have been for years, but have not being used properly ». David L. Parnas Facteurs clés des environnements hyper-productifs: • Développement itératif. • Organisation simple, moins de rôles qu’à l’ordinaire (polyvalence). • Equipe soudée et de petite taille • L’architecte a été un développeur • Forte composante communication • Le noyau a été développé en premier, par une équipe très aguerrie. 8
    • L’agilité est le « nextbigthing » !UML est un acquis, plus une innovation  Il n’est plus une nouveauté que pour les « retardataires »Elle est la solution à la crise chronique du logiciel (fonctionnalités /coûts / délais)Elle représente, non pas une évolution, mais un changement devaleurs, par rapport aux processus classiques. 9
    • Qu’est-ce que l’agilité ? « Just do it ! » Nike
    • Des valeurs aux pratiques Ce en quoi nous croyons Valeurs Les lignes directrices Principes La boite à outils Pratiques 11
    • Donner le rythme au projet Priorité aux personnes et aux interactions • Plutôt que sur les processus et les outils .L’accent est mis sur les individus, leur expertise, l’esprit d’équipe plutôt que sur les processus et les outils Des applications fonctionnelles opérationnelles • Plutôt qu’une documentation pléthorique. On privilégie le code testé Collaboration avec le client • Plutôt que négocier un contrat. Le client devient un partenaire qui participe au projet pour donner régulièrement son feedback Réactivité au changement • Plutôt que suivre un plan. Le planning est flexible pour accepter les modifications Voir le Manifeste agile, sur nécessaires. www.agilealliance.org 12
    • Processus agile == solution miracle ? Non ! « Process is a second order effect ». Alistair Cockburn De très loin, le facteur ayant le plus d’influence sur la réussite des projets est le facteur humain ! 13
    • Les principes •Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. •Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. •Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. •The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. Agile processes promote sustainable development. •The sponsors, developers, and users should be able to maintain a constant pace indefinitely. •Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 14
    • Le marché aux pratiques Une cause d’échec des méthodes agiles est la tentation de « faire son marché » parmi les pratiques L’agilité est basée sur des valeurs et des principes, plus que sur des pratiques Les pratiques doivent êtres adaptées  Utilisées si nécessaires  Abandonnées lorsqu’elles n’apportent plus de valeur  Adaptées lorsqu’elles ne correspondent pas au contexte  « Inspect and adapt », principe des rétrospectives. Se donner comme objectif d’adopter des pratiques détourne de l’objectif final qui est la livraison du produit fini 15
    • Adopter une méthodeagile « I have a dream… » Martin Luther King
    • Les principales méthodes agiles Extreme Programming Scrum Lean Software Development DSDM Crystal 17
    • Ce qui émerge 18
    • Scrum (1 / 4) Origine • Basée sur les travaux de Nonaka et Takeuchi en 1986 • En 1993, Jeff Sutherland et Ken Schwaber ont développé les pratiques initiales de Scrum. Principales pratiques • Élaboration et mise à jour d’un planning produit (product backlog) • Des itérations de 30 jours (sprint) • Planification de chaque itération (sprint backlog) • Réunion d’avancement quotidienne (scrum meeting) • Isolement des développeurs (face au chaos extérieur) • Revue de fin d’itération (sprint review meeting) 19
    • Scrum (2 / 4) 20
    • Scrum (3 / 4) Organisation • Des « feature teams » (et non des modules !)  Une feature représente une tranche de fonctionalité utilisateur. • Des équipes « cross-fonctionnelles »: la polyvalence est encouragée, mais des experts peuvent exister 21
    • Scrum (4 / 4) Les livres 22
    • Lean : Origines (1 / 3) Le Toyota Production System • L’agilité a vaincu le taylorisme depuis le premier choc pétrolier ! 23
    • Lean Software Development (2 / 3) Les principes • Traquer les déchets • Effectuer les tâches en petits • Focalisation sur la lots, à la demande production de valeur pour les utilisateurs • Voir le système dans son • Le manager est intégralité (pas d’optimisation facilitateur locale) • L’équipe est au cœur du processus d’amélioration • Retarder les décisions (laisser les options ouvertes) • Equipe soudée et motivée (jelled team) • Apprendre et améliorer le processus en continu (Kaisen) • Manager qui écoute et règle les problèmes de son équipe (Gemba). 24
    • Lean Software Development (3 / 3) Les livres 25
    • Merci