Cet espace à pour but de regrouper les informations lié au processus (organisation, release, facilitation, participation des utilisateurs etc.). Il s'enrichira au fil des besoins.

Entreprise AFI et BibLibre:

  • L'équipe technique de hotline est composée de développeurs liés à ces 2 entreprises aujourd'hui et s'organise selon un processus Kanban piloté sur "la forge" sous redmine: http://forge.afi-sa.fr
  • L'équipe de développement projet se coordonne selon un processus Scrum et est composée aussi de plusieurs personnes de ces 2 entreprises
  • Une cellule de travail s'organise quand il y a des possibilités autour de besoins "R&D" (Recherche & Développement)

Processus "sprint" : on fait quoi concrètement ?

  • Un sprint est une itération de développement de 15 jours. A l'issue de chaque sprint la livraison des développements est effectuée sur la version "master" Voir notes de version : http://wiki.bokeh-library-portal.org/index.php?title=Cat%C3%A9gorie:Notes_de_version
  • Des tickets de développements émanent du support (correctifs, améliorations), des projets (cahier des charges), d'une commande (financement d'un développement), ou de la R&D (Recherche & Développement) AFI/BibLibre
  • Tous les vendredi (soit 2 par sprint)

L'équipe de développement réalise des "stories" : il s'agit de décrire le ticket en termes fonctionnels et techniques afin d'en évaluer le périmètre et de recouper la demande avec d'autres besoins : est-ce que cela intéresse tous les utilisateurs Bokeh, y'a t'il un risque de conflit avec une autre fonctionnalité, comment organiser les écrans, est-ce une fonctionnalité publique ou réservé aux administrateurs, peut-on utiliser une fonction similaire pour créer la nouvelle fonction attendue etc... Y participe les chefs de projets, les product owners (qui sont responsables de la planification du sprint) et parfois même le client qui a commandé la fonctionnalité quand il est identifié.

- Puis une fois la story réalisée elle est soumise au "poker time". Les développeurs évaluent individuellement le temps de réalisation du ticket selon la complexité de celui-ci. Les tickets sont évalués en points : de 0.5 à 5 en moyenne.

  • Quelques jours avant la fin du sprint précédent :

- Les tickets pokérisés sont évalués par les product owners (2 personnes) selon sa valeur pour la communauté, l'intérêt pour les usagers finaux, sa capacité à résoudre un incident support, l'apport en terme d'innovation ainsi que le budget alloué.

- Les tickets ayant obtenu le plus de points passent candidats au sprint. On passe systématiquement 1 ou 2 tickets de R&D pour ne pas passer que des commandes et garder des développements à valeur ajoutée.

  • Le lundi

- L'équipe de développement livre le sprint précédent : version stable (correctifs) + version master.

- Le sprint qui démarre est planifié : on évalue le temps de développement disponible en fonction du planning des développeurs (absence, disponibilité d'un développeur sur le support ou un autre produit..) ce qui donne un temps en points. On planifie alors selon les points de disponibilité les tickets qui peuvent être réalisés pendant le sprint. Exemple : on obtient 9 points de disponibilité des développeurs. On a prévu en tickets candidat 3 tickets à 3 points, 2 à 0.5 et 1 à 2 points soit 12 points. Ceux sont les tickets qui ont obtenu le plus de valeur lors de l'évaluation des PO qui seront planifiés et ceux qui n'ont pu être ajouté au sprint seront de nouveau candidats pour le suivant. - L'équipe de développement a donc une liste de tickets à réaliser dans les 15 jours.

  • Le temps du sprint

- Les développeurs se répartissent les tickets en début de sprint. Ils peuvent y travailler seul ou en binôme. Le ticket va passer plusieurs statuts : de "à qualifier" il va passer "en développement", puis quand le ou les développeurs estiment avoir terminé le développement, le ticket est soumis à une revue technique : un autre développeur va contrôler la qualité du code. Si il passe les tests, il est alors soumis en "à réaliser/tester". Un fonctionnel (un chef de projet, une personne du support, un formateur ou le client) teste le développement d'un point de vue fonctionnel selon la documentation réalisée par les développeurs. Si le ticket passe le test il passe en "à intégrer" puis en "fermé" sinon il repart en statut "en développement" et le développeur corrige.

  • En fin de sprint (le 2e vendredi)

- L'équipe de développement finalise la documentation du wiki Bokeh (dont captation vidéo quand utile) - Réalise des tests de déploiements

  • Le lundi

- On boucle avec la livraison et la planification du sprint suivant.

Cette catégorie ne contient aucune page, sous-catégorie ou fichier multimédia.

Site hébergé et maintenu par AFI et BibLibre et enrichi par la communauté de Bokeh.