Catégorie: Documentation processus

De WIKI-BOKEH
Aller à : navigation, rechercher

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 Scrum 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)
  • Nous pratiquons le "Scrum" selon un processus reconnu: https://fr.wikipedia.org/wiki/Scrum_(d%C3%A9veloppement)

Cadre de développement Scrum: on fait quoi concrètement ?[ ]

Un sprint est une itération de développement de 3 semaines. A l'issue de chaque sprint la livraison des développements est effectuée. 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


  • Quelques jours avant le sprint :

La Scrum Team 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).

Les stories sont étudiées et priorisées par les product owners (2 personnes) selon leurs valeurs pour la communauté, l'intérêt pour les usagers finaux, leurs capacités à résoudre un incident support, l'apport en terme d'innovation ainsi que le budget alloué.

On évalue ensuite 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.


  • Les stories sont ensuite soumises au "poker time"

Suite à la découpe en tâches des stories, les développeurs évaluent individuellement le temps de réalisation de la tâche selon la complexité de celle-ci. Les tickets sont évalués en points : de 1 à 21 en moyenne.

En fonction de la capacité de l'équipe, les stories sont ajoutées dans le sprint par ordre de priorité définie par les product owners. Celles qui n'ont pu être ajoutées au sprint seront de nouveau candidate pour le suivant. - L'équipe de développement a donc une liste de tickets à réaliser dans le sprint.


  • Le temps du sprint

- L'équipe de développement livre le sprint précédent : correctifs + nouvelles fonctionnalités.

- Les développeurs dépilent les tickets du sprint selon leurs priorités. Ils peuvent y travailler seul ou en binôme. Le ticket va passer par plusieurs statuts : de "planifié" 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, le ticket passe 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. Si le test est concluent,  la story passe en "à release" sinon elle repart en statut "en développement" afin que le développeur intègre les retours fonctionnels.


  • En fin de sprint 

- L'équipe effectue une revue de sprint : L'objectif est d'inspecter le résultat du Sprint et de déterminer les adaptations futures. L'équipe présente les résultats de son travail aux principales parties prenantes et les progressions vers l'objectif de Produit sont discutées.

- L'équipe effectue une retrospective : L'objectif consiste à réfléchir à des pistes pour améliorer la qualité et l'efficacité. L'équipe inspecte le déroulement du dernier Sprint en ce qui concerne les individus, les interactions, les processus, les outils et leur Definition of Done.

- On boucle ensuite avec la planification du sprint suivant.

Média dans la catégorie « Documentation processus »

Cette catégorie comprend 4 fichiers, dont les 4 ci-dessous.