Catégories
Non classé

7 idées pour transformer une bonne équipe en équipe exceptionnelle

Durant le Devoxx France 2013, Samuel Le Berrigaud (développeur depuis 2006 à Atlassian : Jira, greenhopper, etc …) à présenté une conférence sur : « 7 idées pour transformer une bonne équipe en équipe exceptionnelle ».
Il présente un ensemble de pratiques qui peuvent s’appliquer sur la plus part des projets et des organisations :

La zone
La zone est un moment d’hyper concentration où nous sommes dans notre bulle avec une vision parfaite de la façon dont fonctionne l’application et de ce que l’on a à faire. Atteindre ces moments permet une bonne productivité. Le problème est que cet état est cassé par les interruptions et on estime qu’il faut, en général, une dizaine de minutes pour pouvoir retourner dans la zone de concentration. Pour optimiser ces moments, une des possibilités est de créer des plages horaires dans lesquelles vous coupez messagerie, notifications et téléphone et où personne ne peut venir vous déranger.
Mais comment faire dans les open spaces ? On désigne une personne par équipe avec un t-shirt « Talk to me » par exemple. C’est le seul que l’on puisse déranger pendant cette phase horaire.

Alimenter votre cerveau
Aller à des conférences est une excellente chose mais c’est coûteux en temps. En lieu et place, il est possible d’organiser des sessions de développement au sein de votre entreprise ou des Brown Bags (ndr : en France, vous pouvez vous tourner vers les Brown bags lunch. Discuter autour d’un repas de midi avec un expert (pas encore de baggers autour de Montpellier) , n’hésitez pas, c’est par ici que ça se passe : brownbaglunch.fr).

Dites : Bon travail
Remercier quelqu’un pour un travail qu’il vient d’effectuer, c’est la reconnaissance des petites choses. Ça ne coûte rien et c’est motivant.
Chez Atlassian, le concept de Kudos a été mis en place. C’est une reconnaissance via des tickets JIRA pour dire merci. Les employés ont droit à 2 Kudos 3 fois par an.

Report Robot
Il faut être dingue de la collecte de données : revue de code, nombre de bugs, durée du build, performance des serveurs, vélocité, trafic web, publicité, satisfaction client. Tout doit être automatisé pour obtenir des rapports visuels. On partage l’information via des « radiateurs de l’information » : chez Atlassian, des écrans de TV affichent ces différents rapports.

Eat your own dog food
“Eat your own dog food” est l’utilisation de ses propres services ou produits. C’est de l’alpha testing, cela permet d’avoir des retours rapides et de comprendre les problèmes et défauts du produit le plus tôt possible. Attention, il faut s’attendre à avoir beaucoup de retours et ça peut faire très mal à l’ego !

Faites une journée spéciale
On a tous des tâches que l’on souhaiterait ne pas faire (rédaction de documentation ou de tests unitaires manquants), alors oubliez le sprint en cours et faites une journée spéciale dédiée exclusivement à cela. Par exemple, un “doc Sprint” (journée où on écrit de la documentation utilisateur) ou un blitz test.
Attention, il est automatiquement nécessaire d’avoir livré quelque chose à la fin de la journée.

Le temps des expériences
Chez Atlassian, il y a les « Ship it days ». Le but est de développer une idée en 24 heures. Cela stimule l’innovation chez les développeurs et motive les équipes. Un gagnant est désigné à la fin des 24 heures et ça se passe une fois par trimestre. Attention tout de même à la qualité du code si vous souhaitez réutiliser ce qui a été créé lors de la compétition.
Une autre solution est le “20% time”, méthode utilisée chez Google et qui laisse 20% du temps d’un ingénieur à un autre projet de son choix (Gmail, AdSense et Google News viennent de ces moments). Le problème de ce système, c’est qu’en réalité, il est difficile d’y accorder autant de temps à cause des contraintes projets.

Conclusion
Il n’y pas de solutions miracles. Essayer, essayer, essayer. Les solutions présentées ici ne correspondent pas forcément à ce que vous devez faire exactement chez vous, alors faites les vôtres !

Source : Soat

Catégories
Agile

L’agilité, les grands axes

Les méthodes agiles, qu’est ce que c’est ?

