Matériel agile avec développement de logiciels embarqués

Construire des écosystèmes matériels et logiciels complexes qui trouvent l'adéquation produit/marché est une tâche difficile. Alors que la plupart des startups matérielles échouent finalement parce qu'elles manquent d'argent, selon un rapport de CB Insights, la principale raison sous-jacente est en fait le manque de demande pour leurs produits. Cela ne fait que souligner l'importance de l'importance du rôle du chef de produit pour les startups matérielles, car leur objectif principal est de déterminer les besoins et les points faibles des clients afin de fournir un produit réussi.

La dernière entreprise que j'ai dirigée a créé un écosystème d'applications logicielles Web, mobiles, embarquées et de dispositifs matériels pour l'industrie du stationnement. La stratégie de produits matériels faisait partie de mon travail quotidien, ce qui m'a amené à expérimenter divers workflows de développement de produits matériels. Malgré avoir travaillé avec des produits matériels pendant 10 ans et avoir un BS en électronique et télécommunications, j'avais encore beaucoup à apprendre sur le tas. J'ai créé le guide ci-dessous dans l'espoir que vous puissiez vous familiariser plus rapidement avec la gestion des produits dans le matériel avec un espace logiciel intégré plus rapidement que moi.

Défis de la gestion des produits matériels

Alors que les applications SaaS et mobiles peuvent facilement être développées à l'aide d'un cadre agile, les conditions uniques du développement de logiciels et d'appareils matériels intégrés rendent beaucoup plus difficile l'application des principes agiles. Dans cette première section, nous aborderons les caractéristiques du développement matériel qui créent de la complexité. Tous n'ont pas de solutions simples, mais il existe des moyens de réduire la difficulté en utilisant des stratégies de développement de matériel particulières, qui seront abordées dans la section suivante.

Le talent technique spécialisé est difficile à trouver localement

La création de nouveaux produits matériels est beaucoup plus difficile que l'itération sur les produits existants. Cela implique beaucoup de créativité et d'expérience dans le prototypage, qui est rarement enseigné dans les universités. Certaines universités ne disposent même pas d'installations de prototypage ou des outils nécessaires pour développer ces compétences et une telle expérience est presque exclusivement acquise dans les grandes sociétés de matériel qui ont des centres de R&D. Trouver des professionnels locaux possédant une expertise pertinente peut donc être très difficile, ce qui oblige de nombreux fondateurs de startups de matériel informatique à élargir leur vivier de talents en embauchant à distance.

Les systèmes de contrôle de version ne sont pas adaptés à la conception matérielle

La plupart des systèmes de contrôle de version (VCS) sont orientés vers la prise en charge du format textuel, car ils ont été créés pour le travail collaboratif de développement de logiciels. Dans les projets impliquant le développement de matériel, les informations sont plutôt intégrées dans des fichiers de conception créés à l'aide d'outils spéciaux comme OrCAD. Et certains de ces outils ne prennent en charge que les fichiers binaires qui ne sont même pas optimisés pour être utilisés dans les VCS. CADLAB est une tentative relativement nouvelle de créer un VCS compatible avec le matériel et, espérons-le, il y aura plus d'outils comme celui-ci dans un proche avenir.

Les installations de production de matériel sont délocalisées

Les installations de production de matériel sont souvent situées dans une autre région, un autre pays ou un autre continent. La communication entre le producteur de matériel et le fabricant nécessite une attention particulière et est la clé d'une livraison réussie du produit. Une communication réussie nécessite un cadrage plus stratégique pour assurer la qualité du produit et s'assurer qu'il peut faire face aux changements dans la phase dynamique de validation du marché du produit. Pour y parvenir, le producteur de matériel doit créer de nombreuses spécifications détaillées envoyées au fabricant. Le cadre de collaboration doit assurer la livraison rapide des informations et la gestion du cycle de vie des spécifications, car elles peuvent facilement devenir rapidement obsolètes.

Les modifications matérielles sont moins flexibles

