Aperçu
Sprint Execution
- Les développeurs font un « Checkout » du code du Repository partagé, dans leur environnement local, effectuent les changements, les revues de codes et tests (automatisation recommandée pour les revues codes & tests unitaires!)
- Lorsque le code est suffisamment stable (revues & tests passent), ils font un « Commit » du code dans le Repository partagé (au moins une fois par jour!)
- Suite au Commit, le Build (compilation/compression) et les Tests sont effectués
- Si tous les tests passent, cette dernière version du code est déployée dans l’environnement d’intégration « INT » pour les tests manuels .
- Si les tests manuels passent (confirmation testeur), alors cette version est promue dans l’environnement « UAT » et ensuite « STG » selon le même principe
- Finalement, si toute s les étapes précédentes se passent bien, et sur autorisation du Support, cette version est déployée en production « PROD »
Un rapport détaillé est communiqué aux parties prenantes à chaque étape! Pour être effective les opérations CI et DI doivent être le plus possible automatisées
Scrum Board
Comment marche le Scrum Board?
Scrum Board en début de Sprint
Scrum Board après premier daily
Scrum Board après quelques jours
Scrum Board et non respect priorités
Scrum Board et Tâches non planifiées
Exemple de Scrum Board physique
DevOps
En cours de préparation
« Nos experts travaillent avec vos équipes sur vos projets pour vous accompagner et aider à sécuriser vos engagements quel que soit votre niveau de maturité Agile. Nous vous aidons à mettre en place écosystème et conditions d’amélioration continue de votre Organisation. Voir nos services »