De nombreux produits sont développés pour répondre à un besoin spécifique ou sont créés pour tester une idée ou pour adopter une approche « construisons-le et ils viendront ». La première fois qu'un MVP (Produit Minimal Viable) est construit, on n'a pas le temps de penser à l'échelle ou à la manière de travailler avec des fonctionnalités et des fonctionnalités plus complexes. Dans tous les cas, un processus standardisé et transparent de développement produit Agile est une bonne idée à suivre pour obtenir des résultats prévisibles.
Pour maintenir et améliorer continuellement un produit, avoir un processus pour gérer les demandes ainsi que les corrections de bugs aidera à faire avancer les choses et à les publier.
Notre processus de développement de produit commence à l'étape de l'idée.
Cette étape capture toutes les idées de quiconque dans l'entreprise. Il peut s'agir d'idées courtes ou d'idées importantes qui peuvent être discutées lors d'une réunion d'idées ou de remue-méninges. Comme tout le monde peut créer ces idées, c'est aussi une façon de garder le développement de produit ouvert. La manière dont les choses passent de cette étape dépend, peut-être par le vote positif ou simplement par la qualification du Product Owner.
Normalement, toutes les demandes atterrissent ici ; bugs, changements, nouvelles fonctionnalités. C'est la voie d'accès pour tout ce que les employés ou les dirigeants souhaitent voir réalisé. Un problème bien capturé contient une capture d'écran, une courte description et un lien. La personne qui se trouve derrière les demandes est appelée le Reporter, et il défend le ticket tout au long du processus.
Seuls les tickets bien passés, bien compris et vérifiés peuvent atteindre cette étape, et seuls peuvent être déplacés par le Product Owner, ou par quiconque a ce rôle. Une fois déplacés, ils sont priorisés du haut vers le bas. Les développeurs choisissent du haut vers le bas dans la mesure où ils peuvent, cependant ils choisissent de travailler (un grand motivateur). Personne d'autre que le Product Owner n'est autorisé à re-prioriser ou à déplacer des choses dans cette étape. Cela vaut la peine de le répéter.
À partir de cette étape, les développeurs sont eux-mêmes responsables de faire avancer le ticket vers l'état « Terminé ». Cela aide tout le processus, car le développeur l'adaptera et le fera passer comme il le souhaite. Donc, il n'y a pas de réassignation. Le développeur principal responsable du ticket est le développeur qui l'a pris. Plusieurs développeurs peuvent travailler sur le même ticket, mais l'assigné n'est jamais modifié. Les développeurs partagent des informations avec le reste de l'équipe tous les jours sous forme de réunion debout et répondent aux trois questions Scrum : 1) Qu'ai-je fait jusqu'à aujourd'hui ? 2) Que vais-je faire jusqu'à demain et 3) Avez-vous des problèmes pour lesquels j'ai besoin d'aide.
Si un développeur ne peut pas avancer, le ticket est déplacé vers l'étape bloquée. Il pourrait y avoir un contenu manquant, la nécessité d'attendre un Reporter ou la solution n'est pas trouvée. Placer quelque chose dans l'étape bloquée dans un projet Kanban signifie que quelque chose ne bouge pas comme il devrait, et qu'il doit être pris en charge.
Une fois qu'un ticket est fusionné à un environnement de staging ou de test, le Reporter est invité à l'aider à le tester. Bien sûr, il est pré-testé par le développeur avant, ce qui devrait être le comportement par défaut de tout développeur. Personnellement, je ne veux pas déplacer la responsabilité du développeur vers une équipe de test, ce qui prend plus de temps. Mais pour certains tests plus importants et plus complexes, cela pourrait être nécessaire et plus rapide. Les tests automatisés sont également effectués.
Une fois que quelque chose est fusionné à la branche principale et ainsi publié en production, il est marqué comme terminé. C'est une définition claire de ce qu'est terminé.
Wow, vous venez de décrire un projet old school ! Attendez un peu, ce que nous avons ici permet à chaque idée/ticket de passer par le processus indépendamment des autres. C'est la principale différence. De plus, nous pouvons avancer et reculer à tout moment pour toute raison valable. Cela ne peut pas être comparé au projet waterfall avec toutes ses dépendances et problèmes de tests.
Nous aidons les entreprises avec leur technologie, en fournissant des services de CTO et de gestion de produits. Fidèles à nos services de CTO, nous travaillons avec des startups et des entreprises établies dans les pays nordiques, en Suisse et aux États-Unis.
Nous sommes une société suisse (LLC) basée en 
Suisse.