J'ai eu un grand succès. avec des cycles de développement rapides et une intégration continue.
Cependant, je pense que la programmation de paires ou la communication continue des clients sont moins utiles en raison de problèmes spécifiques des programmes logiciels intégrés.
Que pensez-vous? Quelles sont les pratiques agiles les plus utiles sur le développement logiciel incorporé?
3 Réponses :
Le développement logiciel embarqué n'est pas différent du développement de logiciels normal, vous pouvez donc utiliser toutes les pratiques agiles que vous trouvez utiles.
En ce qui concerne la programmation de paires, je l'examine comme un critique de code sur les stéroïdes. Si votre entreprise peut vous permettre d'obtenir suffisamment d'ingénieurs SW, je ne vois pas une raison pour laquelle il ne pouvait pas être utilisé pour le développement logiciel intégré.
Au fait, qu'est-ce que vous considérez exactement sous «Problèmes spécifiques de la programmation logicielle intégrée»? Je n'ai pas d'expérience dans le développement de logiciels non intégré, et je ne vois pas comment cela pourrait être différent.
Ajout à mon commentaire ci-dessus, je pense que la portée des logiciels embarqués est d'une manière ou d'une autre plus large que par exemple. logiciel d'application. Tous les logiciels sont complexes, mais des logiciels intégrés supplémentaires nécessitent souvent une expertise sur des problèmes concernant le comportement en temps réel, l'interaction avec des événements externes, l'interface des connaissances matérielles détaillées, etc., ce qui signifie qu'il est difficile pour deux ingénieurs de connaître assez bien la même partie du système pour pouvoir faire une programmation en paires. Bien sûr, théoriquement, une entreprise pourrait embaucher suffisamment d'ingénieurs pour éviter cela, mais dans la pratique, cela ne se produit pas.
@Solano Le HW est très probablement sur mesure, donc deux ingénieurs ou plus peuvent facilement apprendre à accéder à un tel matériel. RT est probablement la seule chose spécifique pour le développement intégré.
Je devrais être en désaccord. Je l'ai fait, et il y a environ 10 ans, j'ai co-fondé une société de coaching agile spécialisée dans Embedded (nous ne sommes plus une entreprise mais Le site web est toujours up avec plusieurs ressources utiles). J'ai récemment aidé une autre entreprise à adopter agile pour leur projet intégré et cela a très bien fonctionné pour eux.
pratiques agiles telles que les itérations courtes, la programmation de paires et la communication fréquente avec le client sont plus important avec des logiciels intégrés car il y a plus en jeu, les deux, car les systèmes embarqués sont généralement plus difficiles / plus coûteux à mettre à jour. sur le terrain, et parce qu'ils sont souvent utilisés dans des applications critiques.
Comme pour la programmation par paire, si votre entreprise n'a qu'une seule personne qui connaît la première chose à propos d'une composante du logiciel, c'est un risque énorme et une programmation par paire est un excellent moyen de faire un transfert de connaissances bon marché. Les deux développeurs ne doivent pas nécessairement être des experts dans cette partie du code. Vous pouvez avoir un primaire qui est et un secondaire qui n'est pas. Le partenaire secondaire est capable d'offrir de l'aide sur la structure du programme, de comparer les décisions de conception, de garantir des tests et une documentation appropriés, etc. Bien entendu, chaque développeur doit être un élément primaire parfois et secondaire d'autres fois pour faire efficacement la transition. C'est également un moyen très efficace d'apporter de nouveaux développeurs à la vitesse de votre produit.
Enfin, les clients se soucient des fonctionnalités et des plans, pas de code. Intégré ne change pas cela. Montrant ce que vous avez jusqu'à présent et ce que vous comptez faire ensuite vous assure que vous travaillez sur ce que vous êtes censé.
Ce n'est pas évident pour moi la valeur d'agile dans de nombreuses applications.
De nombreuses applications, y compris les applications incorporées, incluent souvent des protocoles ou des technologies basés sur des normes. Vous téléchargez ou achetez la spécification, vous implémentez la spécification, les tests à votre guise, puis vous avez terminé. Que ferais-je à mon quotidien », à l'heure actuelle, j'ai lu aujourd'hui les pages 1 à 9 de la norme, demain, je prévois de lire les pages 10 à 17". Comment le développement de normes a-t-il bénéficié d'Agile? Réponse rapide à l'évolution de la saisie du client, euh, non. La norme ne change pas de jour en jour.
Si le logiciel agile signifie vraiment "entraînement", puis apparitionnement de programmation. Comme indiqué ci-dessus, sauf si vous pouvez vous permettre de doubler exactement le nombre d'ingénieurs, vous aurez probablement différents ensembles de compétences spécifiques entre vos ingénieurs. Dans une grande organisation avec de nombreux ingénieurs avec des compétences en double chevauchant, vous pouvez peut-être faire une paire d'ingénieurs de manière efficace. Dans une entreprise plus petite, comment cela fonctionne-t-il? Sauf si c'est en fait une formation jumelée, alors OK. Semble cher cependant.
Une énorme quantité d'infrastructure est requise pour héberger ou déployer la plus petite quantité de fonctionnalités de première passe. Comment puis-je faire du développement piloté par tester un contrôleur de vol intégré ou un contrôleur de moteur automobile? Des années d'efforts sont nécessaires pour obtenir l'infrastructure en place pour héberger un test. Je ne veux certainement pas le reste de mes concepteurs et d'ingénieurs assis autour de l'inactivité attendant l'infrastructure de test afin qu'ils puissent faire TDD. J'ai besoin de développement dirigé par des normes tout en attendant que de nombreux morceaux se réunissent.
Pouvez-vous donner des exemples de ce qu'il s'agit du développement logiciel intégré qui fait l'une des pratiques mentionnées moins utiles?
Peut-être est-il dû aux spécificités des rôles que j'ai travaillé, mais j'ai toujours constaté que différents ingénieurs sont spécialisés par E.G. sur différents sous-systèmes HW. J'ai trouvé que ce n'est pas si facile de collaborer sur un morceau de code, car seul l'un des ingénieurs connaît le HW affecté en détail, ce qui est un problème spécifique au monde intégré. De plus, je pense que les clients des systèmes embarqués n'ont pas autant de connaissances sur le fonctionnement interne du SW comme dans l'application SW et cela rend moins utile d'avoir une communication constante des clients. Bien sûr, ceci est juste une généralisation.