Paris

La lutte contre les facteurs de coût est éternelle. Le taylorisme et, en allant plus loin, le fordisme ont tenté d'apporter des réponses par la division du travail et l'augmentation des cadences sur les tâches à valeur ajoutée. Ces théories ont trouvé leur mise en application dans le développement informatique à travers les approches classiques, telles que la Cascade et sa version évoluée, le Cycle en V. Dans son approche Lean, Toyota s'est attaché à réduire les coûts en s'attaquant à toute forme de gaspillage.

La gestion des bugs est une question récurrente dans un projet Scrum. L'objectif est de livrer à chaque Sprint une version prête à partir en production avec zéro défaut, pourtant on se confronte régulièrement aux même questions: doit-on faire un backlog séparé ? Le Product Owner doit-il prioriser à chaque nouveau bug le sprint backlog ? Les bugs doivent-ils être planifiés au prochain sprint ? mais alors comment gère-t-on les incidents urgents ? Au fil de notre expérience sur des dizaines de projets nous avons élaboré 3 règles simples pour gérer efficacement les retours de bugs dans le sprint.

Scrum est admirablement efficace quand on travaille sur un unique produit avec une équipe dédiée. Mais comment organiser le Scrum quand on a plusieurs projets à mener de front, qu’ils se chevauchent, qu’ils ont des bases techniques différentes ou au contraires des interdépendances ?

Le Scrumboard est l’outil de pilotage visuel du Scrum. En améliorant votre ScrumBoard vous pouvez améliorer l’efficacité de votre équipe. Dans cette session nous verrons 5 astuces que CLT met en œuvre pour plus de productivité.

Les principes agiles prônent la livraison d'un logiciel qui fonctionne bien, le plus tôt et le plus souvent possible (www.agilealliance.org/principles.html). Ce principe est souvent mal interprété et est présenté comme excuse pour ne pas documenter le code, pour ne pas faire une revue de code, pour limiter la portée des tests unitaires, ... le tout dans le but de présenter l'application le plus rapidement aux personnes qui demandent de la voir. Pourtant, l'agilité n'est pas synonyme de mauvaise qualité ou manque de fonctionnalité: les défenseurs de l'agilité parlent souvent de revue de code, de TDD, d'intégration continue et de la diminution de la dette technique. Ces techniques de développement, couplés à une batterie d'outils, font partie, naturellement, de ce qu'on appelle "pratiques et méthodes agiles". L'agilité n'est donc, pas synonyme des délais de livraison forcement plus courts.

On parle souvent de Scrum comme cadre pour différentes méthodes de développement (le plus souvent agiles) avec des équipes limitées en tailles, avec un Product Owner bien identifié et un ScrumMaster faisant partie de l'Equipe. Mais comment cela se passe dans le cas des projets impliquant plusieurs dizaines de développeurs, dans un contexte de grande ou très grande entreprise? Plusieurs ajustements s'imposent. Les cycles de développement se rallongent, les contraintes sont plus fortes, les règles de gouvernance plus nombreuses. Chaque équipe doit se synchroniser avec d’autres équipes avant la livraison et les équipes sont rarement localisées au même fuseau horaire. Les "Scrums of Scrum" se mettent en place et sont essentiels. Les ScrumMaster ont le choix entre être ScrumMaster et membre de l'Equipe ou être ScrumMaster à plein temps en gérant plusieurs Equipes Scrum.

Sommaire : Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.

Cascade, la performance sans parachute ! La performance est un risque. Échouer à la gérer comme tel peut mettre gravement en péril le projet. Nous allons présenter les soubresauts d’un projet en cascade à partir de sa mise en production, et les tentatives désespérées pour maitriser la performance en production, jusqu'à l’impasse, ou presque.Une raison à tout cela, la performance n’a jamais été prise en compte lors de la construction du logiciel. La mise en production est un grand saut dans le vide, sans parachute. Le processus agile nous fournit l’opportunité de prendre en compte la performance suffisamment tôt. Comment les pratiques de l’Agile telles que le release plan, le test, la définition de terminé, et le design incrémental peuvent-ils nous y aider ?

Manifeste pour une BI industrialisée. Business intelligence…Voila qui laisse augurer un processus de fabrication parfaitement maîtrisé, un haut niveau de productivité, et une forte capacité d’adaptation. L’évolution constante de nos systèmes d’information et la nécessité d’ajuster la stratégie de l’entreprise pourrait en effet le laisser supposer. Mais la réalité est bien souvent, tout autre. Une approche taylorienne de l’industrialisation, l’hyper spécialisation par tache et par outils ont littéralement appauvri les savoir-faire des développeurs et réduit l’adaptabilité des opérationnels face au défis du système d’information L’objectif de cette session sera dans un premier temps de faire un état des lieux, donner une définition moderne de l’industrialisation, et ensuite dessiner les contours d’une BI industrialisée basés sur la mise en œuvre des démarches agiles

Signs of succesful Agile Projects The session proposes to build a perspectiive of team perception of what are the factors and the characteristiscs of an succesfull agile project. Succes mughbe percieved differently when respective of the former experience of the team, the coachn, the client or management. The conference presents a framework of "succes interpretation" in the first part, and propose a second part in a workshop form. The goal of the workshop is to build together a specific "code of succesful Agile" that will be the outcome of the session.