Comment gérez-vous le travail non fonctionnel avec Scrum dans les systèmes électroniques intégrés?

J'ai deux problèmes avec Scrum dans les systèmes embarqués. Premièrement, il y a de nombreuses tâches à accomplir, 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 six sprints.

Les quatre premiers sprints ont été:

• Obtenir le RTOS et en cours d' exécution
• Création de tâches d'écriture de pilotes réseau et série
• Écriture de routines d'interruption pour les boutons, la communication, etc.
• Écriture des classes et méthodes de la base de données primaire
• Écrire 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 l'ensemble du système était le menu de débogage série, intégré au sprint 3, il n'y avait donc rien à démontrer à la fin des sprints. Même le menu série était destiné à un usage interne et non à un utilisateur final. Néanmoins, je souhaite toujours suivre et gérer ces activités de développement via Scrum.

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.

Deuxièmement, comment gérez-vous les versions et les tests? C'est une vraie douleur pour nous parce que les testeurs n'ont pas les débogueurs matériels, nous devons donc construire des versions flash du code et les graver sur leurs cartes de développement pour tester. Les testeurs ne sont pas techniquement aussi pointus que les développeurs et nécessitent souvent beaucoup de soutien pour faire fonctionner les choses dans les premiers stades (réinitialisation de la carte, connexion de la communication série, etc.), ou même pour comprendre la sortie.

Enfin, en ce qui concerne la définition de fait, un sprint ne peut pas être complet tant que toutes les histoires ne sont pas terminées. Toutes les histoires ne sont pas complètes tant qu'elles n'ont pas été vérifiées par les testeurs. Il n'y a aucun moyen d'éviter de "voler" le temps du développeur à donner aux testeurs. En d'autres termes, si les trois dernières user stories du sprint prendront cinq jours à tester, elles doivent être codées et testées à l'unité cinq jours avant la fin du sprint. Que doit faire le développeur? Arrête de travailler?

Je suis facétieux, mais c'est un vrai problème d'essayer de se conformer aux règles. Maintenant, je suis d'accord pour plier les règles, mais le problème que j'ai est que cela fout toutes mes mesures de burndown si je ne peux pas marquer les choses comme avant qu'elles ne soient testées.

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

Vous utilisez une méthodologie sur un produit qui n'est pas compatible à mon humble avis.

De la manière dont la plupart des gens définissent l'agilité, tout le travail est négociable en fonction de priorités changeantes, réorganisable ou remplaçable.

Dans la façon dont la plupart des gens définissent la cascade, le travail est disposé en séquence à l'avance à partir d'un effort architectural important au début.

Les tâches que vous énumérez ci-dessus me semblent très chutes. Ils doivent être dans un certain ordre et ils ne sont pas négociables.

Je ne dis pas que vous devez respecter l'avis de quiconque sur n'importe quel processus, mais au moins pour ces tâches, vous semblez être dans un projet non agile pour moi. Essayer de bash cela dans un processus agile va être un ajustement bâclé au mieux.

Si le reste du projet est bien adapté à l'agilité, je ne m'inquiéterais pas trop de la mauvaise configuration initiale, mais le fait que vous mentionniez RTOS et les cartes de développement me fait suspecter que tout serait mieux dans quelque chose de plus comme une cascade (une longue séquence de dépendances immobilières).

OK, donc je ne sais rien sur la construction de systèmes embarqués, mais d'après ce que je peux voir, rien ne rendrait Scrum inapproprié pour un tel développement. Il est facile de s'inquiéter de ne pas avoir vraiment de fonctionnalités destinées aux utilisateurs, il est donc difficile d'écrire des «histoires d'utilisateurs» avec des utilisateurs. Sauf que les user stories ne font pas vraiment partie de Scrum - elles sont souvent utilisées avec Scrum - mais vraiment juste comme un outil.

