Scrum pour un seul programmeur? [fermé]

Je suis facturé comme "l'expert Windows" dans ma très petite entreprise, qui se compose de moi-même, d'un ingénieur en mécanique travaillant dans un rôle de vente et de formation, et du président de l'entreprise, travaillant dans un rôle de conception, de développement et de support.

Mon rôle est tout aussi général, mais je conçois et implémente principalement la programmation de notre produit qui doit être effectuée pour que nos produits fonctionnent sur les versions de Windows actuelles.

Je viens de terminer de regarder un aperçu de haut niveau du paradigme Scrum, donné dans une webémission. Ma question est la suivante: cela vaut-il la peine d'en apprendre davantage sur cette approche du développement de produits, étant donné que mes éléments de travail de développement sont généralement donnés à un niveau très élevé, comme "internationaliser et localiser le produit".

Si tel est le cas, comment suggéreriez-vous d'adapter Scrum pour l'utilisation d'un seul programmeur? Quels outils, basés sur le cloud ou non, seraient utiles à cette fin?

Si ce n'est pas le cas, quelle approche suggéreriez-vous à un seul programmeur pour organiser ses efforts au jour le jour? (Peut-être que la question se réduit à cette simple question.)

Apprenez Scrum: oui. Ne serait-ce que pour en savoir plus à ajouter à votre ensemble de compétences générales. (mais une saveur de celui-ci "Scrum-ban" est probablement ce que vous cherchez ...)

Scrum est un cadre sympa, mais un principe de base est "Les itérations (sprints) doivent être de durée fixe". Si vous pouvez vraiment vous inscrire et vous engager à travailler dans un délai fixe (1 semaine?), Scrum est un cadre sympa. Si vous ne pouvez pas ... alors Scrum est agréable à apprendre car il a de bons concepts qui se traduisent bien en d'autres choses ... comme ...

Backlog - Scrum ou non, conservez une liste prioritaire des choses que vous devez faire. J'aime Excel (ou Google Doc Spreadsheet ...) Vous aimerez peut-être autre chose. Je garderais un tout petit outil si vous êtes une toute petite équipe. (Feuille de calcul >> Traitement de texte car vous pouvez trier facilement.)

Séparation de la planification et de l'engagement - Planifiez dans une notation abstraite (points) et soyez cohérent (8pts, c'est environ 2x une histoire de 4 points et 4x une histoire de 2 points) Quand il est temps de "faire le travail", revoyez le problème et esquissez-le en heures. Ne changez pas les points.

Engagement - soyez visible pour les autres lorsque vous vous engagez et respectez vos engagements

Rétrospective - après avoir livré, réfléchissez à ce qui aurait pu être mieux fait.

etc.

Scrum est assez facile à comprendre qu'il pourrait être un bon point de départ. Si vous l'aimez, j'envisagerais d'utiliser la variante "Scrum-ban" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Rien d'autre ne me semble "si bien documenté" avec une communauté raisonnablement active pour le soutenir.

J'aimerais également recommander les méthodologies Crystal d'Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer et http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Petit / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), mais cela implique beaucoup plus de lecture et de fouille.

Des choses comme XP fournissent plus de détails sur des pratiques spécifiques, je dirais donc également lire le livre: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= livres & ie = UTF8 & qid = 1304359834 & sr = 1-1

Conseil de lecture finale: Tant que vous acceptez le manifeste Agile et suivez les principes: http://agilemanifesto.org/principles.html vous devriez être en bonne forme.

Recommandation personnelle: Adopter TDD (non négociable, à mon humble avis) Maintenir un carnet de commandes (selon Scrum) Toujours le garder dimensionné et trié en priorité Décomposer les choses "trop ​​grandes pour faire entre les interruptions" en petits morceaux Demander à quelqu'un d'autre de définir / revoir la priorité (non deux éléments ont la même priorité.) Rendez votre environnement de construction capable de construire / tester / déployer (vers env de laboratoire) en 5-10 minutes Montrez à vos clients (internes et externes) les résultats de la finition d'une histoire L'histoire ne se fait pas avant votre client accepte. Tirez les histoires du haut de la pile et travaillez dessus pendant que vous terminez l'histoire actuelle. Ne gardez pas plus de 2 choses ouvertes à la fois. Terminez une distraction avant d'en commencer une autre.

J'espère que cela t'aides

