Time to market delivery in sync with business users changing requests.
Valtech prioritize and reassesses software features in short cycles in order to maximize the business value of the delivered software. The continuous delivery of features and real-time progress data increase stakeholder visibility and ensure that customer requirements are perfectly understood. Continuous testing and user feedback reduces defects to zero or near zero. Time and money aren’t wasted developing no-value-add features.
PDF (296 Kb) - [EN] - Valtech Agile Offshore whitepaper 2005
The case for delivering low cost software development AND strategic business transformation.
The case for delivering low cost software development AND strategic business transformation.
PDF (521 Kb) - [FR] - Agile & Offshore : Technique de survie dans le milieu bancaire
Le développement off-shore exacerbe la plupart des symptômes rencontrés lors de projets menés en sous-traitance on-shore. Sans compter les difficultés spécifiques liées à l'éloignement géographique ou culturel. Un des 4 principes fondateurs des méthodes de développement agiles repose sur la nécessité d'interactions fréquentes entre les acteurs d'un projet : la colocalisation utilisateurs / équipe de développement est présentée comme un atout majeur de réussite. Malgré l'incompatibilité évoquée, mettre en place un processus de développement agile en off-shore est un choix qui, par expérience, s'est révélé extrêmement judicieux en termes de qualité du produit développé comme en termes de gouvernance de projet. Certes, ce n'est pas simple...
Le développement off-shore exacerbe la plupart des symptômes rencontrés lors de projets menés en sous-traitance on-shore. Sans compter les difficultés spécifiques liées à l'éloignement géographique ou culturel. Un des 4 principes fondateurs des méthodes de développement agiles repose sur la nécessité d'interactions fréquentes entre les acteurs d'un projet : la colocalisation utilisateurs / équipe de développement est présentée comme un atout majeur de réussite. Malgré l'incompatibilité évoquée, mettre en place un processus de développement agile en off-shore est un choix qui, par expérience, s'est révélé extrêmement judicieux en termes de qualité du produit développé comme en termes de gouvernance de projet. Certes, ce n'est pas simple...
PDF (1707 Kb) - [FR] - Agile & Offshore : Rétrospective d'un projet à 1 million d'euros
De nombreux projets offshore sont en difficulté et ceci pour de multiples raisons: organisation complexe, problème de communication, manque de visibilité interne vis à vis du client, processus de développement onshore et offshore différents, difficulté d'acquérir rapidement de réelles compétences métier, de comprendre les besoins réels du client et bien d'autres causes. Quelle est donc la clef du succès dans un contexte ou l'offshore s'impose comme quasiment le seul modèle économique répondant à la loi du marché (low cost & time to market) ? L'offshore agit comme un verre grossissant, amplifiant tous les défauts de la fabrique logicielle. La trousse à pharmacie? Etre agile, réagir rapidement, faire simple, se rapprocher du client le plus souvent possible, faire la chasse au bug et bien d'autres petites choses efficaces et simples à la fois. Encore fallait-il y penser.
De nombreux projets offshore sont en difficulté et ceci pour de multiples raisons: organisation complexe, problème de communication, manque de visibilité interne vis à vis du client, processus de développement onshore et offshore différents, difficulté d'acquérir rapidement de réelles compétences métier, de comprendre les besoins réels du client et bien d'autres causes. Quelle est donc la clef du succès dans un contexte ou l'offshore s'impose comme quasiment le seul modèle économique répondant à la loi du marché (low cost & time to market) ? L'offshore agit comme un verre grossissant, amplifiant tous les défauts de la fabrique logicielle. La trousse à pharmacie? Etre agile, réagir rapidement, faire simple, se rapprocher du client le plus souvent possible, faire la chasse au bug et bien d'autres petites choses efficaces et simples à la fois. Encore fallait-il y penser.
PDF (134 Kb) - [FR] - Agilité : à monter soi-même...
Que faire lorsque les pratiques agiles "standards" ne semblent pas appropriées à un contexte donné? Voici un aperçu, avec exemples, de différentes approches inspirées de la "pensée des systèmes" qui permettent d'adapter les méthodes agiles sans pour autant renoncer à leurs valeurs.
Que faire lorsque les pratiques agiles "standards" ne semblent pas appropriées à un contexte donné? Voici un aperçu, avec exemples, de différentes approches inspirées de la "pensée des systèmes" qui permettent d'adapter les méthodes agiles sans pour autant renoncer à leurs valeurs.
PDF (341 Kb) - [FR] - De la différence entre "2 personnes devant un PC" et "binomage"
Le binômage est doublement l'apanage des privilégiés. Tout d'abord, par définition, c'est l'une des pratiques que l'on ne peut pratiquer seul. De plus, le binômage est la partie la plus visible de l'iceberg XP; en ce sens, il est difficile de le mettre en pratique sans l'aval de sa direction. Le binômage est aussi doublement sensible. L'aspect financier fait du binômage l'une des pratiques les plus polémiques et controversées («Binômer c'est multiplier les coûts par 2»). Cela occulte trop souvent l'autre challenge: pour tenter l'aventure du «Pair Programming» de façon efficace et durable, on doit considérer le binôme comme une paire non plus de «ressources», mais bien de «personnes», avec la dimension relationnelle que cela implique.
Le binômage est doublement l'apanage des privilégiés. Tout d'abord, par définition, c'est l'une des pratiques que l'on ne peut pratiquer seul. De plus, le binômage est la partie la plus visible de l'iceberg XP; en ce sens, il est difficile de le mettre en pratique sans l'aval de sa direction. Le binômage est aussi doublement sensible. L'aspect financier fait du binômage l'une des pratiques les plus polémiques et controversées («Binômer c'est multiplier les coûts par 2»). Cela occulte trop souvent l'autre challenge: pour tenter l'aventure du «Pair Programming» de façon efficace et durable, on doit considérer le binôme comme une paire non plus de «ressources», mais bien de «personnes», avec la dimension relationnelle que cela implique.
PDF (545 Kb) - [FR] - Contractualisation des projets Agiles
Les méthodes agiles sont de plus en plus utilisées au sein de tous types d'organisations pour les équipes de développement internes. Cela est beaucoup moins vrai pour les développements sous-traités. Le premier obstacle et peut être le principal est l'impossibilité par nature de contractualiser un projet en méthodes agiles pour un coût fixe. Quelles alternatives à la pure régie peut-on proposer à nos acheteurs ? Comment rendre compatible un projet agile avec un appel d'offre publics ? Doit-on choisir un sous-traitant uniquement sur des critères de prix ? Voici autant de questions sur les contrats auxquelles nous tenterons de trouver une réponse.
Les méthodes agiles sont de plus en plus utilisées au sein de tous types d'organisations pour les équipes de développement internes. Cela est beaucoup moins vrai pour les développements sous-traités. Le premier obstacle et peut être le principal est l'impossibilité par nature de contractualiser un projet en méthodes agiles pour un coût fixe. Quelles alternatives à la pure régie peut-on proposer à nos acheteurs ? Comment rendre compatible un projet agile avec un appel d'offre publics ? Doit-on choisir un sous-traitant uniquement sur des critères de prix ? Voici autant de questions sur les contrats auxquelles nous tenterons de trouver une réponse.
PDF (53 Kb) - [FR] - Language Oriented Programming : Using DSLs as a new Agile abstraction and modeling mechanism
Every single J2EE or .NET programmer has already used some form of Domain Specific Languages (DSLs) on their projects, often without being aware of that fact. In this presentation I will identify different kinds of DSLs and introduce you to Language Oriented Programming, the style of development based on using DSLs as a new abstraction and modeling mechanism. This allows creating more readable, technology-agnostic and agile solutions, thus helping to bridge the gap between professional developers and business people. I will try to show what can be the value added of using Language Oriented Programming on complex real-world projects and present some tools available today that could help you in adapting this approach.
Every single J2EE or .NET programmer has already used some form of Domain Specific Languages (DSLs) on their projects, often without being aware of that fact. In this presentation I will identify different kinds of DSLs and introduce you to Language Oriented Programming, the style of development based on using DSLs as a new abstraction and modeling mechanism. This allows creating more readable, technology-agnostic and agile solutions, thus helping to bridge the gap between professional developers and business people. I will try to show what can be the value added of using Language Oriented Programming on complex real-world projects and present some tools available today that could help you in adapting this approach.
PDF (47 Kb) - [FR] - Le Refactoring : la solution agile pour conserver un code évolutif
A travers une démonstration "live" portant sur du code Java, vous allez apprendre comment manier les techniques de refactoring proposées par les outils de développement modernes pour faire émerger une conception propre à partir d'un code initialement médiocre.
A travers une démonstration "live" portant sur du code Java, vous allez apprendre comment manier les techniques de refactoring proposées par les outils de développement modernes pour faire émerger une conception propre à partir d'un code initialement médiocre.
PDF (2973 Kb) - [FR] - Test Driven Requirements : Intruction et perspectives
La gestion des exigences dirigée par les tests, ou Test-Driven Requirements (TDR), représente l’étape ultime dans l’adoption d’un processus de dévelopement dit « lean ». La présentation se propose de dresser un état de l’art du Test-Driven Requirements après avoir parcouru ses principes fondateurs que sont le Lean Software Development et le Test-Driven Development. Nous détaillerons différentes pratiques de TDR, telles que l’écriture de spécifications fonctionelles testables avec des outils comme FIT, ou la génération de test basée sur l’interprétation de modèles comportementaux. La mise en œuvre de ces pratiques sera illustrée par des retours d’expérience. Les impacts sur l’organisation et la redistribution des rôles seront également mis en lumière.
La gestion des exigences dirigée par les tests, ou Test-Driven Requirements (TDR), représente l’étape ultime dans l’adoption d’un processus de dévelopement dit « lean ». La présentation se propose de dresser un état de l’art du Test-Driven Requirements après avoir parcouru ses principes fondateurs que sont le Lean Software Development et le Test-Driven Development. Nous détaillerons différentes pratiques de TDR, telles que l’écriture de spécifications fonctionelles testables avec des outils comme FIT, ou la génération de test basée sur l’interprétation de modèles comportementaux. La mise en œuvre de ces pratiques sera illustrée par des retours d’expérience. Les impacts sur l’organisation et la redistribution des rôles seront également mis en lumière.
PDF (416 Kb) - [FR] - UML est-il solutble dans les méthodes agiles ?
On entend beaucoup parler de deux approches ayant l'air fondamentalement opposées : l'approche Model-Driven s'appuyant sur une modélisation UML très poussée avec génération automatique de code et les méthodes agiles mettant plutôt l'accent sur la production rapide de code opérationnel sans trop de modélisation amont. Qu'en est-il vraiment ? UML est-il réellement utilisable dans un contexte agile ?
On entend beaucoup parler de deux approches ayant l'air fondamentalement opposées : l'approche Model-Driven s'appuyant sur une modélisation UML très poussée avec génération automatique de code et les méthodes agiles mettant plutôt l'accent sur la production rapide de code opérationnel sans trop de modélisation amont. Qu'en est-il vraiment ? UML est-il réellement utilisable dans un contexte agile ?
PDF (123 Kb) - [EN] - Agile documentation
Documents are often highly prioritized in software development projects. So much in fact that many non-agile practices focus almost exclusively on detailing the production of documents, hardly mentioning anything about the actual coding practices. The exception of course, stating that it should be well documented.
This document centric tradition is hard to break even within agile projects. Too many Word files are emailed, printed out or even checked into the version control system. Documents and diagrams are created out of habit even when they are not needed.
Documents are often highly prioritized in software development projects. So much in fact that many non-agile practices focus almost exclusively on detailing the production of documents, hardly mentioning anything about the actual coding practices. The exception of course, stating that it should be well documented.
This document centric tradition is hard to break even within agile projects. Too many Word files are emailed, printed out or even checked into the version control system. Documents and diagrams are created out of habit even when they are not needed.
PDF (140 Kb) - [EN] - Fragile not Agile
A fragile project lives on the edge, always on the verge of breaking down. Project members are regularly, perhaps constantly, fighting fires. Being fragile can be an exhausting experience for individuals, teams and organizations. So what causes a project to be fragile? Can a team, project or organization give the impression of being Agile when in fact it is very fragile? Sadly, the answer is yes. Misconceptions, miscommunications and misunderstandings cause problems for individuals, teams, projects and organizations. These problems are more vexing and harder to correct when they are due to mistaken beliefs or myths. To dispel a myth, you must understand where it comes from, what it means and why people hold onto it, even if it’s harmful. The next step is to replace myth with truth—replacing Agile myths with Agile truths, using the principles behind the Agile Manifesto. By replacing myth with truth, a fragile project can become truly Agile. In this report we will look at what can cause a fragile project to delude itself into thinking it is Agile. We will look at common beliefs that lead to fragile behavior and cures for turning fragile projects into Agile ones. The cures come from understanding and applying the principles behind the Agile Manifesto.
A fragile project lives on the edge, always on the verge of breaking down. Project members are regularly, perhaps constantly, fighting fires. Being fragile can be an exhausting experience for individuals, teams and organizations. So what causes a project to be fragile? Can a team, project or organization give the impression of being Agile when in fact it is very fragile? Sadly, the answer is yes. Misconceptions, miscommunications and misunderstandings cause problems for individuals, teams, projects and organizations. These problems are more vexing and harder to correct when they are due to mistaken beliefs or myths. To dispel a myth, you must understand where it comes from, what it means and why people hold onto it, even if it’s harmful. The next step is to replace myth with truth—replacing Agile myths with Agile truths, using the principles behind the Agile Manifesto. By replacing myth with truth, a fragile project can become truly Agile. In this report we will look at what can cause a fragile project to delude itself into thinking it is Agile. We will look at common beliefs that lead to fragile behavior and cures for turning fragile projects into Agile ones. The cures come from understanding and applying the principles behind the Agile Manifesto.
PDF (180 Kb) - [EN] - Rural Shore
New outsourcing models are beginning to manifest in the marketplace – namely the move from traditional offshore models to Near Shore, Agile Off Shore and Agile Rural Shore models.
This presentation depicts the reasons for an increasing failure rate in Traditional Offshoring which has led to the evolution of these emerging models.
The presentation will discuss the primary factors contributing to successful project deployments – people, process and technology. Discussions will comprise iterative development; whether SEI/CMMi equates to good software development and Agile methods. The presentation will provide an overview on emerging outsourcing models with a focus on the Agile Rural Shoring model. There will also be an opportunity for audience participatory discussion regarding their experience with different outsourcing models.
New outsourcing models are beginning to manifest in the marketplace – namely the move from traditional offshore models to Near Shore, Agile Off Shore and Agile Rural Shore models.
This presentation depicts the reasons for an increasing failure rate in Traditional Offshoring which has led to the evolution of these emerging models.
The presentation will discuss the primary factors contributing to successful project deployments – people, process and technology. Discussions will comprise iterative development; whether SEI/CMMi equates to good software development and Agile methods. The presentation will provide an overview on emerging outsourcing models with a focus on the Agile Rural Shoring model. There will also be an opportunity for audience participatory discussion regarding their experience with different outsourcing models.
PDF (493 Kb) - [EN] - Moving to Scrum
SCRUM is an Agile, lightweight project management process that can be used to manage and control software and product development using iterative and incremental best practices. SCRUM significantly increases productivity, improves team morale, and reduces the amount of time it takes to begin realizing business value while mitigating project risks. This presentation will give you good insight into what it takes to make SCRUM work on your project and in your organization.
SCRUM is an Agile, lightweight project management process that can be used to manage and control software and product development using iterative and incremental best practices. SCRUM significantly increases productivity, improves team morale, and reduces the amount of time it takes to begin realizing business value while mitigating project risks. This presentation will give you good insight into what it takes to make SCRUM work on your project and in your organization.
PDF (301 Kb) - [FR] - Scrum - l'esprit d'équipe !
Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet.
Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques.
Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet.
Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques.
PDF (317 Kb) - [FR] - XP - ça marche vraiment ?
Régis Medina (www.design-up.com) est interviewé par Véronique Rota sur son retour d’expérience autour de la mise en œuvre d’XP.
Développement et planification par itérations, pair programming, suivi de projet, refactoring, bénéfices et conseils sont des sujets qui sont abordés dans ce papier.
(Chaque thème est illustré par des images recueillies lors des différentes missions.)
Régis Medina (www.design-up.com) est interviewé par Véronique Rota sur son retour d’expérience autour de la mise en œuvre d’XP.
Développement et planification par itérations, pair programming, suivi de projet, refactoring, bénéfices et conseils sont des sujets qui sont abordés dans ce papier.
(Chaque thème est illustré par des images recueillies lors des différentes missions.)
PDF (436 Kb) - [FR] - Agile project Management
Les projets agiles mettent l’accent sur l’interaction entre les personnes, l’initiative et la part
Les projets agiles mettent l’accent sur l’interaction entre les personnes, l’initiative et la part
Search for a subject by typing in a keyword.