Un modèle d'exploitation populaire dans les startups logicielles sacrifie la qualité pour la vitesse dans les premières étapes. Même Facebook a défendu le mantra "bouger vite et casser les choses" pendant un certain temps. Une autre approche familière consiste à "faire semblant jusqu'à ce que vous y parveniez". Cela fonctionne pour les startups logicielles en raison des coûts d'infrastructure bon marché et des cadres de programmation rationalisés qui permettent aux développeurs de déployer quotidiennement des mises à jour de code.

Bien que cette approche du développement se soit lentement glissée dans l'espace matériel, c'est une tendance malheureuse dans ce domaine, car il est beaucoup plus difficile d'apporter et de déployer des modifications matérielles. Les coûts de développement compensent la valeur acquise grâce à des versions rapides et fréquentes, c'est donc en fait une stratégie beaucoup plus souhaitable d'investir davantage dans la phase de conception pour créer des architectures matérielles solides.

Le piège du financement participatif

De nombreuses startups sont piégées dans l'idée que le lancement d'une campagne de crowdfunding matériel réussie équivaut à une validation du marché. Le financement participatif a tendance à être plus efficace pour les produits impliquant un composant matériel, notamment en raison de notre désir inconscient de propriété lié à l'objet physique. Cependant, le financement participatif n'est pas destiné à valider votre produit à grande échelle, mais plutôt à un moyen démocratique de financer le développement de produits à un stade précoce. La triste réalité est que de nombreuses entreprises avec des campagnes de financement participatif réussies ont par la suite trouvé difficile ou presque impossible de faire évoluer leur production car elles n'ont pas validé leur marché à grande échelle.

Certifications, réglementations et approbations

Tous les produits matériels nécessitent une sorte de certification pour être vendus. C'est l'une des étapes les plus négligées au tout début de la mise sur le marché de produits matériels. Comment la contrainte de certification affectera-t-elle le plan produit et le cadre appliqué pour le développement ? Il n'est pas rare de planifier les premières phases du projet avec la certification et d'autres approbations comme jalon du projet, puis de revenir conditionnellement à la phase de lancement. Les chefs de produit peuvent plutôt analyser attentivement les réglementations, les dépendances et les passerelles de décision stratégique du plan produit dans une approche plus en cascade.

Opportunités pour la gestion des produits matériels

Maintenant que nous avons couvert certains des défis existant dans le domaine du matériel avec logiciel embarqué, voyons maintenant comment rendre le processus de développement plus rationalisé et prévisible afin de compenser les difficultés inhérentes au développement de matériel.

Incorporer Agile dans le développement matériel

Les chefs de produit expérimentés sont conscients des défis liés à la création de produits matériels avec des logiciels intégrés qui tentent d'exploiter une opportunité de marché créée par de nouveaux développements technologiques. Ils apprennent à équilibrer l'accélération des délais de mise sur le marché sans compromettre la probabilité de succès du produit dès la phase de planification. La plupart du temps, cela se matérialise par une approche water-scrum-fall.

La phase d'idéation du produit développe les principes, les objectifs et les fonctionnalités de haut niveau du produit avec autant de détails que possible. Les grands chefs de produit passent plus de temps à affiner les livrables de cette phase : vision, mission, évaluation des opportunités, objectifs du produit matériel et fonctionnalités. C'est l'étoile nord du produit qui doit être suffisamment claire avant de commencer à travailler sur tout type de prototype matériel, c'est pourquoi une approche en cascade est recommandée.

Il est essentiel d'avoir des exigences et des spécifications fonctionnelles bien documentées pour les produits matériels, ainsi qu'une bonne architecture technique pour le logiciel embarqué pilotant le produit matériel. Les modifications des exigences et des spécifications doivent être pénalisées et non encouragées une fois qu'elles sont approuvées par toute l'équipe.

Une méthodologie scrum standard peut être utilisée lors du développement de logiciels embarqués. Il est moins coûteux en termes de temps et d'argent d'ajuster et d'affiner l'implémentation logicielle afin de travailler avec l'architecture matérielle prédéfinie que l'inverse.

Les tests d'intégration finaux et les tests d'acceptation par l'utilisateur doivent être effectués dans des conditions de chute d'eau. À ce stade, la phase de développement est terminée et les nouvelles fonctionnalités et fonctionnalités manquantes sont enregistrées en tant que demandes de travail supplémentaires pour la prochaine période de planification.

