Excellent article de Barbara Davis sur les oublis trop fréquents des analystes dans le cadre de projets, lors de la rédaction de spécifications. Pour les avoir expérimentés à divers degrés (et en avoir subi les conséquences), je vous suggère de garder cette liste à portée de la main:
- Effectuer des recherches – l’utilisateur ne connaît pas tout!
- Identifier les écarts ET les gérer – la gestion de risque n’est pas limitée aux chargés de projet
- Gérer l’ambiguité – s’assurer d’avoir la perspective de différents groupes afin de bien documenter les spécifications
- Valider les spécifications par différents moyens – il existe plusieurs techniques qui peuvent être exploitées de façon complémentaire
- Faciliter l’approbation finale – ne pas se contenter de faire lire les spécifications aux utilisateurs; les guider dans leur lecture
Bonne lecture!
Article intéressant de Nielsen sur le design d’interfaces et l’expérience utilisateur dans un contexte de réalisation Agile.
Les deux principales recommandations s’appliquent au design des interfaces, mais pourraient tout aussi bien s’appliquer à la définition des spécifications par les analystes:
- Séparer le développement du design – l’équipe de design se doit de rester un pas en avant par rapport à l’équipe de développement, de façon à ne pas développer des fonctionnalités qui ne sont pas validées;
- Maintenir une vision cohérente de l’architecture des interfaces – idéalement dans un sprint zéro, ce qui permet de s’assurer que les fonctionnalités développées sont cohérentes avec cette vision d’ensemble.
C’est un peu ce qui se passe chez un client pour lequel je travaille. En effet, depuis la mise en place d’une métho plus agile, on s’est rendu compte qu’il était plus facile de définir les interfaces & spécifications à l’avance (mais toujours dans l’esprit d’Agile), ce qui nous permet de s’assurer une certaine harmonie entre les différentes fonctionnalités au fur et à mesure que les sprints avancent.
L’importance du sprint zéro prend ici tout son sens.
Petit résumé intéressant d’une conférence de Forrester sur la création de valeur par l’adoption d’une approche agile pour la définition des spécifications.
Quelques points-clés:
Friction points between traditional and Agile approaches:
- Delivers requirements vs collaboration on the product
- Where in the process you engage vs. iterative
- Requirements that are out of date, long/hard to read, solution focused, take way too long vs. collaborative and timely requirements
Often the customer has no time because they are doing their day-job (the one you are trying to help in some way with software!). There are often many customers to involve in the requirements efforts, not just one or two to quickly jot down stories with. The customers are often distributed so you have to bake in time to work with all of them alone and together. Agile is reliant on good communication but stereotypically, developers don’t communicate well.
We cannot ignore analysis – processes require analysis and solutions require thought - so take time to do these.
L’article complet est ici: http://requirements.seilevel.com/blog/2009/10/delivering-business-value-with-agile_28.html
