[:fr]Développement Agile[:en]Agile development[:]

Agile development

[:fr]Tous nos développements se basent sur la méthode agile, permettant d’atteindre un degré de perfection élevé en un temps restreint et surtout en collant de manière permanente aux besoins réels du client.

Dans le passé, on avait plutôt ça:

projet it avant humour

Et le déroulement était le suivant:

  1. Élaboration d’un cahier des charges
    Devant s’effectuer par le client, cette tâche est lourde et se devait d’être la plus précise possible. Étonnamment il n’est que rarement fait par les utilisateurs finaux.
  2. Analyse et devis
    Le développeur estime le temps qu’il faut pour réaliser un produit répondant au cahier des charges et ajoute une marge pour les imprévus. Tout en se devant d’être le moins cher possible, ce qui un peu incohérent.
  3. Développement et livraison d’une version
    Le client doit alors attendre tout le temps du développement et se retrouve ensuite avec la surprise du résultat, parfois bien loin de son idée initiale.
  4. Corrections et re-livraison
    Le développeur retourne à son travail et va parfois engager une énorme quantité de ressources pour adapter son produit aux attentes. Il aura très vite consommé tout le temps disponible, ce qui amène souvant à des dépenses supplémentaires
  5. Mise en production
    A ce stade, le budget est souvent dépassé, il ne reste alors plus rien à investir pour le suivi et la formation des intervenants. Ce qui serait pourtant capital pour la réussite d’un projet.

Par les méthodes Agiles, on change tout:

Elles prônent 4 valeurs fondamentales :

  • L’équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans l’optique agile, l’équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d’avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu’une équipe composée d’experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.
  • L’application (« Des logiciels intuitifs et opérationnels, plus qu’une documentation exhaustive ») : il est vital que l’application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l’équipe (on en revient à l’importance de la communication).
  • La collaboration (« La collaboration avec les clients, plus que la négociation contractuelle ») : le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes.
  • L’acceptation du changement (« L’adaptation au changement, plus que le suivi d’un plan ») : la planification initiale et la structure du logiciel doivent être flexibles afin de permettre l’évolution de la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent provoquer des demandes d’évolution.
 agile software development methodology

Principes

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

  1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
  2. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage compétitif pour le client.
  3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
  4. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
  5. Le projet doit impliquer des personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
  6. La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
  8. Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue).
  9. Les processus agiles recommandent une attention continue à l’excellence technique et à la qualité de la conception.
  10. La simplicité et l’art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
  11. Les équipes s’auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
  12. À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.

Une méthode qualifiée d’agile doit donc se composer d’un ensemble de pratiques instrumentant le cadre décrit par les 12 principes généraux agiles et en conséquence s’inscrire dans le respect des 4 valeurs fondamentales ayant inspiré le Manifeste agile.[:en]Tous nos développements se basent sur la méthode agile, permettant d’atteindre un degré de perfection élevé en un temps restreint et surtout en collant de manière permanente aux besoins réels du client.

The Agile methodology is based on 4 main values:

  1. Individuals and Interactions Over Processes and Tools
    The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
  2. Working Software Over Comprehensive Documentation
    Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
    The Agile Manifesto values documentation, but it values working software more.
  3. Customer Collaboration Over Contract Negotiation
    Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.
  4. Responding to Change Over Following a Plan
    Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.

With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.

Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method Tailoring, defined in An Agile Information Systems Development Method in use as: “A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.” Agile methodologies allow the Agile team to modify the process and make it fit the team rather than the other way around.

 agile software development methodology

Principles

These values are decomposed in 12 principles :

  1. Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
  2. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
  3. Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
  4. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.
  5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
  6. Enable face-to-face interactions – Communication is more successful when development teams are co-located.
  7. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.
  8. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
  9. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
  10. Simplicity – Develop just enough to get the job done for right now.
  11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
  12. Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.

[:]