Translate

mardi 27 novembre 2012

M - Scrum : le Product Backlog


LE PRODUCT BACKLOG EST LE COEUR DE SCRUM

Le product Backlog qu'est ce que c'est ?

Et bien, il s'agit d'une liste d'exigences formulée par les métiers ou les clients qui permettra de réaliser un produit fini.

Ces exigences peuvent être écrite sous forme d' histoire (Storie)

Ces histoires doivent être priorisée avec le métier ou le client afin de déterminer celles qui seront embarquées en premier.

Exemple d'histoire :

En tant que client
Afin de réaliser des actions sur mes items via l'application 
Je souhaite accéder à une page d'accueil en mode connecté me présentant les 5 actions possibles dans l'application
  • Créer un item
  • Mes items en cours de création
  • Mes items créés
  • Mon fichier de contacts traité
  • Ma consommation
Chaque historie du Backlog est associé à des tests d'acceptation qui permettront de valider le contenu de l'histoire et ainsi de la valider auprès du client lors de la démonstration.

La maquette de l'écran lié à l'histoire dans ce cas 



Exemple de tests d'acceptation de l'histoire ci-dessus

Quand j'accède à la page d'accueil
Alors je visualise la disposition des informations tel que décrit dans la maquette

Quand je clique sur les boutons des items ci-dessous
- Mes items créées
- Mon fichier de contacts traité
- Ma consommation
Alors je suis redirigé vers la page liée (Les pages seront finalisées ultérieurement)

Quand j'accède à la page d'accueil
Alors en haut à droite je visualise la civilité et le nom du contact client

Quand j'accède à la page d'accueil
Alors je visualise en haut de la page un encart comportant un message de suppression du 5ème item sous forme de lien

Quand je clique sur le lien du nom du 5ème item qui sera supprimée
Alors j'accède à la page "Mes campagnes en cours de créations"

Quand je clique sur le bouton "Fermer ce message"
Alors l'encart disparaît de la page d'accueil

Quand je coche la case à cochée "Ne plus afficher ce message" et je clique sur le bouton "Fermer ce message"
Alors suite à ma reconnexion  ultérieure, l'encart d'alerte sur les 5 item en cours n’apparaîtra plus.

Quand je clique sur le lien "Changement de mot de passe"
Alors je suis redirigé vers la page "Changement Mdp"

Quand je clique sur le lien "se déconnecter"
Alors je suis redirigé vers la page d'accueil avant authentification.(Je dois de nouveau m'identifier)

Quand il n' y pas évènement sur l'application au delà de 10 mn
Alors je suis déconnecté et je retourne sur la page d'accueil avant authentification (time out)


vendredi 16 novembre 2012

L - Scrum : Les rôles

Le rôle du Product Owner

Le Product Owner ou PO dans un projet agile scrum est une pièce maîtresse.Il fait le lien entre
    - les objectifs de l'entreprise
    - les besoin des clients
    - l'équipe qui réalise le projet




Le product owner est le propriétaire du produit car il représente les commanditaires, donneurs d'ordre sur toute la durée du projet.
    - Il est le seul à prendre des décisions sur la réalisation du produit.
    - Il construit et porte la vision du produit en fonction des objectifs de l'entreprise
    - Il liste et ordonne les besoins clients en fonction de la valeur business et les fonctionnalités qui répondent à ces besoins


Le rôle du Scrum Master 

Dans le fonctionnement de Scrum, il faut adopter un état d'esprit différent, un regard nouveau sur le travail et son organisation.
Chaque membre de l'équipe doit adopter ce nouveau regard car la qualité du mode de fonctionnement de l'équipe est un point essentiel pour devenir agile.
Le rôle du Scrum Master est essentiel, il est le facilitateur, le référent et le protecteur de l'équipe tout en étant dans l'action du développement.
Il doit véhiculer l'état d'esprit et les valeurs de Scrum  afin d'obtenir l'adhésion de l'équipe.

L'équipe 

