Comment adopter une méthodologie agile pour développer des microprogrammes / logiciels-systèmes embarqués?

Je me suis toujours demandé comment appliquer des méthodes agiles dans des logiciels de systèmes embarqués complexes et volumineux (plus de 100 ingénieurs). Le développement du micrologiciel a des caractéristiques uniques qui rendent difficile la flexibilité (c'est-à-dire que le matériel n'est pas disponible avant la fin du cycle de développement; une fois le produit publié, il ne peut pas facilement mettre à jour le micrologiciel; etc ...)

La norme dans ce type de développement est une documentation épaisse et des évaluations par les pairs exténuantes. Vous ne pouvez pas obtenir un correctif de code simple comme renommer une variable sans 2-3 signatures. (J'exagère un peu, mais c'est typique. De plus, beaucoup de gens prennent des raccourcis et les chefs de projet les approuvent même surtout face aux délais du marché.)

J'aimerais avoir des conseils ou des directives sur la façon d'adopter une méthodologie agile pour les projets de développement de firmware.

Je pense que deux techniques sont essentielles:

• Développez un simulateur complet ou un environnement de test pour le matériel, afin de pouvoir développer le logiciel comme si vous disposiez d'un vrai matériel. Ne lésinez pas et ne prenez pas de raccourcis ici: développer un bon simulateur sera payant.

• Écrivez de nombreux tests unitaires contre le simulateur.

Une fois que vous avez ces choses en cours et que les gens sont convaincus que le simulateur et les tests unitaires donneront une idée précise de la façon dont les choses fonctionneront avec le matériel, il sera plus facile d'adopter d'autres techniques agiles (itérations courtes, refactorisation implacable, etc.) .

L'impact d'Agile sur un processus de développement impliquant plusieurs fournisseurs peut être comparé à ce qui se passe lorsqu'une entreprise passe au JIT.

Pour livrer JIT, chacun des fournisseurs de l'entreprise doit livrer JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

De même, si vous voulez qu'un produit complexe soit développé selon les méthodologies Agile, chaque sous-groupe de la chaîne devrait pouvoir fonctionner de cette façon.

En termes de développement `` incrémentiel '' (alias Tracer Bullets d'il y a 15 ans), cela impliquerait que le `` noyau '' soit libéré très rapidement pour le pilote, et que le pilote de base soit disponible pour l'intégrateur, et que l'interface graphique être développé, avec un seul bouton et une zone d'édition, en même temps.

La partie la plus difficile est de convaincre les concepteurs de matériel, issus d'une solide discipline d'ingénierie avant-gardiste, de rejoindre notre société de bricoleurs.

La deuxième partie la plus difficile consiste à trouver un moyen de permettre le développement incrémentiel dans un monde où une impression matérielle doit être commandée 3 semaines à l'avance. Je pense aux émulateurs, les fpga sont ici. Je ne suis pas un gars du matériel.

Si vous êtes prêt à abandonner le développement matériel incrémentiel, vous pouvez, tout comme aux frontières d'une chaîne JIT, prévoir un mécanisme de mise en mémoire tampon qui permet aux équipes Agile d'avancer.

Ne soyons pas aveugles: Agile doit également gérer des processus lourds! Ne demandez pas à l'équipe Agile de `` refactoriser '' maintenant sa base de code Java en Python lors du prochain sprint. C'est seulement parce que certaines parties sont vraiment très stables que nous pouvons danser nos mouvements Agiles par-dessus eux.

Manifeste Agile: http://agilemanifesto.org/

"Les individus et les interactions sur les processus et les outils"

• Rencontrez plus. Poussez moins de papier.

"Logiciel fonctionnel sur une documentation complète"

• Prototype et construction de pics technologiques tôt et souvent.

• Résolvez le vrai problème de l'utilisateur plutôt que de continuer à développer une adhésion pointilleuse à une spécification. Cela signifie des solutions évolutives . L'idée que nous devons le construire correctement parce que nous ne pourrons jamais le reconstruire est fausse. Prévoyez d'itérer. Intégrez-le à la stratégie de marketing et de déploiement.

"Collaboration client sur négociation de contrat"

• Les processus de contrôle des changements hyper complexes ne sont que des moyens de dire «non» au client.

• Verrouiller toutes les exigences à l'avance, puis imposer un contrôle des modifications est une autre façon de dire «non».

• Si vous envisagez déjà plusieurs versions, vous pouvez plus facilement reporter les exigences à une version ultérieure. Une fois que le client a l'appareil avec le logiciel intégré, la prochaine version changera dans ses priorités.

"Répondre au changement au sujet d'un plan"

• Alors qu'une intégration complexe nécessite un plan complexe, le "programme" global (ou la séquence de projets) ne peut pas être concrétisé trop tôt.

Une méthodologie totalement Agile (ie Scrum) peut ne pas avoir de sens pour un système embarqué.

Le manifeste Agile, cependant, fournit des moyens pour permettre le changement sans permettre un simple chaos.

Mon problème avec Scrum dans les systèmes embarqués est qu'il y a beaucoup de tâches à faire, en particulier dans les premiers stades, qui ne sont pas démontrables. Nous avons commencé avec une carte de développement, pas de système d'exploitation, pas d'affichage, pas de communication série, etc. Nous n'avions pas notre écran pour 6 sprints.

Les 4 premiers sprints étaient: Mise en service et exécution du RTOS Création de tâches Écriture de pilotes réseau et série Écriture de routines d'interruption pour les boutons, les communications, etc. Écriture des classes et méthodes de la base de données primaire Écriture d'un menu de débogage série

La plupart de ces tâches ne conviennent pas bien aux user stories. En fait, la seule interface dans tout le système était le menu de débogage série, intégré au sprint 3, donc il n'y avait rien à démontrer à la fin des sprints. Même le menu série était destiné à un usage interne et non à un utilisateur final.

Bien sûr, chaque classe que nous écrivons a des tests unitaires associés et nous utilisons un framework de tests unitaires pour automatiser l'exécution de tous les tests.

Nous avons fini par écrire des phrases "user stories" comme "En tant que développeur ...", ce qui ne me satisfait pas, mais en utilisant Target Process (www.targetprocess.com), il n'y a pas de concept d'élément de backlog qui est une tâche ou une corvée.

J'adorerais savoir comment les autres ont géré ces situations.