Agile Scrum pour le développement logiciel

Le champ d'application du développement dans le / domaine de l'informatique de logiciels
Les gens et les individus associés au développement de logiciels et le domaine des TI, comme d'utiliser le terme «développement de logiciels» pour décrire leur domaine de travail et l'implication professionnelle. Le terme «développement» est très largement utilisé pour décrire une foule d'activités de restauration dans le domaine de l'informatique. Il peut varier de développer du code pour les applications et les systèmes, le développement d'applications mobiles pour les systèmes d'exploitation mobiles comme Android, iOS, Symbian, Windows OS, etc (visite http://en.wikipedia.org/wiki/Mobile_operating_system), "logiciel de fabrication "de jeu en utilisant des langages de script comme Ruby, AGSScript, Lua, Marathon langage de balisage, Ada, C ++, C #, D, Lisp, Mercure, Pascal, Perl, Python, Scheme, JavaScript, Java, VBScript, EDL, etc, (visiter http://en.wikipedia.org/wiki/List_of_programming_languages​​) portant sur ​​le développement web en utilisant HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc, et même le développement de systèmes d'exploitation complets pour les tablettes et les PC (visitez le site http://en.wikipedia.org/wiki/List_of_operating_systems en savoir plus sur les systèmes d'exploitation).

Le fait est que aujourd'hui, la terminologie "développement de logiciels" est largement utilisé pour parler de presque n'importe quel type ou de l'activité associée à la programmation et le développement de code "voie informatique" de tout type, de toute façon, ou la manière. Quand une méthode ou un cadre particulier est utilisé pour développer du code voie informatique et créer des projets de logiciels, il est important de vérifier si le cadre du développement comprend l'activité spécifique que vous êtes en train impliqué ou associé. Cadres de développement de logiciel et de gestion de projet, comme Agile ont le potentiel de développer des projets informatiques réussis impliquant la grande majorité des plates-formes de développement et systèmes d'exploitation.

Quel est le cadre Agile?  

Tout en expliquant Agile d'une manière simple et directe, il peut être mieux comprise comme un ensemble de méthodologies et des cadres de l'élaboration des projets, dont un cadre ou méthode peuvent être utilisés d'une manière efficace pour développer dynamiquement projets de presque n'importe quel type et de la nature, y compris projets de développement de logiciels. Le cadre est basé sur le développement itératif et incrémental, dans lequel organisé auto-et les équipes de développement auto-gestion à comprendre, planifier et développer des projets sous la supervision d'un chef de projet, et offrent la productivité sous la forme de courtes rafales de cycles de développement (itératif développement) connu sous le nom sprints. Une caractéristique unique de tous les cadres Agile est que le développement réalisé par l'équipe est "livrable" dans la nature à savoir le code développé au cours du cycle de développement du produit est indépendant, testable, vérifiable, traçables, et prêt pour le déploiement après il est rigoureusement vérifié pour les défauts de «fabrication».

Une deuxième caractéristique, très important du développement Agile est que les individus "propriétaires" du projet sont étroitement liés avec l'approbation de développement menées par l'équipe. Un "code" particulier ou «morceau» de la fonctionnalité est vérifiée régression après il est développé, et par la suite présentée aux parties prenantes et les porteurs de projets. Ils constatent le développement réalisé, et effacer comme "OK" pour une future intégration dans le produit réel. Cela conduit à une réussite du développement de projets logiciels, puisque la gestion est toujours au courant de ce que la fonctionnalité est actuellement développé par l'équipe, et jusqu'à quel point il répond aux objectifs du projet. Si les porteurs de projets se sentent la productivité offert par l'équipe n'est pas mise à la marque, ou ne les satisfait en termes de valeur de l'entreprise (combien importante le code ou fonctionnalité est du point de vue du marché, et combien il vaut la peine du point de vue financier) offert par la fonctionnalité, ils peuvent rejeter l'ensemble des fonctionnalités et de charger le chef de projet pour le réaménagement du script particulier ou un code, basé sur une nouvelle série d'apports et recommandé par eux. Cela garantit que le projet de logiciel toujours "maintient" sa valeur d'entreprise à tout moment, même lorsque l'appareil est en cours de développement.

Une troisième caractéristique importante de cadre agile est que toutes les activités du projet sont «temps en boîte", et par conséquent, doivent être achevés dans un délai de temps prédéterminé. Dans un projet Agile, chaque activité est limitée dans le temps. Toutes les activités liées au développement sont «configurés» pour répondre aux besoins propres à chaque projet, et une durée "fixés" pour eux afin qu'ils puissent être accomplies dans un délai imparti. Cela garantit que le projet ne "glisser-on" pas et d'étendre indéfiniment. Les coûts de développement engagés alors que le projet est en cours d'élaboration peuvent être correctement et "rentable" contrôlée, afin que le projet ne devienne pas "trop" cher et difficile à se permettre financièrement.

Principes et les caractéristiques Agile
Cadre Agile diffère considérablement par rapport à linéaire traditionnelle ou méthodologie Waterfall. Agile, le développement de projet est réalisé dans des éclats courts d'activités plutôt que dans les étapes qui doivent être «achevé» l'un après l'autre.

Les principales caractéristiques comprennent Agile:   

• Équipes de développement inter-fonctionnelles, comprenant des développeurs, programmeurs, testeurs, personnel d'AQ, rédacteurs techniques, des analystes de systèmes, etc travailler ensemble comme une seule équipe composite grâce à des efforts de collaboration, offre et de partager des idées et de s'entraider au cours du processus de développement.
• Travailler dans des cycles courts de développement au rythme rapide, avec des objectifs ciblés - Le développement itératif.
• Livrable productivité à la fin des cycles de développement itératifs - Le développement incrémental. La fonctionnalité ne cesse de «croissance» à travers des cycles de développement jusqu'à ce que la totalité de l'application, système, ou le produit est mis au point.
• Communications humaines et la participation a priorité sur l'autorité de gestion et la délégation du travail.
• La transparence et la visibilité de la progression de l'équipe de Total pour projeter les utilisateurs propriétaires, les intervenants et les utilisateurs finaux.
• Commentaires et suggestions aider à s'auto-corriger et offrent de nouvelles voies et moyens pour mener à bien plus rapide, plus efficace, et le développement fiable.

Une caractéristique importante de tous les cadres Agile est que les cadres sont indépendants de la nature du projet qui sera développé à-dire le cadre ne dépend pas de la plate-forme ou l'environnement utilisé pour élaborer le projet de logiciel particulier. L'architecture ou de conception peuvent varier, et pourrait être n'importe quoi. L'aspect important est qu'un cadre Agile doit être mis en œuvre dans le premier projet, et ses avantages prévalu par la suite. S'il vous plaît visitez http://en.wikipedia.org/wiki/Agile_software_development.

Quel est mêlée Agile?  

Scrum, brièvement, est un cadre "léger" Agile, largement utilisé pour développer et fournir des produits logiciels "réalistes", très souvent, et sur ​​une base cohérente. Les logiciels peuvent aller de la mise au point de nouveaux procédés de Web et de systèmes, de solutions de jeux, plugins, applications mobiles, sites de commerce électronique, les portails d'entreprise, développement de thèmes WordPress, RAD projets (Rapid Application Development), oups (Programmation Orientée Objet) projets, solutions de CAO / FAO de rédaction, les services de programmation et de configuration portuaires, développement web et des solutions d'interfaçage de la plate-forme, etc Scrum adhère à tous les principes agiles et les caractéristiques décrites ci-dessus car le cadre est "hérité" de Agile lui-même.

Scrum offre une nouvelle, et une meilleure façon de gérer des projets de logiciels. Il ya beaucoup de raisons techniques pour lesquelles Scrum est populaire et pourquoi de nombreuses entreprises Fortune 500 entreprises préfèrent utiliser le cadre de leurs objectifs de développement du projet. Tout en étant introduit à Agile Scrum, une question qui vient par inadvertance à son esprit est pourquoi Scrum si populaire? Pourquoi est-il tellement "hype" sur Scrum? Est-ce que Scrum offrir une formule magique, qui peut faire des merveilles pour votre projet et le développement de logiciels? Pourquoi une organisation qui a été la suite d'une méthodologie de développement particulier, et se sent à l'aise si, devrait passer à Scrum? Il s'agit d'un article distinct qui porte entièrement sur la raison pour laquelle vous devriez opter pour Scrum. Le point est, cet article l'accent sur ​​l'explication de mêlée à des personnes qui sont nouveaux sur le sujet, et n'ont absolument aucune idée de ce que le cadre est tout au sujet, et ce qu'il peut «faire» pour vous. Des efforts ont été faits pour expliquer que Agile Scrum est applicable à presque tous les types de développement de logiciels, et possède certaines caractéristiques qui rendent le cadre très populaire ainsi que "puissant".

Comment fonctionne Scrum?  

Le processus Scrum réel peut s'avérer difficile à comprendre, dans un premier temps, pour les débutants Scrum. Même si la mise en œuvre Scrum n'est pas difficile, les gens ont besoin de comprendre et de se familiariser eux-mêmes de ce qui est incrément du produit, et comment il se fait au cours du processus Scrum. Le deuxième aspect est d'apprendre à connaître les événements Scrum. Les réunions spéciales, appelées «événements» sont importants pour le suivi de l'activité de développement, et l'analyse de la fiabilité et de l'efficacité de la fonctionnalité développée par l'équipe. Ils aident également à obtenir les commentaires des membres de l'équipe ainsi que les porteurs de projets afin que la valeur de l'entreprise du projet n'est pas affectée, et maintenus en tout temps - même si le produit est en cours d'élaboration. Il est utile d'avoir une "vue d'ensemble" du processus en premier.

 

1. conception du projet - Une idée!  

Tous les projets, qu'il s'agisse de développement de logiciels, ou autrement, commencent par une «idée». Les projets sont développés sur des besoins. Un projet est prévu pour répondre à un besoin particulier ou atteindre un certain objectif. En outre, chacun des résultats du projet dans «quelque chose» dans un laps de temps spécifique - un projet ne peuvent pas prolonger indéfiniment. Il est important ici de faire la différence entre un «projet» et un «programme». Les programmes sont généralement longs appelés, et peuvent même durer des années, à la différence des projets qui ont une durée de vie relativement courte et le dernier pour une brève période, allant de quelques mois à un an même.

   

En règle générale, une personne ou un groupe de personnes se rendent compte qu'il vaut la peine de mettre dans les efforts et les ressources, et de développer «quelque chose» de sorte que «l'autre chose» peut être facilement accompli ou fait usage. Le «quelque chose» est le produit, et le "autre chose" est la solution que le projet est censé fournir. Cette étape de développement du projet implique beaucoup de discussion et des sessions de brainstorming, où le produit est envisagé et «si plus".

Scrum ne figure pas au cours de cette étape. Cependant, la vision vu par les maîtres d'ouvrage, peut, ou peut affecter la manière dont Scrum est mis en œuvre dans le projet, à l'avenir. C'est parce que la nature du produit à développer peut exiger Scrum être configuré d'une certaine manière à obtenir des résultats positifs du projet.

2. version du projet - Mise en route avec le projet de logiciel
Une fois que le projet est «la pensée de« la prochaine étape logique est de travailler sur les choses sérieuses sur la dynamique du projet - l'objectif du projet, la définition du produit, comment le projet devrait idéalement livrer le produit, de quelle manière, ce qui devrait être la «force» de l'équipe, combien de membres de l'équipe, etc

Processus de développement Scrum ne vient pas dans l'image même lors de cette étape. La documentation relative à la création du projet et «tout» concernant le produit à développer est finalisé - en noir et blanc. Scrum ne préconise pas une documentation complète. Vous n'avez pas à préparer schémas détaillés des flux de système et de vastes structures de conception pour commencer avec le développement Scrum. Une idée de base suffira, et vous ne devez passer beaucoup de temps et les efforts qui vous aideront à vous "ouvertes" à l'activité de développement réel. Juste assez d'informations et les spécifications à développer certaines des caractéristiques les plus importantes de produits.

La libération de projet est assisté par le "Product Owner" - la personne qui fonctionne comme un gestionnaire de projet dans le projet Scrum, le Scrum Master qui à l'étranger que Scrum est correctement mis en œuvre et suivi par l'équipe alors que le projet est en cours d'élaboration, et les parties prenantes ou maîtres d'ouvrage qui fait parrainent le projet.

3. Création du backlog de produit (de la liste des caractéristiques du produit) - Définir les caractéristiques des produits et fonctionnalités
Le processus de développement Scrum commence par la création d'une liste de contrôle contenant toutes les caractéristiques et les fonctionnalités requises pour créer le produit dans sa totalité. En termes simples, l'ensemble du produit, qui existent actuellement sur le papier comme «imaginé» par les parties prenantes et les maîtres d'ouvrage, est «décomposé» en ses éléments constitutifs, composé de caractéristiques individuelles et de la fonctionnalité. Le produit est réfléchie, et systématiquement, décomposée de telle sorte que chaque composant individuel peut être développé, testé, et éventuellement intégré à d'autres composants logiciels ou les fonctionnalités développées par l'équipe au cours des jours. Développé individuellement fonctionnalités peuvent éventuellement «donner naissance» à un produit de travail lorsqu'ils sont intégrés ou assemblés par la suite.

Chaque caractéristique ou élément de liste est connu comme un "objet de l'arriéré de produit" ou un "user story" dans un langage simple. Par conséquent, l' backlog de produit ou la liste principale est fondamentalement composé d'éléments produits du carnet de commandes ou des témoignages d'utilisateurs. L'histoire de l'utilisateur représente une caractéristique du produit, et est développé individuellement par les membres de l'équipe au cours du processus de développement - les sprints quotidiens. Chaque histoire peut être minutieusement défini. La description, les critères d'acceptation (Points qui doivent être "remplies" ou satisfaits avant que l'histoire peut être considéré comme connu autant de succès), son importance dans le projet, et la manière dont il est censé être intégré dans le produit final, etc sont mentionnés pour chaque user story.