- conçoit et met en oeuvre les solutions les plus simples et adaptées qui répondent aux exigences du client
- estime le travail à réaliser pour chaque storie répertoriée dans le Backlog produit
- s'engage à mettre toute l'énergie nécessaire ainsi que les moyens mis à sa disposition pour mener à bien le sprint
- présente les résultats du sprint lors de la démonstration au product owner
- se charge de livrer les releases sur les environnements nécessaires
- prend en charge la résolutions des anomalies pendant les différents tests menés



K - Scrum : Le mode fonctionnement

Le fonctionnement


L'approche Scrum peut vous paraître très structurée pourtant cette structure est particulièrement souple et s'adapte à tous types de projet.

C'est à l'équipe de s'approprier les outils mis à sa disposition et de les adapter à son mode de fonctionnement.

Les projets Scrum fonctionnent par itération.
Ces itérations sont des cycles courts d'une durée fixe ( 1, 2 ou 3 semaines)
Ces itérations sont appelés des sprints, et l'équipe se focalise sur la réalisation d'un ensemble de tâches qu'elle a déterminé.

Les cérémonies ou réunions de l'équipe scrum 


Le sprint planning (Backlog) : Réunion réalisée en début de sprint qui permet de prioriser les items du backlog (Backlog de sprint) et d'identifier les items qui seront embarqués sur le sprint
  
Objectifs : 

        - Donner toutes les informations à l’équipe pour le prochain sprint
             - le but à atteindre
             - la liste de participants au Sprint
             - le Sprint Backlog (la liste des User Stories à traiter)
             - la date de démo
             - Le lieu de la réunion Scrum quotidienne.
       - Participation active du Product Owner
       - Engagement mutuel sur le contenu du sprint





Le poker planning : réunion permettant d'estimer en point les items du backlog.
Cela permet d'estimer l'effort nécessaire pour produire le contenu de l'item


Le daily Scrum ou scrum meeting : réunion quotidienne de 15 mn maximum permettant de faire un état des lieux des tâches réalisées la veille et les tâches qui seront réalisée dans la journée
Elle permet aussi d'aborder les questions et les obstacles rencontrés

Objectifs : 


       - Réunion quotidienne de 15 minutes       
       - Toute l’équipe intervient pour exposer
            - Ce que j’ai fait hier et les éventuels problèmes rencontrés
            - Ce que je vais faire aujourd’hui
            - Est ce que j’ai des difficultés pour continuer mon travail.           
            - En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés.           
      - Le Scrum Master apporte des solutions aux problèmes rencontrés            
      - Actualisation de l’avancement

Le sprint review comprend deux étapes : 

     La démonstration : réunion de fin de sprint qui permet de montrer le travail réalisé au client et de confirmer ou d'infirmer la validation du travail par rapport à l'attendu

     Le rétrospective : réunion permettant à l'équipe de passer en revue les méthodes de travail utilisées pendant le sprint et de mettre en place des plans d'action dans l'optique de l'amélioration continue

  Objectifs :

       - Réunion de clôture du Sprint       
       - Validation du livrable par le product Owner      
       - Pas de support spécifique à préparer (Powerpoint ou autre…)       
       - Actualisation de la « vélocité » pour améliorer les estimations futures



J - Scrum les points clés et le cycle de vie

Scrum est une approche innovante et celle- ci à le mérite de favoriser la collaboration, l'implication et la recherche de l'excellence en apportant un cadre. 


Scrum les points clés :  


 - Le client au coeur du projet

 - Esprit d'équipe et d'engagement

 - La communication est le point clé

 - Simplicité, Efficacité et Qualité

 - Adaptabilité et flexibilité aux changements

 - Avancement basé sur le concret

Scrum le cycle de vie  : 



mardi 13 novembre 2012

I - Démarche Agile

La démarche agile est dirigée par la valeur.

       - Cela permet de fabriquer un logiciel qui fonctionne en collaborant avec le client et en acceptant les changements de ses exigences

Approche incrémentale et itérative

   - Le système est conçu et construit par petits morceaux
   - Chaque itération est un point de démonstration et de retour entre tous les acteurs du projet
   - Chaque incrément (Release) doit produire un système fonctionnel et stable

Amélioration continu.

   - Remise en cause du mode de fonctionnement, organisation pour assurer un niveau d'excellence

Priorisation des exigences basée sur la valeur

   - Les fonctionnalités sont priorisées par importance métier au lieu de blocs fonctionnels ou de tâches
   - Le client peut moduler ses exigences

Equipes dédiées et auto-organisées


Appropriation collective de la qualité


H - Manifeste et principes Agiles

Manifeste Agile (2001)


   Individus et interactions vs. Processus et outils
       - Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier.

   Logiciel qui fonctionne vs. Documentation exhaustive
       - Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. 
       - La documentation n'est qu'un support concret qui aide à produire le logiciel.

  Collaboration du client vs. Négociation de contrat       - Il faut penser en équipe qui veut atteindre un but commun : réussir le projet.

  Réponse au changement vs. Suivi d'un plan prédéfini
       - Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique précis et adaptatif.


Les principes Agiles


      - Délivrer rapidement et très fréquemment des versions opérationnelles qui apportent de la valeur au client


      - Accueillir favorablement le changement

      - Assurer une coopération forte entre client et développeurs

      - Garder un haut niveau de motivation

      - Le fonctionnement de l’application est le premier indicateur du projet

      - Garder un rythme soutenable

      - Viser l’excellence technique et la simplicité

      - Se remettre en cause régulièrement

G - Famille Cycle projet Agile


Cycle Agile 

Dans un cycle agile, la solution est mise à disposition des utilisateurs de manière progressive à travers des itérations incrémentales. 
Ce principe permettant de livrer au plus tôt l’essentiel de la solution, affinée conjointement entre Réalisateur et Client, puis de fournir ses compléments progressivement, sur la même base de travail collaboratif.

Panorama des méthodes Agiles

Panorama des méthodes Agiles

F - Le Cycle projet en V


- Depuis quand ce cycle est utilisé
        Le cycle en V est un standard de l’industrie logicielle depuis les années 80.

 - Les projets concernés 
       - Il est adapté aux gros projets industriels complexes avec de fortes contraintes de disponibilité. 

       - Le cycle en V, par lot(gestion des évolutions par release), est bien adapté à ce type de projet.

- La démarche
         Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au début du cycle. Ce cycle exécute des phases qui ont pour caractéristiques de produire des livrables définis au préalable, de se terminer à une date précise, de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d’une étape de validation-vérification.

- Les avantages
         Ce cycle aide à gérer la complexité et les risques en matière de délai et de coûts, même s’il n’optimise ni l’un ni l’autre.
- Adaptation 
         Mais en fonction de la typologie du projet, de sa taille, le cycle en V peut être adapté ou simplifié, par fusion de certaines étapes, simplification ou suppression de certains documents

Le cycle en V standard est le plus couramment utilisé pour le développement de logiciels de gestion

- Schéma du cycle projet en V


E - 3 - Les fondamentaux : Les exigences

1 - Piloter les développements par la gestion des exigences

    - De quelle manière ?

        - Identifier les exigences dès le cahier des charges ou l'expression de besoins.

        - Appliquer systématiquement la règle suivante :

                   une exigence est vérifiable, le besoin pas toujours.

ROI attendu : 


Diminuer les risques de type "Trous fonctionnels ou techniques"

Préparer les bons tests

Détecter au plus tôt les anomalies

Sécuriser les mises en production

lundi 12 novembre 2012

D - 2 - Les fondamentaux : Organisation

1 - Optimisation de l'organisation du projet

 - Préciser l’organisation de projet retenue :

   -   Préciser  les rôles et responsabilités à mettre en place dans le projet.

 - Mettre en place un mode de travail collaboratif :

            Bonnes pratiques à mettre en œuvre :

   - Implication des acteurs des documents en amont (validation au fur et à mesure ).
   - Points réguliers de courte durée Réalisateur-Client dans le but de passer en revue les risques / points durs et de prendre le plus possibles les décisions au fil de l'eau.
   - Ne produire que ce qui est nécessaire et organiser la documentation en fonction des acteurs. 

 - Valider et communiquer sur les choix retenus auprès de tous les acteurs du projet

ROI attendu:

Allègement des étapes de revue et de validation


Visibilité augmenté pour le  Réalisateur et le Client permettant l’anticipation des risques et les prises de décisions rapides.

Optimisation de la documentation

C - 1 - Les fondamentaux : cycle projet & documentation


