Share
L'objectif principal de Scrum est l'organisation et la gestion de projet., Maigre consiste davantage à optimiser les processus afin de produire rapidement des produits de qualité. Cela peut être votre première étape vers l’adoption des principes Agiles, ou bien votre équipe peut évoluer, lorsque Scrum ne suffit pas. Je vous invite à lire l'histoire de mon équipe et à expliquer comment nous sommes passés de Scrum à un processus de développement plus lean-ish..
Le lean est un ensemble de principes définis par l'industrie japonaise de la construction automobile dans les années 1980. L’ingénieur qualité de Toyota, John Krafcik, a inventé le terme, tout en observant les processus et les outils utilisés pour éliminer les déchets dans la production automobile de masse. Ce n'est qu'en 2003 que Mary et Tom Poppendieck ont introduit le Lean en tant que processus de développement logiciel dans leur livre Lean Software Development: An Agile Toolkit..
Tandis que Scrum est un ensemble de règles et de rôles, le Lean est un ensemble de principes et de concepts avec une poignée d'outils. Les deux sont considérées comme des techniques agiles et partagent la même idéologie de la rapidité de livraison, tout en réduisant les défauts et les erreurs. J'insiste toujours sur la capacité d'adaptation d'Agile, mais je ne peux pas ignorer le fait que Scrum se présente comme un ensemble de règles obligatoire. En fait, les fans religieux de Scrum criaient au blasphème de ne pas suivre les règles de Scrum à la lettre..
Lean, en revanche, est plus ouvert; ses adeptes présentent le processus comme un ensemble de recommandations hautement adaptables.
Cela encourage l'équipe ou l'entreprise à prendre des décisions, et il s'adapte aux décisions et aux surprises quotidiennes que votre équipe et votre entreprise doivent affronter..
Au fur et à mesure que mon équipe mûrait et exploitait Scrum, nous avons eu le sentiment que certains aspects nous ont retardés. Nous sommes devenus une équipe assez disciplinée et homogène. Certaines réunions ne nous convenaient plus et nous avons commencé à nous rendre compte que les réunions quotidiennes n'étaient pas efficaces. Nous avons appris que les problèmes devaient être résolus plus rapidement et nous avons ressenti le besoin d'éviter ces procédures qui nous retenaient..
Nous sommes passés.
Lean expose deux concepts majeurs, mais les idées principales sont: éliminer le gaspillage et améliorer le flux de travail.
Si quelque chose va se casser, il le sera vendredi.
Tout ce qui fait obstacle à la production est un déchet. Cela inclut le temps perdu, les matériaux restants et une force de travail inutilisée. Les défauts du produit final sont des déchets; cela gaspille du temps pour les réparer, gaspille de l'argent pour les remplacer et des ressources pour trouver d'autres solutions.
Le concept de déchet se traduit bien dans le monde du développement logiciel. Les déchets peuvent être décrits par des retards de livraison, des bugs et des programmeurs n'ayant rien à faire (ne confondez pas ceci avec "les programmeurs doivent programmer huit heures par jour sans pause et youtube").
Le concept Lean de Toyota se concentre sur le flux de production. Dans une usine de production, le flux est une chaîne de procédures qui transforment les matières premières en leurs produits finis. Ces procédures peuvent être très différentes les unes des autres et prendre beaucoup de temps, mais elles peuvent toutes être améliorées pour les rendre plus efficaces. C'est une bataille constante pour trouver et améliorer les goulots d'étranglement dans le processus.
Un flux idéal est un flux dans lequel chaque étape prend le même temps et les mêmes efforts pour produire la même quantité de produits..
Cela ne signifie pas que chaque processus devrait coûter la même somme d'argent, mais chaque processus devrait pouvoir être exécuté avec la même facilité..
Ironiquement, Scrum a été l’outil qui nous a finalement amenés à réaliser le gaspillage de notre projet. Alors que nous adhérions à Scrum pur dans certains domaines de notre production, nous avons commencé à identifier des bugs et / ou des retards que nous pourrions facilement éviter en adoptant une approche différente..
Nous en savions peu sur Lean à ce moment-là. Nous avons lu quelques articles sur le sujet, mais nous avons fait la mauvaise chose et les avons ignorés, car nous étions tellement concentrés sur notre processus Scrum. Nous étions presque convaincus que Scrum était le Saint-Graal, mais notre "mitrailleuse Scrum" a commencé à s'égarer. Nous devions ouvrir nos esprits.
Pour le développement de logiciels, les principes de Lean ont été adaptés aux sept suivants:.
Le passage de Scrum à Lean était réellement libérateur.
En développement logiciel, vous pouvez rechercher et éliminer les déchets en reconnaissant les éléments à améliorer. De manière pragmatique, tout ce qui ne représente pas une valeur directe pour le client est un gaspillage. Pour donner quelques exemples: gaspillage est un bug, un commentaire dans le code, une fonctionnalité inutilisée (ou rarement utilisée), des équipes en attente sur d’autres équipes, prenant un appel personnel… vous avez l’idée. Tout ce qui vous retient, votre équipe ou votre produit est un gaspillage, et vous devez prendre les mesures appropriées pour le supprimer..
Je me souviens que l’un de nos problèmes était la nécessité fréquente de réagir plus rapidement que deux sprints. Développer dans les sprints et respecter les règles de Scrum vous empêche de changer les histoires assignées au sprint actuel. Une équipe doit s'adapter lorsqu'un utilisateur trouve un bogue et a besoin d'une solution ou lorsque le client le plus important souhaite une fonctionnalité pouvant être facilement complétée en deux jours. Scrum n'est tout simplement pas assez flexible dans ces cas.
Accorder une grande valeur à l'éducation.
Vous avez des déchets et vous voulez naturellement moins de déchets à l'avenir. Mais pourquoi y a-t-il des déchets? Cela vient probablement d'un membre de l'équipe qui ne sait pas trop comment aborder un problème particulier. C'est d'accord; personne ne sait tout. Accorder une grande valeur à l'éducation.
Identifiez les domaines qui nécessitent le plus d'amélioration (connaissances) et commencez la formation. Plus vous et votre équipe en savez, plus il est facile de réduire les déchets..
Par exemple, l’apprentissage TDD (Test Driven Development) peut réduire le nombre de bogues dans votre code. Si vous avez des problèmes pour intégrer les modules de différentes équipes, vous voudrez peut-être savoir ce que Intégration continue signifie et met en œuvre une solution appropriée.
Vous pouvez également apprendre des commentaires des utilisateurs. Cela vous permet d'apprendre comment les utilisateurs utilisent votre produit. Une fonctionnalité fréquemment utilisée ne peut être accessible qu'en naviguant dans cinq menus. C'est un signe de gaspillage! Vous pouvez initialement imputer de tels gaspillages aux programmeurs et aux concepteurs (et vous avez peut-être raison), mais les utilisateurs ont tendance à utiliser votre logiciel de manière inattendue. Apprendre de vos utilisateurs aide à éliminer ce type de gaspillage. Cela vous aide également à éliminer les exigences erronées ou incomplètes. Les commentaires des utilisateurs peuvent conduire un produit sur des chemins que vous n'auriez jamais envisagés autrement.
À un moment donné, mon équipe a découvert que certains modules auraient pu être mieux écrits si nous en savions plus sur le domaine au début. Bien sûr, il n’ya aucun moyen de revenir en arrière et la réécriture d’une énorme quantité de code n’est pas pratique. Nous avons décidé d'investir du temps pour en apprendre davantage sur le domaine lorsque nous avons été chargés d'une fonctionnalité plus complexe. Cela peut prendre quelques heures, voire plusieurs semaines, selon la complexité du problème..
Chaque décision a un coût. Ce n'est peut-être pas immédiat et important, mais le coût est là. Le report des décisions vous aide à vous préparer pleinement aux problèmes auxquels vous devez faire face. L’exemple le plus courant de décision retardée est probablement lié à la conception de la base de données..
Les décisions ne doivent pas nécessairement être de nature technique; La communication avec les clients vous aide à prendre des décisions qui ont une incidence sur votre approche des fonctionnalités de vos produits..
Mais les utilisateurs ne savent pas toujours ce qu'ils veulent. En reportant les décisions relatives aux fonctionnalités jusqu'à ce que les utilisateurs aient réellement besoin de la fonctionnalité, vous obtiendrez plus d'informations sur le problème et pourrez fournir les fonctionnalités nécessaires..
Choisissez la méthodologie Agile qui fonctionne le mieux pour vous et votre équipe..
Il y a quatorze ans, l'équipe a décidé de stocker la configuration de l'application dans une base de données MySQL. Ils ont pris cette décision au début du projet et l’équipe actuelle (la mienne) a un fardeau difficile à porter. Heureusement, ce produit n'est plus en développement, mais nous devons le maintenir de temps en temps. Ce qui devrait être une tâche simple finit par être un monument énorme.
Du côté positif, nous avons tiré les leçons des erreurs de nos prédécesseurs. Nous prenons les décisions de programmation, d'architecture et de projet le plus tard possible. En fait, nous avons appris cette dure leçon avant d’adopter Lean. Écrivez du code ouvert et découplé et écrivez un modèle persistant - et indépendant de la configuration. C'est certes plus difficile à faire, mais au final vous fait gagner beaucoup de temps dans le futur.
Il y a quelque temps, nous avons ajouté une fonctionnalité à notre produit qui compresse les données sur le disque. Nous savions que cela serait utile et voulions l'ajouter à notre produit le plus rapidement possible. Nous avons commencé avec une fonctionnalité simple, évitant les décisions concernant les options et la configuration jusqu'à une date ultérieure. Les utilisateurs ont commencé à fournir des commentaires après quelques mois et nous avons pris ces informations pour prendre des décisions concernant les options et la configuration de la fonctionnalité. Nous avons modifié la fonctionnalité en moins d'une journée et aucun utilisateur ne s'est plaint ou n'a demandé plus de fonctionnalités. C'était une modification facile à faire; nous avons écrit le code en sachant que nous ferions une modification à l'avenir.
Nous vivons dans un monde en constante évolution. Les programmes que nous écrivons aujourd’hui sont destinés à des ordinateurs qui seront obsolètes dans deux ans. La loi de Moore est toujours valable et continuera à l'être.
La rapidité de livraison est tout dans ce monde en évolution rapide.
Livrer un produit en trois ans vous place derrière le peloton. Il est donc primordial de donner de la valeur à vos clients le plus rapidement possible. L’histoire a prouvé qu’un produit incomplet avec une quantité acceptable de bogues est mieux que rien. De plus, vous avez des commentaires précieux de l'utilisateur.
Notre société avait un rêve: livrer après chaque sprint. Naturellement, cela n’est pas pratique dans la plupart des cas. Nos utilisateurs ne souhaitaient pas un produit mis à jour toutes les semaines ou tous les mois. Ainsi, alors que nous nous efforçons de publier chaque version de notre code, nous ne le faisons pas. Nous avons appris que "vite" est ce que l'utilisateur perçoit - pas ce que nous sommes physiquement capables de faire. Dans l'industrie de nos produits, rapide signifie mises à jour régulières tous les quelques mois et corrections de bugs critiques en quelques jours. C'est ainsi que nos utilisateurs perçoivent "rapidement"; d'autres types de produits et d'industries ont des définitions différentes de "rapide".
Les programmeurs étaient autrefois des ressources enfermées dans des cellules, effectuant silencieusement leurs tâches pour leur entreprise. C’était l’image de marque d’un programmeur à la fin des années 90, mais ce n’est certainement plus le cas.
L’histoire a démontré que cette approche et la gestion de projet en cascade traditionnelle ne conviennent pas aux logiciels..
C'était tellement grave à un moment donné que seulement 5% environ de tous les projets de logiciels étaient réellement livrés. Des entreprises et des produits d'un million de dollars échouaient dans 95% des cas, entraînant des pertes énormes.
Lean a constaté que les programmeurs démotivés étaient à l'origine de ce gaspillage. Mais pourquoi ce manque de motivation? Eh bien, les programmeurs et les équipes de développement n'ont pas été écoutés. La société a défini les tâches et microgéré les employés qui étaient uniquement perçus comme des ressources produisant du code source..
Lean encourage les gestionnaires à écouter les programmeurs, et les programmeurs à enseigner à leurs gestionnaires le processus de production de logiciels. Cela encourage également les programmeurs à travailler directement avec les clients et les utilisateurs. Cela ne signifie pas que les développeurs font tout, mais cela leur donne le pouvoir d'influencer l'évolution de la production. Étonnamment, avoir ce sentiment de "Vous connaissez cette fonctionnalité intéressante que les utilisateurs adorent? C'était mon idée!"est un facteur de motivation important.
Mais ne pensez pas que cela ne fonctionne que pour les grandes équipes; notre équipe est petite. Notre société ne compte qu'une poignée de développeurs, nous avons donc toujours été proches de nos utilisateurs. Cette relation nous a permis d’influencer notre produit au-delà de ce que nos gestionnaires auraient pu initialement envisager.
Tout ce qui fait obstacle à la production est un déchet.
L'intégrité concerne la robustesse de votre produit et c'est ainsi que les clients voient votre produit dans son ensemble. L'intégrité concerne l'uniformité, la fiabilité et la sécurité de l'interface utilisateur, ainsi que l'utilisateur se sentant en sécurité lorsque vous utilisez votre produit. L'intégrité est l'image complète que l'utilisateur crée pour votre produit. Par exemple, l'intégrité de l'interface utilisateur implique l'aspect et la convivialité entre les pages, les écrans, les modules ou même entre l'interface utilisateur de votre système et le site Web de l'entreprise..
Mais l'intégrité peut également être observée et mise en pratique au niveau du code source. L'intégrité peut signifier que vos modules, classes et autres morceaux sont écrits de la même manière. Vous utilisez les mêmes principes, modèles et techniques dans l'ensemble de votre base de code, même entre différentes équipes. L'intégrité signifie que vous devez fréquemment refactoriser votre code. C’est un travail continu et sans fin, et vous devriez vous efforcer de l’atteindre mais ne jamais l’atteindre..
Maintenir l'intégrité de notre code source est une tâche difficile. Nous nous sommes rendu compte que la recherche du code en double était la chose la plus difficile à faire, et par duplication, je ne veux pas dire quelques lignes de code en double dans la même méthode ou la même classe..
Il ne s'agit même pas de rechercher dans différents modules le même code; il s'agit de trouver ces morceaux de logique commune, de les extraire dans leurs propres classes et de les utiliser à plusieurs endroits.
Trouver une duplication logique est très difficile et nécessite une connaissance intime du code source.
Je suis sur le même projet depuis plus d'un an et je suis toujours surpris de trouver du code en double. Mais c'est une bonne chose. nous avons atteint un point où nous voyons réellement ces choses et agissons en conséquence. Depuis que nous avons commencé à supprimer activement la logique de haut niveau en double, la qualité de notre code a augmenté. Nous faisons un pas de plus vers l'intégrité.
Les utilisateurs ne savent pas toujours ce qu'ils veulent.
Lorsque vous créez votre application, vous devez prendre en compte les composants tiers sur lesquels vous comptez pour développer votre produit, ainsi que les autres tiers avec lesquels votre produit communique. Votre application doit être intégrée à la conception d'un périphérique ou au système d'exploitation d'un ordinateur de bureau. N’est-il pas plus facile d’utiliser une application qui s’intègre avec le système de notification de votre smartphone, et l’interface utilisateur reflète celle du système d’exploitation?
Oui, voir l'ensemble n'est pas si facile. Vous devez vous détacher des petits détails et regarder votre produit de loin. L'un des moments mémorables dans le développement de notre produit a été le moment où nous avons réalisé que nous devions compter sur ce que d'autres programmeurs produisent dans d'autres projets. Nous nous sommes rendu compte que le noyau du système, programmé par d’autres, est l’un de ces composants tiers sur lesquels nous comptons..
À un moment donné, ce composant tiers a changé. Nous aurions pu simplement appliquer des pansements à notre application ou emprunter la voie de la facilité et blâmer les programmeurs qui ont écrit ce composant. Au lieu de cela, nous avons pris le problème par les cornes et avons corrigé le problème dans le noyau tiers. Voir le tout et travailler avec peut être gênant, mais cela peut faire la différence entre un produit et un excellent produit.
Il existe plusieurs outils et techniques pour faire fonctionner Lean. Je préfère Kanban, un outil basé sur un tableau de bord, similaire au tableau de planification de Scrum. Imaginez un tableau Kanban en double entonnoir.
À gauche se trouve la liste interminable d’histoires que nous devons aborder. Toutes les histoires finies se superposent à droite et le responsable ou le propriétaire du produit détermine quand publier une nouvelle version, en fonction de cette liste..
Au milieu se trouve notre processus Kanban efficace. Le produit doit être stable et prêt à être publié lorsque nous terminons une histoire. Cela ne signifie pas nécessairement qu'une fonctionnalité est terminée; le produit peut avoir quelques fonctionnalités partiellement implémentées. Mais la stabilité, la sécurité et la robustesse du produit doivent être la qualité de la production.
Nous nous sommes bien débrouillés avec notre sprint actuel. C’était un lundi habituel, une journée calme avec peu d’excitation, mais nous avons commencé à voir des problèmes dès mercredi. C'est bon, ça arrive tout le temps. Pour surmonter ces difficultés, il a toutefois fallu un peu de temps. Notre responsable de produit a accepté avec nous de continuer à travailler sur la fonctionnalité actuelle et de prolonger le sprint actuel de trois ou quatre jours supplémentaires..
Vendredi est arrivé avec une surprise. Vous connaissez la règle: si quelque chose se brise, ça le sera vendredi. Un client important et potentiel avait besoin d’une certaine fonctionnalité avant de signer un contrat avec l’entreprise. Nous avons dû réagir (et vite!). Une nouvelle version était obligatoire… mais attendez! Nous sommes au milieu d'un sprint. Le produit doit être prêt à être publié à la fin du sprint. Qu'est-ce qu'on fait? Scrum dirait de faire la nouvelle fonctionnalité dans le prochain sprint, mais nous sommes déjà en retard avec le sprint actuel! C'était le moment où nous avons commencé à réaliser que nous devions penser plus petit qu'un sprint individuel. Nous devons être en mesure de nous adapter plus rapidement et de libérer plus tôt si nécessaire.
Un tableau Kanban ressemble assez à un tableau de planification Scrum, mais avec quelques ajouts afin de mieux s'adapter au processus Lean..
La première colonne à gauche est l'arriéré complet: tout ce que nous devons faire à un moment donné. À l'extrême droite, vous avez l'autre entonnoir contenant toutes les histoires terminées (mais non publiées)..
Au milieu se trouve notre processus. Ces colonnes peuvent différer selon chaque équipe et processus. Il est généralement recommandé d’avoir au moins une colonne pour les tâches suivantes et une autre colonne pour les récits en cours de développement. L'image ci-dessus montre plusieurs autres colonnes pour mieux présenter le processus de développement..
le Faire La colonne répertorie les tâches à accomplir. Ensuite nous avons Conception, où les développeurs travaillent sur la conception des histoires actuelles. La quatrième colonne est Développement, le codage réel. Finalement, le Essai la colonne répertorie les tâches en attente de révision par un autre coéquipier.
Personne ne sait tout.
Si vous comparez ce tableau Kanban à un tableau de planification Scrum, vous remarquerez immédiatement les différences évidentes. Tout d'abord, chaque colonne a un nombre, représentant le nombre maximum d'étages autorisés à résider dans cette colonne. Nous avons quatre tâches à effectuer, quatre en conception, trois en développement et deux en test. L'arriéré et les tâches terminées n'ont pas cette limite.
La valeur de chaque colonne doit être définie par l'équipe. Dans l'image ci-dessus, j'ai attribué des nombres arbitraires aux colonnes; vos chiffres peuvent différer considérablement. De plus, les chiffres ne sont pas définitifs. Adaptez les chiffres lorsque vous identifiez et supprimez les goulots d'étranglement.
L’une des qualités les plus étonnantes de Kanban et de Lean est l’importance de la collaboration et de la réallocation des efforts. Comme vous pouvez le voir au tableau, chaque colonne de notre processus contient des cartes avec des personnes. Il y a huit développeurs sur le tableau d'exemple - une équipe assez nombreuse! Le conseil présente toujours le statut actuel de qui fait quoi à un moment donné.
Selon notre conseil d'administration, trois personnes travaillent sur la conception, deux paires travaillent sur le développement et une testeur. Les histoires passent à la colonne suivante, le travail dans la colonne en cours est terminé et, selon le type de développement et d'organisation de l'équipe, le même développeur peut continuer à travailler sur la même histoire tout au long du processus..
Supposons que nous avons des personnes spécialisées. La principale fonction des trois concepteurs est donc la conception, les quatre développeurs écrivent du code et le testeur solitaire teste principalement le produit / la fonctionnalité. Si un designer termine une histoire, l'histoire passe au développement et une autre histoire de la liste des tâches à faire est ajoutée au design.
Ceci est un processus normal. Une histoire a été déplacée de la conception au développement, et maintenant le développement est à son maximum. Mais que se passe-t-il si un autre designer termine une autre histoire? Cela donne à l'équipe de développeurs quatre histoires - une situation indésirable.
Lean veut éviter la congestion. Il est interdit de déplacer une histoire dans la colonne suivante si elle dépasse le maximum de la colonne. Dans ce cas, les ressources doivent être réaffectées. le concepteur qui a terminé sa tâche doit choisir quoi faire ensuite. Sa première option consiste à extraire une autre tâche de la colonne des tâches, mais il ne peut pas le faire car il doit transmettre sa tâche nouvellement terminée à l'équipe de développement (ce qu'il ne peut pas faire). Sa seule autre option est de commencer à travailler sur une histoire de développement. Il n'est peut-être pas le meilleur développeur, mais ses efforts aideront à maintenir le flux de processus.
Si le testeur termine la dernière histoire de sa rubrique, il peut aider le concepteur dans sa tâche de développement..
C'est bien! L'équipe peut se réorganiser à la volée! Voyez-vous un gaspillage? Voyez-vous un goulot d'étranglement dans le flux? Prendre des mesures immédiates!
Une fois l’histoire complétée dans la colonne de développement, le testeur repasse à l’essai, le concepteur à la conception et les développeurs récupèrent l’histoire sur laquelle travaillent le concepteur et le testeur. Mais gardez à l'esprit que vous ne devez pas suivre cette prescription exacte; le développeur peut commencer à concevoir lorsque le concepteur et le testeur ont fini de développer leur histoire. C'est à vous!
Notre conseil est maintenant de retour à la normale.
Il est interdit de déplacer une histoire dans la colonne suivante si elle dépasse le maximum de la colonne..
J'ai regardé avec nostalgie le démantèlement de notre conseil d'administration par notre maître de mêlée. Pièce par pièce, il a déchiré notre planche bien-aimée, qui est ensuite devenue une montagne de papier froissé.
Un autre collègue entra dans la pièce, quelques énormes feuilles de papier blanc fraîchement entre les mains. Notre conseil d'administration était sur le point de renaître en quelque chose de différent, quelque chose de mieux adapté à nos besoins. Après que les feuilles de papier aient été collées au mur, nous avons commencé une réunion ad-hoc pour définir les colonnes dont nous avions besoin pour définir notre processus. Nous avons ensuite débattu du nombre d'histoires qui devraient figurer dans chaque colonne. Après que tout ait été soigneusement peint et agencé au mur, nous avons éprouvé ce sentiment étrange… tristesse pour l'ancien mais bonheur pour le nouveau.
Nous avons fait quelque chose que beaucoup de gens appellent, Scrum-Ban. Nous avons conservé certains concepts de Scrum, tels que les rôles de maître de scrum et de propriétaire de produit, et nous continuons d'estimer et d'évaluer les histoires. Mais nous nous concentrons maintenant sur le lean et le kanban, en préservant le flux, et en découvrant et en corrigeant les déchets et les goulets d'étranglement.
Le passage de Scrum à Lean était réellement libérateur. Les membres de l'équipe sont devenus beaucoup plus amicaux les uns avec les autres et nous avons compris que nous devrions offrir de l'aide dès qu'il n'y a plus rien dans notre colonne. Ce sentiment d’importance des développeurs nous a fait penser au projet dans son ensemble; nous nous soucions plus du projet que jamais auparavant.
Lean n'a pas toujours été considéré comme agile. Même aujourd'hui, certains agilistes refusent de le reconnaître comme une méthodologie agile. Mais de plus en plus, les programmeurs acceptent le Lean comme l’une des dernières méthodologies Agile..
Comme l’a souligné l’un de mes sages collègues, Lean et Kanban vous permettent de suivre cette méthodologie par vous-même. Alors, si vous êtes un développeur isolé et avez besoin d’outils pour vous simplifier la vie, essayez des outils gratuits Kanban..
Le site Web AgileZen offre un compte gratuit, vous permettant de suivre un seul projet..
J'ai trouvé que c'était l'un des meilleurs outils gratuits en ligne Kanban; Je l'utilise même tous les jours pour suivre et planifier l'avancement des articles et des cours que je fournis à Tuts +. Bien sûr, vous pouvez toujours mettre à niveau votre compte AgileZen, si vous devez suivre davantage de projets..
Dans cet article, nous avons examiné Lean et Kanban comme une évolution de Scrum. Est-ce que cela signifie que Lean est meilleur que Scrum? Absolument pas! Cela dépend des projets et des personnes avec qui vous travaillez. Comme toujours, choisissez la méthodologie Agile qui vous convient le mieux, à vous et à votre équipe..
Accentsconagua