Une fois la liste des fonctionnalités est créé, il est disposé en fonction de l'importance de chaque user story dans le backlog de produit. Importants témoignages d'utilisateurs sont disposés dans le "top" partie de la liste, des histoires moins importants dans le milieu, et les fonctions moins importantes et la fonctionnalité dans la partie inférieure.

4. réunion de planification Sprint - Planifier la façon de développer les caractéristiques du produit
Les fonctions des produits du carnet de commandes que la principale «colonne vertébrale» de toutes les activités liés au développement de Scrum. Une fois qu'il est "développé" par le propriétaire du produit et les parties prenantes, l'activité de développement réel peut commencer. Une réunion spéciale appelée "Planification de Sprint"Réunion se tient à lancer l'activité de développement. La réunion est suivie par l'équipe de développement, en plus de la propriétaire du produit "PO" et le scrum master "SM".

La réunion se déroule en deux parties. Dans la première partie, le propriétaire du produit sélectionne quelques-uns des témoignages d'utilisateurs ou les caractéristiques du produit le plus important de la partie supérieure de la backlog de produit, et les transfère à une liste temporaire appelé «Carnet de Sprint" à des fins de développement. Lors de la réunion, le propriétaire du produit profite de l'occasion pour expliquer chaque user story dans les détails aux membres de l'équipe - comment les histoires d'utilisateurs devraient être idéalement développés, et les activités de l'équipe doit effectuer afin que chaque histoire peut être marqué terminé avec autant de succès.