1 - Adapter le cycle projet en fonction de ses besoins


  - Identifier les risques 
  - Comparer avec le référentiel de cycle
  - Analyser les variantes et adapter la référence en conséquence


Par exemple, si les fonctionnalités du projet ne sont pas perceptibles par les utilisateurs alors un cycle projet proposant de l'itératif n'est pas pertinent.


2 - Optimiser la documentation

  - Identifier les besoins de documentation

  - Produire la documentation utile
  - Ne pas prendre en compte les informations redondantes et inutiles

  - Produire une documentation efficace

  - Se concentrer sur l'objectif de chaque document
  - Orienter le contenu du document en fonction de l'utilisateur à qui il est dédié

  -  Optimiser l'effort 

  - Produire au bon moment avec les bons interlocuteurs
  - Eviter de passer du temps sur les cas à la marge. Appliquer  la règle de Pareto des 80/20.

Identifier avec le client la documentation en adéquation avec ses attentes

  - Communiquer pour obtenir l'adhésion des différents acteurs du projet -

dimanche 11 novembre 2012

B - Processus de mise en oeuvre d'un projet SI


Avant de commencer un projet, il faut se poser les questions suivantes en se projetant dans le contexte du projet concerné :

-  Quel est le cycle projet le mieux adapté au contexte de ce projet ?
-  Quels sont les livrables, et surtout les livrables documentaires, absolument nécessaire à fournir ?
-  Quelle est l’organisation à mettre en oeuvre  et comment optimiser les rôles et  les responsabilités de chacun des acteurs ?
-  Comment assurer la traçabilité des exigences  ?

Pour cela, il faut identifier les caractéristiques ci-dessous

-  Le type de projet :

-  Projet de refonte, 
-  Nouveau système,
-  Maintenance,
-  Palier technologique,
-  Etc....

-  Les caractéristiques majeures du projet :

Les réflexions à mener sur le  projet sont  :
-  Est-il inclus dans un projet multi domaines ? 
-  Embarque-t-il un progiciel ?
-  Est-il de petite ou de grande taille ? 
-  One shot ? 
-  Etc...

-  Les contraintes en terme de pilotage :

La contrainte majeure est-elle :
-    les délais ? 
-    ou le coût ? 
-    ou la qualité ? 
-    ou la flexibilité ?

L’analyse de ces différents éléments va permettre de choisir de manière optimisée :

-  Le cycle projet,
-  Les livrables documentaires
-  L’organisation incluant les rôles et les responsabilités de chacun des acteurs  et la démarche projet la mieux adaptée au contexte du projet.

A - Constat et démarche pour les projets SI


Quelques chiffres pour avoir une vision globale sur la réussite des projets SI

- Selon le Standish Group (2006)

        - 35% des projets respectent les délais et les budgets

        - 46% dépassent le budget ou sont en retard

        - 19% sont abandonnés ou voient leur périmètre largement restreint

- Les freins

                    - Le contexte économique difficile met une pression forte

                    - Rapports parfois difficiles entre la maîtrise d’ouvrage et la maîtrise d’œuvre


                    - Confusion entre des besoins estimés et des besoins réels


                    - Les guerres contractuelles font oublier l’objectif initial


                    - Chacun s’abrite derrière les modalités d’un forfait qui fige dans le marbre des spécifications incomplètes



- Les facteurs d'échecs

                   - Le manque de communication à tout niveau

                   - Une mauvaise compréhension des besoins

                   - L’insuffisance de l’architecture

                   - L’absence de maturité des outils utilisés

                   - La mauvaise formation des personnes

                   - Le cadre contractuel inadapté

                   - L’insuffisance des tests

                   - L’absence d’une démarche Thing Big – Start Small

                   - Les effets Tunnel







Face à ce constat, et pour aller vers un objectif d’optimisation des moyens, sans remettre en cause la qualité du produit, voici 2 axes à suivre en terme de réflexion  :

-   Axe de réflexion sur la démarche à suivre afin d’identifier, personnaliser et appliquer le cycle le mieux adapté.
-   Axe de réflexion sur les  différents types de cycle d’ingénierie actuellement existant dans les projets informatiques.


Schéma de la démarche du choix d'un cycle projet