Catégorie : Scrum

Le backlog de produit répertorie toutes les caractéristiques, fonctions, exigences, améliorations et corrections requises pour les versions du produit. Les projets du backlog de produit ont les attributs de description (détaillés de manière appropriée), de story points (estimations) et d’ordres (hiérarchisés). Ils doivent être continuellement ajoutés, supprimés et mis à jour (Emergent) dans le backlog, et refléter la compréhension du backlog de l’équipe en temps opportun et de manière appropriée .

Le développement agile est une méthode de développement centrée sur l’humain, itérative et graduelle. Dans le développement agile, la construction d’un projet logiciel est divisée en plusieurs sous-projets, et les résultats de chaque sous-projet ont été testés et ont les caractéristiques d’intégration et d’exploitation. En d’autres termes, un grand projet est divisé en plusieurs petits projets qui sont interdépendants mais qui peuvent aussi être exécutés indépendamment, et achevés séparément. Au cours de ce processus, le logiciel est toujours dans un état utilisable.

LeSS est un cadre Agile léger permettant d’étendre Scrum à plus d’une équipe. En 2005, Bas Vodde et Craig Larman ont développé le cadre LeSS après avoir utilisé les principes et les règles de Scrum sur des projets à grande échelle. Leur objectif était de développer avec succès des projets à grande échelle tout en restant dans les contraintes de Scrum.

La plupart des formations Agile et Scrum font référence à une règle de 7 +/- 2, c’est-à-dire que les équipes Agile ou Scrum devraient compter de 5 à 9 membres. Les enthousiastes de Scrum se souviendront peut-être que le guide Scrum stipule que les équipes Scrum ne doivent pas compter moins de 3 membres ni plus de 9. D’où vient cette règle empirique ? et pourquoi ?

LeSS a été créé par Bas Vodde et Craig Larman à partir d’une expérience pratique de mise à l’échelle de Scrum, fondée sous le nom de LeSS Company en 2014. Le principe “More with LeSS” est au cœur de LeSS (Large Scale Scrum). Le développement de produits complexes ne nécessite pas de solutions complexes. Il nécessite une compréhension profonde de l’essence des problèmes, qui peuvent ensuite être résolus avec des solutions plus simples.