jeudi 12 décembre 2013

Analyse de Kano

L'analyse de Kano permet de qualifier les exigences d'un produit afin de différencier leur impact sur la satisfaction des utilisateurs afin de lui donner un positionnement unique sur le marché.

Les caractéristiques du produit pourront être classées dans 6 catégories dont 3 à prendre en compte:

  • Indispensables (Must have)
  • Linéaires (Performance)
  • Attractives (Exciter)
Ceci selon l'avis des utilisateurs en fonction de deux axes:
  • Insatisfaction à Satisfaction
  • Niveau d'implémentation dans le produit
Afin de déterminer la catégorie à laquelle appartient une exigence ou caractéristique d'un produit, chaque utilisateur est interrogé sur chacune à l'aide de deux questions:
Fonctionnelle:
Quelle est votre opinion si cette caractéristique est inclue dans le produit?
Dysfonctionnelle:
Quelle est votre opinion si cette caractéristique n'est pas présente dans le produit?

5 réponses sont possibles à chaque question:
  • Cela me plait
  • Je l'espère comme cela
  • Cela m'est indifférent
  • Je ne le veut pas comme cela
  • Cela ne me plait pas
L'ensemble des réponses des utilisateurs pour une caractéristique sont synthétisées dans une matrice qui va permettre de déterminer la catégorie dominante.
LikeExpectNeutralLive withDislike
LikeQEEEP
ExpectRIIIM
NeutralRIIIM
Live withRIIIM
DislikeRRRRQ

M: Must have
E: Exciter
P: Performance
I: Indifferent
Q: Questionnable
R: Reverse

Les Must have sont des caractéristiques indispensables pour l'utilisateur. Tellement évidente pour lui, qu'il ne les exprime pas toujours. Mais si elles ne sont pas présentes dans le produit, il sera automatiquement rejeté.

Les Exciter sont des caractéristiques qui ne sont pas toujours formulées, ni attendues mais leurs présences peut faire la différence avec un autre produit. C'est le petit plus inattendu qui peut emporter l'adhésion au produit. Par contre, leur absence n'est pas une source de rejet du produit.

Les Performance sont un fort levier de satisfaction de l'utilisateur. Cette satisfaction pourra être proportionnelle au niveau et à la qualité d'implémentation de la caractéristique.

samedi 12 octobre 2013

Formations Agile LT en décembre 2013

Calendrier Learning Tree de décembre 2013 des prochaines formations Agiles

Formateur: Christian SIMON

Assistance à maîtrise d'ouvrage dans un environnement agile

Formation 3511 - 3 jours
11 au 13 décembre 2013 - Learning Tree à Paris Clichy
http://www.learningtree.fr/courses/3511

Scrum: Gestion de projet Agile

Formation 918 - 3 jours
18 au 20 décembre 2013 - Learning Tree à Paris Clichy
http://www.learningtree.fr/courses/918

vendredi 2 août 2013

Scrum guide

Le site officiel consacré au Scrum Guide.

Scrum est  décrit complètement dans Le Scrum Guide par Ken Schawber et Jeff Sutherland, les auteurs de Scrum.


Consultez la dernière version du  Scrum Guide de juillet 2013.

lundi 1 juillet 2013

The State of Scrum: Benchmarks & Guidelines

Un nouveau rapport sur l'état de Scrum est publié sur le site de la Scrum Alliance.
http://www.scrumalliance.org/why-scrum/state-of-scrum-report

Ce rapport montre qui utilise Scrum, pourquoi il est utilisé et quelques perspectives pour Scrum.
Une occasion de situer ses besoins et pratiques par rapport à d'autre.

vendredi 22 février 2013

Sprint 0 pour préparer un projet Agile



Le Sprint 0 ou itération 0 ou phase de préparation est abordé sous de nombreux noms dans la littérature agile.

Cette pratique n’est pas décrite dans le guide Scrum mais reconnue comme pouvant être utile pour assoir les fondations d'un développement Agile.
Elle permet de préparer les  sprints suivants afin de s’y consacrer essentiellement sur les aspects métier et fonctionnel. Mettre en place une base solide pour la suite agile du projet. Définir la vision globale et assurer une cohérence globale du produit.

Le sprint 0 peut être réalisé au niveau de l’équipe et dans le cadre des grands projets  multi-équipes au niveau des Scrums de Scrums.
Il peut s’assimiler à la phase de préparation avant une course.

Exemple d’activités durant le sprint 0
Vision du produit
Constitution du backlog (éléments, priorité, estimation) initiale à deux niveaux :
-          Granularité fine (user stories) pour les sprints proches
-          Granularité plus haute (Epics, thèmes) pour les sprints éloignés
Définition de rôles et de personae
Recherche sur l’interface, l’ergonomie, l’IHM. Décisions sur les grandes orientations.
Input : Principaux écrans attendus pour les entrés
Output : Principales impressions et statistiques
              Définition de processus métiers
Constitution de l’équipe
Expérimentations (SPIKE) techniques et fonctionnelles pour lever des incertitudes
-          Temps nécessaire
-          Niveau de difficulté
-          Choix entre plusieurs solutions
-          Ressources (humaine, savoir-faire, …) nécessaires
Architecture global du système
Etude système global
Technique et composant
Définition des domaines fonctionnels
Première version des modèles de données et de classes
Planification macro des versions
Analyse des dépendances dans le Backlog
Identification des risques
Normes, réglementation applicables
Règles de codage au sein de l’équipe
Projets multi-équipe
Attribution des domaines fonctionnels  à des PO de domaines
Constitution des équipes
Etude des dépendances et synchronisation
Règles de codage partagées entre les équipes
Architecture globale

Le sprint 0 peut durer de 1 à 4 semaines en fonction de la complexité du produit. Il ne doit pas devenir dans le cadre d’une organisation encore insuffisamment Agile un prétexte à entreprendre une phase déguisée d’analyse et spécification. Comme souvent ainsi que dans les 4 valeurs privilégiées dans le manifeste Agile, il s'agit de trouver le juste équilibre entre trop de recherche détaillée avant de se lancer et un manque total de repère.Où placer le curseur.
Le terme sprint est trompeur puisqu’il n’a pas nécessairement  la même durée que les sprints suivants et ne débouche pas sur la livraison d’un logiciel opérationnel. Le travail à faire et les livrables  dépendant du contexte, du projet et de la maturité de l’équipe.

Toute l’équipe de développement ne participe pas nécessairement à cette phase mais l’engagement de tous permet de mettre en place l’esprit d’équipe, les habitudes de travail ensemble.
L’ensemble des activités proposées pour le sprint 0 peuvent également être incluses dans une réunion de planification de version et une réunion de planification de sprint puis réparties sur les premiers sprints si le contexte le permet.