Comment utiliseriez-vous AGILE ici?

Question

Je suis un grand partisan de l'agilité, mais un de mes amis (qui ne sait pas encore agile - un type managérial ^^) m'a demandé comment j'allais planifier et développer un projet distribué complexe, avec une couche de base de données , couche de communication, interface et intégration dans des périphériques intégrés. La méthode agile met l'accent sur le concept de libération anticipée et répétitive, mais dans le cas d'un projet avec de nombreux composants interconnectés qui doivent tous être fonctionnels pour que le tout fonctionne, il serait difficile de sortir tôt. version sans travailler sur tous les composants. Comment agile aiderait mon ami ici? Comment l'utiliserait-il le mieux?

Answer 1

Les équipes de mon entreprise font face aux mêmes types de problèmes. Nous construisons des projets avec un grand nombre de pièces mobiles et de couches architecturales qui rendent difficile la création précoce d'un produit fonctionnel. De plus, il y a souvent des ressources spécialisées qui doivent être planifiées ou légèrement désynchronisées avec l'équipe. Certaines approches que nous avons prises sont ci-dessous. Cela a été difficile, mais ces approches semblent aider.

Construire le plus verticalement possible

• En d'autres termes, chercher à avoir quelque chose de travail, de bout en bout le plus rapidement possible. Nous obtenons généralement quelques sprints sur un projet de 9-16 mois.
• Vous trouverez souvent un nombre significatif de couches pouvant être raillées ou retenues.
• Souvent, les composants face à des clients initiaux sont détenteurs de place.Nous créons un peu de fonctionnalité qui ressemble à ce que le client veut, mais qui sera probablement très différent dans le projet final. Cela nous permet de prouver le reste du produit au niveau du système et d'offrir une visibilité du point de vue du système.

architecture de base séparée du produit

Nos premiers sprints sont souvent centrés sur l'infrastructure/architecture. Par exemple, les sous-systèmes de threading, la surveillance des performances, les communications et les frameworks de test.

• Traiter les sous-systèmes livrables séparés
• définir entièrement chaque sous-système
• complet (vraiment complet, pas seulement une mise en œuvre partielle) chaque sous-système
• charge test à chaque sous-système dans le contexte de la façon dont il sera utilisé dans le produit final

Answer 2

Faites votre première itération être dédié à la conception architecturale, y compris l'identification des composants nécessaires et la définition des relations et des communications entre eux. Une fois que vous avez une idée claire de la façon dont les composants interagissent, construisez le squelette de chacun. C'est-à-dire, implémenter des composants «stub» qui n'ont que la partie communication sur place, et le reste de la fonctionnalité ne fait rien ou retourne des données de test. Avoir une interaction dédiée à cette tâche (y compris tester les mécanismes de communication des composants).

Ensuite, vous pouvez planifier itérations pour développer pleinement chaque composant dans l'ordre approprié, afin que le système puisse se développer d'une manière ordonnée.

Answer 3

TDD - itérer avec des parties incomplètes après tests d'écriture. Mock les bits qui ne sont pas prêts. Cela semble excitant.

Answer 4

Si vous ne pouvez pas briser le grand projet en parties plus petites qui sont utiles (à savoir permettre à certains cas d'utilisation) sur leur propre, agile ne sera probablement pas vous aider beaucoup dans ce projet. Vous pouvez choisir quelques techniques comme la programmation par paire, le refactoring, etc. mais la planification globale a été faite de manière conventionnelle.

Answer 5

Il est peu probable que chaque couche doive être complète pour être utilisable par les autres couches - par exemple, la couche de persistance pourrait simplement sérialiser des objets dans un fichier et convertir pour utiliser une base de données lorsque le besoin s'en fait sentir. Je chercherais à implémenter le minimum de chaque couche nécessaire pour les histoires initiales et étoffé pour ajouter des fonctionnalités à mesure que le système se développe.

Growing un système de cette façon signifie que vous ne mettre en œuvre les fonctionnalités dont vous avez besoin, plutôt que toutes les fonctionnalités que vous pensez que vous pourriez avoir besoin à un moment indéterminé dans l'avenir.