Ce qui fait partie de Scrum est l'idée de fournir des fonctionnalités complètes qui sont entièrement testées et potentiellement implémentables dans un environnement en direct à chaque Sprint. Lorsque vous partez de zéro le premier jour de tout type de projet, la valeur réelle de tout type de fonctionnalité que vous pouvez offrir dans Sprint 1 est assez petite. C'est parce que chaque petite chose a besoin de tonnes et de tonnes d'infrastructures construites pour le faire fonctionner. Mais le fait est que vous ne construisez que suffisamment d'infrastructure pour faire fonctionner chaque fonctionnalité. Et puis vous le construisez à mesure que vous ajoutez plus de fonctionnalités.

L'idée est que vous ne passez PAS spécifiquement des mois et des mois à construire une infrastructure qui n'a aucun moyen d'être détectée de l'extérieur du système. Pourquoi? Parce que jusqu'à ce que vous construisiez ce qui fait réellement des choses, vous ne savez pas exactement ce que l'infrastructure doit être. C'est ce que vous apprenez en construisant les fonctionnalités réelles du système. Si vous construisez l'infrastructure au début, vous la construisez lorsque vous en savez le moins sur le système.

Si vous êtes déterminé à écrire des histoires d'utilisateurs, n'oubliez pas que les utilisateurs ne doivent pas nécessairement être des personnes. Donc, vous écrivez des trucs comme: "En tant que gestionnaire d'interruption CMOS, j'ai besoin de pouvoir détecter l'état du drapeau de modulation de la pile de bzz whozzit lorsque le compresseur fluxotronic signale une sous-charge de contournement passif". N'écrivez absolument pas les histoires d'utilisateurs "En tant que développeur ...".

Vous utilisez Scrum dans un domaine très spécifique et vous violez le processus supposé à chaque étape. Votre question devrait probablement être: Existe-t-il une autre méthodologie agile qui s'adaptera mieux à mon environnement? Simplement, il est très difficile de vous aider à faire mieux Scrum si votre environnement ne le permet pas. Les problèmes que je vois dans votre description:

• Aucune tâche démontrable qui peut être considérée comme une tâche d'infrastructure. Si vous avez besoin de plusieurs sprints pour faire quelque chose qui n'est pas considéré comme une valeur commerciale, vos user stories sont probablement mal définies. Si vous avez besoin de créer un outil ou autre pour être en mesure de fournir une valeur commerciale, le produit peut être divisé en deux parties / versions - créer un outil et créer une valeur commerciale. Dans ce cas, vos user stories "En tant que développeur ..." seront entièrement valides, car un outil est créé pour les développeurs.

  Le problème ici est de savoir comment communiquer cela avec le client, car son implication dans la première version est nulle. S'il n'y a pas de valeur commerciale pour les clients, comment peuvent-ils participer? Comment le propriétaire du produit peut-il définir la priorité commerciale?

  Je pense que le principal problème ici est que ce n'est pas quelque chose qui convient à Scrum. Scrum essaie de fournir les fonctionnalités commerciales les plus importantes en premier, mais vous avez besoin de deux mois pour livrer les premières. Scrum et l'ensemble agile embrassent le changement - que se passera-t-il si, après avoir livré les premières fonctionnalités, le client a besoin d'un changement qui remonte à travers tous vos sprints initiaux?

• Essai. Un autre échec car une équipe de Scrum est considérée comme un groupe de membres interfonctionnels. Cela signifie que tout le monde fait du développement et des tests et à cause de cela, il n'y a pas de situations décrites dans votre point final (ou au moins pas cinq jours). Cela ne signifie pas qu'il ne peut pas y avoir d'AQ séparée pour effectuer des tests plus complexes et sophistiqués, mais l'équipe doit fournir une fonctionnalité déjà testée / vérifiée. Dans votre cas, il semble que Scrum ne soit pas ce dont vous avez besoin. Vous avez besoin d'un développement et de tests gérés séparément et de passer des fonctionnalités entre eux.