Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Fiche de révision 4MET / Partie 2

Par Marc ALLIOT Publié le 19/10/2018 à 14:59:28 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Suite de la fiche

Lien de la partie 1

https://www.supinfo.com/articles/single/8043-fiche-revision-4met-partie-1

1) A quoi sert la roue de Deming ?

C'est une méthode de gestion :

Le cycle Plan Do Check Act (PDCA), est pour améliorer la qualité en voyant simplement quelles sont les étapes à suivre.

Ce cycle permet de passer d'une idée en une action puis de l'action en connaissance.

2) Quelles sont les quatre étapes du développement ?

  • On identifie le besoin (on transforme le projet en tâche)

  • Faire l’architecture et le design (les parties qui auront des grandes choses à marcher/Qu’est ce qui marchera et ce qui ne marchera pas/les priorités)

  • La phase de développement

  • Teste, livre et on attend le retour client vis à vis du produit

3) Quels sont les critères pour avoir la transparence ?

La conduite du projet (basé sur le principe Go/No Go)

  • Ça vaut le coût « ROI »/ça ne vaut pas le coût « ROI »

  • Je continuerai/Je m’arrête ici

  • Je suis capable/Je ne serai pas capable

Pour l’utilité intérieure et extérieure (courageux)

  • Ne soit pas timide

  • N’ait pas honte

  • Dire au client/coéquipier où on en est vraiment

4) Quelle est la nécessité de la transparence ?

Sans la transparence nous pouvons aboutir systématiquement par une perte de productivité et d’efficacité.

Tout ce qui ne sera pas traité se retrouvera nécessairement sur notre route plus tard, et devra être traité avec des coûts plus élevés sans nul doute.

5) Qu'est ce que le Pair Programming ?

La programmation en binôme, une méthode de travail dans laquelle deux développeurs travaillent ensemble sur un même poste de travai, un rédige le code l’autre assiste en soulignant les imperfections, en vérifiant que le code implémente correctement le design et en suggérant des alternatives de développement.

Si celui qui code est absent l’autre peut prendre le relais d’où la nécessité de codé avec des standards pour que tout le monde se retrouve dans le code.

6) Que fait-on à la fin d’un Sprint si toutes les tâches n’ont pas été réalisées ?

  • On en discute et étudie de nouveau ces tâches dans le Sprint Retrospection Meeting qui a pour but de souligner les leçons apprises au Sprint précédent.

  • Redéfinir /Diviser en plus petite tâches

  • Continuité dans le prochain Sprint

  • Abandonner ces/certaines tâches (décision du Product Owner)

7) Quelles sont les étapes pour passer de la Vision aux Tâches ?

- Transformer progressivement la vision (cahier des charges) en N fonctionnalités

- Qui sera progressivement transformé en N User Story

- Qui sera progressivement transformé en N tâches

La vision est donc : N features => N stories => N tasks

8) Quels sont les rôles Scrum?

Il y a 3 rôles Scrum :

  • Product Owner :

    • Le client / le représentant du client

    • Celui qui va payer

    • Celui qui va utiliser le produit

    • Présent pour dire ce qu'il veut, ce dont il a besoin et quelle est la priorité

    • Le représentant des utilisateurs qui porte la vision du produit que l'on souhaite réaliser dans le cadre du projet. Il est responsable du Product Backlog et en interaction directe avec la Dev team.(en cas d’ajustement, rejet ou consentement de fonctionnalité ou priorité)

  • Scrum Master :

    • Garant du respect du cadre méthodologique Scrum.

    • Peut aussi être un membre core de la Team Dev (l’équipe de développement)

    • Il a également un rôle de coach vis à vis de la Dev Team et du Product Owner afin d’aider ces derniers à jouer pleinement leur rôle.

    • N’est pas obligatoire pour travailler

  • Scrum Team :

    • Rassemble en partenariat la Dev Team, le Product Owner et le Scrum Master.

    • Typiquement 5-9 personnes (en temps plein de préférence.)

    • Auto-géré

9) Qu'est ce qu'un Sprint ?