On parle plus souvent de pratiques agiles, plutôt que de méthodes agiles. C’est la synthétisation d’un certain nombre de valeurs communes à différentes méthodes apportées par les fondateurs du manifeste agile.

Quelles sont ces valeurs ?

Les quatre valeurs fondamentales agiles sont de valoriser :

  • Les individus et leurs interactions plus que les processus et les outils.
  • Des logiciels opérationnels plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que le suivi d’un plan.

Les 12 principes :

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
  • Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • Un logiciel opérationnel est la principale mesure d’avancement.
  • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
  • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  • Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  • À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Traditionnellement les pratiques agiles sont opposées aux méthodes de cycles en V.
Les spécifications sont écrites par une personne, ensuite il y a une personne qui développe et enfin une personne qui met en production.
Le cycle est unique et dans un seul sens.

La méthode agile propose de faire des cycles itératifs plus ou moins courts, où, à chaque fin de cycle on va livrer un incrément du logiciel.
Au démarrage du projet, dans un univers Agile, les premiers cycles servent à adapter le contenu aux équipes, et à étalonner les différents indicateurs. Le cycle de release sera adapté par rapport à la vélocité de l’équipe, et à ce qu’attend le client final.

Kanban : Méthodologie orientée vers la gestion de livrable en continu. Au lieu de livrer un produit comme on le fait avec Scrum, la méthode est adaptée pour livrer des services, ou des outils par exemple. C’est une organisation des taches par un workflow d’exécution, qui vont prendre différents états (analyse, réalisation, validation, …). On va travailler sur les contraintes et sur l’exécution, ce qui va permettre d’avoir une fluidité de livraison. C’est une méthode adaptée aux projets en TMA, avec peu de nouvelles fonctionnalités et beaucoup de bugs. Cela permet de gérer le bug sans attendre qu’il entre dans une itération. Le kanban fonctionne aussi très bien sur les équipes qui sont sur plusieurs projets en même temps.

Extreme programming : méthode orientée développement (comme le TDD, le pair programming, le simple design, le collective code ownership), qui vise à livrer un meilleur logiciel. Le pair programming, par exemple, c’est un ordinateur pour deux, où la réalisation est partagée. Ça permet d’être mieux challengé, et d’avoir une meilleur qualité de code (puisque la revue du code se fait en temps réel). Cela permet aussi un meilleur partage des connaissances, puisque à la fin de la séance de pair programming, les deux développeurs sont au même niveau de connaissance. Cela permet enfin de faire monter en compétence les développeurs sur certaines méthodes, sur certaines pratiques, ou sur de nouveaux concepts.

Scrum : petites équipes auto-organisées et pluri-disciplinaires (design, code, testeurs, …). Les livraisons sont découpées en itération, et le développement suit ces itérations, appelées Sprints. Chaque semaine on optimise le processus par une rétrospective, pour améliorer les sprints suivants.
Scrum est davantage une organisation de projet plutôt que des pratiques techniques, d’où son attrait aujourd’hui.
Scrum est difficile à mettre en place en entreprise par des managers, parce que les managers font partie des couches qui dans Scrum n’ont plus lieu d’exister. Dans le Scrum il y a trois profils, le product owner, le Scrum-master, et l’équipe de développement. Pour qu’un projet puisse être correctement mené à bien avec Scrum, il faut sensibiliser toutes les parties sur le fait que les trois profils pré-cités font partie de la même équipe, et qu’ils travaillent ensemble pour produire un logiciel. C’est d’autant plus difficile à mettre en place en France, que les modèles utilisés dans les entreprises utilisent des archétypes MOA et MOE figés, et ne veulent pas migrer vers ce que préconise Scrum, c’est à dire une collaboration. C’est pour cela qu’il est important lors de la mise en place de Scrum, que tous les membres de l’équipe (Product Owner, Scrum Master et équipe de développement) soient physiquement dans le même bureau.

Le bilan :
Beaucoup d’entreprises s’essaient aux pratiques agiles, mais sans un changement de culture d’entreprise, et sans soutien des cadres dirigeants, peu réussissent à l’adopter pleinement. Pourtant chez les entreprises où le changement à été accepté, accompagné, et accueilli positivement, les bénéfices de la mise en place des méthodes agiles se sont fait rapidement ressentir : meilleure cohésion des équipes, meilleure adaptation aux changements, meilleur rendement, et une valorisation des personnes.