J'ai récemment rejoint un jeune hackerspace encore en cours de création. Nous avons de la chance parce que l'espace a quelques projets internes qui nécessitent d'être travaillés et aucune pénurie de bénévoles pour y travailler.
Il y a eu quelques discussions sur la façon d'organiser ces projets. Mon expérience professionnelle la plus récente a été avec Scrum, donc j'envisage de proposer une approche Scrum pour nos projets logiciels, mais je ne suis pas sûr que ce sera un bon choix.
Bien que j'ai vu Scrum bien fonctionner pour de petites équipes à temps plein, la nature de cette organisation est différente:
- Les membres sont bénévoles . Certains sont étudiants à plein temps. D'autres travaillent à plein temps. Nous ne pouvons pas nous attendre à un niveau constant de contribution de quiconque, car leur vie réelle est prioritaire.
- Alors que presque tout le monde a des années d'expérience dans l'écriture de logiciels, peu de membres l'ont fait de manière professionnelle ou en équipe.
- Il n'y a pas de Product Owner . Les exigences de ces projets sont déterminées par un comité. Les membres de ce comité travailleront également à la mise en œuvre. Cela signifie que nous n'aurons pas de propriétaire de produit unique et dédié.
- Nous n'avons pas de délais (doux ou dur). Les projets seront réalisés lorsqu'ils seront terminés.
Ce sont des différences assez importantes, mais je ne suis pas convaincu qu'ils entraveront l'application de Scrum. Je pense que quelques ajustements mineurs pourraient nous aider à surmonter cet obstacle:
- Si nous modifions les Sprints pour avoir une taille de point d'histoire fixe, mais une durée fluide (temps), nous pouvons toujours bénéficier de versions itératives sans exercer de pression de livraison irréaliste sur les développeurs volontaires.
- Nous pouvons abandonner les graphiques de combustion et le calcul de la vitesse . Si je comprends bien, ce sont des outils et des métriques qui fonctionnent comme un pont entre l'équipe de développement et la direction. Ils servent à rendre compte des progrès sous une forme qui soit significative à la fois pour les développeurs et les parties prenantes. Étant donné que nous n'avons personne à qui faire rapport (pas de chef de projet, pas de propriétaire de produit et pas d'intervenants externes), je pense que nous pouvons abandonner tout cela.
Des choses dont je pense que nous pourrions bénéficier et qui ne nécessiteront pas de modifications:
- Le rassemblement Exigences réunion (s). Où tout le monde est assis autour d'une table et discute des histoires d'utilisateurs, esquisse des simulations d'interface utilisateur et crée un backlog de produit.
- Rétrospectives Sprint . Ce sera une façon intéressante pour nous de converger vers un processus de développement qui fonctionne pour nous en tant qu'équipe de bénévoles.
Choses dont je ne suis pas sûr:
- Comment traiter les Stand-up quotidiens ? Je me demande s'ils auraient beaucoup de valeur dans notre cadre. Ma compréhension du rituel de stand-up est qu'il facilite la communication en diffusant naturellement des informations dans toute l'équipe. Compte tenu du fait que nos sprints fourniront probablement beaucoup moins de complexité qu'un sprint moyen, il pourrait être moins nécessaire d'être au courant des progrès / développements de tous les autres membres de l'équipe.
- Dois-je pousser pour des choses XP comme l'intégration continue, les revues de code et TDD? Je crains que cela demande beaucoup. Je serais plus tenté d'introduire ces concepts dans de futurs projets une fois que les gens seront plus familiers avec Scrum et travailleront en équipe.
Mes questions:
Scrum peut-il être adapté à un environnement basé sur le volontariat?
Et, mon approche prévue va-t-elle jusqu'à présent dans la bonne direction?