Au cours de la deuxième moitié de la rencontre, l'équipe de développement analyse le backlog de sprint et distribue chaque histoire aux membres de l'équipe. Dans la pratique, les membres de l'équipe décident à l'unanimité de savoir qui doit prendre quelle histoire en fonction de leurs compétences de développement et les niveaux d'expérience. Simple et facilement des éléments développables sont donnés à des histoires moins expérimentés ou «plus frais», tandis que difficile, ou plus complexes sont repris pour le développement par les programmeurs ou développeurs plus expérimentés et supérieurs.

5. Les sprints quotidiens - Développer les caractéristiques du produit
C'est le principal domaine d'activité dans Scrum. Le produit est entièrement développé en «bits» et «morceaux» à travers les cycles quotidiens de sprint. Un cycle de sprint n'est rien mais une collection de travail ou jours de «développement» au cours de laquelle les membres de l'équipe siègent effectivement en face d'un PC et de développer les fonctionnalités ou les caractéristiques du produit. Le cycle de sprint est temps en boîte et ne devrait pas prolonger son délai.

Chaque élément inclus dans le backlog de sprint lors de la réunion de planification de sprint devrait être développée alors que le sprint est actuellement en cours. Une brève réunion appelée «réunion Scrum Daily" est maintenue pour une durée maximale de 15 minutes chaque jour devant les membres de l'équipe commencent leur travail. Le but de la réunion est de se faire une idée sur la façon dont beaucoup de travail a été complété par chaque membre de la veille, et ce que chaque membre se propose de faire «aujourd'hui». Si un membre de l'équipe est confrontée à des problèmes ou des problèmes, il peut être mentionné lors de la réunion, et le maître de mêlée veillera à ce que le problème est vite résolu.