Incorporer Agile dans le développement de logiciels embarqués

La création de produits matériels complexes avec des logiciels intégrés a un impact sur la manière dont les méthodologies de développement de logiciels traditionnelles sont appliquées. De nombreux systèmes utilisés pour produire des logiciels qui s'exécutent sur un ordinateur personnel ne conviennent pas au développement de logiciels embarqués, car il existe des contraintes liées à la rareté des ressources et à des cycles de développement beaucoup plus longs.

Un groupe d'universitaires et de professionnels du Brésil a proposé une solution potentielle : Méthodologie de conception logicielle basée sur une plate-forme pour les systèmes de contrôle embarqués : une boîte à outils agile . Cette méthodologie intègre les principes agiles dans le développement de logiciels embarqués. Vous trouverez ci-dessous un bref résumé de la méthodologie, mais il est fortement conseillé aux responsables de produits matériels de lire la description complète avant de l'appliquer dans leur pratique.

Les rôles impliqués dans cette méthodologie sont :

• Propriétaire de la plateforme – Responsable de la définition des objectifs de qualité, de planification et de coût
• Chef de produit - Responsable de la mise en œuvre, de l'intégration et des tests du produit
• Feature leader - Responsable de la gestion des projets de sous-systèmes et du suivi de la progression du livrable de la fonctionnalité
• Équipe de développement – ​​Travailler sur le développement du produit

La méthodologie divise le développement de logiciels embarqués en trois groupes de processus :

1. Groupe de processus de plate-forme système. Un système choisit les composants système qui feront partie de l'architecture et des plates-formes API à partir d'une bibliothèque de plate-forme et les personnalise pour satisfaire les contraintes de l'application en question. Le processus de personnalisation s'effectue en cycles itératifs en programmant les processeurs configurables par le concepteur et la logique reconfigurable à l'exécution intégrée à la plate-forme.
2. Groupe des processus de développement de produits. Les fonctionnalités qui composent le produit sont partitionnées en éléments matériels ou logiciels de la plate-forme. La méthodologie fournit des algorithmes de partitionnement pour prendre en compte la consommation d'énergie, le temps d'exécution et la taille de la mémoire des composants de l'application.
3. Le groupe des processus de gestion des produits surveille et contrôle les paramètres de portée, de temps, de qualité et de coût des produits. Les approches proposées sont principalement constituées des pratiques promues par la méthode Scrum Agile ainsi que des patterns agiles.

Créer un programme de développement de matériel

La structuration d'un programme de développement de matériel à un stade précoce a permis aux entreprises de fournir un pivotement rapide ou un plan B. D'un point de vue commercial, cela peut diminuer les marges financières, mais au final, cela offre l'agilité nécessaire pour faire face à un marché en constante évolution. conditions en termes de produits libérés par la concurrence et de progrès des capacités technologiques.

Supposons qu'une entreprise mène une campagne de financement participatif réussie pour son produit matériel avec logiciel intégré. Ils fonctionnent très bien pour le premier lot de produits jusqu'à ce qu'une grande entreprise établie annonce quelque chose de similaire. La polyvalence et le délai de mise sur le marché sont les plus importants, et une réponse pragmatique et agile à cette situation augmente la probabilité d'un produit réussi. En ayant un programme de développement matériel en place, l'entreprise peut rapidement s'adapter et mettre en avant une version plus riche du produit en réponse à ses concurrents.

Tests réussis du matériel avec le logiciel embarqué

Les tests sont un élément crucial de la gestion des produits matériels car, contrairement aux tests logiciels agiles, la plupart des bogues matériels ne peuvent être corrigés qu'en produisant un nouveau lot de produits. Les appareils Samsung Galaxy Note 7 qui prenaient feu sont un excellent exemple de la raison pour laquelle les tests matériels devraient être une priorité absolue pour tous les chefs de produit.

Les tests fonctionnels sont l'objectif clé de la validation technique du matériel avec des produits logiciels embarqués. La complexité de ces procédures vient du fait que les erreurs sont susceptibles de provenir de n'importe quelle partie du système.

