J'ai maintenant été témoin que deux entreprises se déplacent au développement agile avec Scrum.
Dans les deux cas, la norme de codage était suffisamment bonne lorsque chaque partie de la requête n'a été utilisée que par un ou deux développeurs avec les développeurs qui passent un temps raisonnable travaillant dans une partie de la demande avant de passer à la prochaine tâche. Les taux de défaut étaient également raisonnables.
Cependant, avec Scrum, les développeurs sont attendus:
Les qualités de code sont devenues un problème dans les deux projets Scrum.
Voilà donc un moyen de faire scrum qui ne conduit pas à ces problèmes, sans avoir d'abord d'obtenir tous les développeurs à faire du développement axé sur les tests?
Avez-vous vu Scrum fonctionner bien sur un vaste projet sans développement axé sur le test? (Si oui comment?)
9 Réponses :
Oui, Scrum décrit l'approche de gestion de logiciels. Le paradigme du programme et de la gestion de projet ne doit pas dicter si vous utilisez ou non un développement axé sur les tests.
TDD est une pratique ou une technique de développement de logiciels et bien qu'il fonctionne bien avec Scrum, je ne pense pas que cela fera ou brisera votre succès avec la pratique.
J'ai personnellement vu Scrum fonctionnent bien sur des projets de taille moyenne sans une approche axée sur le test du développement. Cela ne veut pas dire que nous n'avons pas écrit de tests automatisés, ils n'ont tout simplement pas toujours été écrit d'abord.
Alors pouvez-vous faire Scrum sans que chaque programmeur soit fait pour travailler sur chaque code?
Bien que cela puisse aider, je pense personnellement que cela soit nécessaire. Avec tout projet de taille significative, il n'est tout simplement pas possible.
Il ne suffit pas beaucoup de sens du point de vue de l'efficacité pour que DevS fonctionne sur chaque bit de code IMO. Toutefois, il existe une énorme quantité de valeur dans les commentaires informels des pairs. Faire deux devs travaillant sur différents morceaux de code promener leurs sections respectives à travers l'autre ont montré de gros gains sur mon équipe
Diriez-vous que Scrum pourrait fonctionner sans tests automatisés?
Je dirais que cela peut fonctionner sans aucun test automatisé, et cela remonte au point que Scrum est une méthodologie de gestion, pas une méthodologie d'ingénierie; Tout projet bénéficierait probablement de tests automatisés
Oui, Scrum est entièrement possible et dans la plupart des cas mis en œuvre sans utiliser une approche TDD.
Cependant, la flexibilité que TDD fournit est certainement quelque chose qu'une méthodologie Scrum peut bénéficier.
J'aimerais développer ce que Dan a dit.
C'est une idée fausse très courante que Scrum / Agile dicte les principes d'ingénierie logicielle. C'est une erreur pour de nombreuses raisons. Comme Dan a mentionné, Scrum est un logiciel Gestion , pas un processus d'ingénierie logicielle. Cela étant dit, très souvent, vous verrez de nombreux principes d'ingénierie associés à Scrum; Des méthodologies telles que TDD, XP, etc. ont tendance à compléter la méthodologie de gestion que Scrum favorise, mais ne sont pas nécessaires. La raison pour laquelle CI, TDD et d'autres pratiques d'ingénierie sont souvent trouvées à la main avec Scrum, de nombreuses bonnes pratiques sont de bonnes pratiques à suivre quelle que soit la méthodologie de gestion utilisée. J'aimerais aborder un couple d'autres faussades dans votre op: Cependant, avec Scrum, les développeurs sont attendus:
Comme mentionné ci-dessus, Scrum ne dicte pas quel type ou sorte de travail qu'un développeur fonctionne. Les développeurs eux-mêmes décident de ce que le travail s'engage à s'engager; Si une base de données-lourde devient ne fonctionne que sur les histoires DAL et associées, il n'y a aucune raison qu'ils ne peuvent pas.
Encore une fois, Scrum ne peut rien dicter sur la manière de construire l'application, de sorte que votre deuxième point est discutable (voir point 1).
C'est une erreur, car il n'y a rien qui dit qu'un développeur ne devrait travailler que sur le code qui n'est ni le leur, ni quoi que ce soit sur la manière dont un développeur devrait se développer. Si un développeur sur une équipe de Scrum se trouve seulement de travailler sur le code des autres, ce serait une coïncidence, non pas à cause du processus de Scrum lui-même.
voir Ceci Question / Répondre Pour plus d'informations sur les qualités généralement attendues dans un scrum de travail développeur.
J'aimerais pouvoir +10 cette réponse.
Étant donné que la plupart des histoires vont de l'UI tout le chemin de la base de données et de retour à nouveau et il est normal qu'une histoire soit utilisée par un seul développeur, je ne vois pas comment un développeur peut choisir de travailler uniquement sur le dal et l'association histoires.
Peut-être que le Dev choisit simplement des histoires techniques, ou peut-être que le devise l'histoire, le DAL fonctionne-t-il et remet l'histoire à un autre membre de l'équipe. Parce que l'équipe dans son ensemble s'engage à compléter toutes les histoires dans un sprint, il n'y a pas vraiment la question qu'un devigne a travailler sur tous les aspects d'une histoire donnée. Il n'y a pas non plus de dire qu'une équipe de Scrum ne peut pas écrire leurs histoires qui ne sont que dal-seulement ou une autre zone ou service spécifique, par exemple, "... permettent aux consommateurs de la capacité de ...".
@Ian Ringrose. Scrum est à propos de l'équipe qui s'engage à produire des résultats et l'équipe était habilitée à décider de la manière de le faire. Si cela signifie 1 dev par une histoire utilisateur, génial. Si cela signifie 3 devs par une histoire utilisateur thats aussi bien. Quelle que soit la bonne façon, l'équipe de Scrum croyait être la meilleure façon de faire le travail est ce qui devrait arriver.
@JOSH E, je pense que cela dépend de si Awesomeservice a une valeur comme un client faisant face à une chose, sinon, bien que faisable, votre scénario élève des maux de tête d'intégration et des fissures dans le code où il n'y a pas de ligne de responsabilité claire.
Bon points Yishai, je pense que Paul Rowland a encapsulé ce que j'essayais de transmettre mieux que moi!
sans régie de l'utilisation de Scrum, ce que vous voyiez était un changement d'une approche de propriété d'une approche de code communal. Pour que cela fonctionne, il faut changer de processus qui le soutient. Une de ces possibilités est TDD. Il y en a d'autres (des tests d'unités automatisés, même si ne conduisez pas de conception couplé avec des critiques de code, une communication de conception forte, une plus grande conception à l'avance, ne se développant pas sur le code sans premier appariement avec l'auteur d'origine sur le code et plus je suis sûr que vous pourrait penser à).
Approche communautaire Travailler dans des communautés plus petites (en grandes, il peut dégénérer dans une tragédie des Communes) avec un sentiment de cohésion élevé entre les membres.
merci, vous avez peut-être frappé sur la tête
Le projet principal que je travaille sur utilise une approche Scrum, mais la nature intégrée de notre projet fait du développement axé sur les tests (la façon dont la plupart des gens le font) n'est pas impraticable.
Je pense que le problème que vous avez rencontré était que les attentes des programmeurs ont changé, et non que le processus de gestion a été allé à un système de style Scrum. Si les programmeurs sont constamment mélangés à des parties du code qu'ils ne connaissent pas, étudient le processus de la manière dont les tâches sont déléguées par rapport à l'ancienne méthode. Les tâches sont-elles attribuées au développeur qui sait que la zone est la meilleure ou allant au développeur avec la liste la plus courte à faire? Existe-t-il un long arriéré d'articles à faire pour une partie du code et une pénurie d'articles à faire pour une autre partie? Si vous souhaitez que les développeurs se concentrent sur les zones où ils excellent, la gestion de projet voudra ajuster des longueurs de sprint et des priorités de tâches afin de s'assurer que la charge de travail peut être distribuée à votre guise et être réalisable étant réalisable compte tenu des contraintes de temps du sprint. < / p>
Le cadre Scrum est assez petit, il définit quelques réunions, des longueurs idéales d'itération, des responsabilités du propriétaire de produit, des maîtres de Scrum ... et peut-être un peu plus.
Cependant, une fois que nous avons commencé notre itération, rien dans Scrum qui dicte comment et quand un développeur devrait développer quelque chose. Il n'y a que l'engagement que cela sera «fait» à la fin du sprint.
Scrum concerne l'équipe qui s'engage à produire des résultats et que l'équipe était habilitée à décider de la manière de le faire. Si cela signifie 1 dev par une histoire utilisateur, génial. Si cela signifie 3 devs par une histoire utilisateur thats aussi bien. Quelle que soit la bonne façon, l'équipe de Scrum croyait être la meilleure façon de faire le travail est ce qui devrait arriver.
Pour répondre à la question, oui Scrum est possible sans développement axé sur les tests.
TDD est une pratique intéressante / recommandée, mais les résultats varieront en fonction de l'équipe / du contexte. Par exemple, TDD était en place au début d'un projet ou essayez-vous d'injecter la méthodologie à une date ultérieure.
Nous faisons Scrum au travail, mais nous ne pratiquons pas TDD. Rien dans les "Directives" Scrum vous indique que vous devez utiliser TDD. En fait, la plupart des pratiques agiles sont simplement une recommandation dans la mesure où elles se sont révélées bien fonctionner dans des environnements agiles (voire non agiles) sans qu'ils soient indispensables si vous souhaitez mettre en œuvre Scrum.
Nous écrivons des terrains et de nombreux tests d'unité et d'intégration afin d'éviter des tests manuels approfondis et de vous assurer que les modifications ultérieures du code ne conduisent à aucun effet secondaire imprévu. Mais ce n'est pas TDD. C'est surtout une approche judicieuse pour assurer une bonne qualité de code et de logiciels.
Veuillez noter que non la mise en œuvre de TDD n'était pas une décision "active", elle vient de se produire. Nous sommes encouragés à "écrire des tests d'abord", par ex. Lors de la correction d'un bug, il est donc un type de manière volontaire, axée sur la situation non obligatoire d'avoir un sentiment de TDD en l'appliquant régulièrement, mais ce n'est pas obligatoire.
Comme les autres a déclaré: Scrum est un cadre qui peut contenir toutes les pratiques que vous souhaitez appliquer dans votre équipe de développement. Certaines pratiques agiles viennent naturellement, car elles ont généralement un sens, mais lesquelles vous voulez utiliser et lesquelles vous ne voulez pas, c'est à vous de décider.
C'est fondamentalement comment nous le faisons aussi. TDD est idéal pour les corrections de bugs, mais pue vraiment (OMI) pour tout développement à part entière car elle inhibe une refactorisation majeure rapide.
Il y a une certaine confusion sur Scrum ici.
Scrum en soi ne vous dit pas comment / quand faire techniques choses telles que TDD (c'est une cible mobile pour toujours). Scrum vous dit comment / quand gérer les choses les choses les choses qui se produisent sur un projet. C'est une technique Gestion de projet globale, pas une technique Gestion de la construction.
Si votre manager souhaite faire les trois choses énumérées ci-dessus pendant vos sprints, c'est bien, mais cela ne fait pas partie du cadre de Scrum. Ce sont pour la gestion de la construction, qui n'est pas scrum. Il peut être utilisé dans votre projet délimité par Scrum-Framework, mais ce n'est pas dans le cadre officiel de Scrum.
Je pense qu'il est facile d'être confondu à ce sujet, cependant. Les techniques agiles telles que Scrum sont généralement évangélisées par des personnes sur le filet qui portent tous des mots à la mode et des choses «heureuses brillantes», et comme telles ne comprennent pas toujours / communiquent bien. Au moins, c'est comme ça que les techniques agiles m'ont été introduites, par un apologiste agile. Il m'a fallu un bon 6 mois avant que je puisse avoir dépassé la terminologie battue / déroutant et j'ai compris ce qu'ils parlaient.
S'il y a des parties que j'accepte ci-dessus, je crois vraiment que vous ne pouvez pas fournir de petites incréments de code (Scrum pour logiciels) sans période de test.
Comment savez-vous que votre sprint n'a pas cassé les 4 derniers? Comment pouvez-vous garantir des produits livrables si vous ne savez pas que vous n'avez rien brisé dans le passé.
Pendant que je suis d'accord Scrum est un processus de gestion et que TDD est un processus logiciel. Vous devez avoir un moyen de pouvoir vérifier que vous n'avez pas reculé.
Scrum vous apprend que les livrables quotidiens et qui avancent toujours au détriment de la vitesse.
Quand quelqu'un dit que je veux faire CI ou Agile ou Scrum, cela signifie que cela signifie automatiquement qu'il doit y avoir des tests unitaires (pas d'essai d'intégration comme mentionné ci-dessus) mais plutôt chaque pièce mobile a sa propre unité testée.
Si vous faites un test d'intégration, vous ne testez pas chaque partie individuelle de manière autonome. Par conséquent, tout ce que vous prouve est que la méthode appelée dans un flux fonctionne plutôt que chaque branche possible que vous verriez dans le MSIL
"Ne travailler que sur une zone de la demande pendant quelques jours au plus avant de passer à la zone suivante" Vraiment? Pourquoi? Pourquoi quelqu'un a-t-il insisté à ce sujet? "Pour travailler principalement sur le code, ils n'ont pas écrit" vraiment? Pourquoi? Pourquoi faisaient-ils cela? Ce ne sont pas des problèmes de scrums. Pouvez-vous développer ces points? Ce qui se passait?
Pourquoi l'avez-vous appelé «Déploiement axé sur des tests» lorsque la plupart des gens l'appellent «développement axé sur les tests»? Pourquoi "déploiement"? Où as-tu vu ça?
@ S.Lott, parce que nous avons tous lu ce que nous pensons que nous lisons, y compris vous lorsque vous lisez la question hier
Je vote pour fermer cette question comme hors-sujet car il ne s'agit pas de la programmation.