Vous pouvez utiliser certaines pratiques utilisées dans Scrum comme le backlog de produit, la priorisation, l'estimation relative, la livraison incrémentielle, mais l'utilisation de Scrum entier comme processus de gestion du développement de produit par une équipe de membres interfonctionnels auto-organisés n'est probablement pas la voie à suivre pour un seul salon. .

La question est de savoir si vous pouvez diviser vos éléments de travail en petits morceaux qui peuvent être livrés progressivement? Si vous n'utilisez pas la plupart des pratiques, cela n'a pas de sens. Scrum est également une coopération étroite avec le propriétaire / client du produit. Cela ne devrait pas être comme: "Ici, vous avez un devoir et revenez une fois terminé".

Bien que je ne dise rien pour ou contre Srum à 1 homme, je dirai qu'un système de traction Kanban à 1 homme fonctionne très bien. Kanban combiné à des tests unitaires automatisés m'a rendu beaucoup plus productif et "documenté". Bien que ce ne soient pas vraiment des méthodologies, mais plus d'outils (et très différents à cela), les deux me forcent à décomposer de grands projets solo en morceaux de petite taille, ainsi qu'à me donner une sorte de rituel pour m'encourager à faire plus de choses chacun journée. Il n'y a rien de plus satisfaisant que de cliquer sur "exécuter tous les tests" et de voir chaque élément passer au vert ... rien, sauf prendre une carte de la colonne "En cours" de mon tableau Kanban à "En cours de test" (ou complètement hors du tableau) .

Je pense que le vrai problème avec le travail en solo, c'est que vous avez le choix entre plusieurs méthodologies, qui sont vraiment destinées à des groupes de développeurs, et que vous les adaptez le mieux à vos besoins. L'objectif final est vraiment juste de vous tenir responsable, productif et heureux. Qui sait faire mieux que vous (avec un peu tiré d'ici et un peu de là).

J'ai essayé ceci quand je travaillais seul à un moment donné. Les choses qui ont bien fonctionné étaient:

1. Avoir tous les éléments de travail sur un tableau blanc. Je pouvais très rapidement voir quel travail remarquable il y avait; où se trouvaient les dépendances et les blocages. De plus, beaucoup de gens passaient par mon forum et le lisaient - et nous en discuterions. Je pense que cela les a aidés à comprendre ce que "le geek" faisait toute la journée ;-)
2. Le tableau de combustion était également excellent. Je viens d'utiliser Excel pour cela. Cela m'a permis de mieux faire des estimations dans cet environnement. Cela m'a donné un bon aperçu de la direction que j'allais prendre avec l'itération. Mon manager, qui n'était pas une personne technique, a également aimé cela car elle pouvait voir toutes les différentes choses impliquées dans une fonctionnalité, et où elles en étaient.
3. Stand up quotidien. Du mieux que je pouvais. Chaque matin, je mettais à jour tous les éléments de travail et le tableau de brûlage et notais tous les obstacles qui devaient être résolus.
4. Les tests automatisés et l'intégration continue (MSTest / TFS), de préférence TDD, aideront toute équipe de développement, en utilisant n'importe quelle méthodologie - mais mérite d'être mentionnée ici.
5. De courtes itérations (1 semaine) m'ont vraiment aidé à me concentrer sur la livraison de quelque chose.
6. Le maintien d'un carnet de commandes était formidable car lorsque j'ai reçu un nouveau travail, j'ai pu le placer dans le contexte de tous les autres travaux et amener le propriétaire du produit à redéfinir les priorités.

Ce qui n'a pas fonctionné, c'est:

1. Travailler par vous-même, vous ne recevez jamais ce coup de pouce en collaborant avec des personnes aux vues similaires; ou ce sens de la compétition et de la concentration qui vient d'une équipe avec un moral et une culture vraiment excellents. Il n'y a pas d'autre cerveau à choisir lorsque vous êtes coincé, donc les blocages comme celui-ci ne peuvent pas être éliminés par un maître de mêlée dans le stand up quotidien.
2. Il n'y a pas de Scrum Master - donc il n'y a personne pour arrêter les interruptions. J'ai eu beaucoup de mal à ce que les gens posent constamment des questions sur d'autres choses et interrompent mon flux. Sous un bon Scrum Master, des trucs comme ça sont interceptés et vous pouvez continuer. Je n'ai jamais voulu être impoli avec les gens (peut-être que je suis doux), donc c'était un problème. De plus, sans Scrum Master, vous pouvez facilement vous éloigner du processus.

C'était un exercice intéressant, mais j'ai arrêté de le faire après un peu. Je pense que les avantages de Scrum doivent être vus contrairement aux équipes traditionnelles de cascade. Mais les deux sont en quelque sorte sans objet lorsque vous êtes seul. Il n'y a pas de problèmes de communication ou de collaboration - il vous suffit de parcourir le travail défini et vous avez terminé.

Je pense que tout le monde devrait garder un journal de bord et faire TDD cependant.

Éléments d'Agile / Scrum / Kanban qui, je pense, ont du sens dans un monde de développeur unique:

1. Ayez un tableau sur lequel vous organisez vos user stories / éléments actifs de backlog, sur des fiches, comme le kanban.

2. Obtenez l'adhésion des non-développeurs sur la valeur de ces principes:

   • Donnez-moi le temps de travailler sans changer mes priorités sur moi ou la microgestion (le point des sprints). Donnez-moi du temps et j'essaierai de déterminer à l'avance exactement ce que je peux faire, et je ferai de mon mieux pour le faire.

   • Si j'ai besoin de quelque chose (je suis bloqué), et je viens à vous, et vous ne pouvez pas le trier pour moi, alors le sprint devra peut-être être annulé anormalement. (Cela signifie simplement que nous avons besoin d'un nouveau plan.)

   • Personne ne change rien au milieu du sprint. Ou, si nous le faisons, nous annulons simplement le sprint et nous en créons un nouveau. si cela se produit souvent, la productivité baisse.

   • la communication entre les personnes qui sont parties prenantes peut se produire lors de réunions quotidiennes régulières, qui communiquent la plupart des mêmes choses qu'une mêlée régulière, y compris les réalisations de votre développeur pour la journée. Essentiellement, vous pouvez signaler les éléments qui ont pris plus de temps que prévu ou qui se sont bien déroulés, ainsi que les ajustements que vous apportez à vos plans de mise en œuvre. (J'ai trouvé quatre nouveaux bogues et les ai enregistrés, je pense qu'ils sont plus importants que cette fonctionnalité facultative, et je pense donc que je vais passer du temps à les corriger et à pousser cette fonctionnalité facultative.)

J'ai fait beaucoup de travail en tant que développeur unique, et je peux dire avec certitude que la confiance entre le développeur unique et ses superviseurs / patrons non développeurs, et une bonne communication sont les clés, pas une méthodologie. Mais vous pouvez toujours être plus efficace si vous suivez de bons principes.

J'ai lu un blog à ce sujet et je pense que cela peut vous aider avec votre question.

Première partie: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Deuxième partie: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Vous trouverez peut-être plus d'informations sur ce blog.

Je ne suis aucunement connecté; juste quelque chose que j'avais dans mes favoris. J'espère que cela peut vous aider.

Oui. Et gardez à l'esprit que le Scrum n'a pas besoin d'impliquer des outils sophistiqués, il peut simplement s'agir d'une simple réunion debout de 15 minutes où tout le monde parle de ce sur quoi il travaille. L'avantage de Scrum est que tout le monde sait ce qui se passe, ce qui facilite la résolution des problèmes avant qu'ils ne surviennent et l'anticipation des problèmes sur la route.

Beaucoup de ces réponses manquent un point important.

Une équipe Scrum n'a pas besoin d'être composée uniquement de programmeurs.

Un de vos collègues s'occupe de «conception» / «développement» et l'autre de «vente».

Peut-être que votre collègue «vente» peut être propriétaire d'un produit (proxy). Quelles sont les attentes du client?

La conception et le développement de votre autre collègue ressemblent vraiment aux disciplines de l'équipe Scrum pour moi. Le développement de Scrum n'est pas progressif mais vertical (exigences de repassage, conception et mise en œuvre en un seul sprint).

Vous pourriez faire la mêlée avec vous trois.

Que faut-il pour que «cela» soit fait? Les réunions de planification de sprint de Scrum se concentrent sur la question de savoir ce que c'est. Qu'est-ce que le propriétaire du produit attend de voir pour que cela soit considéré comme terminé?

Lors d'une réunion de planification de sprint, vous pouvez expliquer à vos autres collègues pourquoi «internationaliser et localiser le produit» peut être techniquement difficile à mettre en œuvre.

Des tonnes de raisons d'utiliser Scrum Imho.

Je suggère d'essayer Kanban et de commencer par les bases: visualisation et limitation des travaux en cours (WIP).

Même si vous l'interrompez plus tard, vous serez plus agile dans le processus. Et bien que Kanban soit bon pour le développement de logiciels "normaux", Kanban + un processus basé sur les flux (par opposition aux itérations) surpasse les autres outils de processus lorsque vous êtes confronté à la fois au développement de nouvelles fonctionnalités et à la maintenance.

J'appuie la recommandation du livre Kanban de David Anderson, et vous pouvez également jeter un coup d'œil à mes diapositives d'un Meetup local pour savoir pourquoi et comment commencer avec un simple Kanban , ou crisp.se/kanban pour une courte introduction.

Pour votre contexte, j'ai quelques réflexions:

• la visibilité est la clé, alors utilisez plutôt un tableau blanc physique qu'un outil numérique si vous ne pouvez pas l'afficher sur un (grand) écran en permanence (si vous êtes colocalisé)
• commencez avec votre processus actuel
• commencez par votre sphère d'influence uniquement, y compris les phases de transfert en amont et en aval (devenant une file d'attente pour vous, par exemple, des fonctionnalités conçues prêtes pour le développement, ou une file d'attente pour vous, par exemple, des fonctionnalités finies, prêtes pour la vente)
• si vos collègues souhaitent étendre la visualisation en amont ou en aval, tant mieux. Peut-être que vous finirez par visualiser l'ensemble du flux de valeur (ou réseau) pour votre entreprise, c'est-à-dire comment la valeur passe du concept à l'argent
• minimisez le multitâche (!) en limitant le WIP. Si le flux de travail est visible pour vos collègues, ils doivent comprendre pourquoi et voir facilement ce qu'il y a dans votre assiette
• il sera peut-être utile de séparer le travail en 3 ou 4 types de travail (classes de service), qui ont différentes exigences: f.ex. bogues, problèmes critiques, travail avec des délais stricts, travail sans délais
• observez comment votre travail se déroule, par exemple, si vous rencontrez des goulots d'étranglement quelque part, ou si le travail est bloqué ou si vous êtes "affamé" pour le travail selon des schémas quelque peu prévisibles. C'est plus facile à long terme si vous utilisez un outil numérique, référez-vous à certaines de mes dernières diapositives.
• améliorer le flux de travail étape par étape

Si vous voulez essayer quelque chose dès maintenant, aujourd'hui, pendant que vous prenez votre décision, je vous recommande d'essayer un kanban personnel sur le mur ou la fenêtre ou le placard à côté de vous, comme je l'ai fait la semaine dernière ...

Après avoir lu toutes les autres réponses ici, je pense que la réponse pragmatique simple est:

Utilisez des processus, des techniques ou des méthodes utilisés pour APPRENDRE quelque chose qui vous aidera à mieux faire votre travail.

Maintenant, cela pourrait signifier de prioriser vos tâches - chaque jour - religieusement.

Cela pourrait vouloir dire éliminer l'arriéré.

Cela pourrait signifier de signaler les progrès - à votre patron (même s'il s'en fiche ... c'est une bonne chose de vous permettre mentalement de faire le point sur votre situation).

Vous pouvez utiliser toutes sortes de méthodes ou de techniques, car elles vous permettent en fin de compte de mieux travailler, ce qui = mieux dormir la nuit.

Faites des choses qui fonctionnent (pour vous, dans votre situation actuelle), jetez des choses qui ne fonctionnent pas.

À moins que vous n'ayez les éléments suivants en place

• Moyens d'organiser et de hiérarchiser les besoins entrants.

• Pour estimer avec précision l'effort qui sera fait afin de savoir ce que vous pouvez engager dans une itération

• Itérations et amélioration continue - Le concept d'itérations dans lesquelles on inspecte et s'adapte continuellement est inestimable. Cette pratique encourage l'expérimentation et elle renforce l'apprentissage continu. Scrum in Church, page 4

• Eh bien, vous ne pouvez pas faire une réunion de mêlée quotidienne, mais au moins vous pouvez vous rappeler la tâche que vous vous engagez aujourd'hui. Une réunion de mêlée quotidienne est utilisée pour que les équipes puissent se synchroniser sur ce qu'elles font.

• Réflexion après un sprint - dans la mêlée, cela s'appelle Sprint Retrospective, à la fin de chaque itération, vous pouvez réfléchir à ce qui se passe après l'itération, et penser à ce qui s'est mal passé et comment vous pouvez l'améliorer, quelles sont les meilleures pratiques pour les garder Faire

Je suggère que vous adoptiez une approche minimaliste, et par amélioration continue, vous pouvez avoir une mêlée qui correspond bien à vos besoins.

Scrum n'est pas Scrum si vous ne pouvez pas l'adapter à vos besoins et vous adapter à votre situation actuelle.