Développement de logiciels adaptatifs - Pratiques
Les pratiques de développement de logiciels adaptatifs sont guidées par la croyance en une adaptation continue, le cycle de vie étant équipé pour accepter le changement continu comme norme.
Le cycle de vie du développement logiciel adaptatif est dédié à -
- Apprentissage continu
- Changer d'orientation
- Re-evaluation
- Regarder dans un avenir incertain
- Collaboration intense entre les développeurs, la direction et les clients
SDLC adaptatif
Le développement logiciel adaptatif combine RAD avec les meilleures pratiques en génie logiciel, telles que -
- Lancement du projet.
- Planification adaptative du cycle.
- Ingénierie des composants simultanés.
- Revue de qualité.
- QA final et version.
Les pratiques de développement de logiciel adaptatif peuvent être illustrées comme suit -
Comme illustré ci-dessus, les pratiques de développement de logiciels adaptatifs sont réparties sur les trois phases comme suit -
Spéculer - Initiation et planification
Lancement du projet
Établissement de la boîte de temps pour l'ensemble du projet
Décidez du nombre d'itérations et attribuez une case de temps à chacune
Développer un thème ou un objectif pour chacune des itérations
Attribuer des fonctionnalités à chaque itération
Collaborate - Développement de fonctionnalités simultanées
Collaboration pour les équipes distribuées
Collaboration pour les petits projets
Collaboration pour des projets plus importants
Learn - Revue de qualité
Qualité du résultat du point de vue du client
Qualité des résultats d'un point de vue technique
Le fonctionnement de l'équipe de livraison et les membres de l'équipe des pratiques utilisent
Le statut du projet
Spéculer - Initiation et planification
Dans le développement de logiciels adaptatifs, la phase de spéculation comporte deux activités -
- Initiation
- Planning
Speculate a cinq pratiques qui peuvent être exécutées de manière répétitive pendant la phase d'initiation et de planification. Ils sont -
- Lancement du projet
- Établissement de la boîte de temps pour l'ensemble du projet
- Décidez du nombre d'itérations et attribuez une case de temps à chacune
- Développer un thème ou un objectif pour chacune des itérations
- Attribuer des fonctionnalités à chaque itération
Lancement du projet
L'initiation de projet implique -
- Définition de la mission et des objectifs du projet
- Comprendre les contraintes
- Mise en place de l'organisation du projet
- Identifier et décrire les exigences
- Faire des estimations initiales de la taille et de la portée
- Identifier les principaux risques du projet
Les données de lancement du projet doivent être rassemblées lors d'une session préliminaire JAD, en considérant la vitesse comme l'aspect majeur. L'initiation peut être complétée dans un effort concentré de deux à cinq jours pour des projets de petite à moyenne taille, ou de deux à trois semaines pour des projets plus importants.
Pendant les sessions JAD, les exigences sont rassemblées de manière suffisamment détaillée pour identifier les fonctionnalités et établir une vue d'ensemble de l'objet, des données ou d'un autre modèle architectural.
Établissement de la boîte de temps pour l'ensemble du projet
La période de temps pour l'ensemble du projet doit être établie, en fonction de la portée, des exigences de l'ensemble de fonctionnalités, des estimations et de la disponibilité des ressources qui résultent du travail de lancement du projet.
Comme vous le savez, spéculer n'abandonne pas l'estimation, mais signifie simplement accepter que les estimations peuvent mal tourner.
Itérations et time-box
Décidez du nombre d'itérations et des longueurs d'itération individuelles en fonction de la portée globale du projet et du degré d'incertitude.
Pour une application de petite à moyenne taille -
- Les itérations varient généralement de quatre à huit semaines.
- Certains projets fonctionnent mieux avec des itérations de deux semaines.
- Certains projets peuvent nécessiter plus de huit semaines.
Choisissez l'heure, en fonction de ce qui fonctionne pour vous. Une fois que vous avez décidé du nombre d'itérations et de la longueur de chacune des itérations, attribuez un calendrier à chacune des itérations.
Développer un thème ou un objectif
Les membres de l'équipe doivent développer un thème ou un objectif pour chaque itération. C'est quelque chose de similaire à l'objectif de sprint dans Scrum. Chaque itération doit fournir un ensemble de fonctionnalités qui peuvent démontrer la fonctionnalité du produit en rendant le produit visible pour le client afin de permettre un examen et des commentaires.
Au cours des itérations, les versions doivent fournir des fonctionnalités fonctionnelles de préférence quotidiennement, permettant le processus d'intégration et rendant le produit visible à l'équipe de développement. Les tests doivent faire partie intégrante et continue du développement des fonctionnalités. Il ne doit pas être retardé jusqu'à la fin du projet.
Attribuer des fonctionnalités
Les développeurs et les clients doivent attribuer ensemble des fonctionnalités à chaque itération. Le critère le plus important pour cette attribution de fonctionnalités est que chaque itération doit fournir un ensemble visible de fonctionnalités avec des fonctionnalités considérables pour le client.
Lors de l'affectation des fonctionnalités aux itérations -
L'équipe de développement doit proposer les estimations des fonctionnalités, les risques et les dépendances et les fournir au client.
Les clients doivent décider de la hiérarchisation des fonctionnalités, en utilisant les informations fournies par l'équipe de développement.
Ainsi, la planification des itérations est basée sur les fonctionnalités et effectuée en équipe avec les développeurs et les clients. L'expérience a montré que ce type de planification permet une meilleure compréhension du projet qu'une planification basée sur les tâches par le chef de projet. De plus, la planification basée sur les fonctionnalités reflète le caractère unique de chaque projet.
Collaborer - Développement de fonctionnalités simultanées
Pendant la phase de collaboration, l'accent est mis sur le développement. La phase de collaboration comporte deux activités -
L'équipe de développement collabore et fournit des logiciels fonctionnels.
Les chefs de projet facilitent la collaboration et les activités de développement simultanées.
La collaboration est un acte de création partagée qui englobe l'équipe de développement, les clients et les managers. La création partagée est favorisée par la confiance et le respect.
Les équipes devraient collaborer sur -
- Problèmes techniques
- Besoins de l'entreprise
- Prise de décision rapide
Voici les pratiques pertinentes à la phase de collaboration dans le développement de logiciels adaptatifs -
- Collaboration pour les équipes distribuées
- Collaboration pour les petits projets
- Collaboration pour des projets plus importants
Collaboration pour les équipes distribuées
Dans les projets impliquant des équipes réparties, les éléments suivants doivent être pris en compte -
- Différents partenaires d'alliance
- Connaissances étendues
- La façon dont les gens interagissent
- La façon dont ils gèrent les interdépendances
Collaboration pour les petits projets
Dans les petits projets, lorsque les membres de l'équipe travaillent à proximité physique, la collaboration avec des discussions informelles dans le couloir et le gribouillage sur tableau blanc doit être encouragée, car cela s'avère efficace.
Collaboration pour des projets plus importants
Les projets de plus grande envergure nécessitent des pratiques supplémentaires, des outils de collaboration et une interaction avec le gestionnaire de projet et doivent être organisés en fonction du contexte.
Apprendre - Examen de la qualité
Le développement de logiciels adaptatifs encourage le concept «d'expérimentation et d'apprentissage».
Apprendre à partir des erreurs et de l'expérimentation nécessite que les membres de l'équipe partagent tôt le code et les artefacts partiellement terminés, afin de -
- Trouvez des erreurs
- Apprenez d'eux
- Réduisez les retouches en trouvant les petits problèmes avant qu'ils ne deviennent de plus en plus importants
À la fin de chaque itération de développement, il y a quatre catégories générales de choses à apprendre -
- Qualité du résultat du point de vue du client
- Qualité des résultats d'un point de vue technique
- Le fonctionnement de l'équipe de livraison et de l'équipe des pratiques
- Le statut du projet
Qualité du résultat du point de vue du client
Dans les projets de développement de logiciels adaptatifs, obtenir les commentaires des clients est la première priorité. La pratique recommandée pour cela est un groupe de discussion avec les clients. Ces sessions sont conçues pour explorer un modèle de travail de l'application et enregistrer les demandes de modification des clients.
Les sessions de groupe de discussion client sont des sessions animées, similaires aux sessions jad, mais plutôt que de générer des exigences ou de définir des plans de projet, elles sont conçues pour examiner l'application elle-même. Les clients fournissent des commentaires sur le logiciel de travail résultant d'une itération.
Qualité des résultats d'un point de vue technique
Dans les projets de développement de logiciels adaptatifs, un examen périodique des artefacts techniques devrait être accordé de l'importance. Les revues de code doivent être effectuées de manière continue. Les examens d'autres artefacts techniques, tels que l'architecture technique, peuvent être effectués chaque semaine ou à la fin d'une itération.
Dans les projets de développement de logiciels adaptatifs, l'équipe doit surveiller périodiquement ses propres performances. Les rétrospectives encouragent les équipes à s'informer sur elles-mêmes et sur leur travail, ensemble en équipe.
Les rétrospectives de fin d'itération facilitent l'auto-évaluation périodique des performances de l'équipe, telles que -
- Déterminez ce qui ne fonctionne pas.
- Ce que l'équipe doit faire davantage.
- Ce que l'équipe doit faire moins.
L'état du projet
La revue de l'état du projet aide à planifier les travaux ultérieurs. Dans les projets de développement de logiciels adaptatifs, la détermination de l'état du projet est une approche basée sur les fonctionnalités, la fin de chaque itération étant marquée par des fonctionnalités terminées aboutissant à un logiciel fonctionnel.
L'examen de l'état du projet doit inclure:
- Où est le projet?
- Où est le projet par rapport aux plans?
- Où devrait être le projet?
Comme les plans des projets de développement de logiciels adaptatifs sont spéculatifs, plus que la question 2 ci-dessus, la question 3 est importante. Autrement dit, l'équipe de projet et les clients doivent se demander continuellement: «Qu'avons-nous appris jusqu'à présent et cela change-t-il notre point de vue sur ce que nous devons aller?»