Pour évaluer le travail réalisé pour produire la présente conférence
Qu’est-ce que je pourrais mesurer?
Exemple : l’effort dans le temps
Voici ce que la théorie pourrait me donner pour une première approche
J’ai mesuré l’effort dans le temps
Était-ce les meilleurs paramètres de mesure?
Si j’avais mesuré la motivation, mon plaisir, mon inspiration, …
Avertissement
Pas exhaustif, il y a d’autres indicateurs.
Beaucoup de connu, de rappels.
Basé sur mon expérience, ce n’est pas nécessairement la vérité, d’autres interprétations sont possibles
En fonction du contexte, ça peut changer
Coût (en effort, en $, en jours, en points,…)
Cédule (en date, en jours,…)
Portée
Qualité
Risques
Efforts
Motivation
Enthousiasme
Plaisir
Engagement
L’intensité
Stress
On fait de la planification (par ricochet de l’estimation) pour réduire les risques. Cependant, en faisant cette activité en début de projet, on est dans le gros du cône.
Notre planification, visant à réduire les risques, est donc très peu précise et ne nous permet pas toujours de bien gérer les risques en amont.
C’est pour cette raison, que dans un processus agile, la planification et l’estimation se font tout au long du projet; de façon itérative.
La difficulté d’estimation.
C’est en partie pour ça qu’on fait de l’agilité car estimer, c’est dur.
Pourquoi pas prendre la 5e édition du PMBok, parce qu’il y a la technique de prise de décision collective.
#10. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
#10. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
Ce qui est important c’est de regarder la tendance, non pas juste celle dans le sprint, mais aussi celle d’un sprint à l’autre
Vous trichez
On se donne une définition de « terminé » qui nous permet d’obtenir nos points.
4 semaines dans le sprint, par exemple.
On pourrait s’attendre à ce que les points soient otenus graduellement pendant le sprint.
À mains levées, quelles sont les équipes qui réussissent toujours à terminer tous leurs points (en accord avec la définition de terminé)?
À mains levées, quelles sont les équipes qui réussissent parfois…?
À mains levées, quelles sont les équipes qui réussissent jamais…?
Pour quelles raisons on ne livre pas tous les points?
Permiers sprints – rodage et ajustements
Grands imprévus – mais ça ne devrait pas arriver tout le temps
X est le moment ou la probabilité de finir est la plus grande. Puisque l’aire à gauche est <50%, cette probabilité est tout même plus petite que 50%. C’est-à-dire que les chances de dépasser ce moment sont plus grande.
Ajouter à cela la probabilité de finir dans les temps prévu.
La durée du projet ou encore la durée d’un étape du projet ou encore d’une fonctionnalité. Ça peut varier
Les changements de rôles, de spécialités amènent des changements de stabilité, de personnes dans le projet. Gestion…
On représente ici la courbe avec l’intensité en ordonnée car c’est plus représentatif que l’effort. Ça se mesure moins bien car plutôt qualitatif.
On va privilégier, toujours dans la théorie, des personnes polyvalentes, que j’appelerai « les développeurs ». Personnes capables de faire autant l’analyse que la programmation.
Avec ces rôles et les concepts de terminés, itératifs, etc. on va obtenir une intensité qui varie moins et qui surtout varie sur une plus courte période de temps.
Même en agilité
Choses importantes à contrôler pour minimiser cet effet :
- o Defect Report Content
Originator / Origination Date
Defect Description
Sequence of Events
Supporting Data
Defect Lifecycle History
Subsystem or Domain Category
Root Cause
o Defect Tracking Process
Numbering Scheme
Prioritization Scheme
Categorization Scheme
Root Cause Assignment Scheme
Assignment to Team Members
Defect Lifecycle Flow (States and State Transitions)
State Transition Communications
o Defect Reviews
Required Attendees
Defect reviews should begin during unit testing.
Review Schedule (meet more often for new projects)
Defect Review Agenda (assignment of priorities, assignment of defects to
team members, reassignments, review of backlog, reporting to management)
o Process Training
Training and User Manuals
On se souvient qu’il faut analyser les tendances.
La vélocité est une mesure importante des processus agiles.
Name: Velocity
Question: How much software can my team deliver
per iteration?
Basis of Measurement: Story points or “ideal
engineering hours”
Assumptions: The team is delivering software every
iteration.
Level and Usage:Velocity is most useful at the project
level. It allows the team to forecast how much work
they can expect to complete based on prior efforts.
Expected Trend: Velocity can be affected by many
things: Changing team members, obstacles, toolsets,
difficulty of feature or amount of learning required, etc.
will lower the velocity of the team. However a stable
team on the same project with the required resources
will generally gain in velocity during the course of the
project.
When to Use It: Velocity is a very useful metric for
the team, and should be used during the course of the
project once work has started.
When to Stop Using It: The there is a longer project
when the team, resources, and technology are all stable,
velocity will also become stable. The team may
suspend collecting velocity since it is “known.”
How to Game It: Teams will estimate their work
differently from other teams. For example one team
might estimate 1000 hours while another 600 hours for
the same work, and both will complete the work in the
iteration. Comparing velocity of teams is problematic.
If teams know they are getting compared, they can
inflate their estimates, and hence increase their velocity
while completing the same amount of work.
Warnings: Velocity is not the same as value. A team
with excellent velocity could spend months quickly and
effectively delivering software that does not have the
investment potential. Comparing velocity of teams is
problematic (see above). This diagnostic is a barometer
for the team as a unit. Team member velocities are
problematic, so velocity should be measured at the
team level, since that is the unit that produces the value
La vélocité s’applique seulement à une seule et même équipe dans un même contexte.
On se souvient qu’il faut analyser les tendances. Si la cadence n’est pas stable, impossible de prédire la vélocité ( sans utiliser la théorie des grands nombres et donc avoir une centaines de sprints!!!)
Mike Cohn recommande d’utiliser 8 sprint pour déterminer la vélocité (best case, worst case) d’une équipe. Il faut avoir plus de 8 sprint pour se faire.
Burndown de livraison
Burndown de produit
Et sa version moderne, le sunset graph!
Burndown de livraison
Burndown de produit
Et sa version moderne, le sunset graph!
Importance d’analyser la tendance
À surveiller dans le burndown :
Ne pas faire de points importants ou optionnels tant qu’une tendance adéquate n’est pas visible
Faire une bonne maintenance de la portée au fur et à mesure.
L’avancement réel est ce qu’on a qui est utilisable si on arrête le projet
La valeur acquise a mauvaise presse :
Mesure le plan et la performance, mais pas la valeur
Est basée sur des unités financières
Se base sur le fait que tout est défini à l’avance
Rien sur la qualité
Et… c’est compliqué!
Pourtant :
C’est un complément aux indicateurs que nous avons vu
Deux principaux volets couverts dans la valeur acquise :
L’échéancier
La performance
C’est vrai que c’est compliqué… si ça vous est mal expliqué…
Ça ne va pas à l’encontre des 12 principes du manifeste agile – j’ai vérifié
CBTP – Coût Budgété du Travail Prévu
Coût cumulé en fonction du temps.
.55 à .70 environ
.8 lean high end engineer
La théorie des queues
Don Reinersten, The principles of Product Development Flow
Coût Budgété Travail Effectué.
Avancement physique en coûts budgété. Ce qui veut dire le % d’avancement du projet reporté en pourcentage.
Plus difficile à mesurer.
Normalement, selon les formules c’est CR/(CR+RàF)
Peut correspondre au nombre de points obtenus à présent/nombre de points total du projet.
Le Coût Réel du Travail Effectué
Le Coût Réel du Travail Effectué
Ça coût moins cher que prévu, mais ça s’enligne pour coûter plus cher que ça devrait
CV < 0 et SV < 0
CV > 0 et SV < 0
CV < 0 et SV > 0
A Good Agile Metric or Diagnostic …
1 Affirms and reinforces Lean and Agile
principles. Supports the customer-intimate and value
focused traits that reinforce Agile principles. This
requires that people who understand Agile participate
in metrics design. The truism "you get what you
measure" reminds us that counterproductive behaviors
may ensue if you reinforce the wrong things (ex:
overtime, % utilization, paperwork).
2 Follows trends, not numbers. Measure "one
level up" [5] to ensure you measure aggregated
information, not sub-optimized parts of a whole. (Ex:
the financial community has a mature sense of typical
industry "shapes" or trends). Aggregate above the
individual team level for upper management use. To
promote process health, do not track at levels more
granular than “a team”, and “an iteration”.
3 Belongs to a small set of metrics and
diagnostics. A "just enough" metrics approach is
recommended: too much information can obscure
important trends. Aggregate upward to roll interrelated
or competing factors into a single big picture (see
previous item).
4 Measures outcome, not output. In an Agile
environment where simplicity or "maximizing the
amount of work not done" is promoted, the most
spectacular outcome might be achieved by reducing
planned output while maximizing delivered value.
Outcomes are measured in terms of delivered Customer
value.
5 Is easy to collect. For team-level diagnostics
the ideal is "one button" automation - where data is
drawn from operational tools (i.e. the Product Backlog,
acceptance test tools, code analyzers). For management
use, avoid rework (ex: PowerPoint) and manipulation
of lower level data, aggregation is preferable.
6 Reveals, rather than conceals, its context
and significant variables. Should be visibly
accompanied by notes on significant influencing
factors, to discourage false assumptions and facilitate
improvement.
7 Provides fuel for meaningful conversation.
Face-to-face conversation is a very useful tool for
process improvement. A measurement isolated from its
context loses its meaning. Note: It's a good sign when
people talk about what they've learned by using a
metric or diagnostic.
8 Provides feedback on a frequent and
regular basis. To amplify learning and accelerate
process improvement, metrics should preferably be
available at each iteration retrospective, and at key
periodic management meetings.
9 May measure Value (Product) or Process.
Depending on where problems lie, diagnostics may
measure anything suspected of inhibiting effectiveness.
Consider the appropriate audience for each metric, and
document its context/assumptions to encourage proper
use of its content. And remember: you get what you
measure!
10 Encourages "good-enough" quality. The
definition of what's "good enough" in a given context
must come from that context's Business Customer or
their proxy, not the developers.
Diriger un projet en se basant que sur les chiffres est
comme conduire une voiture en ne regardant que le tableau de bord!