Les entreprises et les organisations de développement informatique ont utilisé Agile à stimuler leur activité de développement et de réaliser des projets limités dans le temps. Comme aujourd'hui, le cadre Agile est populairement utilisé pour réduire la dette technique et contrôler régression. Le cadre fournit des fonctionnalités grâce à laquelle incréments de produits peuvent être servis sur une base cohérente et user stories livrables sont livrés à la fin d'itérations de sprint. Si beaucoup a été discuté sur les livrables dans Agile, livrable le plus important est une version du logiciel de travail de bug construit en utilisant le code bien conçu - le "code de base". Il est très important de fournir la valeur du projet requis par bien conçu, logique, et sans bug code. En mêlée Agile, l'équipe de cross de développement fonctionnel devrait idéalement présenter des vertus telles que la responsabilité, pragmatisme, professionnalisme, et même fierté, tout en offrant la productivité durant les sprints quotidiens. Ces valeurs permettent de vérifier la dette technique et de renforcer les valeurs de l'entreprise associés à des histoires d'utilisateurs.
La portée et les types de projets de logiciels qui peuvent être développées en utilisant Scrum
Tout en discutant de tout projet basé IT, les besoins de développement de logiciels et la portée des phases de développement du projet restent généralement les mêmes, et ne change pas grand chose quel que soit le type de projet de logiciel à développer. Les différents types de projets qui peuvent être développés en utilisant Scrum comprennent:
La portée et les types de projets de logiciels qui peuvent être développées en utilisant Scrum
Tout en discutant de tout projet basé IT, les besoins de développement de logiciels et la portée des phases de développement du projet restent généralement les mêmes, et ne change pas grand chose quel que soit le type de projet de logiciel à développer. Les différents types de projets qui peuvent être développés en utilisant Scrum comprennent:
- Une application / système client-serveur
- Une application / système autonome
- HTML / DHTML / XHTML, ASP, PHP, Joomla, DotNetNuke et basé sur le Web le développement du site / portail
- Java, VB Script, ou tout autre développement de script basé sur
- Android / Symbian / iOS ou tout autre développement des applications mobiles, etc
Alors qu'est-ce qui peut augmenter la "agilité" dans Agile et livrer des projets de logiciels à succès?
Code bien conçu et fabriqué
La plupart des entreprises informatiques estiment que sur le plan pratique, il est presque impossible, ou très difficile, pour développer bug code libre offrant des fonctionnalités robustes pour les utilisateurs finaux. Des entreprises de TI ont tendance à développer des projets dans des conditions de stress lié extrêmes, et il est important de respecter les dates de sortie et les délais des clients. L'équipe de développement, dans la plupart des cas, met fortement l'accent sur l'achèvement du projet et dans le délai prévu, et cela devient le point central de leur activité de développement. La précipitation dans l'élaboration du projet laisse souvent très peu à tester les fonctionnalités du logiciel et les fonctionnalités d'une manière appropriée. Cela conduit à la dette technique. La société peut même avoir pour "retirer" la version du logiciel si les fonctionnalités de base ne fonctionnent pas correctement, et cela peut conduire à des frais généraux de développement pléthorique. Si le re-développement ne parvient toujours pas à fournir la valeur du projet pour les utilisateurs finaux, la dette technique ne cesse d'augmenter. Si ce n'est pas cochée, il peut devenir impossible de contrôler la dette technique et recouvrer les coûts de développement du projet.
Agile aide à réduire la dette technique et contrôler régression. Lorsque la fonctionnalité sous la forme de récits utilisateur est développé par l'équipe, il est largement testé par rapport aux critères d'acceptation qui lui sont liés. Lors de la rétrospective de sprint, le propriétaire du produit détermine le développement en ce qui concerne la définition de "Done" et avalise l'histoire si elle satisfait au critère. La fonctionnalité du produit ainsi, "livrable" et sans bug est assurée par des sprints Agile. C'est ainsi que la régression est principalement adressé à l'aide Agile. En outre, le développement de sprint est effectuée sur la base de la rétroaction profité des utilisateurs finaux et les parties prenantes. L'équipe de développement est en mesure de se concentrer sur la fourniture de la fonctionnalité de base, tout en développant les récits utilisateur. Cela a directement et indirectement, contribue à vérifier la dette technique et garder le contrôle.
Les premières réactions et fiable
Agile doit précoce et les informations fiables pour produire des incréments de produits réussis. Le retour devrait également être compatible. L'une des principales causes de préoccupation dans le développement informatique est la disponibilité des informations cohérentes et fiables auprès des utilisateurs finaux. Le développement effectué peut être soumis à des tests de qualité rigoureux et de référence. Toutefois, lorsque la libération est déployé pour les utilisateurs finaux sur le marché, ils peuvent souvent faire valoir en ce qui concerne la nature des fonctionnalités offertes. La fonctionnalité peut être bien conçu, mais ne parviennent pas à livrer exactement ce que l'utilisateur final peut effectivement désir ou le besoin. Si tel est le cas, la faute n'incombe pas à l'équipe de développement. Il se trouve en fait dans la façon dont la fonction ou fonctionnalité particulière est compris et envisagés par le propriétaire du produit. Le résultat est une augmentation de la dette technique, puisque la même histoire doit être re-développé conformément aux exigences précises suggérées par les utilisateurs finaux.
Les premières réactions dans Agile empêche que cela se produise. Quand une fonctionnalité particulière est développée sous la forme d'un récit utilisateur par l'équipe, il est approuvé par le PO pendant les séances rétrospectives (la réunion rétrospective sprint), qui vérifie, et vérifie si elle est techniquement c'est à dire qu'il satisfait l'acceptation critères. Par la suite, les parties prenantes examinent la fonctionnalité approuvée par le PO, et s'assurer de sa valeur d'entreprise à savoir combien importante de l'histoire est à l'utilisateur final et combien il contribue à la «valeur» du produit. L'histoire est en fait considéré comme "livrable" seulement après que les intervenants approuvent pour sa valeur commerciale. Cette fonctionnalité empêche Agile dette technique de plus en plus depuis les utilisateurs finaux s'impliquer dans le projet à un stade précoce et d'approuver le développement effectué pour savoir si elle répond à leurs critères, et est en effet utile pour eux.
Équipes de programmation professionnels
L'équipe de développement constitue la base de toutes les activités de développement Agile. À bien des égards, il est l'épine dorsale de tout le cadre Agile. Une équipe transversale fonctionnelle, expérimenté et capable d'exécuter des sprints succès peut aller un long chemin à faire des projets Agile succès. Avec Scrum et Agile discussions relatives s'adressant principalement à la propriétaire du produit et le scrum master, il est tout aussi important de discuter de l'équipe de développement sans laquelle, l'existence de la PO et scrum master devient superflu. La productivité offert par l'équipe de développement influe directement sur la réussite du projet. Si l'équipe est bien collaboré, part opinions et points de vue, et se sent confortable réalisation des sprints quotidiens, cela conduirait à incrément de produit fiable et cohérente. L'une des principales questions pourquoi l'équipe ne parvient pas à livrer des témoignages d'utilisateurs livrables, c'est que l'équipe perd souvent se concentrer face à des problèmes techniques et a du mal à trouver des solutions acceptables. Un autre facteur important qui influe sur l'acceptation des histoires développées par l'équipe est un manque de compréhension claire de ce que l'utilisateur final s'attend vraiment à partir des caractéristiques du produit. Il est très commun pour l'équipe de développement de fonctionnalités qui sont rejetés par les utilisateurs finaux après le logiciel est déployé tout simplement parce qu'il ne fonctionne pas de la manière on le souhaite. En réalité, l'équipe n'est pas à un défaut, car il suit le plan de développement. Ce scénario est très fréquent dans le cas des méthodes cascade dans laquelle l'activité de développement est réalisée en plusieurs étapes.
Agile offre les informations fiables et à jour qui permet à l'équipe de comprendre les besoins des utilisateurs finaux et exercer l'activité de développement, conformément à la rétroaction reçue des intervenants et les utilisateurs finaux. Si la fonctionnalité ne satisfait pas aux utilisateurs finaux, il est rejeté et repris pour le développement de nouveau. Ce contrôle grandement l'augmentation de la dette technique puisque le développement est "contesté" immédiatement après avoir effectué, et des témoignages d'utilisateurs ne se déploie à développer à nouveau plus tard.
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'il a à offrir.
