70 locations de salle rémunérées (formation extérieur)
Une participation à la conférence Flowcon (Conférence ou atelier)
Sponsoring Flowcon.
Les sujets que nous avons travaillés
Initiation de la conférence #demain
Reprise de l’activité après le COVID
Nos charges
Voici nos principales sources de dépenses cette année, soit prêt de 26 500€ :
Montant mensuel
Montant unique
Loyer main d’Or
1770
Electricité main d’Or
40
Assurance main d’Or
44
Internet main d’Or
40
Gestion administrative
300
WordPress – blog tribu
4
Nom de domaine .fr et .com
3
Meetup
6
Sponsoring et intendance
1000
Sessionlab
13
Internet
40
Total à l’année
27 120
1000
Les frais sont vraiment partagés entre tous les membres, avec une contribution libre et volontaire (via une feuille de calcul partagée entre tous les membres).
Le cadre de travail du Proxy PO est rattaché à la scalabilité d’un Produit nécessitant de le découper en plusieurs sous produits. Il faut de l’énergie et du courage pour être un facilitateur de PO et faire circuler l’information.
Rôle du Proxy PO (PPO ou PMO)
Etre au service des Products Owner
Défendre la roadmap, être le représentant des PO
Aider à trouver des solutions et à les mettre en place.
Il est le garant des processus mis en place au sein de l’équipe PO.
Canalisateur de l’information et de la transparence qui en découle.
Aider à la décision entre plusieurs PO ou trouver la ou les bonnes personnes pour prendre la décision.
Le Proxy PO Priorise la RoadMap mais il ne peut pas dire comment réaliser les sous produits,
Il est facilitateur et doit connaitre un maximum de personne pour orienter et aiguiller les PO : Aiguilleur du ciel.
Le PPO est sur le terrain avec les PO et donc il sait qui fait quoi dans la team de PO.
Comme pour une team de développeur avec son Scrum Master, chaque PO de son équipe va présenter les éléments de son produit aux CODIR et démos externes.
Facilitateur des autres PO (au préalable les autres PO lui auront donnés mandat de PPO), le Proxy Product Owner peut même être élu dans une équipe de PO par élection sans candidat.
Le PPO n’est pas obligatoirement hiérarchiquement supérieur au autres PO.
Avec le temps le proxy PO devrait disparaître, pour redevenir PO à plein temps, il devrait garder et gérer le sous produit le plus petit.
Ce que Damien nous montre est dans le cadre du développement de votre produit, mais comment faire si vous avez un produit non maintenue (legacy) et que vous devez faire des modifications ? Comment faire si mon produit est basé sur un progiciel (logiciel propriétaire, sur étagère à paramétrer) dont je ne connais pas la qualité ?
Il faut mettre en place une chaîne de test TNR ( test de non régression) fiable et sécuriser avec vos scénarios les plus importants. L’automatisation de vos tests de non régression permet de faire vivre votre produit dans un cycle agile afin de vous permettre de le modifier quand vous voulez et d’avoir un feedback immédiat pour mettre en production dans la journée. Vous y gagnez du temps de réaction et réduirez votre coût de recette car votre équipe recettera uniquement les changements. Dans le cadre du logiciel à intégrer dans votre entreprise , les paramétrages du logiciel doivent être sous le contrôle de tests automatisés.
Si votre produit est prioritaire, stratégique pour votre entreprise, vous comptez l’utiliser sur plusieurs années et le faire évoluer, vous devriez faire appel à un qualiticien expérimenté pour la mise en place des outils de tests et son DSL de test.
Deux approches de test à faire : Via la couche API : Si votre produit est récent, vous devriez avoir accès aux APIs des services du produit (rest, soap, client-serveur). Cette méthode est privilégié car plus simple à mettre en place afin d’éviterez les temps de latence de la couche IHM ou le scripting sur l’XLM qui provoque souvent des faux-positifs. Via la couche IHM : Utiliser des robots via des scriptes pour remplir les champs et valider les résultats via votre IHM logiciel : voir Robot Framework ou Cucumber.
Dans votre stratégie de test, chaque paramétrage a un objectif de comportement du produit, c’est ce comportement que vous devez tester et que vous devez rendre testable. Pour cela votre qualiticien basera ses efforts en suivant le pattern SOLID :
Responsabilité unique (single responsibility principle)une classe, une fonction ou une méthode doit avoir une et une seule responsabilité Ouvert/fermé (open/closed principle)une entité applicative (class, fonction, module …) doit être ouverte à l’extension, mais fermée à la modification Substitution de Liskov (Liskov substitution principle)une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme Ségrégation des interfaces (interface segregation principle)préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale Inversion des dépendances (dependency inversion principle)il faut dépendre des abstractions, pas des implémentations
Pourquoi un qualiticien pour réaliser votre stack de tests ? Le plus compliqué n’est pas d’écrire le test ou de tester, le plus compliqué est de définir les bons outils à mettre en place pour tester votre produit, et ensuite de mettre en place une mécanique de test résiliant aux changements des données sur votre environnement de test et minimiser les faux-positifs. Ensuite, son travail est de gérer l’effort à mettre dans chaque test par rapport à son ROI car rappelez-vous la pyramide de tests présenté par Damien plus haut, les tests d’IHM et d’intégration sont les plus chers à faire et maintenir.
C’est la mission du Qualiticien Agile afin de vous permettre de sécuriser votre produit avec la mise en place du BDD Behavior Driven Development ou pour nous ici du TDS : Test Driven Settings.
Si besoin, nous travaillons avec des partenaires experts dans la mise en oeuvre de l’automatisation de vos tests de non régression TNR.
Espace, frontière de l’infini, vers laquelle voyage notre Enterprise Agile. Sa mission : explorer de nouveaux mondes étranges d’entreprises libres, découvrir de nouveaux styles de vie, d’autres civilisations bienveillantes, et au mépris du danger et de l’Etat, reculer l’impossible de l’employabilité…
J’aimerais travailler dans une entreprise où je me sens moi avec des collègues qui partagent les mêmes socles de valeurs.
Cette entreprise nous permettra de grandir ensemble et de prendre du plaisir.
Yannick AMEUR
Notre raison d’être :
Participer à la création d’un concept d’entreprise Libre et Agile, devenir des équipiers et co-construire notre entreprise afin de travailler ensemble dans un environnement qui nous ressemble.
La Vision :
Une Structure Agile, équitable, exemplaire, transparente sur sa stratégie et ses chiffres, qui permet l’accompagnement de ses équipiers et la gestion collaborative de la vie de cette entreprise.
besoin de sens et de raison d’être,
besoin d’écoute,
être fier de faire partie de l’Agile Tribu Enterprise,
besoin d’être responsabilisé (adulte à adulte),
envie de partager des valeurs,
besoin d’être acteur dans son entreprise,
besoin de transparence sur tout,
besoin d’un engagement solidaire et d’investir sur la planète : pour soi, pour ses collègues, pour l’entreprise via des actions et non des promesses,
besoin d’exemplarité de l’entreprise, de ses collègues et de soi-même.
Les hypothèses issues des interviews de futurs équipiers
A qui adressons-nous cette entreprise Agile ?
A ceux qui veulent :
entrer dans un modèle salarié équitable en gardant de la liberté,
partager et compter sur des collègues réellement bienveillants,
avoir une gestion de l’administratif centralisée et commune,
travailler avec un ADN Agile et une culture ouverte en interne.
Ceci est la première version de la vision l’Agile Tribu Enterprise. Merci à vous de venir participer et de nous aider à grandir.
La chaîne de valeur dans votre Produit ou dans votre entreprise est spécifique, donc je vous propose une solution à adapter avec si possible un coach Agile.
La recherche de chaînes de valeurs est pour moi la résultante d’un système complexe dans certain grand groupe, ou dans des contextes de Produits imbriqués nécessitant une gestion scallée des équipes. Quand les membres d’un système ne comprennent plus ce qu’ils apportent comme valeur dans le système : quêtes de sens, responsabilités, valeurs.
Voilà donc une façon d’aborder la définition d’une chaîne de valeur(s).
Merci à Béatrice Kreng d’avoir scribé la Chaîne de Valeur
Définition de la chaîne de valeur : la chaîne de valeur est l’ensemble des produits et des personnes qui participent à la réalisation de votre Epic.
L’Epic est une fonctionnalité Macro à réaliser, elle peut se découper en plusieurs Users Stories.
Release glissante : c’est un ensemble d’Epic qui représentent 3 mois de production estimée des Produits de votre système.
Chaque Epic doit aller en production le plus rapidement possible et permettre à une nouvelle Epic de rentrer dans la release, d’où la notion de Release Glissante.
Le Framing Agile donne du sens à nos initiatives de BootCamp et des starterKit Agile qu’AgileTribu a lancé ces dernières années.
Le Framing Agile est née de différente aventures initialisées avec Nathaniel Richand, poursuivi avec Judicael Paquet lors de nos missions communes.
Judicael à réussi à formaliser les réflexions sur : comment industrialiser le bootstrapping de Produit Agile avec Agile Framing sur son blog MyAgilePartner :
Bravo pour cette synthèse que nous partageons et qui évolue avec les différents coach, clients, Produits, tests réalisés autour des différents éléments du Framing.
Entre les membres pas de commission, nous partageons l’activité et la relation long terme.
Les apporteurs d’affaires et Partenaires doivent reverser ou contribuer à l’Agile Tribu. Comment ? A définir.
Si la tribu est référencée, alors elle prendra sur une mission en direct de 5% afin d’aider aux frais (sponsoring, produits …) et faire grandir la tribu.
Si vous êtes membre vous pouvez participer aux frais de la tribu.
A ce jour, la cotisation est de 250 € ht par mois sans engament.
Vous pouvez aussi prendre les options GoogleAPP 4€ (mail Drive ….) et DropBox Pro Tribu 120 € / an.
Agile Tribu 