Intervalle de temps court (1 mois maximum, souvent appelé itération), pendant lequel la Dev Team va concevoir, réaliser et tester de nouvelles fonctionnalités.

Le but à la fin d’une Sprint est d’avoir une solution/mini-projet livrable.

Bien que Agile valorise le changement, aucun changement est accepté en dedans d’une Sprint, en dehors oui, mais pas pendant la Sprint.

10) Une fois que la Sprint a commencé, pourquoi le Product Owner ne peut pas faire de changement dans le Sprint Backlog?

On contredira le principe de Scrum qu’aucun changement est accepté en plein Sprint.

Ce changement n’a pas été estimé, étudié, remise en question et priorisé par toute l’équipe comme les autres tâches dans le Sprint Planning meeting, donc qui dit que le Product Owner n’a pas mal visionné l’importance de cette urgence.

Bien que ce changement peut être minimal, le fait de ne pas avoir eu de Sprint Planning meeting pour ce changement déraillera la Team Dev et l’intégrité du Sprint sera atténué.

Le Product Owner pourra rajouter sont changement dans le Product Backlog comme et quand il veut et cela sera étudié par la suite en dehors du Sprint.

11) Quels sont les principaux indicateurs de progrès d’un projet Scrum? Et les indicateurs de productivité ?

Les indicateurs de progrès du projet s’associent aux tâches étant :

  • Not Started

  • In process

  • Accomplish

Les indicateurs de la productivité s’associent à :

  • La durée des tâches dans le To-Do List entre la colonne « To-Do » et « Done »

  • Fluidité du Continuous Integration.

  • La Value produit par chaque Sprint, à noter que chaque user story a une value

12) Quel est le but du Sprint Review?

Sprint Review/Demonstration Meeting

  • Il faut inviter toute l'équipe Scrum, et tout ceux concernés par le projet.

  • La review est censé durer 1h00 par semaine de sprint effectué. (Donc 2h pour 2 semaines etc..)

  • But : Faire une démonstration du projet actuel et présenter le projet. Il ne faut jamais montrer au client des parties partiellement réalisées ou en cours de finalisation

  • Réunion de travail consistant à présenter aux parties prenantes les fonctionnalités terminées au cours du Sprint afin de recueillir leurs feedbacks. Et à faire le point sur l'avancement global du projet.

13) Qu’est-ce que le Extreme Programming?

Discipline de développement logiciel basé sur :

  • la simplicité (il vaux mieux faire simple et fonctionnel que de faire compliqué et demain non utilisé)

  • communication (garde une fluide communication quotidienne entre Team Dev et le Client)

  • feedback (permet de contrôler la qualité du boulot à l’instant)

  • courage (par rapport au critique négatif vis-à-vis du client)

  • respect (respect du client et de ses coéquipiers)

Extreme Programmers :

  • Travaillent en binômes ( Pair Programming)

  • Testent en permanence ( Test Driven Development / TDD)

  • Planifient grâce à la roue de Deiming, les to do lists et le planning poker.

  • Cherchent à éviter les dérives entre le besoin et ce qui est en train d'être fait. Le lien avec Agile Manifesto est la collaboration et l'implication de la clientèle et les 12 principes d'Agile poussé à l'extrême.

  • Voici 5 pratiques :

    • Rythme durable (une semaine de 40 heures) : L'équipe maintient sa capacité à rester efficace en ne surchargeant pas le planning et en s’aménageant des horaires raisonnables. Basé sur une collaboration équilibré et transparente.

    • Intégration continue : Une pratique de développement de logiciel où les membres de l’équipe intègrent/fusionnent le travail fréquemment.

    • Coding Standard/ Règles de codage : Elles donnent au code un aspect uniforme sur toute l'application, ce qui facilite le partage du code et le travail en binômes.

    • Pair Programming/ La programmation en binôme : Une méthode de travail dans laquelle deux développeurs travaillent ensemble sur un même poste de travail (un codeur/un « superviseur »).

    • •TDD / Test Driven Developement (Développement Piloté par les Tests ) : Au lieu d’écrire « le nez dans le code » on écrit les tests avant d’écrire le code ! Ecrire un nouveau test -> Constater l’échec du test -> Eliminer toutes formes de redondance et rendre le code plus simple et optimal.

14) Quels sont les trois C dans l’Extreme Programming ?

Les 3 C dans l’Extreme Programming constituent les trois aspects critiques du User Story :

  • Card : Ecrire sur une carte, le requis/besoin simple et essentiel -> Le Qui, Quoi et Pourquoi

  • Conversation : C’est les échanges entre le client et l’équipe de développement à propos de la durée complexité, les fonctionnalités, le raisonnement…

  • Confirmation : C’est le fait que le client accepte la livraison du produit et qu’il valide que le produit correspond à ses besoins définis dans la carte.

15) Qu’est-ce que la Business Value ? Qui l’assigne. Quel est le but de cette Value?

  • La valeur attribuée à une tâche symbolisant le niveau d’importance de cette tâche pour l’utilisateur.

  • C’est le Product Owner qui l’assigne.

  • Grâce à la Business Value, la Team Dev comprend toute suite le cœur du métier et la vision du Product Owner.

  • Les tâches seront mieux ordonnancée dans le Product Backlog, tâches ordonnancée par Business Value et par complexité. La Team Dev traite les tâches selon l’ordre de simplicité et haute importance, on vise ce qui rapporte et qui est simple

16) Qu’est ce le Lean IT/ Lean software développement ?

C'est l’adaptation au monde IT des principes qui ont fait le succès de Toyota.

Il y a alors 7 principes :

  • On élimine toutes les sources de gaspillage (la simplicité) jusqu’au point d’éliminé les commentaires du code

  • Amplifie/Favoriser l’apprentissage, es développeurs s’améliorent

  • Reporter la décision, se décider au dernier moment

  • Livre au plus vite pour un Fast feedback

  • Responsabiliser l’équipe, rendre l’équipe habile : Motivation, environnement convenable…

  • Incorporer un travail complet, construire la qualité, viser l’excellence, la discipline…

  • Avoir une vision complète de l’ensemble, une attitude holistique, une vue Produit & Valeur plutôt que strictement projet.

17) Qu’est-ce que le Planning Poker ?

  • C'est une technique d'estimation collective.

  • Chaque élément du Product Backlog (revoir la partie sur le Product Backlog) est estimé collectivement en se basant généralement sur l'unité appelée « Story Point » visant à mieux définir la priorité de chaque User Story.

  • Suite au choix d’unité (complexité, priorité, durée…)

  • Chaque personne assigne une valeur (suite Fibonnaci par exemple) à une User Story et on se met d’accord démocratiquement sur une valeur finale.

18) Quelle est la différence entre le Product Backlog et Sprint Backlog ?

  Product Backlog Sprint Backlog
Définition Liste ordonnancée (priorisée) des besoins (généralement formulés sous forme de User story) du projet. Répond au « Qu’est ce qui va/droit être développer » Une liste de quelque tâche du Product BackLog que nous avons décidé de traité pendant le Sprint pour répondre à un Sprint Goal. Répond au « Quelle partie du projet est en train d’être développé »
Différence Gérer et déterminé par le Product Owner en relation avec la Team Dev et le Scrum Master. Le Product Owner a le droit de le modifier à tout moment Gérer et déterminé par la Team Dev et le Scrum Master en relation avec le Product Owner. N’accepter aucun changement en plein Sprint

19) Comment passer d'un Sprint à un nouveau cycle ?

  • Le Scrum Master fait généralement une rétrospective du sprint

  • On définit un nouvel axe à développer.

  • Les tâches à effectuer, l'axe principal sera composé de 2 ou 3 parties à améliorer, on dirait les plus importantes avant de refaire un cycle de sprint.

Sources

Les sources utilisées pour cet fiche / article sont les cours de Supinfo 4MET.

Des recherches complémentaires ont été effectuées afin de confirmer certains doutes liés à la compréhension des cours Supinfo.

Il est possible que certains points aient déjà été abordés dans la première partie.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels