Charte graphique : de sa création à sa mise en application !
Qu'est-ce que la charte graphique ? Découvrez les étapes essentielles de sa création et de sa mise en application pour une identité visuelle cohérente
Lors de notre première partie, nous avons abordé les grands principes de Shape Up ainsi que la phase de shaping. Nous allons désormais nous intéresser aux autres grands moments: le Betting (comment choisir les projets qui seront implémentés), le Building (lorganisation des équipes et du travail de développement) et le Cooldown (pause entre deux cycles ou réelle opportunité? ).
Le "Betting" a pour but de sélectionner, parmi les projets pitchés, ceux qui seront développés.
Il n'y a rien d'autre à disposition, pas de listes d'idées, ou de backlogs à revoir en session de grooming. Il y a uniquement quelques options formalisées dont les risques ont été réduits : les pitchs produits.
Les réunions de "Betting" sont moins fréquentes, souvent courtes et très productives. Les pitchs sélectionnés seront traités dans le cycle suivant, autrement, ils seront oubliés (rien n'empêche un collaborateur de garder une idée, et de la re-proposer lors du prochain cycle, ou lors d'un moment plus opportun).
L'idée principale est bien de repartir d'un état d'esprit frais à chaque nouveau cycle, de ne pas maintenir du legacy avec des fonctionnalités du dernier trimestre, de s'assurer que les projets sur lesquels on "Bet" soient nécessaires, et apportent une réelle plus-value à l'instant T.
On remarquera automatiquement une problématique qui n'est pas sélectionnée et qui refait surface régulièrement. De plus, chaque personne est libre de tracker individuellement des éléments qui lui semblent intéressants (bugs, retours utilisateurs, données, concurrences), afin de proposer une solution en phase de "shaping".
Chacun peut garder une liste individuelle de ce qu'il souhaite voir implémenté un jour.Voici une répartition du périmètre qui peut être appliquée :CTO : architecture / technologiesProduct Manager : nouveau produit / améliorationsProduct Owner : nouvelle feature / outilsDesigner : ergonomie / comportementsDéveloppeur : bug / refactorisations
Les personnes présentes lors des séances de "Betting" sont généralement les mêmes que celles du "shaping". Il peut cependant y avoir des variations, comme la présence du CEO ou d'une partie prenante extérieure. Les personnes assises autour de la table doivent avoir les connaissances nécessaires pour évaluer les solutions et les risques (CTO, Développeur sénior, Product Strategist, Business Analyst, etc).
On cherche à définir notre cycle de 6 semaines, les décisions prises sont définitives et ne seront pas influencées par la suite. Il est donc essentiel d'avoir les compétences et le poids décisionnel nécessaires pour cela.
C'est également le moment où l'on assigne les équipes aux projets. On choisit les profils selon leurs compétences, au sein de notre "Core Team" afin qu'ils soient en adéquation avec les besoins du projets.
En présence de pitchs bien définis, de risques minimisés, de compétences correctement allouées, et de décisionnaires informés, les sessions de "Betting" sont désormais des moments ou l'on exerce un contrôle sur le futur du produit, plutôt qu'une bataille de ressources ou encore, une demande de priorisation.
Nos "Bets" doivent être respectés, on cherche à livrer un projet en 6 semaines, un projet avec une réelle plus-value et non pas de simples incrémentations produit. Ce sont de réels engagements, les équipes y seront dédiées et ne seront pas interrompues dans leur processus de développement. Enfin, 6 semaines, c'est aussi ce que l'on est prêt à "perdre", mais en aucun cas on ne perdra plus que le temps alloué. C'est notre plafond maximum.
Dans une logique d'amélioration, suivez vos équipes, vos projets, on notera les éléments suivants :
Il y a deux types de cycles très distincts lors du développement :
Pour le premier, nous sommes dans un univers connu, il n'y a pas de surprises et les phases de Betting sont donc assez simples. Dans le cas du deuxième en revanche, cela devient plus compliqué, on aura donc de petites variations au sein de nos cycles : les modes.
Chacun de ces modes peut durer plusieurs cycles, jusqu'à ce qu'une première version du produit soit disponible aux utilisateurs. On se trouvera alors de nouveau dans un cycle : ajout de fonctionnalité à un produit existant.
En mode R&D, l'équipe n'est pas forcément la même que d'habitude. On pourra y trouver les dirigeants, des C-levels et des consultants externes. Ajustez à vos objectifs, à la taille de votre structure et à la taille de vos équipes.
On utilisera plusieurs types de questions lors des sessions de "Betting" afin de bien différencier et choisir les projets qui seront développés.
Maintenant que l'ensemble des "Bets" ont été fait pour nos pitchs, il ne nous reste plus qu'à annoncer les projets sélectionnés pour la phase de "Building".
Après la session de Betting, annoncez les pitchs sélectionnés avec un message de lancement. Vous pouvez même aller plus loin avec un compte rendu de session.
Exemple de message de lancementSource : [[https://basecamp.com/shapeup/2.3-chapter-09](https://basecamp.com/shapeup/2.3-chapter-09)](https://basecamp.com/shapeup/2.3-chapter-09)
Le "Building", outre la livraison d'un produit ou d'une fonctionnalité, sert également à responsabiliser les équipes et collaborateurs. On leur fait confiance pour travailler à l'intérieur des limites du pitch, puis définir eux-mêmes leurs tâches et leurs approches. Ils ont une autonomie complète, pour des décisions réelles de Design et d'implémentation.
L'équipe organisera une réunion rapide de "kick-off", où l'on centralise les informations du projet, le pitch et ce qui le constitue. C'est l'occasion de poser quelques questions sur des éléments qui n'auraient pas été compris, ou qui resteraient trop vagues. Elle s'attaquera ensuite à une phase d'exploration et ne développera pas directement. C'est un moment où chaque personne de l'équipe explore la problématique, les possibilités, les solutions. Elles analysent le pitch pour comprendre comment le système fonctionne, et pour trouver le meilleur point de départ. Il est important de respecter ce moment car c'est un travail légitime : "j'essaie encore de comprendre par où commencer".
Enfin, une fois le point de départ trouvé, chacun commence réellement son design ou son développement. Puisque nous n'avons pas de backlog ou de tâches assignées, c'est un travail réel impliquant de la découverte et des dépendances. On notera, après l'ajout d'un nouveau bouton sur l'interface, qu'il manque de l'espace pour la version Mobile. Ou encore, lors d'un travail sur une base de données, que celle-ci aurait besoin d'être migrée. En bref : le meilleur moyen de comprendre ce qui doit être fait, c'est en réalisant un travail concret.
Créez des espaces de travail indépendants pour chacune des équipes. Elles ne doivent en aucun cas être perturbées par des imprévus ou des éléments extérieurs.
On pense généralement les projets en 2 couches : front-end et back-end, Design et code. Le problème, c'est que peu importe l'état d'avancement de l'un ou de l'autre, si les deux ne sont pas interconnectés, alors rien n'est réellement fait, terminé. Une page de profil ne contiendra aucune information si elle n'est pas connectée à la base de données utilisateurs. On va donc chercher à réaliser une tranche du projet en particulier. Un Designer peut se contenter des éléments d'un questionnaire et de leur hiérarchie, ce qui permettra au développeur de connaître rapidement les bases de données avec lesquelles communiquer.
Exemple de structuration rapide de formulaireSource : [[https://basecamp.com/shapeup/3.2-chapter-11](https://basecamp.com/shapeup/3.2-chapter-11)](https://basecamp.com/shapeup/3.2-chapter-11)
Il faut impérativement partir du centre du projet, quel est le but principal, quelle est la fonctionnalité principale ? En choisissant le centre, les dépendances suivront naturellement. On pourra s'appuyer sur 3 critères pour choisir ce que l'on développe en premier :
Arrivez rapidement à quelque chose de concret, une production, et non un prototype.
Avec la phase de shaping et l'analyse des points de départs, on commence à découvrir des tâches qui devront être réalisées. Puis, lors du développement, on réalise les dépendances existantes ainsi que la structure dont nécessite le projet. C'est alors que l'on peut définir les "scopes" de ce dernier, les grandes zones de développement.
Exemple de délimitation de scopeSource : [[https://basecamp.com/shapeup/3.3-chapter-12](https://basecamp.com/shapeup/3.3-chapter-12)](https://basecamp.com/shapeup/3.3-chapter-12)
Les scopes représentent les parties importantes d'une fonctionnalité qui devront être réalisées. Elles peuvent d'ailleurs l'être indépendamment les unes des autres, et sur une courte période, quelques jours tout au plus. Les scopes deviendront les éléments de langage du projet à un niveau macro afin d'aligner les parties prenantes sur l'avancement du projet.
Attention à ne pas retomber dans le spectre de la planification. On ne recherche pas les scopes, on les découvre petit à petit, ils émergent des dépendances que l'on rencontre. C'est pourquoi ils ne sont pas visibles au début du projet mais plutôt après 1 à 2 semaines, une fois le développement commencé.
On saura que l'on a défini de bons scopes lorsque :
Il devient évident que tout au long du processus de lancement, nous découvrons de nouveaux éléments, de nouvelles dépendances, de nouveaux scopes et donc, de nouvelles tâches à réaliser. Notre date de fin étant fixée, notre créneau étant défini, nous ne pouvons tout réaliser. C'est l'occasion de faire la différence entre les “must-have” et les “nice-to-have” afin de ne pas se perdre sous une tonne de tâches à développer. Les “nice-to-have” pourront être réalisés lors de la période de Cooldown par exemple.
On découvre toujours de nouvelles tâchesSource : [[https://basecamp.com/shapeup/3.4-chapter-13](https://basecamp.com/shapeup/3.4-chapter-13)](https://basecamp.com/shapeup/3.4-chapter-13)
Vous pouvez représenter vos scopes sous forme de “to-do lists” :
Shape Up utilise un système particulier pour définir l'état d'avancement des scopes et donc du projet : the Hill. L'idée est de voir le statut d'une fonctionnalité sans avoir à compter les tâches réalisées, ni estimer celles à venir. The Hill se divise en deux parties :
The Hill selon Shape UpSource : [[https://basecamp.com/shapeup/3.4-chapter-13](https://basecamp.com/shapeup/3.4-chapter-13)](https://basecamp.com/shapeup/3.4-chapter-13)
The Hill est un outil spécifique a Basecamp, à vous de l'adapter selon vos outils, l'important est de garder la distinction entre les éléments inconnus et connus :
Lorsque l'on design ou développe une fonctionnalité, chacun souhaite livrer la meilleure version possible. Nous avons pu voir, qu'au cours du développement, nous trouvions de nouvelles idées, de nouvelles dépendances, des “nice-to-have”. Au fur et à mesure que le cycle avance, il faut pourtant définir un point d'arrêt. A quel moment arrêtons-nous de développer un scope, une fonctionnalité ?
Shape-up se base sur ce qu'ils appellent la "Baseline" : ce qui est déjà disponible pour l'utilisateur (en tant que fonctionnalité actuelle ou produit concurrent). On s'intéresse ensuite au performance de la fonctionnalité, comparé au temps de développement passé par rapport à cette baseline.
Définition de la BaselineSource : [[https://basecamp.com/shapeup/3.5-chapter-14](https://basecamp.com/shapeup/3.5-chapter-14)](https://basecamp.com/shapeup/3.5-chapter-14)
A partir du moment où notre fonctionnalité apporte une plus-value par rapport à la baseline, alors le progrès est suffisant. Il est d'ailleurs également possible que notre scope ait été mal défini, et que ce dernier soit trop important.
Rien ne nous empêche alors, de redéfinir ce dernier, en se posant les bonnes questions sur les nouveaux éléments (ajouts, bugs, améliorations, redesigns), on appelle cela “le hammer” :
La QA est réalisée par les membres de l'équipe directement. Tout ce qui est détecté est automatiquement un "nice_to_have" et ne change donc pas le scope. En fonction des disponibilités et de l'avancement, l'équipe passe certains "nice_to_have" en "must_have" pendant le cycle ou la période de Cooldown.
Le "Cooldown" a pour but de marquer une pause entre deux cycles. Cette phase ne signifie pas une relaxe totale. On s'intéresse à de la refactorisation, au traitement de bugs, à de l'amélioration de processus, de l'implémentation de “nice to have”, ou peut-être de retours utilisateurs ?
A vous d'organiser ce temps, et pourquoi pas, demander à vos équipes comment elles souhaitent en tirer profit ? Seul ? A plusieurs ? En votant ? C'est le moment d'être créatif et collaboratif !
Shape Up est définitivement un framework intéressant à mettre en place. Il faut cependant prendre le temps de l'analyser, de l'implémenter, en s'assurant qu'il réponde aux problématiques rencontrées au sein de l’organisation.
Il conviendra particulièrement aux petites équipes qui cherchent à optimiser leur temps de conception et de développement. Dans les faits, se passer d'une QA en tant que telle restera difficile mais pas insurmontable, à vous d'adapter le framework à vos besoins.
Cette méthode assure une réelle autonomie des équipes avec beaucoup d'effets positifs pour les collaborateurs. On regrettera un manque de visibilité sur les tests et retours utilisateurs.
Si l'on devait retenir quelques éléments de cette méthodologie :
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision