Avec quelles méthodes de développement logiciel Agile avez-vous eu le plus de succès ?[fermé]

Question

Il existe de nombreux Développement de logiciels agiles méthodes.Lesquels avez-vous utilisés dans la pratique pour mener à bien un projet, et comment la méthode a-t-elle contribué à ce succès ?

Answer 1

J'ai été impliqué dans un certain nombre d'organisations qui prétendaient travailler de manière « agile », et leurs traitements semblaient généralement être basés sur XP (programmation extrême), mais aucune d'entre elles n'a jamais suivi toutes les pratiques.

Cela dit, je peux probablement commenter quelques-unes des pratiques XP

• Tests unitaires semble s'avérer très utile si cela est fait dès le début d'un projet, mais il semble très difficile d'accéder à une base de code existante et de commencer à essayer d'ajouter des tests unitaires.Si vous avez la possibilité de repartir de zéro, le développement piloté par les tests est d’une réelle aide.

• Intégration continue semble être une très bonne chose (ou plutôt, son absence est vraiment mauvaise).Cela dit, les organisations que j'ai rencontrées étaient généralement si petites qu'elles rendaient toute autre approche insensée.

• Cartes d'histoire d'utilisateur sont bien dans le sens où c'est génial d'avoir un objet physique à jeter pour la priorisation, mais ils ne sont pas assez détaillés à moins que votre développeur ne connaisse vraiment le domaine, ou que vous ayez un client sur site (ce que je n'ai jamais réellement vu) .

• Réunions debout ont tendance à être très utiles pour que les nouveaux membres de l'équipe apprennent à connaître tout le monde et ce sur quoi ils travaillent.Les anciens se relâchent très vite et se contentent de dire des choses comme "Je travaille toujours sur X", ce qu'ils font depuis une semaine. Il faut un leader fort pour les forcer à approfondir les détails.

• Refactorisation est maintenant un terme vraiment mal utilisé, mais lorsque vous disposez de suffisamment de tests unitaires, il est vraiment utile de séparer conceptuellement l'activité de « modification de la conception du code existant sans modifier la fonctionnalité » de « l'ajout de nouvelles fonctionnalités ».

Answer 2

Scrum parce que cela montre où sont les fainéants.Il identifie également beaucoup plus rapidement que l'unité commerciale n'a généralement aucune idée de ce qu'elle souhaite réellement livrer.

Answer 3

Mêlée.

La réunion debout quotidienne est un excellent moyen de s'assurer que les choses restent sur la bonne voie et que des progrès sont réalisés.Je pense également qu'il est essentiel d'impliquer les responsables du produit et du marché dans le processus de manière réelle et significative.Cela créera un environnement plus collaboratif et supprimera une grande partie des déchets contradictoires qui surviennent lorsque l'équipe produit et les équipes de développement sont des « silos » séparés.

Answer 4

Organiser des rétrospectives régulières est un excellent moyen d'aider une équipe à devenir plus efficace/agile.Plus que d'adhérer à une saveur spécifique d'Agile, cette pratique peut aider une équipe à identifier ce qui fonctionne bien et à s'adapter à un environnement changeant.

Assurez-vous simplement que la personne qui organise la rétrospective sait ce qu'elle fait, sinon cela pourrait dégénérer en une séance de plaintes.

Il existe un certain nombre d’exercices que vous pouvez faire réaliser à une équipe pour l’aider à réfléchir et à extraire de la valeur de la rétrospective.Je suggère d'écouter l'interview de Linda Rising sur Software Engineering Radio pour une bonne introduction.

Effectuez une recherche Google sur « Rétrospectives Heartbeat » pour plus d'informations.

Answer 5

J'ai travaillé avec une équipe utilisant des pratiques XP et Scrum saupoudrées de Lean.Cela a été très productif.

Standup quotidien- nous aide à garder une trace complète de ce sur quoi et où chacun travaille.

Programmation en binôme- a amélioré notre base de code et aidé à supprimer les bugs "idiots" introduits dans le système.

développement itératif- L'utilisation d'itérations d'une semaine nous a permis d'améliorer notre vélocité en fixant des objectifs plus directs, ce qui nous a également aidé à dimensionner nos exigences.

TDD- m'a aidé à changer ma façon de programmer, maintenant je n'écris plus de code qui ne corrige pas un test défectueux et je n'écris aucun test qui n'a pas d'exigence clairement définie.Nous avons également utilisé des exigences exécutables, ce qui a vraiment aidé les développeurs et les BA à comprendre les exigences.

tableaux Kanban- montrer en temps réel où nous sommes.Nous en avons un pour le Milestone ainsi que pour l'itération actuelle.D'un seul coup d'œil, vous pouvez voir ce qui reste à faire et ce qui est fait et ce qui est fait et accepté.Si vous ne signalez pas dans votre stand-up quotidien quelque chose concernant ce qui est écrit au tableau, vous devez expliquer.

équipe colocalisée- tout le monde est au courant et en phase avec ce que font les autres.la communication est juste à temps, très productive, mon cube ne me manque pas du tout.