En Scrum, les sprints quotidiens peuvent généralement durer de 2 semaines à un maximum d'un mois. La durée du sprint est décidé au cours de la deuxième étape - la libération de projet - et il ne devrait pas être étendu en aucun cas - même si l'une des histoires d'utilisateurs dans le backlog de sprint n'ont pas été mis au point, ou dont le développement est incomplet.

6. avis Sprint - Contrôle et vérification de la productivité (c'est le développement OK?)
Scrum insiste sur le développement de la fonctionnalité «livrable» à la fin du cycle quotidien de sprint. Chaque histoire utilisateur développée pendant le sprint quotidien est vérifiée par le propriétaire du produit et vérifié pour sa fiabilité, les niveaux d'acceptation, et si elle est "sans erreur". Dans Scrum, il est très important de fournir erreur fonctionnalités gratuites - chaque histoire d'utilisateur doit être correctement testé pour une régression, et s'il répond aux critères d'acceptation liés à son développement.

Juste après la fin du cycle quotidien de sprint, une réunion est immédiatement organisée pour examiner le développement réalisé par l'équipe. Il est important de faire la distinction entre les sprints quotidiens et le cycle de sprint. Le sprint quotidien est l'activité de développement réalisé par toute l'équipe sur une journée de travail particulier. Beaucoup de ces «sprints quotidiens" se combinent pour former le "Daily Sprint Cycle", aussi connu comme le «produit du cycle progressive» Agile. La réunion se tient à la fin du cycle supplémentaire de produit - le cycle quotidien de sprint. Il est principalement assisté par le propriétaire du produit, le maître de mêlée, et les membres de l'équipe. Il n'est pas obligatoire pour les parties prenantes à participer à cette réunion. Ils peuvent choisir d'y assister s'ils le désirent.

L'objectif principal de cet événement, ou plutôt la réunion, est de vérifier si les caractéristiques ont été développées par l'équipe selon le plan de la production, et si la fonctionnalité a des défauts de «fabrication». Chaque fonctionnalité doit être entièrement testé pour les défauts de l'équipe avant de le présenter à cette réunion. Le propriétaire du produit vérifie si la fonction est exempt d'erreurs et vérifie si elle satisfait aux critères d'acceptation qui lui sont liés. C'est une sorte de chèque «finale» réalisée avant de présenter le développement des parties prenantes et les porteurs de projets dans le sprint prochaine réunion rétrospective. Lors de la réunion, le propriétaire du produit indique l'équipe comment elle peut améliorer son travail et offrir encore une meilleure productivité en utilisant des pratiques et des normes de programmation plus efficaces.

7. Sprint rétrospective - Finalisation de la fonctionnalité du produit et de contempler encore meilleurs
Agile Scrum préconise la participation des clients. Le client est une entité très important dans Scrum, et a le dernier mot en ce qui concerne le développement des caractéristiques du produit est concerné. Le manifeste Agile souligne principalement sur ​​la participation et la livraison d'incréments de produits assortis de délais client parce que ces deux aspects sont très importants pour le développement de projets couronnés de succès. Un client "satisfait" souvent "revient" à développer plus de projets depuis les projets réussis aider le client à obtenir des marges bénéficiaires plus élevées.

La rétrospective est l'occasion pour toute l'équipe de démontrer sa productivité devant les intervenants et les clients. En plus le propriétaire du produit, scrum master, l'équipe de développement, la réunion peut également être assisté par les utilisateurs finaux, le personnel de l'équipe technique, les fournisseurs, les distributeurs, et même d'autres employés puisque le but principal de la réunion est de se prévaloir de la rétroaction des individus et entités étroitement liées avec le marché, et qui ont une bonne connaissance en ce qui concerne ce que les caractéristiques des produits sont susceptibles de "marquer" sur le marché une fois que le produit est lancé, et ce qui peut aider le produit à «vendre».

La rétrospective propose aussi une chance pour toute l'équipe ainsi que le client à réfléchir sur le processus de développement, et voir ce que l'on pourrait faire pour rendre le produit meilleur. Des discussions sont menées pour déterminer la vitesse à laquelle des témoignages d'utilisateurs sont actuellement en cours d'élaboration par l'équipe, et ce de nouveaux procédés ou méthodes doivent être mis en place pour accélérer le processus.

Abonnez-vous à la version gratuite permanente de l'outil de gestion de projet Quickscrum pour avoir une idée sur la façon dont l'outil fonctionne et ce qu'elle a à offrir. Pour les personnes nouvelles dans le processus de mêlée, il pourrait être difficile de comprendre comment cadre Agile est mis en œuvre dans des projets en direct. Si vous voulez en savoir plus sur mêlée et sa mise en œuvre, et le désir de développer des projets dynamiques et rentables logiciels, s'il vous plaît envoyez-nous un e-mail à support@quickscrum.com - nous pouvons vous envoyer mêlée documentation de formation pour vous aider à savoir plus sur mêlée .