Processus 2 Flashcards
(56 cards)
Comprendre le contexte qui a mené à l’agilité en développement logiciel et pourquoi on a voulu l’accélérer
➢ Le monde des affaires opère de plus en plus dans un environnement globalisé où:
1) le logiciel est omniprésent;
2) la vitesse de réponse aux opportunités et aux conditions changeantes devient cruciale.
➢ En raison de ce nouvel environnement d’affaires en mouvance, il devient souvent impossible d’obtenir un ensemble de requis stables. Il faut parfois une première version du logiciel avant de comprendre tous les besoins des utilisateurs.
➢ Le besoin de méthodes pour un développement logiciel rapide est connu depuis 1980. Il s’agit de développer du logiciel utile rapidement.
Pouvoir expliquer les valeurs de l’agilité
- Les individus et les interactions priment sur les processus et les outils: on sentait que les expertises étaient moins importantes et avant le focus était surtout sur le processus, alors qu’il est important de miser que le potentiel de créativité, l’expertise et la communication
- Les logiciels opérationnels priment sur la documentation compréhensive: revenir au code et aux artéfacts plutôt que juste se concentrer sur la documentation
- La collaboration avec le client priment sur la négociation d’un contrat : impliquer les clients dans le travail et ne pas les voir seulement comme ceux qui donne le travail, collaborer activement avec
- L’adaptation aux changements priment sur le suivi d’un plan: voir les changements comme des opportunités
Les principes de l’agilité
- Satisfaire le client est la priorité (vérifier la satisfaction et être en interaction)
- Accueillir les demandes de changement
- Livrer le plus souvent possible des versions opérationnelles de l’application
- Assurer une coopération permanente entre le client et l’équipe du projet
- Construire des projets autour d’individus motivés
- Privilégier la conversation en face à face
- Mesurer l’avancement du projet en termes de fonctionnalités de l’application
- Faire avancer le projet à un rythme soutenable et constant
- Porter une attention continue à l’excellence technique et à la conception
- Favoriser la simplicité
- Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
Ajuster, à intervalles réguliers, son comportement pour être plus efficace
Comprendre l’agilité par rapport à l’organisation systématique du travail et la responsabilisation des développeurs
En développement logiciel, les pratiques agiles mettent en avant la collaboration entre des équipes autoorganisées et pluridisciplinaires et leurs clients. Elles s’appuient sur l’utilisation d’un cadre méthodologique léger mais suffisamment centré sur l’humain et la communication. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement
inconvénients des approches structurées
➢ Les approches disciplinées, à moins d’être judicieusement adaptées, impliquent un effort important de planification, de conception et de documentation.
➢ Pour les petits et moyens projets, cet effort devient trop important relativement à l’effort total de développement et peut même dominer le processus.
inconvénients des approches agiles
➢ Difficultés d’application:
▪ La collaboration active du client est difficile à obtenir.
▪ Lorsque l’équipe de développement souffre d’un manque de cohésion entre ses membres.
▪ La difficulté à maintenir la continuité de l’équipe de développement.
▪ Lorsqu’il y a plusieurs intervenants et que ceux-ci priorisent des requis différents.
▪ Maintenir la simplicité demande davantage de travail.
▪ Les grandes organisations ont mis des années à implanter un processus structuré. Elles sont résistantes au changement.
▪ Les cycles d’évolution lors de projet de maintenance seront plus coûteux puisque l’absence de documentation ralentit le travail (dans le cas du document de spécification en particulier).
Droits du client en EP
- Droit du client:
➢ Vous avez le droit de changer d’avis, de substituer des fonctionnalités et de changer des priorités.
▪ Pour maximiser votre investissement.
➢ Vous avez le droit de voir l’avancement du produit, prouvé par des tests d’acceptation répétables.
➢ Vous avez le droit d’être informé de changements de planification à temps pour choisir les solutions pour respecter vos échéances. Vous pouvez même annuler à tout moment le développement du produit et garder le résultat du travail reflétant l’investissement jusqu’à date.
Devoirs du client en EP
- Devoirs du client:
➢ Faire confiance aux décisions techniques des développeurs
➢ Analyser les risques des récits adéquatement
➢ Choisir les récits ayant le plus d’impact
➢ Fournir des récits précis
➢ Travailler au sein de l’équipe
droit du développeur en EP
- Droit du développeur:
➢ Vous avez le droit de dire combien de temps chaque récit vous prendra pour l’implémenter ainsi que de réviser les estimations.
➢ Laisser au client les décisions d’affaire.
➢ Vous avez le droit de produire un produit de qualité à tout moment, qui satisfait les besoins du client.
➢ Vous avez le droit à un travail productif, agréable et amusant, avec un horaire prévisible et sensé
Devoirs du développeur
➢ Suivre les directives de l’équipe pour que le système soit simple et bien testé.
➢ Développer uniquement ce qui est demandé pour garder le projet simple et de grande valeur pour le client.
➢ Communiquer constamment avec le client pour comprendre ses enjeux et lui fournir l’information nécessaire à ses décisions.
Connaître les valeurs de la méthode agile XP
Les valeurs XP:
▪ Communication
▪ Simplicité
▪ Rétroaction
▪ Courage
▪ Respect (2004)
Connaître les pratiques de la méthode agile XP
Pratique:
Vue Client :
➢Équipe tout entière
▪ S’asseoir ensemble – On travaille dans un espace ouvert qui peut contenir toute l’équipe.
▪ Client présent – Le client est assis avec l’équipe à plein temps. C’est un membre de l’équipe.
▪ Espace de travail ouvert et informatif – L’espace de travail devrait être consacré au projet. .
➢Tests client
▪ Récit utilisateur – Une fonctionnalité que le client désire avoir.
▪ Tests client – Tests conçus par le client qui lui permettent de vérifier le progrès du développement.
➢Jeu de planification - Le client décide le but et la planification des livraisons en se basant sur les évaluations fournies par des développeurs. Ceux-ci font l’implémentation seulement de la fonctionnalité exigée par les récits de cette itération.
1) Release planning
2) Iteration planning: features -> tâches
➢Livraisons fréquentes - Le système est mis en production immédiatement, l’ensemble minimal de requis offrant une valeur marchande est implémenté. Le système peut être intégré une ou plusieurs fois par jour. Un livrable est remis au client à toutes les deux semaines environ.
Vue Équipe :
➢Intégration continue - Le nouveau code est intégré avec le système très rapidement. Tous les tests doivent être réussis sinon les fonctionnalités sont éliminées.
➢Propriété collective - Les programmeurs améliorent n’importe quelle section du code, n’importe où dans le système, à tout moment, s’ils en voient l’occasion.
➢Métaphores - Le système est défini par une métaphore ou par un jeu de métaphores partagées entre le client et les programmeurs. Une métaphore est une histoire que chacun peut raconter en se référant au système.
➢Standard de programmation – Pour faciliter la compréhension du code.
➢40-heures semaine (rythme soutenable) - Personne ne peut travailler d’heures supplémentaires.
Vue Programmeur
➢Développement piloté par les tests (TDD) - Les programmeurs écrivent les tests unitaires avant de coder. Les clients écrivent les tests fonctionnels pour les récits de l’itération.
➢Programmation en paire - Tout le code de production est écrit par deux personnes à un écran / clavier / souris
➢Réusinage - La technique de transformation de code pour l’améliorer sans modifier le comportement. Cette pratique est concourante à l’implémentation.
➢Conception simple – On fait juste assez de design pour implémenter les requis de l’itération courante. Pas plus. On reporte les décisions pour lesquelles on n’a pas d’information
Définir ce qu’est un récit utilisateur
3 aspects aux récits utilisateur:
- Une description écrite du récit
- Des conversations à propos des récits qui servent à fournir les détails
- Des tests qui documentent les détails et qui servent à déterminer si l’implémentation du récit est complétée
Avantages des récits utilisateur
- Encouragent la communication verbale plutôt qu’écrite
- Sont très faciles à comprendre
- Ont une taille parfaite pour l’estimation et la planification
- Conviennent très bien à du développement itératif rapide
Encouragent d’attendre qu’on soit rendu à leur implémentation avant d’obtenir trop de détails
Connaître les attributs de bons récits utilisateur (INVEST)
Attributs de bons récits
- Indépendant: éviter d’introduire des dépendances entre les récits
- Négociable: les récits ne sont pas des contrats
- A de la valeur pour le client/utilisateur: il faut éviter les récits orientés vers les développeurs, le client peut être à l’origine de contrainte quand meme
- Estimable: effort estimé par l’équipe
- Petit
- testable
Connaître les méthodes pour obtenir les récits utilisateur et comprendre les conseils d’écriture des récits
➢ Les techniques pour obtenir les récits (trawling selon Cohn) sont les mêmes que pour le processus unifié.
▪ Des entrevues avec des utilisateurs
▪ Des questionnaires
▪ De l’observation
▪ Des ateliers d’écriture de récits
1. Commencer par les buts des récits Dans les grands projets, il est parfois difficile de savoir par quoi commencer. On suggère alors de considérer chacun des types d’utilisateur et de déterminer leurs motivations (leurs objectifs) à utiliser le logiciel
2. Couper une tranche du gâteau Il existe plusieurs façons différentes de diviser un récit trop vaste. La tendance des développeurs est de diviser un récit selon les frontières techniques. Les récits doivent avoir de la valeur pour le client. La fonctionnalité doit passer à travers toutes les couches
3. Écrire des récits fermés Le récit doit pouvoir se fermer, c’est-à-dire que le récit se termine en ayant atteint un ou des objectifs significatifs. Savoir quand c’est terminé et on peut donc le tester
4. Spécifier les contraintes Une catégorie spéciale de récits sont les contraintes. Celles-ci correspondent aux spécifications supplémentaires.
5. Se tenir loin du GUI aussi longtemps que possible.
6. Ne pas être dogmatique. Certaines exigences (comme des détails d’interface) se communiquent mal par récit utilisateur.
7. Écrire un récit pour un seul utilisateur. (ne pas utiliser le pluriel)
8. Utiliser le style actif plutôt que passif.
9. Insister pour que le client écrive les récits.
10. Ne pas numéroter les récits.
Savoir comment utiliser les récits utilisateur pour estimer et planifier un projet de développement logiciel
➢ Les récits sont estimés par les développeurs en termes de points. Ces points sont des valeurs relatives qui se réfèrent à la complexité, à l’effort et à la durée d’un récit.
➢ Les estimations sont faites par l’équipe et sont la responsabilité de l’équipe entière et non des individus.
➢ L’ordre de grandeur se compare à la vélocité. La vélocité correspond au nombre de points que l’équipe peut ou planifie compléter en une itération.
➢ En considérant les estimations, le client priorise les récits en fonction des livraisons et des itérations.
Connaître le fonctionnement de la méthodologie Scrum
Il y a trois phases dans SCRUM:
1. Une première phase de planification.
2. Une série de cycles de sprint. (un peu comme une itération)
3. Une dernière phase de clôture du projet.
Connaître les rôles de Scrum et leurs responsabilités
Les différents rôles sont:
▪ le propriétaire du produit: chargé de maximiser la valeur du produit et le travail de l’équipe. Il gère le carnet de produit (les exigences) en: ▪ exprimant clairement les items du carnet; ▪ hiérarchisant les items du carnet afin d’atteindre les objectifs du projet; ▪ s’assurant que le travail de l’équipe est de qualité;
▪ le SCRUM master: responsable de la compréhension et de l’application de SCRUM. ▪ Il est un facilitateur qui organise les mêlées quotidiennes. ▪ Il fait le suivi du travail restant à faire. ▪ Il garde une trace des décisions d’équipe. ▪ Il mesure le progrès. ▪ Il communique avec le client et l’organisation. est un meneur au service de l’équipe (Servant leader). Il sert le gestionnaire de produit. Il sert l’équipe de développement. Il sert l’organisation.
▪ les développeurs: st structurée et habilitée par l’organisation à organiser et gérer son propre travail. ➢ L’équipe de développeurs est: ▪ Auto-organisées ▪ Pluridisciplinaires ▪ Sans titre particulier pour les individus ▪ N’est pas divisée en sous-équipes avec des responsabilités particulières. ▪ Il peut exister des spécialisations, mais la responsabilité du projet est indivisible et incombe à tous
Connaître les événements de Scrum
➢ Évènement 1: La réunion de planification du sprint
▪ La réunion de planification regroupe toutes les parties prenantes du projet. On y décide de l’objectif du sprint en termes d’items du carnet de produit.
▪ L’équipe de développement assemble ensuite un carnet de sprint (sprint backlog) qui contient la liste de toutes les tâches à faire pour atteindre l’objectif du sprint
➢ Évènement 2: Le sprint ▪ 15 à 30 jours d’analyse, de conception, d’implémentation et de tests pour atteindre l’objectif du sprint. ▪ Il y a des mêlées quotidiennes à chaque jour.
➢ Évènement 3: La revue de sprint ▪ Inspection en fin de sprint de l’incrément du produit et adaptation du carnet de produit si nécessaire. ▪ C’est une analyse et une démonstration de ce qui a été fait, avec les intervenants, pour réfléchir aux prochains items à être développés.
➢ Évènement 4: La rétrospective de sprint ▪ Inspection de la manière dont s’est déroulé le dernier sprint
▪ On crée un plan pour améliorer les processus de travail de l’équipe SCRUM.
➢ Évènement 5: Les mêlées quotidiennes sont: ▪ Une réunion de 15 minutes pour planifier les prochaines 24 heures. Habituellement en stand-up. ▪ Un partage d’information où l’on décrit les problèmes rencontrés, garde trace du progrès accompli (burndown chart) et fait la planification de la journée. ▪ Un mécanisme permettant à tout le monde de participer dans la planification. Le SCRUM master n’est pas celui qui assigne le travail. Il est la personne ressource pour les problèmes.
Le SCRUM prône l’auto-organisation des équipes
Connaitre les 3 phases du SCUM
Phase 1: Lancement:
Il y a deux sous-phases:
▪ Planification: * Produire la liste initiale des requis du système (carnet de produit, product backlog). * Analyser les risques associés au projet. * Estimer et obtenir les ressources nécessaires pour le projet de développement. * Déterminer le calendrier général du projet.
▪ Architecture / Conception de haut-niveau: * Déterminer une architecture minimale pour le système qui intègre les requis actuels du carnet de produit.
Phase 2: Développement
➢ Les sprints ont une durée fixe. 2 à 4 semaines
➢ Le point de départ de la planification est la liste du travail à faire. Lors de l’étape d’évaluation (assess), cette liste est revue, des items sont priorisés et des risques sont identifiés. Le client est impliqué et il peut donner de nouveaux requis.
➢ Lors de la sélection (select), toute l’équipe choisit les fonctionnalités et les features à développer lors de ce cycle de sprint. Elle les regroupe dans un carnet d’itération (sprint backlog).
➢ Lorsqu’on s’entend sur le travail à faire, l’équipe s’organise elle-même pour développer (develop) le logiciel. Il y a des mêlées quotidiennes impliquant toute l’équipe. L’équipe est isolée de l’organisation, tout passe seulement par le SCRUM master.
➢ En fin de cycle, le travail est révisé et présenté aux intervenants (review).
Phase 3: Fin du projet
➢ Travail final d’intégration des sprints si nécessaire.
➢ Derniers tests systèmes.
➢ Préparation de la documentation pour l’utilisateur.
➢ Formation des utilisateurs.
➢ Tests d’acceptation.
➢ Déploiement du système.
Connaître les artefacts de Scrum
- Product Backlog
- Sprint Backlog
- Produit
Connaître les forces et les faiblesse de Scrum
Forces:
➢ Développement rapide et économique.
➢ Processus itératif-incrémental
➢ Les requis sont évolutifs. Processus très adaptatif.
➢ Implication d’un client/utilisateur.
➢ Processus simple, sans overhead de planification
➢ Encourage les livraisons fréquentes de fonctionnalités au client.
➢ Plusieurs occasions pour identifier des problèmes et les régler en équipe.
Faiblesses:
➢ S’ajuste difficilement à des équipes au-delà de 12 personnes.
➢ Problématique si le SCRUM master est un chef de projet déguisé qui devient directif.
➢ Les communications doivent être constructives et honnêtes.
➢ Des itérations courtes peuvent mener à une négligence des tests.
➢ Facile de perdre la perspective globale du projet en se concentrant sur les détails des fonctionnalités.
➢ La qualité n’est pas toujours au rendez-vous.
Savoir expliquer les attitudes et les compétences attendues chez les professionnel.le.s du code (savoir dire non, savoir s’engager, connaître sa relation au code, kata, l’importance des tests dans la pratique, gestion du temps, communication des estimations, etc).
➢Savoir dire non.
▪ La tentation de jouer les héros et de résoudre le problème est grande. Mais abandonner ses disciplines professionnelles n’est pas une façon de solutionner les problèmes.
➢Dire oui est un engagement.
▪ Les professionnels n’ont pas à dire oui à tout, mais quand ils disent oui, ils s’engagent réellement en utilisant un langage qui ne laisse aucun doute sur leur engagement.
➢La façon d’écrire du code.
▪ Le code de 3h du matin, le code soucieux, le syndrome de la page blanche, être dans la zone.
➢TDD offre tellement d’avantages qu’il est pratiquement non professionnel de ne pas l’utiliser.
➢Un professionnel pratique sa discipline. Seul ou en groupe, il pratique des coding dojo. Exemple: kata et wasa
