à l'université, nous avons parlé de programmation agile, mais aussi combien de méthodes agiles ne sont pas utilisées dans des affaires, comme une programmation par paire.
J'aimerais savoir quelles méthodes appartiennent à une programmation agile (programmation extrême, programmation par paire) et qui sont vraiment utilisées / utilisez-vous. Qu'en est-il du développement itératif et incrémentiel?
Edit: à ceux qui souhaitaient fermer cette question à cause de "subjectif et argumentatif". Cette question peut être répondue, car le développement agile est une expression définie. http://fr.wikipedia.org/wiki/agile_software_Development . De plus, de nombreux utilisateurs s'intéressent à cette question, pour le fermer n'est pas bien considéré
11 Réponses :
La méthodologie agile est une base pour le développement agile.
En d'autres termes, Programmation extrême , Scrum et ainsi de suite sont des méthodologies agiles basées sur des principes agiles. Vérifier que ces questions répondront à vos questions.
Quant à Agile lui-même, et quels types de développement agile ont en commun Check Out Wikipedia pour une vue d'ensemble.
Pylkworks est l'une des entreprises qui ont un développement agile en vigueur. En savoir plus sur le développement agile directement depuis site web de Martin Fowler's .
En affaires, je pense que vous verrez généralement des équipes prenant les aspects qu'ils aiment de différentes méthodologies de programmation et de les combiner dans leurs propres pratiques. Ils vont probablement appliquer n'importe quel terme qu'ils veulent même s'il n'est pas précis à 100%.
Dans notre équipe, nous appliquons des stand-ups quotidiens et une programmation d'équipe (environ la moitié du temps - dépend de la tâche). Nous ne prétendons pas faire agile cependant.
On dirait que vous voulez vraiment savoir ce que les gens utilisent réellement dans le monde réel. Il y a beaucoup de sites sur ce qui est dans et ce qui n'est pas une pratique / méthodologie agile.
Alors, mon expérience jusqu'à présent dans mes récents rôles (5 dernières années):
Bien que c'est votre expérience, ça sonne assez sombre. Surtout les points 1 et 3. Ce n'est pas comme ça partout.
J'apprécie votre propre expérience. Oui, toutes les équipes ni chaque développeur ne colle pas de la philosophie agile idéale. Ils ont la liberté de choisir quelles pratiques et rejeter les autres.
La plupart des développeurs expérimentés sont devenus des gestionnaires de projet depuis ou des directeurs informatiques. À l'époque, il y a environ 20 ans, ces méthodologies telles que le développement de logiciels agiles n'existaient même pas, et ils ont pu produire et fournir des systèmes de travail.
Ces mêmes gars pourraient ne pas avoir connaissance de telles pratiques proposées à partir de ces nouvelles méthodologies résultant d'une sorte de résistance à la mise en place de cette approche.
Nous ne pouvons donc pas être brutes pour eux, ils ne résistent que des changements qu'ils ne savent ni ne comprennent, tout comme disons un client qui est utilisé pour travailler d'une manière, et puis nous venons avec nos nouvelles méthodes et ensuite Changez les habitudes de ce client dans une journée! Il est tout à fait normal que ces résistances se produisent, elles sont des bahviours humains.
En outre, pour certains de ces plus expérimentés, ils ne comprennent pas simplement le point de travailler en paire, par exemple. Tout comme ils ne croient généralement pas aux réunions de Scrum, ils préfèrent la voie vieille école, ce qui a connu son succès d'une manière d'une certaine manière, d'une réunion d'une durée de 1 à 2 heures par semaine.
Quant aux administrateurs, les responsables des budgets des ressources de programmation, comme pour la programmation par paire, de payer un programmeur de ne rien faire pendant que ce faisant non-programmeur pourrait fonctionner sur une autre partie du code pour multiplier la productivité. Vous ne pouvez pas vraiment les blâmer ni, comme ce qu'ils le pensent est plein de sens.
Certaines suggestions du développement logiciel agile sont plus faciles à bénéficier de l'avantage par rapport à d'autres. Tandis que la programmation des paires peut ne pas connaître un réel succès dans la pratique, ni même des réunions quotidiennes de Scrum, ce qui est un succès cependant, de mon expérience, commence à coder dès que nous obtenons un croquis suffisamment précis du logiciel, ses exigences et ses caractéristiques, jamais oublier les priorités données du client lui-même. Ensuite, mettez à jour l'analyse UML tout en développant une itération.
Les itérations de logiciels, dans mon expérience, commencent un succès croissant.
Laissez l'heure, le développement logiciel agile, tel que le développement axé sur les tests, bien dans ma région, reste de nouvelles choses. Une fois qu'ils auront plus de pratiquants, leurs pratiques pratiquées grandiront avec elle, je crois.
La première mise en œuvre du Scrum a été exécutée à Easel Corporation en 1993.
Oui, aux Etats-Unis. Mais par exemple, certaines entreprises fonctionnent toujours avec leur ancien AS400 ou VAX, est donc âgée de plus que 1993. Une fois la méthode qui fonctionne au sein d'une entreprise, elle est à peine abandonnée pour un autre plus récent qui serait plus prometteur. Les gens doutent. Une fois que quelque chose fonctionne, pourquoi le changer? Si ce n'est pas cassé, ne le répare pas. Voilà toute l'histoire.
Certaines personnes ne remarqueront même pas quand quelque chose est brisé. Ils supposeront simplement que la douleur de l'échec est «normale» - n'ayant jamais vu quelle version de travail appropriée ressemble à ...
Cela dépend de la société à la société. Je travaille pour une entreprise qui fait tous TDD, tous les jumelages, tous les CI, tout le temps. L'équipe n'a pas peur de vous appeler si vous soumettez du code, mais que vous n'avez pas soumis à des tests de l'unité / fitnessse, et moins d'une minute après que vous soumettez du code, le serveur CI exécute toute la suite de tests et si votre code casse la construction ou Amy des tests échoue, les lumières s'éteignent et vous êtes signalé comme celui qui a cassé la construction.
Ce n'est pas la situation la plus courante, mais là-bas sont les entreprises qui pratiquent vraiment agile.
Je suis maintenant à ma deuxième entreprise qui a pratiqué Agile de manière assez proche de votre description. Je pense que la plus grande clé se souvient cependant des trucs dans le manifeste. Tous les autres ne sont que des outils pour vous aider à atteindre ces objectifs. Si l'une des "pratiques" agiles se met en route, vous devez les reconsidérer.
Le développement agile n'est pas une méthodologie en soi, c'est un terme parapluie qui décrit plusieurs méthodologies agiles (qui appartiennent tous au développement itératif et incrémental - IID - Famille).
Texte alt http://img62.imageshack.us/img62/6374/DDD997578TeamProjagileum .png
à la signature du Manifesto agile en 2001 , les méthodologies suivantes ont été représentées: une programmation extrême ( XP), Scrum, DSDM, Développement de logiciels adaptatif (ASD), Crystal, Développement dirigé par des fonctionnalités (FDD), Programmation pragmatique. Chacun d'entre eux partage les valeurs fondamentales du manifeste agile mais les implémenter avec une approche légèrement différente.
En revanche, la programmation par paire est une pratique d'ingénierie (c'est l'une des pratiques de XP qui capture de nombreuses pratiques comme un ensemble indivisible mais vous pouvez l'utiliser en dehors de XP). Et, pendant que je tiens beaucoup de pratiques, gardez à l'esprit que les pratiques ne sont pas une fin, elles sont juste une moyenne, car j'ai écrit Scrum et XP (utilisé ensemble) sont les plus couramment utilisés de nos jours.
Beaucoup de personnes semblent mal comprendre des concepts comme le refactoring, la programmation par paire et le concept général d'équipes auto-organisées ... Ceux-ci peuvent être difficiles pour les personnes qui ont obtenu une mesure de succès de la cascade et ont pris en retrait de cette façon de faire des choses. C'est un problème d'obtenir ces personnes à essayer XP.
Comme d'autres personnes ont mentionné qu'Agile est un terme parapluie et peut être mis en œuvre de différentes manières; Cela étant dit que l'état actuel de la Buzz de Buzze d'Agile a conduit à beaucoup d'entreprises qui tentent de mettre en œuvre agile qui vient vraiment implémenter un ensemble de PROCÉDURES DE MARGO CULT-ESQA et attendez la flexibilité d'Agile.
Dans ma précédente société, les gestionnaires ont saisi une hausse d'agile comme si c'était la réponse à tous leurs problèmes. Mais la seule chose que cela a fait était de créer beaucoup plus de problèmes.
Nous avons eu des réunions très régulières appelées "STANDUPS" (une sorte de terme agile).
Je pense qu'ils ont essayé beaucoup de techniques agiles, mais cela n'a pas vraiment bien fonctionné pour nous à l'époque.
Je viens de surtout sur le Pratiques Agile Résultats de l'enquête: juillet 2009 . C'est un ensemble d'échantillons assez petit (123), mais il offre une perspective intéressante. Par exemple, les 10 principales pratiques agiles agiles les plus efficaces (telles que rapportées par les répondants) étaient les suivantes:
Il y a aussi des diagrammes pour les 10 premières pratiques agiles que:
Nous ne faisons pas les pratiques pour les pratiques. Les pratiques agiles sont sorties des principes agiles comme expliqué sur le Site Web Manifesto . Le principe d'agile le plus élevé est le suivant: "Pour satisfaire le client par la livraison précoce et continue de logiciels précieux". tôt , continent , et valeur de valeur sont les mots clés là-bas. Si une équipe ne comprend pas la manière dont les principes conduisent les pratiques, ils courent le risque d'être, comme @GuildenCrantz a déclaré, Cargo-culte, ne pas avoir le succès de la magie-balle qu'ils attendent, déclarant agile un échec et abandonnant ça.
Je n'ai pas de bonne citation à portée de main, mais il est généralement considéré comme plus facile d'être agile sur Greenfield Projects qu'il consiste à convertir un Brownfield Project à Agile. Une des raisons pour cela est que le code existant est souvent écrit d'une manière qui rend difficile d'ajouter des tests automatisés. Michael Feathers a écrit un livre complet sur l'ajout de tests au code hérité. Il est plus facile d'être agile sur un nouveau projet que de convertir un projet en agile:
Je suis également curieux de connaître la réponse à cela parce que je développe également une application qui implique un modèle de cascade classique. Le problème est que les changements arrivent comme et lorsque nous développons. Nous le prenons en tant que CR (changement de changement) et réactivez la portée plutôt que d'accepter le changement tel qu'il est. Cela signifie-t-il que j'implique une saveur agile?
Apparemment, mon entreprise commence la méthode agile. Je suppose que tout est meilleur que la méthode de la cascade.
@BRAGAADESHESH: Même dans Agile, vous n'acceptez pas les changements qu'ils viennent. Vous courez vers l'objectif actuel (à proximité) et acceptez les changements que lorsque vous l'avez atteint. Vous ne pouvez abandonner que l'objectif actuel si le changement actuel le casse entièrement, ou implémenter un modification de l'utilisateur si la section n'a pas encore été mise en œuvre et constitue une cible de l'objectif actuel.
@Exittoshell Essayez un développement basé sur l'anarchie («Agile, mis en œuvre par les gestionnaires qui pensent qu'Agile signifie que les gestionnaires ne font rien») et vous changerez votre esprit vraiment rapidement.
@Closer Pouvez-vous expliquer ce qui est subjectif et argumentatif dans cette question? C'est ridicule.