Les tests unitaires se déroulent généralement dans un environnement simulé après chaque sprint, car le matériel simulé offre l'avantage d'être parfaitement contrôlable. Les scripts de test peuvent être automatisés, peuvent superviser l'exécution et tuer les tests qui semblent s'être écrasés sans produire de résultats.

Les tests d'intégration doivent prendre en compte les opérations en ligne et hors ligne et la soumission du produit matériel à des conditions opérationnelles réelles. Par exemple, si l'entreprise développe un système de surveillance du cerveau monté sur la tête lors d'activités de plein air, les conditions de test doivent tenir compte de ces particularités.

Le test du système consiste à tester l'ensemble du système pour détecter les erreurs et les bogues. Ce test est réalisé en interfaçant les composants matériels et logiciels de l'ensemble du système (qui ont été préalablement testés unitairement et en intégration) puis testés dans leur ensemble. Ce test est répertorié sous la méthode de test de la boîte noire, où le logiciel est vérifié pour les scénarios attendus par l'utilisateur, les exceptions potentielles et les conditions de cas extrêmes. Catégories spéciales de tests mentionnables :

• Tests déclenchés par événement : lancés par des événements particuliers ou des changements d'état dans la vie du produit matériel (par exemple, démarrage, réinitialisation, arrêt). Son but est de détecter les défauts permanents.
• Test déclenché par le temps : lancé à des moments préconfigurés dans le fonctionnement normal du système, effectué périodiquement pour détecter les défauts permanents. Il est utile dans les systèmes fonctionnant pendant de longues périodes, où aucun événement significatif de déclenchement de test ne se produit. Les tests déclenchés par le temps sont également utiles pour détecter les défauts intermittents.

Acceptation du produit du matériel avec logiciel intégré

La valeur du produit pour les produits matériels avec logiciel intégré est généralement validée après l'étape d'acceptation du produit dans la méthodologie water-scrum-fall. L'écosystème matériel avec logiciel intégré doit donner la priorité au matériel par rapport au logiciel pour la validation et l'acceptation. Comme indiqué précédemment, les modifications matérielles sont plus difficiles et coûteuses à effectuer. Il est courant que les chefs de produit conçoivent des solutions innovantes, nécessaires pour résoudre des problèmes d'acceptation ou d'ajustement de la valeur en considérant la contrainte de ne pas pouvoir modifier le matériel et de privilégier les itérations supplémentaires sur le terrain du développement logiciel.

Les excellents chefs de produit ont le sens aigu des produits et une grande vision pour prévoir les besoins matériels et hiérarchiser les bonnes fonctionnalités incluables afin que le modèle commercial soit solide, que l'acceptation soit solide et que les utilisateurs apprécient l'utilisation du produit. Considérant les logiciels embarqués, la « décoration » du matériel ne devrait pas surprendre, car elle doit suivre des règles et des contraintes, dictées par les processus de développement du matériel, les procédures de certification, les défis de production et l'acceptation du marché.

Le développement matériel nécessite une agilité gérée

Agile a pris d'assaut le monde du développement logiciel et a maintenant commencé à se glisser dans l'espace matériel. Cependant, les conditions du produit matériel avec le développement de logiciels embarqués impliquent divers défis :

• Manque de talents spécialisés
• Systèmes de contrôle de version non adaptés au matériel
• Installations de production délocalisées
• Des modifications plus difficiles à effectuer par rapport aux logiciels
• Exigences de certification et de réglementation qui imposent des obstacles à la planification

Ces défis rendent plus difficile l'application des principes agiles de la même manière que le font les éditeurs de logiciels.

Afin de lutter contre ces défis, une approche d'agilité gérée est nécessaire sous la forme de mêlée d'eau. Le développement du logiciel embarqué est créé en suivant les procédures scrum standard, tandis que d'autres étapes telles que l'idéation, la création de spécifications et les tests sont implémentées dans une configuration en cascade. Cela permet aux entreprises de matériel informatique de récolter les fruits d'Agile tout en maintenant une approche de gestion de produit fonctionnelle qui doit tenir compte des diverses contraintes énumérées ci-dessus. Cette approche d'agilité gérée permet d'avancer avec succès dans le contexte de conditions de marché en évolution rapide et d'améliorations technologiques constantes.