Introduction Flashcards
Une Méthodologie?
Une méthodologie fournit un ensemble de lignes directrices
complètes pour la réalisation de chacune des activités du
cycle de développement des systèmes.
methodologie inclut quoi?
- Un processus d’encadrement de projet basé sur un cycle donné
- Des livrables
Une Méthodologie?
Plusieurs types de projets mais tous passent par les mêmes
étapes de développement
- Initiation
- Quand le projet commence, objectives et portée définis
- Planification
- Lister qui fait quoi, quand
- Exécution
- Identification et execution des taches
- Test
- Assurance qualité
- Critères d’acceptation
- Lancement
- livraison
- Revue
- Fermer le projet
Certaines méthodologies conventionnels de
processus de développement logiciel:
Modèles conventionnels
Coder et corriger : Écriture de code sans analyse ou sans plan
(Code and fix)
Exigences-codage : Codage fondé sur les besoins opérationnels
(Requirements to code)
En cascade : Phases séquentielles et analyse de tendance de jalons
(Waterfall)
Qualité
Ressources :
§ Equipe dédié d’utilisateurs
§ Ressources compétentes de projet
§ Un environnement de
collaboration adéquat
Qualité
Processus:
§ Approche / méthodologie de développement
§ Planification de projet
§ Gestion des besoins
§ Ensemble de techniques
§de modélisation
§gestion de projets
§Interview des utilisateurs
§ Critères de succès
Qualité
Technologie:
§ Standards
§ Outils
§ Architectures de référence
Quels problèmes rencontrons-nous ?
Succès: Le projet est réalisé selon le
budget et les délais convenus. Il
comporte les fonctions et
caractéristiques demandées.
Défi: Le projet est en retard, le budget a
été dépassé ou il manque certaines
fonctions et caractéristiques demandées.
Échec: Le projet a été arrêté avant sa
fin ou le logiciel développé a été livré
mais n’a jamais été utilisé.
Problèmes de communication?
Le développement logiciel est un
jeu coopératif d’invention et de
communication. Il est apparenté au
développement de produit.
Les sources de problème dans
notre profession sont les gens et
les interactions dysfonctionnelles
plutôt que les processus et les
outils.
Une complexité inhérente
Selon Grady Booch, la complexité est une
caractéristique inhérente au logiciel et elle
provient de quatre éléments :
1) la complexité des problèmes ;
2) la difficulté à contrôler le processus de développement ;
3) la flexibilité dans la programmation ;
4) le passage du monde continu au monde discret.
L’approche classique se décompose en trois phases et donner les problemes :
Conception:
Il faut concevoir tout le produit et répondre à toutes les questions dès le début;
Les utilisateurs sont sollicités dans un délai court pour valider l’intégralité du dossier
de conception;
Réalisation
Les travaux sont fortement parallélisés et sont souvent bloqués par des questions
fonctionnelles;
Toutes les fonctionnalités sont intégralement développées sans arbitrages sur le R.O.I.;
Les utilisateurs sont sollicités dans des démonstrations trop longues leur montrant de
nombreuses fonctionnalités;
Recette
Les utilisateurs sont fortement sollicités sur une période très courte;
Certains points soulevés en recette peuvent remettre en cause profondément d’autres
fonctionnalités;
Les constats
Il est très difficile de faire une conception exhaustive au démarrage du projet.
La phase de réalisation est basée sur cette exhaustivité et elle n’intègre pas
la notion de complément de conception ni de variation du besoin.
Les erreurs de conception ou de programmation ou variation du besoin sont
détectées au dernier moment ce qui aggrave leurs conséquences.
Il n’est pas efficace de solliciter les utilisateurs de manière intense sur des
périodes courtes.
L’application opérationnelle n’est disponible qu’à la fin du projet.
Il est difficile de communiquer directement avec les utilisateurs
Les constats
Les meilleures idées ne viennent pas forcément au
début du projet
- Modèle en cascade
- Il est plus facile de construire par étape que tout imaginer dès le début
Les constats
Les besoins peuvent évoluer pendent le projet
- Demandes de changements
Les constats
Le formalisme n’est pas naturel
Les constats
Contraintes contractuelles
- Insatisfaction constante du client
Les constats
Chiffrages et Reste à Faire sont difficiles à évaluer
- On ne sait pas estimer la charge restante
Certaines méthodologies itératives de
processus de développement logiciel
Modèles itératifs:
Construction incrémentale
Cycles itératifs de développement, de vérification et de démonstration
Modèle évolutif
Développement exploratoire
Agile (aussi SCRUM)
Participation du client
En spirale
Gestion des risques
Alors pourquoi le développement
Agile?
- Pour satisfaire rapidement notre client avec des solutions logicielles utiles
- Pour augmenter la qualité
- Pour faire face à la complexité
- Pour réduire les inefficacités
- Pour éviter les longues périodes de stabilisation en fin de projet
- Pour maximiser la collaboration
- Pour augmenter la motivation et l’engagement des individus
- Pour avoir du plaisir au travail
C’est quoi l’Agilité ?
La capacité d’une personne à se mouvoir facilement, avec aisance.
Implique les réflexes, la coordination et l’équilibre de l’individu
C’est quoi l’Agilité ?
Nouvelle manière d’organiser le travail
Approche réactive et itérative d’organisation de travail
C’est quoi l’Agilité ?
Evolution des métiers
Focalisée sur la fonctionnalité et satisfaction client
C’est quoi l’Agilité ?
Valorisation du capital immatériel
- Construit en adéquation avec les capacités et limites humaines
Les méthodes agiles
* Une méthode agile est une approche itérative et incrémentale, qui est menée
dans un esprit collaboratif avec juste ce qu’il faut de formalisme
- Elle génère un produit de haute qualité tout en prenant en compte l’évolution
des besoins des clients
Cependant…
Agile ne donne pas la recette secrète du développement logiciel;
Agile fournit simplement les mécanismes permettant de mettre en lumière les
problèmes et difficultés que nous rencontrons dans nos projets de
développement logiciel afin d’être en mesure de les régler;
Une équipe Agile apprend à s’améliorer
continuellement
La genèse du phénomène Agile
En 2001, dix-sept figures du développement logiciel
se sont réunies pour débattre du thème unificateur
de leurs méthodes respectives.
De cette réunion devait émerger le Manifeste Agile,
considéré comme la définition canonique
du développement Agile.
La genèse du phénomène Agile
Le manifeste Agile, Il se compose de 4 valeurs et de 12 principes.
Personnes et interactions <- que Processus et outils
Un produit opérationnel <- Documentation exhaustive
Collaboration avec le client <- Négociation d’un contrat
Adaptation au changement <- Suivi d’un plan
12 principes sous-jacents au
manifeste
- Notre plus haute priorité est de satisfaire le client en livrant rapidement
et régulièrement des fonctionnalités à grande valeur ajoutée. - Accueillez positivement les changements de besoins, même tard dans
le projet. Les processus Agiles exploitent le changement pour donner
un avantage compétitif au client. - Livrez fréquemment un logiciel opérationnel avec des cycles de
quelques semaines à quelques mois et une préférence pour les plus
courts. - Les utilisateurs ou leurs représentants et les développeurs doivent
travailler ensemble quotidiennement tout au long du projet. - Réalisez les projets avec des personnes motivées. Fournissez-leur
l’environnement et le soutien dont ils ont besoin et faites-leur
confiance pour atteindre les objectifs fixés. - La méthode la plus simple et la plus efficace pour transmettre de
l’information à l’équipe de développement et à l’intérieur de celle-ci est
le dialogue en face à face. - Un logiciel opérationnel est la principale mesure d’avancement.
- Les processus Agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires, les développeurs et les
utilisateurs devraient être capables de maintenir indéfiniment un rythme
constant. - Une attention continue à l’excellence technique et à une bonne
conception renforce l’Agilité. - La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile
– est essentielle. - Les meilleures architectures, spécifications et conceptions émergent
d’équipes auto-organisées. - À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus
efficace, puis règle et modifie son comportement en conséquence.
Les Méthodes ‘Agiles’
Les méthodes classique fonctionnent bien, à
condition d’avoir:
- Stabilité et prévisibilité
- Communication et compréhension parfaite
- Choix parfaits dès le départ
Libérer le génie humain
pour l’auto-organisation dans un contexte qu’il peut maîtriser :
- La taille de l’équipe est limitée
- le domaine du problème est limité
- Petites équipes autogérées
- Portée fonctionnelle restreinte à un moment donné
- Garder un rythme de travail soutenable
- Avancement par itération
Les Méthodes ‘Agiles
Adaptables :
- Réactives aux nouveaux besoins
- Réceptives aux nouvelles solutions
- Prendre les décisions définitives le plus tard possible
- De courtes itérations permettent de changer de direction sans laisser des
éléments à moitié fait
Les Méthodes ‘Agiles
Collaboration avec le client:
* Pourquoi on veut des contrats ?
- Instaurer la confiance autrement
- Eviter les effets pervers d’un contrat
Les Méthodes ‘Agiles’
Toujours focalisées sur le produit final:
- Une vision commune pour l’équipe
Ø la satisfaction du client - Découper le projet autrement
Ø par fonctionnalité - Organiser en cycles de développement réduits
Ø itérations
Les Méthodes ‘Agiles’
L’estimation de charge est difficile, mais les courtes
itérations nous aident:
- On est plus précis sur les petites tâches
- Feedback très rapide
- Plus facile à s’adapter face aux dérives, surprises
Les Méthodes ‘Agiles’
Points forts
- Itératif à planification souple
- Simple à mettre en œuvre
- Fait une large place aux aspects techniques : prototypes, règles de
développement, tests… - Innovant: programmation en duo, kick-off, rétrospective, meetings
debout …
Les Méthodes ‘Agiles’
Points faibles
- Ne couvre pas les phases en amont et en aval au développement :
capture des besoins, support, maintenance, tests d’intégration… - Élude la phase d’analyse, si bien qu’on peut dépenser son énergie à
faire et défaire - Assez flou dans sa mise en œuvre: quels intervenants, quels
livrables ?
Adapter son processus de
développement…
Travailler de façon itérative et incrémentale:
- Que ce soit au niveau des plannings, des spécifications, ou des
développements…
Adapter son processus de
développement…
L’itératif permet une gestion efficace des risques,
- Aborder dès les premières itérations, les points difficiles
- Par exemple, les premières itérations de la phase technique aborderont les
aspects sécurité et transaction.
Adapter son processus de
développement…
L’itératif permet de présenter rapidement des éléments de
validation aux utilisateurs:
- Réaliser des prototypes de validation
Les bénéfices attendus de l’agilité :
Un produit qui correspond mieux aux attentes des utilisateurs;
Produit plus rentable;
Mise à jour en temps réel des jalons et des coûts;
Transparence sur l’avancement du projet;
Améliorer la qualité et la maintenabilité du projet;
Les utilisateurs connaissent déjà l’application;
Satisfaction de toute l’équipe
Particularités communes
Développement itératif et incrémental
Emphase sur la qualité:
Tests automatisés
Inspection et adaptation
Intégration continue
Satisfaction du client
Erreurs communes
- Faire de l’Agile « pour être dans le vent »
- Faire du développement itératif et non incrémental
- Commencer à sprinter seulement lorsque tous les besoins sont recueillis
- Effectuer des « mini cascade »
- Laisser les spécialistes travailler en silo
- Avoir un client qui ne s’implique pas suffisamment
- Ne pas travailler en équipe
