Programmation Partie 2 : Modèles de développement et programmation Agile

1. Introduction: Bonjour, tout le monde. Et bienvenue à ce cours. Nous allons parler de modèles de développement de logiciels dans ce cours, et il est dit donc que ce qui va juste se passer, c'est quelques-uns des modèles très populaires que nous utilisons depuis très longtemps dans l'ingénierie logicielle, ainsi que que parler de cette nouvelle idée de mêlée agile et combiner, qui conduit façon plus flexible de développer des logiciels. Alors ils vont à ce cours, nous allons juste examiner différents modèles et comment ils se rapportent au monde réel et comment vous pouvez les utiliser pour mieux développer des logiciels. Maintenant, une petite note. C' est une classe de 102. Vous pouvez le prendre indépendamment par lui-même, et la plupart de cela va avoir un sens parfait. Cependant, dans le cours un a one one, nous parlons en quelque sorte des bases de toutes ces choses. Donc, si certains de ces trucs ne sonnent pas à 100%, disons clair pour vous. Peut-être que ça semble un peu déroutant. Consultez le parcours 101. Il aura une très grande sorte d'introduction à tout ce matériel avant de réellement entrer dans les modèles eux-mêmes, donc je veux juste donner cette disclaimer rapide. C' est aussi sur ma chaîne. Si vous voulez vérifier celui sur une vidéo sortie aussi bien. Mais tout le monde, bienvenue au partage des compétences. Si vous avez des questions, laissez-les dans les commentaires du cours et je serai heureux de vous aider dans n'importe quel domaine, et j'ai hâte de commencer. 2. Modèle de chute 1-1: Le premier modèle majeur que nous allons couvrir est celui du modèle cascade. Donc, avec le modèle de cascade, ce que nous faisons, c'est que l'eau tombe d'une étape à l'autre. Nous avons donc commencé les exigences, puis une fois que nous sommes sûrs que les exigences sont parfaites, nous avons passé à la conception que nous passons de là à l'implémentation une fois que nous sommes sûrs que c'est parfait jusqu'à tester le déploiement jusqu'à entretien. Maintenant, ça n'a pas à l'être. Vous savez, ces étapes. Ce pourrait être n'importe quel Siris d'étapes qui nous amèneront à cette conclusion finale. Mais l'importance de l'eau pour la méthode ou le modèle de cascade est que nous passons de étape à l'étape deux, et c'est une sorte de ce que nous avons couvert tout le parcours, comment nous parlons comme si tout était dans un flux linéaire et vous suivez toujours. Suivez ces étapes. Cependant, le problème avec le modèle de cascade est qu'il n'est pas très adaptatif. C' est très, très prédictif. Rappelez-vous ces deux mots que nous utilisons dans la dernière conférence, et parce que c'est très, très prédictif, cela signifie que si nous trouvons des erreurs, disons dans la phase de test, cela signifie que nous allons devoir aller à l'envers. Donc, si, par exemple, nous le trouvons dans les tests, changeons la couleur ici, alors nous allons réellement devoir revenir à l'implémentation, puis de l' implémentation à la conception Et puis les exigences et fondamentalement, ce que nous allons devoir faire, disons que nous trouvons un air ici une erreur vraiment sérieuse avec la façon dont nous avons programmé sont nos logiciels. On va devoir changer les exigences, réparer les exigences. Ensuite, nous allons aller réparer la conception, nous avons mis au point de nouvelles conceptions de sous-systèmes, nouvelles conceptions de modules, etc. Ensuite, nous allons retourner dans l'implémentation, devrons le recadrer, et ensuite nous allons devoir le tester à nouveau. Et si les choses déjà déployées, nous devons aller encore plus loin. On doit continuer à retourner et retravailler tout à partir de là. Et une fois qu'on sera à la phase de maintenance, c'est un peu comme dans un cercle en bas, ça va continuer. Cependant, si nous faisons des changements majeurs dans la phase de maintenance, nous devons toujours faire exactement la même chose ou encore la chaleur graphique remontant tout le chemin et refaire tout pour nous assurer que toute la documentation est pris en charge dans le modèle de cascade. Donc, le modèle de cascade est très, très, comme je l'ai dit, prédictif. C' est quelque chose où votre équipe doit avoir codé ceci avant pour qu'elle soit couronnée de succès. Maintenant, avec cela, il est également très efficace et il est très simple à utiliser. Donc, il y a beaucoup de frais généraux. Donc encore une fois, si vous créez plusieurs sites Web ou quelque chose comme ça, alors ce modèle est probablement quelque chose qui va être une bonne équipe de peur, parce que je n'ai pas à passer beaucoup de temps à penser à la conception du logiciel processus. Ils peuvent utiliser un processus qui a déjà été conçu avec un tas d'étapes, et ils pourraient simplement travailler avec cela maintenant avec le modèle cascade. Nous avons également ce problème de ce coût au fil du temps à résoudre. Donc, disons chacune de ces étapes différentes, de sorte que vous savez que c'est une fois que les exigences sont terminées. Une fois la conception terminée, une fois l'implémentation terminée, une fois que tous les tests sont terminés, que le déploiement est terminé et ainsi de suite, il peut s'agir d'étapes différentes. Mais l'importance de ce graphique est de vous montrer qu'au fur et à mesure que vous allez plus loin, ce n'est pas seulement un coût linéaire au fil du temps, ce qui signifie que réparons, si nous leréparons,si nous devons faire quelque chose ici, c'est juste tout combinés pour revenir à ce point. C' est ce genre de chose exponentielle où si nous faisons une erreur et que nous le découvrons, peut-être dans la phase de mise en œuvre ou près de la phase de déploiement, cela prendra beaucoup plus de temps que si nous le corrigeons dans la phase des exigences peut-être jusqu'à 50 fois plus de temps pour revenir en arrière et tout changer pour que cela fonctionne à nouveau. Et pour cette raison, le modèle de cascade n'est pas flexible du tout. Chaque étape doit être extrêmement bien planifiée. Nous devons nous assurer que tout est parfait, et certaines sociétés le feront, et c'est vraiment très, très. Beaucoup de programmeurs vont s'asseoir et tourner leurs pouces, attendant que les exigences ou quelque chose soient passés par un tas de comités différents pour s'assurer que c'est parfait et donc ceux qui pourraient perdre du temps dans là aussi. Mais il doit être extrêmement bien planifié. Et cela va prendre un certain temps pour mettre le produit sur le marché. Si nous faisons quelque chose dont nous allons parler plus tard, quelque chose de plus, plus itératif où nous créons un V qui est vraiment basique, et nous commençons à ajouter des fonctionnalités avec le 3 et la version pour l'inversion 5. Ensuite, nous sortons le produit vraiment, très bientôt. Et à partir de ça, on peut, vous savez, commencer à construire dessus, et je ne sais pas pourquoi, mais un bonhomme de neige est venu à l'esprit ici, et on peut en fait obtenir un produit qui, vous savez, commencez à travailler pour ça. Nous pouvons obtenir des commentaires de ce test bêta affaiblir pour lequel nous pouvons obtenir de l'argent, mais avec cela nous avons fait tout en un seul coup. La première version du produit va probablement être la version finale du produit, et parce que nous pourrions réellement manquer notre opportunité de marché, Peut-être que si nous avions sorti, vous savez, moitié assed beaucoup présente trois mois plus tôt, il aurait été beaucoup plus de succès que d'avoir trois mois de retard avec toutes les fonctionnalités, et quelque chose qui est très important est que la technologie évolue rapidement et ce que cela ? Nous ne serons pas en mesure de nous adapter aux nouvelles technologies. Donc, si nous sommes dans un domaine en développement rapide, comme, par exemple, les voitures où vous savez que les logiciels automobiles sont en train de développer assez rapidement des choses de même avec, exemple, logiciels de l' Internet des objets, Vous savez, comme des montres intelligentes ou comme des chemises intelligentes ou quoi que ce soit. Tout ce marché se développe très vite. Et les nouvelles technologies sortent 68 peut-être un an à la fois. Et donc à cause de ce genre d'itération rapide, cause de , vous savez, l'itération annuelle ou peut-être même mensuelle de la technologie, si nous construisons un logiciel qui prend deux ans à construire, Et nous ne mettrons rien entre ces deux années, au moment où nous sortons notre logiciel, la technologie a peut-être évolué et tout notre projet est obsolète, donc nous devons en tenir compte aussi. Mais le modèle de chute d'eau. A cause de tout cela, c'est décemment mauvais dans beaucoup de domaines, mais il ne devrait pas être radié immédiatement. Il a ses avantages dans des structures plus organisées et des endroits où les équipes créent les mêmes choses encore et encore, et il a cette idée efficace et peu coûteuse. Mais c'est le premier modèle, l'eau pour le modèle. C' est très important et beaucoup de choses sont basées sur lui. 3. Modèle 1-2 V: Donc le prochain modèle dont nous parlons sera celui du modèle. Et le modèle V est une sorte d'amélioration par rapport au modèle de cascade. Ou au moins il prend soin d'un problème que les gens ont remarqué avec le modèle de cascade. Et ce modèle V prend essentiellement la chute d'eau. Donc la chute d'eau étant, vous savez, le bas, le bas, le bas et le bas, et il le prend et il la plie sur ce genre d'implémentation ici, et ça amène les tests à droite, puis le déploiement est un peu comme peut-être la prochaine étape à droite ici une fois que tout cela est terminé. Mais ce que ce modèle fait, c'est qu'il fonctionne de cette façon. Alors ne pense pas qu'on va faire comme ça et puis remonter le bon côté. Ce qu'on fait, c'est qu'on travaille essentiellement sur ces couches ici. Nous avons donc cette couche supérieure, qui est ce lien entre les exigences et les tests d'acceptation que les tests de conception et de système , l'intégration architecturale et les tests de module et d'unité. Et la raison pour laquelle nous faisons cela est parce que rappelez-vous dans la dernière conférence, nous parlons de la façon dont il y avait un problème avec cela dans le fait que les tests sont la situation où nous trouvons des bugs, non ? Eh bien, si on trouve un gros insecte, on doit aller jusqu'au bout pour réparer ces bugs. Donc on doit y aller. Tous les environnements actifs ont conçu l'implémentation pour corriger ces bogues. Quelqu' un est mort. Si c'était le cas, si c'est l'étape où nous trouvons le plus de bugs n'aurait pas de sens de ne pas le mettre à la fin, mais près du début et de le faire à chaque étape que nous descendons. Si c'était le cas, si c'est l'étape où nous trouvons le plus de bugs n'aurait pas de sens de ne pas le mettre à la fin, Et c'est ce que fait le modèle V. Donc, avec cela, nous avons chaque étape, et ensuite nous avons des tests pour vérifier cette étape. Donc, il y a le côté droit ici, c'est essentiellement la vérification de vérification. Donc, le bon style sera que nous vérifions que chacune de ces étapes est réellement bonne avant de passer à autre chose. Et ce côté droit est juste ce qu'on a fait. Que la conception maintenant avec ce modèle, nous avons pris cette partie de conception et nous avons en fait divisé en ses sous-composants. Rappelez-vous comment nous avons parlé de l'architecture et ils différents modules, puis la conception dans son ensemble ? C' est ce qu'on fait ici. On s'en prend à ça, c'était en fait la rupture pour que nous puissions avoir différentes parties à tester. Donc, le 1er 1 est les exigences avec les exigences. Ce que nous avons, c'est que nous avons cette idée d'acceptation. Test, acceptation. Les tests sont des tests pour s'assurer que les exigences sont exactement ce que nous voulons. Un exemple de cela serait de simplement venir avec les exigences et essayer de presque créer des simulations ou potentiellement venir avec des documents qui détailleraient chaque cas d'utilisation. Alors, comment prévoit-on exactement que l'utilisateur utilise le système ? Et puis nous essayons essentiellement de presque simuler ce qu'un utilisateur ferait et de voir s'il va accomplir ces tâches. Nous examinons donc les exigences. Nous essayons de créer un utilisateur qui l'utiliserait et de voir s'il y a quelque chose que nous avons manqué, quelque chose que nous ne comprenons pas. Ceci est généralement fait avec le client pour s'assurer que encore une fois il est acceptable, faisaient ce que nous voulons faire et sera donc une solution acceptable. L' étape suivante est la conception, et quand nous parlons de design comme celui-ci, nous parlons de l'ensemble du système conçu, donc nous parlons de ce très haut niveau ou nous disons que nous allons avoir cette section, cette section, cette section de cette section et peut-être juste un peu, comme, peut-être, la communication ici et la communication comme celle-ci. Et ça va être le tout pense que c'est la conception de l'ensemble du système dans son ensemble. Et la fois que nous aurons cela, nous allons faire des tests de système, peut-être faire quelques cas de test jusqu'à un peu de code juste pour voir et s'assurer que cette conception fonctionne correctement. Ensuite, nous allons un pas plus loin. En fait, on les a percés. Nous commençons à concevoir des architectures, comprendre tout cela, travailler et ensuite nous faisons l'intégration, tests, assurant que tout cela fonctionne ensemble et puis qu'il fonctionne ensemble, toujours avec l'autre les uns. Et puis nous faisons tout le chemin jusqu'au test de module, qui est l'endroit où nous les divisons en petits modules, les bits de code qui communiquent réellement les uns avec les autres. Nous faisons cette idée de tests unitaires, dont nous avons parlé, et puis nous allons peut-être remonter la chaîne pour nous assurer que le reste fonctionnera avec tout le reste à cause de tout cela parce que nous avons fait tous les tests dans ce phase. Une fois que nous arrivons à la mise en œuvre et que nous l'enrobons, nous avons fini parce que les tests ont été faits tout au long de la partie. Et maintenant, nous garantissons en quelque sorte que nous ne courons pas dans cette grande zone où nous allons avoir beaucoup de bugs qui les trouveront plus tôt et donc réduiront le coût car au lieu de les trouver peut-être ici sur le chronologie des coûts, nous les trouvons ici. Et nous essayons de nous assurer de les trouver avant ce point, et ils ne finissent pas par en cascade jusqu'à ce point. Et c'est donc ce qu'est le modèle V. C' est une sorte de prochaine étape sur la bouteille en cascade. Maintenant, la seule arnaque avec cela est qu'il y a plus de travail initial là-dedans. Chaque étape que nous prenons, nous devons trouver des algorithmes de test entiers. Souviens-toi, on parle de tests. Les tests sont difficiles. C' est quelque chose qui n'est pas très facile à penser et pas très facile à mettre en œuvre. Donc, avec cela à l'esprit, nous devons comprendre qu'en raison de la façon dont nous faisons cela, nous devons tester chaque section SEC ici, ce qui signifie que nous allons avoir plus de coûts initiaux. Ça va être plus difficile. Ça va être un peu plus complexe de gérer ce logiciel. Mais c'est génial si nous ne sommes peut-être pas sûrs à 100%, nous avons une sorte d'idée de la façon dont nous voulons aller, mais nous ne sommes pas sûrs à 100% sur la façon d'y arriver dans cette situation. Nous voulons utiliser le modèle V afin que nous puissions prendre des mesures pour continuer à le tester afin de nous assurer que nous marchons sur la bonne voie. 4. Modèle 1-3 Sashimi: Le prochain modèle dont nous allons parler, c'est un modèle Sheemie ? Et ce modèle a été construit à partir d'une idée à laquelle nous n'avons peut-être pas pensé au début. Mais quand on y pense, c' est très pratique, et c'est que dans chacune de ces phases, nous n'avons pas nécessairement les mêmes ingénieurs. Donc, beaucoup de fois, nous sommes sous l'hypothèse que peut-être nous avons un ou deux ingénieurs et qu'ils vont faire les exigences, puis concevoir et ensuite la mise en œuvre dans les tests et le déploiement dans la maintenance. Mais ce que nous avons généralement, surtout dans les grandes entreprises, c'est que nous avons des ingénieurs spécifiques qui font des choses comme les exigences qui font des choses comme la conception, ce soit le backend ou le front end, que nous avons des ingénieurs en implantation. Nous avons des ingénieurs de test, nous avons des ingénieurs de déploiement et de maintenance. Et à cause de tout cela, nous avons ce problème où si nous le faisons étape par étape, comme dans les exemples précédents avec le modèle E V et le modèle cascade, tous ces ingénieurs, il ici doivent attendre que le précédent est terminée, puis une fois l'étape précédente terminée, tous les ingénieurs et le haut attendent une fois de plus. Donc, vous obtenez ce genre de secteur où beaucoup de vos employés sont assis autour d'attendre que d'autres travailleurs accomplissent leurs tâches. Et donc le modèle sashimi, nous avons la possibilité de tracer ces lignes vers le bas. Donc, en gros, on l'a coupé. Donc c'est le modèle sashimi. Si vous avez déjà eu du sashimi, c'est un c' plat de poisson cru découpé, et il est généralement disposé l'un sur l'autre, comme d' habitude l'un sur l'autre. Et c'est pour ça que c'est le cas. Elle me modèle est parce que vous avez ces pièces toutes posées les unes sur les autres, et ensuite vous couper fondamentalement deux catégories différentes ici. Donc si on va de l'avant, on ne pourrait pas dessiner ces tranches ici et ce que c'est. Ce sont les différentes phases de développement, et nous pourrions, bien sûr, faire ces phases comme si nous avions des objectifs d'un mois ou de deux mois. Mais essentiellement, ce que nous faisons c'est de faire un peu de tout dans chacune de ces phases. Donc, avec les exigences et ce graphique, nous allons de cette façon. Donc, le temps que nous traversons le temps, nous nous dirigeons par là. Donc quand nous commençons, vous savez, nous commençons par les exigences, la conception et peut-être un peu de mise en œuvre, peut-être un peu de tests ici et ensuite la phase suivante. Nous travaillons toujours sur les exigences et la conception et maintenant beaucoup de la mise en œuvre . Mais nous recevons également nos tests et notre déploiement est la maintenance. Les ingénieurs ont impliqué le déploiement. Les ingénieurs sont en train de trouver la meilleure façon de jouer la maintenance ou peut-être de créer des systèmes. Peut-être qu'il y avait des modèles de test ou des bêtas. Que ces gars travaillent est bien, et nous continuons à le faire à chaque étape. Donc, dans la prochaine étape, ce que nous avons, c'est que nous faisons maintenant tout. On découpe tout en même temps. Et puis ici, on se réduit lentement jusqu'à ce que nous soyons dans la phase de maintenance. Et encore une fois, cela nous aide parce qu'il permet à différentes disciplines de commencer à travailler plus rapidement et aussi raccourcit le temps de développement au lieu d'avoir à attendre. Disons, si c'était, vous savez, apparaître deux semaines. Donc, c'est la quantité de semaines 23456 et sept semaines pour chacune de ces semaines. Une fois cette tâche terminée sept semaines, cette tâche prendrait cinq semaines. Imaginez que si nous faisions ces un à la fois, ce serait deux plus trois plus quatre plus cinq plus six plus sept. Ou ce que nous pouvons faire, c'est que nous travaillons un peu sur eux, et nous sommes tous en train de les commencer presque dans la même semaine. Donc, le temps total viendra probablement à quelqu'un autour de sept ou huit semaines au lieu d' ajouter tous ces éléments ensemble. Et c'est beaucoup de temps en sécurité là-bas. Maintenant, le problème que nous pourrions avoir avec ceci est qu'il peut entraîner de l'air et de la refonte. Ce que cela signifie est juste comme quoi ? Le modèle de cascade. Si on trouve un air, ATT est un point, on va devoir remonter tout le chemin, et l'erreur est largement répandue dans cette situation, et c'est parce que nous n'avons pas fini les exigences ou la conception. Pourtant. Au moment où nous mettons en œuvre et testons, ce qui signifie que nous pourrions trouver quelque chose qui doit être complètement retravaillé et tout le dos du pied, peut-être que comme ça ici doit être retravaillé. Et à cause de cela, tout le travail que nous ne faisons pas Onley doit juste retravailler les exigences. Nous devons maintenant retravailler tout ce que les exigences touchaient. Donc tout ici, on va devoir retravailler. Donc ça nous ouvre en quelque sorte à ça, ce potentiel où si nous ne pensons pas à cela et si nous sommes un peu bâclés et air en retard, nous allons devoir nous avons de l'air en retard, nous allons devoirfaire beaucoup de retravailler et il peut en fait s'avérer que fera qu'il sera plus lent à se développer de cette façon si nous avons ces émissions. Mais si nous n'avons pas ces flèches, nous avons beaucoup de travail pour son utilisation et son efficacité et nous avons vraiment raccourci le temps de développement. 5. 1-4: Donc, pour les deux prochains modèles, nous devons comprendre quelques termes. Donc, ça a du sens. Et ça va être cette idée de vers incrémentiels. itératif et incrémental et itératif sont assez similaires, sauf qu'ils ont une sorte de façon différente d'avoir le produit in. Et ce que nous entendons par là, c'est qu'ils progressent et progressent vers l'objectif final en s' appuyant sur un produit original. Donc il y a quelque chose que nous avons commencé avec et nous sommes en train de construire dessus. Cependant, avec incrémentielle ont été construites au fil du temps. Pensez à une chaîne d'assemblage où nous n'arrivons jamais au produit final jusqu'à ce que nous soyons au produit final et à une itérative où nous construisons de nombreux produits finaux et continuons à en faire de nouveaux qui sont légèrement plus proches de notre produit final. Mais cela fonctionne presque entièrement. Alors passons en revue pour entendre un peu plus en profondeur. Encore une fois, notre 1er 1 est incrémental. Construire des pas au fil du temps, la chaîne de montage , vous savez, nous avons, vous savez,nous commençons avec une voiture et ça a commencé comme un cadre, puis il se déplace vers, vous savez, le côté extérieur de l'intérieur que peut-être le moteur, etcetera, etc. Peut-être qu'on parlait de construire un ordinateur. Donc nous commençons par, vous savez, l'affaire, puis l'étape suivante, nous l'envoyons aux personnes qui ont mis les cartes mères. On a une petite carte mère là-dedans, et l'étape suivante, on l'envoie aux gens qui vont mettre le processeur. Donc maintenant, nous avons une carte mère dans le CPU et l'étape suivante. Nous avons maintenant un processeur de carte mère, puis nous y mettons du bélier, et ainsi de suite et ainsi de suite jusqu'à ce que nous ayons un ordinateur finlandais. Mais notez qu'à aucun moment, nous n'avons un ordinateur capable de fonctionner. Il n'y a rien où nous allons vraiment avoir quelque chose qu'on puisse donner à un client pour voir comment ça se passe. Nous construisons au fil du temps. On le donne d'un pas à l'autre. Et c'est ce qu'est le modèle incrémental. Nous examinons ces étapes, ces objectifs que nous voulons atteindre, et fondamentalement nous construisons pour atteindre cet objectif et nous avons ces derniers, comme presque de nombreux projets pour le construire de cet état à cet état. Disons ST 123 et 4. Donc nous le construisons à partir de l'Etat un pour essayer de l'amener au début de l'Etat puis nous allons de l'Etat pour essayer d'arriver au début. Estate 3 et nous passons à travers, comme maintenant avec le modèle itératif étaient la construction de prototypes, et nous l'ajustons avec de nouveaux prototypes. Ce serait comme si on construisait une voiture et qu'on construisait une version vraiment, vraiment mauvaise. Peut-être avec, comme presque, tu sais, voler des sièges à l'intérieur. Donc, il n'y a même pas de rembourrage à l'intérieur. C' est juste ce siège en acier à l'intérieur de ça. Cette voiture, il y a quelques roues dessus, et c' est à peu près là. C' est toujours un bloc pour nous n'avons même pas conçu cette pièce. Mais la suivante, on commence à le raffiner un peu. Peut-être qu'on y ajoute un peu de forme. Donc, au lieu de ce genre d'apparence bloquée maintenant, nous avons une meilleure partie de l'aérodynamique dedans. On avait, tu sais, de meilleures roues. Nous avions mieux semer, puis la partie suivante, nous avions les caractéristiques de luxe. Peut-être qu'on avait autre chose et ainsi de suite et ainsi de suite. Mais chacun de ces produits va tous accomplir les tâches à accomplir, qui signifie que si nous avons ce taux de produit ici, il devrait être capable de faire fondamentalement tout ce que le produit final devrait être capable de dio. Cependant, ce produit ici va être une version pire de ça. Ça va utiliser une partie moins chère. Ce sera là où le design n'est pas entièrement mis en œuvre. Peut-être que certaines choses sont expérimentales là-dessus. On teste certaines choses. Nous testons les roues sur ce point, par exemple, mais nous devrions quand même être en mesure de le faire fonctionner. On devrait toujours pouvoir le montrer à un client. Si c'est, ah, logiciel de chacun de ces côtés, celui-ci, nous ne pourrions jamais montrer à un client avant cette partie ici, nous pourrions peut-être le montrer une fois que ça sera presque terminé. Mais certainement pas au début. Alors que ce taux après avoir terminé le premier prototype, nous devrions être en mesure de montrer ça au client et de dire : C'est là que nous sommes en ce moment, vous savez ? Allez, prenons un petit pilote de test, laissez-moi vous montrer comment fonctionne ce programme. Permettez-moi de vous montrer quelques détails du programme. Et la prochaine fois, ils vont peut-être donner des commentaires et ça ira dans notre prochaine génération. On va faire quelques ajustements et le montrer au début et encore. Et c'est la différence entre incrémental et itératif. C' est une différence importante. Ils ressemblent beaucoup à, et ils sont très faciles à confondre, mais comprendre cela est important pour certaines des prochaines étapes. 6. Modèle d'échelon 1 à 5: donc, le modèle incrémentiel utilise ce terme dont nous venons de parler, qui est incrémentiel, ont été mis en œuvre quelque chose adopté. Donc, avec le modèle incrémentiel, ce que nous faisons est de terminer le processus de développement logiciel plusieurs fois tout au long du développement. Cependant, à chaque processus, nous avons un certain objectif en tête. Donc, nous avons, par exemple, l'or pour, vous savez, construire l'extrémité arrière ou construire l'extrémité avant ou construire un pour montage. Construisez une page et nous allons de l'avant. Nous créons les exigences pour concevoir la mise en œuvre, les tests, puis nous avons déployé dans ce que notre produit final va être. Donc, nous allons fondamentalement dans le premier incrément. Une fois que c'est fini, on va dans la seconde ou ça n'a pas à l'être. De plus, nous n'avons pas à finir ça pour arriver à la seconde. Beaucoup de fois passeront aux étapes et une fois que nous aurons fini,par exemple, par exemple, commencerons à mettre en œuvre le programme de dépistage du chômage. La prochaine étape commencera la prochaine phase de développement, ce qui nous permet d'avoir un peu de chevauchement ici, ce qui nous permet de continuer à travailler à un rythme efficace, et tout au long de ce processus, nous construisons lentement vers le produit final. Les incréments de la marque nous permettent également de montrer les parties finales de la conception. Donc, si c' était la première page et quelques formulaires, on pourrait l' envoyer au client et lui dire : Est-ce que cette partie a l'air bien à nouveau ? Ce n'est pas un produit fini. On ne peut pas leur demander de tester tout ça et de nous donner des commentaires pour changer tout ça . Ce que nous pouvons faire, cependant, est donné un peu de rétroaction sur les pièces et pièces actuelles que nous avons construites et voir comment, exactement ils aiment ces pièces et pièces. Donc, nous construisons la première page et quelques fermes en quelques pages, et c'est notre premier accroissement. Une fois que cela est fait, nous pouvons envoyer au client pour commentaires et ensuite passer à la phase suivante, euh, euh, avec l'un de ces changements, ou nous avons créé une nouvelle phase pour changer réellement tout ce que le client a eu des problèmes avec, et avec cela, nous avons l'idée de pouvoir mettre en quelque sorte ces portes tout au long du processus où nous pouvons continuer. Nous pouvons continuer à produire, mais nous pouvons également continuer à obtenir des commentaires pour voir si le produit et le projet vont dans la direction que nous voulons qu'il aille. Cela ajoute un peu d'adaptation au processus. Rappelez-vous prédictif et adaptatif. Cela nous permet d'aller un peu plus loin dans ce côté adaptatif où nous pouvons réellement nous déplacer et nous adapter à ce que le client pense et à la façon dont la production se déroule. Cela ajoute également des couches de ces commentaires qui nous aident également. Un côté négatif de cela est à nouveau retravaille. Si nous avons besoin de faire des remaniements majeurs ici, peut-être que nous avons déjà commencé à développer en tenant compte de cela ici, de sorte que nous pourrions devoir changer certains des développements futurs. Modifiez les exigences ici mais ici et ici, ce qui changerait tout le tas de processus plus tard aussi. Nous devons reculer et reconstruire différentes choses. Une autre chose, c'est le coût. Le coût d'exécuter tout un tas d'incréments différents va être beaucoup plus élevé. Non seulement nous allons devoir avoir cette surcharge de gestion de cette chose, nous allons aussi avoir plusieurs équipes de travail sur des incréments différents parce que la même équipe qui travaille sur cet incrément pour terminer celui-ci pourrait ne pas être la même équipe qui peut travailler sur ce sujet. Sinon, nous allons en quelque sorte dans cette chose linéaire ou nous passons juste d'un à l'autre, et cela peut être un processus. Nous pouvons faire un processus incrémentiel où nous passons simplement d'un à l'autre. Mais nous perdons un peu de l'avantage quand nous faisons cela, parce que nous perdons un peu de cette vitesse et tout ça. Nous gagnons à travers cela, mais c'est le modèle incrémental. C' est une excellente façon d'emballer différents processus de conception. Et ce qui est bien à ce sujet, c'est que dans chacun de ces processus, nous pouvons réellement utiliser un modèle tout à fait différent. Cela pourrait donc être le modèle incrémental, et nous pourrions utiliser la cascade pour ce modèle. On pourrait utiliser le modèle ici, et on pourrait utiliser une elle moi ici. Cela n'a pas vraiment d'importance parce que ce sont tous de petits produits individuels. Mais le modèle incrémentiel est important, et c'est un très bon élément de construction pour d'autres modèles à l'avenir. 7. Cadre de processus unifié: Donc, le prochain modèle dont nous allons parler n'est en fait pas un modèle, mais plutôt un cadre que nous appelons, et la raison en est que nous pouvons réellement utiliser des modèles dans ce modèle. Donc, tout au long de ce processus, nous pouvons utiliser différents modèles comme le modèle cascade ou le modèle TV. Est-ce que ça me voit tout au long de chaque étape avec ici ? Et donc nous ne sommes pas en quelque sorte contraints à un seul modèle, étaient fondamentalement avoir un plan de jeu ou un aperçu de ce que nous essayons de faire. Et puis à partir de cela, nous utilisons des modèles pour accomplir ces tâches. C' est donc le cadre de processus unifié. Et il y a beaucoup de déviations de cela probablement jusqu'à 20 écarts différents de personnes qui ont regardé cela et essayé de trouver un qui résout un problème spécifique . Par exemple, il y en a un qui s'appelle le modèle Rational, Unified Process. Il y en a un qui est très léger. Il y en a un qui est spécialement conçu pour plus de choses comme Agile. Il y a beaucoup d'itérations différentes parce que c'est une très bonne façon de capturer l' idée de développement de logiciels et ensuite une sorte de donner un aperçu vraiment Ni de celui-ci. Donc c'est une sorte de graphique ici à gauche de l'endroit où nous passons notre temps. Nous avons ces différentes phases appelées création, élaboration, construction et transition. Et ceux-ci ici sont en quelque sorte des espaces réservés. Si vous êtes dans une entreprise, vous créerez vos propres yeux ou faciliterez ou voit Ortiz et chacun d'entre eux aurait un but à la fin de celui-ci. Donc, dans chaque phase de construction, vous mettriez un objectif à la fin de la phase. Et c'est comme ça que vous savez, si vous êtes passé à la phase suivante d'une fois, ces choses ont été terminées, et ceci essaie juste de vous donner une idée de la façon dont ce processus fonctionne. C' est à la phase initiale. Nous déterminons la faisabilité du projet. Peut-il être quelque chose que nous pouvons construire cela même possible ? Nous examinons le calendrier et les coûts potentiels du projet. Essaie d'estimer, tu sais, combien de temps ça va prendre ? Combien vas-tu coûter à la compagnie ? Quel est le retour sur investissement ? Alors nous décidons. Voulons-nous l'acheter ou le construire ? Peut-être qu'il y a une solution là-bas. Peut-être qu'il y a une solution partielle là-bas que nous pouvons acheter la solution partielle et construire à partir de là. Nous devons également nous pencher sur cette question lors de la phase initiale. Et puis la livraison ou l'objectif pour cela est d'essayer d'obtenir des objectifs de cycle de vie, essayer de comprendre le plan, savoir où nous allons, ce que le coût, qui nous avons besoin d'un truc plus élevé comme ça. Et c'est dans cette phase de lancement, et vous verrez que nous avons ce genre de ce dont nous avons parlé tout ce temps le côté gauche. Ici, nous avons eu les exigences pour concevoir la mise en œuvre, les tests et le déploiement ici puis cette idée de modélisation d'entreprise, qui est juste cette idée, vous savez, les coûts et les personnes à embaucher et des choses comme ça. Et donc vous remarquerez que dans la phase initiale, ce que nous faisons, c'est que nous faisons un peu d'exigences, quelque sorte de donner un aperçu approximatif de ce que nous essayons de créer. Mais en fait, nous sommes en train de comprendre que c'est quelque chose que notre entreprise veut passer du temps et que la ressource est à construire, et c'est important parce que nous ne voulons pas construire quelque chose qui ne va pas nous rendre l' argent à long terme. Et c'est une excellente façon de gérer les risques. Au lieu de sauter dans un projet et de dépenser beaucoup d'argent, nous dépensons une petite quantité d'argent exploratoire à l'avance pour déterminer si c'est bon pour nous une fois que nous sommes sortis de cette phase. Une fois qu'on a une idée, on a des coches qui disent, oui, allons-y. Nous passons à la phase d'élaboration, les phases d'élaboration où nous prenons cette idée. Ceci et cette idée que nous avons eu une création et nous le construisons, nous arrivons avec leurs exigences. C' est donc là que les exigences sont lourdes. Nous traitons ici des facteurs de risque connus. Nous vérifions et validons les architectures du système. Donc, dans ce cas, nous allons réellement construire le code prototype très central pour les tests. Donc on va construire une idée très, très lâche de code qui va se parler l'un à l'autre. Ça va faire ce que nous avons, mais ça va nous montrer que c'est possible. Fondamentalement, la preuve de concepts est ce que nous appelons cela. Donc nous allons taper du code, voir si ça marche de la façon dont nous pensons que ça va marcher. Et à partir de là, nous pouvons vraiment commencer, vous savez, élaborer dessus dans la construction. Mais dans cette phase, on fait juste un peu de ça. Et c'est pourquoi vous pouvez voir la mise en œuvre va ici. Nous recommençons un peu la mise en œuvre pour essayer de comprendre Peut-on le faire ? Et si oui, de quelle façon ? Nous faisons un peu de tests parce que nous devons voir s'il fait ce que nous pensons qu'il devrait être, puis le déployer. Nous le déployons à d'autres personnes qui le donnaient aux testeurs montraient aux gens que, hé, cette preuve de concept fonctionne réellement. Et puis c'est lourd et l'analyse et la conception aussi bien. Nous construisons donc des diagrammes de cas d'utilisation et des diagrammes de classe et des diagrammes d'architecture, etcetera dans la construction avec la construction. Ce qu'on fait, c'est qu'on construit le truc. Donc, nous travaillons fortement dans la mise en œuvre ici. Nous allons mettre toutes nos ressources dans ce domaine, et il s'agit de la phase la plus longue et la plus grande du projet. Vous pouvez voir par cela qu'ils ont élaboré avec plusieurs valeurs voir ici, plusieurs phases différentes et une sorte de façons de passer par cela. Ce système est construit sur les bases établies par l'élaboration. Nous avons donc construit ce genre d'architecture, ce très petit modèle ou peut-être même un petit projet. Et à partir de là, nous allons construire à partir de là. Les fonctionnalités sont implémentées dans de courtes itérations de boîte de temps. C' est important. Cela signifie que nous construisons essentiellement entièrement travailler dans des produits sans fonctionnalités. Donc nous avons, bien sûr que vous savez, ça commence par la boîte, et plus tard, nous ajoutons les caractéristiques comme si c'était une voiture que nous avions les roues et plus tard, nous ajoutons, vous savez, le pare-brise, etcetera, etcetera. Mais ce que nous faisons, c'est que nous commençons par une unité viable. Donc ici, tu sais, je veux dire le mal. Arrête de sortir. On pourrait mettre, tu sais, blocs carrés ici. C' est toujours une voiture. Il est toujours capable d'être piloté, mais avec le temps, nous le rendons meilleur, meilleur et meilleur. Nous ajoutons plus de fonctionnalités recevaient un peu de commentaires, et nous ajoutons plus de fonctionnalités en raison de ces commentaires et en faisant de meilleures itérations. Et cela s'entend de cette idée de l'aération. Rappelez-vous, intuitif et incrémental Will cela accomplit effectivement un peu des deux dans les petites parties ici. Ce qu'on fait, c'est qu'on incrimine. Donc nous en faisons un en faisant de minuscules incréments jusqu'à ce qu'on fasse une itération réelle. Une fois que nous avons terminé la génération, nous la déployons obtenons des commentaires de celui-ci, et nous recommençons par incréments jusqu'à ce que nous ayons à cette itération et ainsi de suite et ainsi de suite. Et le livrer quoi ? Voici un flux continu d'amélioration des logiciels. Donc on va avoir, tu sais, c'est là qu'on a la version. Tu sais, je crois que ça commence habituellement par, genre, 0,1, qu'on obtient 0,20 point trois, etcetera, où on commence à trouver ces étiquettes de version à mesure que nous devenons de mieux en mieux. Et enfin, nous avons cette idée de la transition. La transition est l'endroit où le système est déployé vers les utilisateurs cibles. commentaires sont reçus, des améliorations sont apportées et le taureau de livraison est une fois que cela est terminé, le produit final est également terminé. Donc, dans la phase de transition, la plupart de notre conception est à peu près fait étaient en train de se dérouler. Le déploiement a été affiné et s'assurer que la modélisation de l'entreprise et les exigences sont complètement retrouvés. La phase de test commence ici, et nous commençons vraiment la phase de déploiement où nous la donnons aux gens et voyons ce qu'ils pensent. Voyez s'il y a des changements si nous avons besoin de faire quelques itérations supplémentaires sur le projet final. Donc, avec ce genre d'idée avec cette idée, nous avons un cadre sur lequel nous pourrions en quelque sorte créer notre plan. Donc ce n'est pas quelque chose que vous savez que vous pouvez regarder. Et il y aura un guide 123 sur la façon de créer un cadre de processus unifié pour votre projet. Tout ce qu'il y a c'est que ce n'est que ces groupes et ce genre de description de ce que vous devriez faire. Et puis à partir de cela, vous devez développer un plan complet pour votre projet. Pour cette raison, nous avons certains avantages et inconvénients associés à cela. Les pros sont qu'il est adaptatif. Sa qualité et son objectif de réutilisation. Il est axé sur la gestion des risques à chaque étape. Nous sommes en quelque sorte à réévaluer les exigences, déterminer si nous devons continuer ou si nous devrions abandonner le projet flexible faire entreprise. D' autres modèles, nous pouvons, comme je l'ai dit, inclure d'autres modèles et zones dans chacune des étapes chaque incrément. Nous pouvons changer complètement le modèle et travailler à partir de là. Les inconvénients O r Si vous avez regardé cela et dit, Eh bien, comment pouvons-nous réellement mettre en œuvre cela ? Eh bien, la façon dont vous le faites c'est que vous avez besoin de beaucoup de bons gestionnaires et de gens qualifiés pour élaborer ce plan dès le début. Ce n'est pas facile. Ce n'est pas quelque chose où on peut juste le regarder et y aller, ouais , OK, laisse-moi sortir un bout de papier et écrire ça très vite. Il a beaucoup de frais généraux, ce qui le rend très compliqué. Ça va avoir beaucoup trop de frais généraux pour les petits projets si tu veux. Et la petite échelle est quelque chose aussi grand que, euh , comme , une application comme une application sur l'APP Store qui juste comme une seule tâche, disons que c'est peut-être un jeu sur l'APP Store. Cela pourrait être trop petit d'une échelle pour que cela soit réellement un cadre réalisable à utiliser. Et donc cela signifie que vous avez cette chose vraiment grande où vous n'avez pas beaucoup de projets qui correspondent à cela. Nous parlons vraiment, vraiment de grands projets ou de projets qui ont beaucoup de disciplines différentes impliquées. Vous savez, les choses qui contactent les serveurs et les différents yeux AP et les choses qui sont construites sur le front et le back-end et toutes ces choses différentes. C' est là que ça pourrait être justifié. Mais pour beaucoup de projets, c'est beaucoup trop compliqué et aussi à cause de la façon dont il est conçu à cause de cette façon de faire toutes les phases à la fois, et nous travaillons potentiellement sur différents modèles et sur des tout en même temps, il va avoir besoin de plus. La ressource est en cours d'exécution Plus de programmeurs, plus de gestionnaires, plus de testeurs. Mawr Euh, fondamentalement tout le plus d'argent pour faire ce truc, et la chronologie aussi va probablement être assez rapide, mais ça va coûter beaucoup, donc on a le chemin. C' est la vitesse de cela qui est importante en raison de ce coût. Mais c'est là le cadre de processus unifié. Je vais certainement chercher cela sur Google ou quelque chose sur, et regarder dedans un peu plus parce qu'il y a beaucoup de variation différente de cela, et ils sont tous assez de viande et de viande et bon à comprendre chaque fois que vous apprenez ingénierie logicielle. Mais c'est une chose très importante, et c'est en fait l'un des cadres les plus utilisés dans l'industrie aujourd'hui. 8. Modèle spirale 1-7: Maintenant, nous avons le modèle en spirale. Le modèle en spirale est juste qu'il s'agit d'une spirale. Ce que nous faisons ici, c'est que nous examinons constamment le même genre de domaines développement encore et encore pour nous assurer que nous analysons les risques ou analysons à chaque étape. Et nous nous assurons que nous allons et validons ce que nous faisons au fur et à mesure que nous allons de l'avant, il y a un très axé sur les risques. Nous essayons d'avancer avec de très petits pas et de nous assurer que nous avons cette idée de « go » ou « no go ». Signification. Voulons-nous continuer le projet, ou voulons-nous le mettre au rebut ici ? C' est très bon pour les idées expérimentales, idées que vous pensez peut-être possibles, mais vous ne savez pas encore vraiment, donc nous faisons ces petits pas en avant et nous nous assurons que nous n'allons pas tous sur le point non édité. Nous voulons simplement nous assurer que nous analysons la situation, que nous analysons ce que nous avons fait et que nous procédons si cela est encore faisable et qu'une bonne idée de procéder . Alors quoi ? Le modèle en spirale ? Ce que nous faisons, c'est que nous commençons dans ces quadrants et que nous les traversons continuellement. Donc, c'est le quadrant 123, puis le quadrant quatre. Et ce qu'on fait, c'est qu'on y va. 123412341234 Comme ça et ce que nous faisons alors que nous continuons à aller de plus en plus loin, c'est que nous élargissons la portée, le coût, le nous en profondeur de chaque étape, le temps global que nous y consacrons. Donc, au tout début, nous créons des prototypes rapides. Et à mesure que nous sortons, il devient plus lent. Nous le regardons plus. Nous mettons un peu plus d'analyse dans ce que nous faisons. Plus de tests jusqu'à ce que nous arrivions à un produit final à un moment donné. Donc, disons que nous commençons ici à évaluer dans cette partie, qui est que nous allons déterminer des objectifs, alternatives et des contraintes. Donc, ici nous sommes déterminés ces objectifs, les alternatives que les contraintes étaient de déterminer tout ce que le projet est, nous sommes fondamentalement à venir avec un plan. De là, nous passons et identifions et résolvons les risques. À ce stade, nous sommes en train d'identifier les risques. n'y a rien à résoudre puisque nous n'avons rien codé et que nous venons avec un prototype qui, dans cette situation, n'est qu'un plan. Ensuite, nous commençons à exécuter ce plan, le concept d'opération. Donc ici, nous pouvons avoir au lieu de coder réellement dans cette première phase, peut-être que nous créons, vous savez, des modèles de classe. Ou peut-être que nous avons en quelque sorte une idée générale sur la façon dont le concept fonctionne. Et c'est pourquoi il s'agit d'une validation de concept. Nous n'avons même pas intégré les exigences et les choses comme ça. Nous créons ensuite le ou nous le regardons. Donc, nous jouons dans la prochaine génération. Nous avons donc trouvé ce concept qui vient avec cette idée générale de la façon dont un prototype devrait fonctionner, analyser le risque. Maintenant, nous allons trouver le plan des exigences et le plan du cycle de vie. Comment va-t-on développer ça ? Comment nous allons trouver un ensemble solide d'exigences et ensuite nous avons planifié cela, et c'est sur l'exploration. Donc maintenant, nous sommes ici, faire une autre analyse des risques, c'est toujours quelque chose qui semble réalisable avec nos coûts, notre budget et notre main-d'oeuvre. Si c'est le cas, nous construisons à nouveau le prototype suivant. Cela pourrait être juste une itération sur le plan. Dans l'ensemble, il n'est pas nécessaire que ce soit un véritable prototype fonctionnel. C' est juste une sorte de peut-être que la documentation est un peu plus épaisse ici. Nous passons ensuite aux simulations. Eso sont dans cette situation particulière. Nous faisons des modèles de simulation ou des benchmarks. C' est tout son domaine. Donc on est en quelque sorte juste ici pour prolonger ce qu'on fait. Donc, dans cette boucle particulière étaient probablement faire les exigences logicielles, validation des exigences, choses comme ça, nous venons juste avec le plan général de celui-ci. Ensuite, nous avons élaboré un plan pour la prochaine phase, à savoir le développement. Déplacer ici, faire le développement de la vérification, Faire l'analyse des risques au mouvement d'intégration. La phase suivante Faire l'analyse des risques, Regardez un prototypes opérationnels de quelque chose que nous pouvons réellement donner à quelqu'un doom ou tests de benchmarks, puis libérer. Et c'est une très, très sorte de modèle de base. Il peut y avoir ah, beaucoup de boucles, et entre celles-ci, surtout pendant la phase de développement, nous pouvons faire ce genre de modèle itératif en ce sens. Donc ici, nous avons juste eu une seule boucle où nous avons enrobé tout le truc, et ça a évolué, mais il pourrait y avoir une tonne de boucles, et il pourrait y avoir, vous savez, 100 petits différents. cadre de ce processus de développement, nous vérifions constamment les risques et planifions notre prochaine phase, en continuant de passer en revue les objectifs et les contraintes et en sortant de là. Et c'est un modèle très, très puissant parce que cette chose axée sur le risque est très bonne si nous faisons, vous savez, pas en avant dans un domaine inconnu, et c'est très, très adaptatif. Donc encore une fois, c'est le long de cette idée de. Au lieu d'aller droit, nous pourrions devoir nous déplacer pour atteindre notre objectif. C' est un grand modèle. Faites cela parce que nous réévaluons constamment ce que nous faisons, regardant ce que nous avons fait au cours du dernier cycle et en arrivant à une nouvelle idée pour le prochain cycle. Maintenant, cela semble compliqué, et c'est parce que c'est compliqué, surtout dans la conception de ceci pour un projet riel. Cela devient très compliqué, et cela coûte plus cher à gérer. Tu dois avoir une très bonne idée de ce que tu fais pour garder tout sur la bonne voie ne pas pour ne pas commencer par une spirale et ils ont juste comme, Ok, on va juste l'enrouler et commencer par une spirale et ils ont juste comme, Ok, vous savez, pas réellement passer par les tests et la mise en œuvre et l'analyse des risques constants. Et vous avez également besoin d'un engagement plus constant des parties prenantes. Ce que c'est l'intervenant, c'est comme le client, la personne qui paie pour le logiciel. Vous avez besoin de leur engagement constant dans ce domaine. Si vous voulez aller avec les options pour aller ou non, ce qui signifie qu'on continue, ou qu'on abandonne le projet ? Vous allez avoir besoin de leur mot à dire chaque boucle. Si ces boucles sont, disons tous les cinq jours, peut-être là toutes les deux semaines. Même vous aurez besoin de cet intervenant toutes les deux semaines pour venir à une réunion, s'asseoir, apprendre ce que vous avez fait la semaine précédente et décider s'ils veulent continuer ou non. Et cela pourrait devenir un peu fastidieux pour eux. Vous avez donc besoin d'intervenants qui sont enclins à ce qui veut être engagé dans le projet . Beaucoup de fois, ils ne le font pas. Ils veulent juste payer la personne qui l'a construit, ils ne veulent pas vraiment être impliqués dans le processus quotidien de celui-ci. Mais si vous avez tout ce modèle de flèche est un excellent modèle pour ce risque. La gestion est un excellent modèle pour construire des choses qui nécessitent une découverte, où vous essayez de faire de petits pas en avant. 9. Introduction 2-1: Maintenant, nous avons parcouru quelques zones les plus traditionnelles. Je voulais passer en revue quelque chose de nouveau. Je veux dire, quand je dis nouveau, c'est dans les 20 dernières années. Mais c'est quelque chose que beaucoup d'entreprises ont choisi, et c'est cette idée de la méthodologie agile ou de l'agile. En général, Agile est une façon de penser. C' est une sorte d'ensemble de principes que vous appliquez. Et puis nous allons passer en revue un tas de modèles différents qui fonctionnent avec la méthodologie agile , choses comme Scrum et Kon Bon et d'autres termes que vous avez pu entendre parce qu'ils sont plus répandus dans l'industrie d'aujourd'hui. Les vieux, ils n'étaient pas mauvais. C' est juste qu'il y avait lents. Nous développons des produits du point A au point B. Nous avons donc commencé. Nous sommes allés tout droit à travers et nous y sommes arrivés. Parfois, tu sais, peut-être qu'on a dévié un peu. Nous avons dû revenir et nous avons trouvé notre objectif final. Mais c'est à peu près tout ce qu'on pouvait faire avec les anciens. Dans le marché en mouvement d'aujourd'hui, les choses changent. moyens de développer la technologie changent tous les jours, et à cause de cela. Nous devons nous assurer de développer le logiciel qui résout le problème. Le problème lui-même pourrait changer. Et à cause de cela, nous avons cette idée de ce type de manifeste agile et de cet ensemble de principes qui nous permettent d'être vraiment, vraiment fluides et flexibles dans notre processus de développement. Cela signifie que nous pouvons trouver des idées qui nous font aller dans des directions complètement différentes et qui vont continuer à évoluer avec le client jusqu'à ce que nous trouvions exactement ce qu'il cherchait . Et avec le modèle typique, il serait très difficile pour nous de continuer à bouger cela. Nous perdrions beaucoup d'argent, mais avec cela, nous le prenons en fait par petits incréments et nous pouvons continuer à avancer à chaque incrément dans la bonne direction et avec le temps nous commençons à développer le bon logiciel. Donc, chaque décision que nous prenons, nous nous portons lentement. Le client est heureux ou constamment communiquer avec eux pour construire son produit final et à la méthode de cascade ou la cascade sorte d'ensemble d'idées, qui est une sorte de tout dans l'exemple précédent que cet ensemble de, vous savez, nous faisons d'abord la conception et ensuite, ou nous faisons d'abord les exigences, puis nous faisons la conception, puis nous commençons à mettre en œuvre et nous commençons à tester ce genre d'idée. Où nous allons un à l'autre a des problèmes. L' un d'eux est pendant la vérification. Beaucoup de problèmes inattendus se posent. Nous, par exemple, si nous avons codé un bug dans l'architecture et que nous sommes dans la vérification avant de le découvrir , il n'y a pas vraiment où nous pouvons aller avec cela. Ou si nous arrivons à une vérification, nous la montrons à nos clients. Et ils disent, Oh, non, ce n' est pas exactement ce que nous voulions, mais il y a eu une petite erreur de communication. C' est ce que nous voulions. Eh bien, il n'y a aucun moyen de revenir en arrière et nous n'avons pas vraiment eu l'occasion de réparer ça à l'avance avec Agile. Il y a des solutions à ce sujet. Les systèmes logiciels sont complexes et ne peuvent pas être prédits à 100%. C' est quelque chose qui est très, très vrai, c'est que si nous embauchons quelqu'un pour faire une sieste, nous pourrions ne pas savoir exactement ce que nous voulons. L' application pour dio. Nous voulons communiquer avec eux au fil du temps pour construire lentement cette application pour la construire. La façon dont nous voulons, et nous voulons qu' ils nous aident à trouver ce que nous voulons dans une application, parce que ce sont eux qui savent comment programmer. Ce sont eux qui savent créer des choses, nous comme l'idée. Les gens ne savent pas exactement ce que nous voulons faire l'application et ce qui est capable. Donc on veut travailler avec quelqu'un de très, très intelligent. Une entreprise technologique qui se développe réellement apte à trouver l'idée finale et une méthodologie agile vous aide avec cela. À la fin, certains logiciels ne répondaient plus aux exigences d'origine ou modifiées. Si ce n'est pas très flexible, les exigences peuvent avoir changé au fil du temps, et nous voulons être flexibles afin de pouvoir changer avec eux, puis les marchés évoluent au fil du temps. Le produit pourrait être obsolète au moment où nous finissons. Ah, beaucoup de modèles agiles ont en fait cette idée de venir avec un M V P ou un produit minime viable, quelque chose que nous pouvons mettre sur le marché, vous savez, vous savez, dans les quatre mois, quelque chose que nous peut jeter là-bas qui a juste les caractéristiques de base , mais rien d'autre. Et nous pouvons commencer à recevoir des commentaires des utilisateurs et nous pouvons commencer à résoudre le problème. Peut-être pas 100%, mais nous sommes au moins en train de le résoudre un peu avec ça. Avec la cascade, c'est généralement que nous ne sortons pas un produit tant qu'il n'est pas complètement fini. Et à cause de cela, nous avons ce très gros problème de ça pourrait être obsolète. Disons qu'il faut deux ans pour bien développer ce logiciel. Le problème aurait déjà pu être résolu par une autre entreprise à ce moment-là. Le problème aurait pu changer au fil du temps. Ah, beaucoup de choses différentes peuvent arriver où nous pourrions devenir obsolètes au moment où nous finirons et ensuite tout cet argent est gaspillé. Nous voulons donc nous assurer que nous pouvons être flexibles dans des situations où nous savons que les marchés évoluent constamment. Et le manifeste agile était en quelque sorte ça. C' est un groupe d'ingénieurs réunis et ils ont décidé que des changements étaient nécessaires. Ensemble, ils sont venus avec le manifeste agile que nous allons discuter en détail dans la prochaine conférence est un ensemble d'idées pour développer des logiciels meilleurs, plus rapides et plus agiles. Je supposais améliorer le système dans son ensemble, et beaucoup d'entreprises ont constaté qu'il fait exactement cela 10. Manifeste agile 2-2: Alors maintenant, parlons du manifeste agile. Nous l'avons mentionné dans la dernière conférence, mais passons un peu plus en profondeur. La chose importante à comprendre à ce sujet est agile est un ensemble de lignes directrices qui ensemble d' idées que nous développons ensuite des modèles avec. Donc il n'y a pas de modèle agile là-bas. Il n'y a pas de processus de développement agile. Il y a la ligne directrice agile, puis nous créons des modèles basés sur les lignes directrices agiles. Quelque chose comme Scrum, par exemple, est un modèle qui est basé sur ces lignes directrices. Donc la mêlée est le modèle que nous développerons dans la mêlée. Mais la mêlée est un modèle agile, et c'est juste quelque chose d'important parce que beaucoup de gens se mêlent. Ils disent, vous savez, nous développons une agile quand ce n'est techniquement pas vrai. Ce qu'ils font, c'est qu'ils utilisent un modèle basé sur l'agile, si agile est encore ce manifeste. C' est cette idée. C' est son ensemble de directives que nous utilisons pour développer des logiciels, et nous pouvons en fait, si nous le voulons, nous pouvons mettre ces chiffres ici et ce sont des locataires différents ou des idées et des lignes directrices différentes . Au lieu d'ingénieurs, ils Fondamentalement, l'histoire raconte qu'ils se sont réunis et ils sont venus avec cela. Je pense que c'était quelque part au début des deux milliers. Ils se sont tous rencontrés et ont décidé que l'ingénierie logicielle en général avait un problème. Il y avait un ensemble de problèmes, et c'était surtout parce que l'ingénierie logicielle venait de l'ingénierie régulière. Il a été conçu comme une transition presque directe de, vous savez, comme construire un pont et les gens ont pensé, OK, nous allons construire le logiciel comme nous construisons un pont. Cependant, logiciel est un peu différent, et il y a des exigences et des façons de procéder légèrement différentes lorsque vous parlez de logiciel. Alors ils se sont réunis et ils ont pensé, Nous allons trouver un moyen qui améliorerait l'ensemble de l'industrie du développement logiciel et ensemble ils sont venus avec ces quatre locataires et beaucoup d'entreprises les utilisent pour les locataires nos jours parce que ils sont fondamentalement une très bonne façon de faire des affaires. Ils augmentent la productivité, augmentent les relations avec les clients et augmentent globalement les bénéfices, ce qui est ce que les entreprises veulent . Ainsi, le 1er 1 est les individus et l'interaction sur le processus et les outils. Donc celui-ci se concentre sur les individus, les ingénieurs et tous ceux qui participent à la construction du logiciel plutôt que sur l'utilisation d'un outil ou d' un processus que nous avons utilisé dans le passé et de nombreuses entreprises. Chaque fois qu'ils se développent ou qu'ils vont dans un sens, ils obtiennent un ensemble de processus et un ensemble d'outils qu'ils utilisent. Et si une équipe d'ingénieurs arrive à une piste et qu'ils leur disent, vous savez, nous pensons que ces outils et processus seraient meilleurs. Beaucoup de fois ces idées ont été abattues parce que c'est comme ça que ça a toujours été fait. Ces anciens processus et outils sont déjà en place, alors pourquoi le changer dans ce domaine essayait de dire que l'individu devrait avoir plus de contrôle sur la façon dont il a développé le logiciel. Si l'ensemble des individus se réunit et qu'ils décident qu'un nouvel ensemble de processus, un nouvel ensemble d'outils devrait être mis en place pour améliorer fondamentalement la situation qu'ils ne devraient avoir une plus grande priorité sur l'ancienne façon de faire les choses, et nous voulons aussi travailler en quelque sorte, disant que l'individu est plus important que le processus dans les outils eux-mêmes, nous voulons traiter les individus avec respect. Nous voulons traiter les interactions qu'ils ont avec respect. Nous voulons essayer de créer un bon environnement de travail. Nous ne voulons pas, vous savez, faire tomber les gens parce qu'ils veulent utiliser de nouveaux logiciels et outils parce qu'ils s' écartent légèrement des processus et outils actuels. Nous voulons élever nos ingénieurs, et nous voulons leur donner le plus de respect possible. Le numéro deux travaille sur un logiciel sur une documentation complète, et c'est une déviation assez loin des idées précédentes selon lesquelles nous avons passé sur les méthodologies de cascade et les modèles sashimi et tout ce genre de choses. Et c'est parce qu'elle sait qu'elle était très concentrée sur la documentation et l' arrachage de tout avant que nous commencions à nous développer ici, même si nous avons en quelque sorte tourné ça sur sa tête. Et nous voulons un logiciel de travail avant ou du moins comme une priorité plus élevée que la documentation complète . La documentation est toujours importante car elle permet à notre logiciel d'être maintenable. Cependant, il y a une limite où si nous avons 15 livres sur la façon dont notre logiciel devrait fonctionner et comment il va être construit, nous ne serons probablement pas en mesure de montrer cela à qui que ce soit et d'obtenir des commentaires réels ce sujet. Nous voulons créer un logiciel de travail avec un peu de documentation. Peut-être, vous savez, une quantité moyenne de documentation, quelque chose que nous pouvons donner aux clients ou aux deux testeurs ou aux utilisateurs et obtenir des commentaires réels à ce sujet afin que nous puissions apporter des changements en temps réel. Nous ne voulons pas attendre jusqu'à la fin pour commencer à recevoir des commentaires, réaliser que quelque chose ne va pas, changer l'ensemble du logiciel et ensuite devoir réécrire toute notre documentation. Ça n'a pas de sens. Nous voulons donc nous concentrer sur le fonctionnement des logiciels, logiciels, la conception correcte, construction correcte plutôt que la documentation de l'ensemble du processus. Encore une fois, nous ne disons pas que nous abandonnons la documentation. Nous disons juste que nous voulons donner un peu plus de concentration pour obtenir le logiciel réellement construit, puis travailler à l'obtenir parfaitement documenté. Numéro trois Collaboration client sur la négociation de contrat. Nous voulons avoir une bonne relation avec nos clients et nos clients. Nous ne voulons pas avoir à signaler un contrat chaque fois qu'un changement veut ou chaque fois que quelque chose doit essentiellement déplacer un peu beaucoup de fois avec les entreprises. Ils obtiennent ce contrat et ils pointent vers le contrat. Chaque fois que quelque chose arrive et dit, que dit le contrat ? Ok, on ne fait rien de différent. Nous essayons de dire que la collaboration client est ce qui nous permettra d'obtenir ce bon produit final. Si le client arrive et qu'ils disent Ok, j'adore où va le logiciel, mais il y a une nouvelle chose qui vient de sortir et ça va être, vous savez, peut-être que ce logiciel a besoin d'un peu de plus ici. Peut-être qu'il a besoin d'être un peu retravaillé là-bas. Nous voulons rendre le client heureux afin qu'un ils nous donnent de bonnes critiques. Ils nous payent correctement tout ça. Nous voulons que le client se sente apprécié. Nous voulons rendre le processus vraiment, vraiment agréable pour eux. Si chaque fois qu'ils viennent demander des changements de vol, nous disons disons Allons retravailler le contrat. Nous finissons par impliquer les équipes juridiques, réajuster les prix et passer par tout ça. Ça va être une douleur et personne ne voudra travailler avec nous. Donc, ce que nous essayons de dire, c'est que nous voulons que cette collaboration soit primordiale pour Oh, c'était, au moins sur les contrats de négociation de contrats. Encore une fois, ils sont importants. On ne jette pas tout ça dehors. On dit juste : Parlons au client Mawr. Faisons une relation très forte pour qu'on y aille et qu'on continue. Lee a travaillé avec des contrats pour répondre au changement plutôt que de suivre un plan. Nous voulons être en mesure de faire preuve de souplesse. Nous ne voulons pas être enfermés dans un certain plan, et chaque fois qu'un problème survient, nous disons : Eh bien, Eh bien, quel est le plan dit que nous allons rester avec le plan si nous ne pouvons pas répondre au changement que nous sommes pas dans et de son ent ou en lui-même, agile, que le mot agile n'était pas que nous ne sommes pas flexibles avec notre processus de conception, Et c'est ce qu'Agile essaie de faire est d'essayer de créer une autonomisation des gens, réellement construire le logiciel et faire des logiciels qui changent avec le temps parce que technologie change rapidement. Nous ne voulons pas de processus qui ne nous permettent pas de changer rapidement avec la technologie, alors nous voulons donner à nouveau. Nous voulons un plan, mais nous voulons permettre de le modifier. Nous ne pouvons pas être flexibles pour déplacer le logiciel de cette façon. De cette façon, chaque fois que nous collaborons avec le client, nous allons construire un logiciel de travail pour que le client puisse voir ce qui se passe, et qu'il puisse nous donner des idées pour que nous puissions réagir au changement. Nous voulons avoir ces individus et l'interaction avec le client et nos ingénieurs afin que de nouvelles idées et de meilleures idées soient présentées. Nous pouvons changer nos outils, nous pouvons construire des logiciels de travail, nous pouvons le montrer à nos clients et nous pouvons réagir au changement. Dans l'ensemble, c'est le manifeste agile que nous essayons de créer. Cet ensemble de directives qui nous permettent de changer et de bouger avec l'orteil Times nous permet développer des logiciels de manière plus optimale. Et agile a fait un excellent moyen de classer que dans les prochaines conférences, nous allons commencer parler des modèles qui sont basés sur agile, et vous pouvez voir que vous serez en mesure de voir comment ce sont des moyens plus rapides et plus rapides de développement que ce dont nous avons parlé précédemment. 11. 2-3 Scrum: Donc, le premier modèle agile dont nous allons parler est le modèle Scrum, donc Scrum que vous avez peut-être entendu auparavant parce que c'est une façon très populaire de développer des logiciels et Scrum se concentre sur ces intervalles de 1 à 4 semaines différents. Donc, en gros, on les appelle sprints et scram. C' est un sprint de scrum et le sprint est cette idée de développement rapide, en ajoutant les fonctionnalités les plus prioritaires, puis en allant vers le client, les parties prenantes, tous ceux qui sont impliqués, en leur montrant, en prenant des commentaires et en refaisant le cycle. C' est son idée de planifier, construire, apprendre, répéter. Donc, nous allons faire toute notre conception définie, construire et tester dans ce genre de sprint scrum ici. Et c'est là que les idées de tests de retour à dos entrent en jeu parce que l'affaiblissement utilisé dos à dos pour s'assurer qu'entre les sprints, que nous ne casser quelque chose de la précédente et pour s'assurer que les nouvelles fonctionnalités sont fonctionnant correctement aussi. Donc, à chaque sprint, nous allons créer un produit légèrement meilleur que le sprint précédent . C' est à son idée de le prototyper. Donc chaque prototype va être juste un peu meilleur que le prototype précédent et beaucoup de fois peut-être après le troisième ou le quatrième sprint, nous avons un produit que nous pouvons réellement lancer sur le marché et ensuite nous commençons. Nous continuons de nous développer, ajoute-t-il. Il est publié sur le marché afin que nous puissions obtenir un produit dans, vous savez, trois mois, peut-être quatre mois que le client peut commencer à gagner de l'argent peut commencer à prendre ces idées sur la façon de le réparer et de le rendre meilleur. Et nous pouvons continuer à le développer en fonction de l'interaction de l'utilisateur. Et donc la mêlée est très populaire à cause de cela, il est très rapide de se développer très rapidement pour que le client commence à gagner de l'argent, et cela permet également une flexibilité extrême dans le processus de développement. Donc, ce sont des personnes différentes impliquées dans le processus de mêlée. Nous avons le propriétaire du produit et ce sont essentiellement les parties prenantes, tous ceux qui sont impliqués dans la recherche de ce logiciel, donc nous obtenons des commentaires des dirigeants, de l' équipe, parties prenantes, clients et utilisateurs, puis le propriétaire du produit regarde tout ce genre d'entrée et ils ont aidé à prioriser la liste des prochaines étapes, ce que nous devrions faire pour notre prochain sprint. Nous avons donc besoin d'une communication constante avec le propriétaire du produit et c'est une sorte d' inconvénient parce que peut-être nous avons un propriétaire de produit qui n'aime pas passer le temps à prioriser ce qui est ensuite. Ils veulent juste qu'on fasse tout. Et si c'est le cas, les locataires de Scrum s'effondrent parce que nous sommes censés créer fondamentalement ce design flexible qui fonctionne avec le propriétaire du produit. S' il sort, il ou elle sort. Nous n'avons pas ce point de vue et nous commençons à évoluer dans des directions potentiellement erronées. Le maître de mêlée. Ils tiennent l'équipe responsable des idées mêlées et ils facilitent les réunions et font la résolution des conflits à un peu de planification sur le côté. Et donc la réunion de mêlée est essentiellement la personne principale pour le modèle de mêlée là-bas. Un autre pourrait aussi être un ingénieur logiciel principal. C' est, vous savez, travailler avec plus de code, mais le maître de mêlée tient l'équipe responsable, assurez-vous qu'ils suivent tous les locataires de mêlée et qu'ils font tout la bonne manière et de la bonne façon. parce que si on s'effondre et qu'on arrête, tu sais, d'adhérer à nos sprints. Et nous n' atteignons pas nos objectifs pendant nos sprints. Ensuite, tout le processus va encore s'écrouler parce que nous n'aurons pas de produits finis à montrer à notre client. On n'aura pas cette rétroaction, et on ne sera pas très flexibles. Et enfin, nous avons l'équipe, et c'est l'équipe qui construit le logiciel. Et ce ne sont pas seulement des ingénieurs logiciels. On pourrait avoir des ingénieurs qui dirigent des ingénieurs. On a peut-être des designers. Nous avons peut-être juste des codeurs de base qui ne savent pas grand-chose sur l'ingénierie, mais ils sont assez bons dans un seul langage, faisant une seule chose. Ah, beaucoup de fois ça pourrait être de l'aide à l'extérieur pour une tâche spécifique. Peut-être qu'on va regarder un site web indépendant. Nous engageons quelqu'un juste pour ce sprint pour nous construire un module, payer la personne, et puis il est parti pour le prochain sprint. Comme nous avons de plus en plus de gens, il y a donc l'équipe peut changer en quelque sorte. Mais il y a des gens de base dans l'équipe, et il y a des rôles, et ils se réunissent tous pour créer le produit in. C' est une sorte de façon typique que la mêlée fonctionne est que nous avons cette idée de l'arriéré de produits . C' est un ensemble de, ah, liste essentiellement des choses qui doivent être faites. Donc nous avons, vous savez, cette liste d'idées et de choses à faire, le problème. Nous ne savons pas comment hiérarchiser cette liste. Donc, beaucoup de fois, nous allons amener les parties prenantes bien pour la réunion de planification du sprint. Alors on va leur demander. Qu' est-ce que vous voulez ensuite dans ce processus ? Qu' est-ce qui vous aiderait ou que voudriez-vous voir ? Qu' est-ce qui est le plus important pour sortir ce produit ? Une fois cette idée mise en place, nous créons un arriéré de sprint où il s'agit essentiellement de l'ensemble des idées sur lesquelles nous allons travailler pour ce sprint actuel. Nous avons fixé une date limite. Si on le fait dans trois semaines, dans deux semaines, on le fera dans 15 jours. Nous avons vu une sorte de délai, avons notre liste d'objectifs, puis nous avons commencé le processus de création. Nous commençons donc à avoir ces réunions de mêlée quotidiennes, ce qui signifie qu'elles durent généralement moins de 20 minutes. L' équipe de mêlée se réunit pour parler de ce qu'elle a fait hier, ce qu'elle prévoit de faire aujourd'hui et des obstacles auxquels elle fait face et éventuellement des mesures qu' elle va utiliser pour réparer ces barrages routiers. Et cette communication est importante parce que peut-être un certain utilisateur ou un certain ingénieur parle de la façon dont ils font face à ce barrage routier avec l'intégration de la base de données ou quelque chose comme ça. Eh bien, un autre ingénieur, pensez que vous aimez bien, en fait, j'ai fait ça dans le passé. Je sais comment réparer ça. Nous allons nous réunir aujourd'hui et je vais vous montrer comment réparer ça et franchir ce barrage routier. Ainsi, cette communication permet à différents ingénieurs de participer à différents projets ou à différentes parties du projet, et de s'aider mutuellement. Ils terminent tout leur travail le lendemain. Ils ont la réunion quotidienne de mêlée, et ils continuent d'aller de l'avant. Cela permet également à tout le monde de suivre à quel point ils sont proches de la fin de leur sprint et maintenir ou de s'assurer qu'ils sont dans les délais prévus pour leur sprint. Une fois que le sprint est fait, il va dans Sprint Review. Typiquement ramener les parties prenantes en démontrer le Sprint prend quelques suggestions, ils ont demandé à une partie prenante, Est-ce ce que vous parliez. Ils disent oui. Sauf que nous pensions que ce secteur devrait faire cela et cela. Nous notons cela, nous faisons ces notes, et généralement, cela reviendrait peut-être à l'arriéré des produits. Bien que nous ayons les intervenants ici. On leur a demandé. Ok, qu'est-ce que tu veux au printemps prochain ? Ils nous disent ce qu'ils cherchent dans la prochaine. Ils donnent la priorité à notre liste. Nous recommençons le processus. Maintenant, le fait est que nous faisons aussi une rétrospective de sprint. Donc, après avoir fait la vue du sprinter avec les parties prenantes, les propriétaires de produits, tous ceux qui, vous savez, n'ont pas vu ce produit au cours des deux dernières semaines sont de 1 à 4 semaines. Ensuite, nous allons dans une rétrospective Sprint, qui est juste l'équipe logicielle elle-même. Nous parlons du processus sur la façon dont les 1 à 4 dernières semaines se sont écoulées et nous voyons si leurs façons de le faire mieux ce que vous savez, nous ont empêchés dans une sorte d'environnement d'équipe. Et ce qui nous a empêchés individuellement sont là des moyens que nous pouvons corriger qu'après une rétrospective Sprint , nous commençons la prochaine planification Sprint. Obtenez toutes ces listes et nous répétons le processus encore et encore jusqu'à ce que le produit soit terminé. Donc, c'est génial pour sa flexibilité parce que nous avons tellement de commentaires, tant de commentaires de nos intervenants étaient constamment en train d'obtenir des directives sur ce que nous devrions faire ensuite. Nous ne sommes pas trop engagés dans quelque chose où, vous savez,nous vous savez, créons ce projet géant et quand le produit est développé, c'est complètement faux. nous assurons que nous faisons ces petits sprints minuscules, marchant de l'avant, étape par étape et en prenant des commentaires, Donc, nous créons le produit que le client nous embauche pour créer. 12. 2-4 Kanban: notre prochain modèle agile est celui de la moissonneuse-batteuse. Donc, si vous savez quelque chose sur la langue japonaise, c'est un mot très japonais, et la raison en est qu'il a été réellement développé au Japon. Ses origines remontent au Royaume-Uni dans le développement de Spitfire. Ce sont de très beaux avions qu'ils ont développés à l'époque, cependant, il a été popularisé, raffiné et vraiment mis en œuvre sur le marché de la consommation avec Toyota et Toyota est une entreprise japonaise. Ils ont essentiellement regardé le processus actuel de fabrication de voitures, et ils voulaient la rendre plus située. Donc, tout était disponible que les constructeurs automobiles de l'usine pouvaient obtenir. Tout était disponible comme si ce n'était pas un supermarché et vous pouviez aller chercher tout ce dont vous aviez besoin pour terminer votre processus. Fondamentalement, ils voulaient tout pour une personne, faire leur travail pour être à portée de main, et ils voulaient une planche pour suivre les progrès, regarder le flux actuel et continuer à améliorer le flux afin qu'ils puissent faire plus et de plus plus de voitures, et il est devenu très populaire. Il a fait des toilettes un couvent très, très réussi a été depuis adapté dans le monde du logiciel et c'est le même genre de technique que nous voulons mentir populaire ou vous voulez affiner notre flux. Je veux prendre le flux de cartes de bogues de fonctionnalités, et nous voulons savoir où sont les goulets d'étranglement et continuer à améliorer continuellement sur elle. Et en voici un petit exemple. Beaucoup de sociétés de logiciels utilisent quelque chose comme ça, donc vous aurez des cartes. L' arriéré est l'utilisation de celui qui est le plus rempli, donc vous avez un tas de cartes dans le carnet de commandes, puis quand nous voulons démarrer un projet, nous voulons commencer l'une des cartes. On le déplace juste. Donc, disons que nous avons un couple dans la phase d'analyse un dans la phase de développement, et alors peut-être que nous en avons quatre dans la phase de test, puis deux dans la phase de libération. Juste en regardant ça, nous voyons deux choses que nous voyons. On a beaucoup de choses à faire. Il reste encore beaucoup de choses dans ce projet, et nous voyons que nous avons un petit goulot d'étranglement dans la phase de test. Il y a un problème ici. Peut-être qu'on n'a pas assez d'ingénieurs sur les tests. Peut-être que nos tests actuels ou nos méthodologies actuelles avec les tests sont lents ou qu'ils ne fonctionnent pas correctement. Peut-être qu'il y a beaucoup de bogues ou d'erreurs qui se produisent dans les tests en raison d'une mauvaise analyse. En regardant cela, nous savons qu'il y a un problème avec la phase de test et que nous voulons améliorer la phase de test et nous essayons de le faire de manière lente et incrémentielle. Nous faisons un peu de changement. Nous le repassons et nous voyons si nous améliorons cela. On essayait d'attraper ces gros chiffres ici. Nous examinons les pourcentages dans la colonne de test. Peut-être qu'en ce moment, c'est quelque chose comme 25% de toutes les cartes sont assis ici, et donc nous essayons de faire quelques changements. Nous y jetons un coup d'oeil dans deux ou trois mois, et nous essayons peut-être d'obtenir une distribution de 15 % meilleure au lieu de, vous savez, ils sont une grosse masse, puis à la baisse et à la baisse dans cette grosse masse, puis à la baisse. Nous essayons, vous savez, faire en sorte qu'il soit parfaitement de niveau pour que le développement se déplace parfaitement , et avec tout cela, nous avons quelques locataires principaux. Ici, nous avons les propriétés Con Bon et les principes CONVEN, les propriétés de l'air, juste une sorte d'idées et de choses que nous pourrions vouloir suivre. Alors que les principes sont à peu près enfermés dans la pierre, sont des choses que chaque fois que vous regardez, combinent les principes. Tu vas prendre ce set ici, et on va passer en revue ça d'abord. Donc le numéro un commence par. Qu' est-ce que tu sais ? Ceci est important car le système Kon Bon pourrait être implémenté sur votre système actuel . C' est une façon de suivre les progrès et d'améliorer le flux de ces progrès afin que vous puissiez techniquement les mettre sur n'importe quoi et continuer à améliorer le flux. Vous pourriez même attacher cela à aimer une méthode de cascade de la bonne manière et voir ce vous tient pendant cette méthode avec Khan Bun la première à nouveau, Commençons par ce que vous savez ? Nous ne voulons pas tout jeter et commencer complètement à partir de zéro. Ce que nous voulons faire, c'est que nous voulons remettre cela, mettre en œuvre un petit changement. Peut-être que nos changements ont été la mise en place d'un tableau comme celui-ci afin que nous puissions réellement commencer suivre les progrès et ensuite nous déplaçons à partir de là. À partir de là, nous acceptons de poursuivre un changement évolutif progressif. Ce que ça veut dire, c'est que nous n'essayons pas de tout changer en même temps. On ne va pas regarder ça et faire ce que les tests sont évidemment là où se trouve le goulot d'étranglement. Embauchons cinq autres ingénieurs d'essai. C' est un changement majeur. Et ça pourrait causer d'autres problèmes sur la route. Ou peut-être une meilleure sorte de changement que nous pourrions faire est de dire, Hey, celui qui travaille sur le développement, peut-être qu'on peut avoir un de ces gars toutes les deux ou trois semaines, passer quelques semaines Ou peut-être une meilleure sorte de changement que nous pourrions faire est de dire, Hey, Hey, celui qui travaille sur le développement, peut-être qu'on peut avoir un de ces gars toutes les deux ou trois semaines, et tester et sauter d'avant en arrière. C' est un petit changement quand les ingénieurs vont juste déplacer des rouleaux juste pour un peu d'esprit d'aller-retour pendant quelques semaines chaque mois. Et qu'alors on conteste, c'est que ça aide ? Est-ce blessant et fera plus de changements sur la base de cela. Nous voulons donc un changement évolutif progressif, pas des sauts géants. Nous voulons respecter le processus actuel, les rôles, les responsabilités et les titres, et c'est important parce que nous ne voulons pas complètement abandonner un système simplement parce que nous pensons qu'il pourrait être faux. Nous voulons à nouveau apporter ces petits changements afin de respecter le processus actuel. Nous voulons respecter tout ce qui se passe avec notre configuration actuelle. Nous voulions les examiner très sérieusement et ne faire que de petits changements. Nous ne voulons pas commencer à virer les gens et à déplacer les gens partout. Cela crée cette peur d'instabilité au sein du projet qui va nous ralentir encore plus. Nous voulons donc examiner le problème, voir comment nous pouvons l'améliorer et apporter ces petits changements. Et enfin, celui-ci est parfois ajouté, parfois pas. Mais je pense qu'il est important d'encourager les actes de leadership à tous les niveaux. Ce que cela signifie, c'est que nous voulons encourager nos travailleurs les plus bas au même montant que nos travailleurs les plus élevés, le plus bas des travailleurs, ce qui signifie qu'ils ne font que coder. Ils ne font pas beaucoup du processus de conception. Ils font juste des changements. Nous voulons nous assurer qu'il y a d'être honnête et qu'ils sont francs dans la façon dont ils codent. Nous voulons qu'ils prennent de très bonnes décisions. Alors que les revêtements encourageraient ces actes, et que le leadership ici ne signifie pas qu'ils menaient d'autres personnes, cela peut signifier simplement qu'ils inspirent les autres parce qu'ils travaillent très dur et qu'ils créent très code solide et très sans bug. Alors quoi ? J' encourage le fait qu'à tous les niveaux et dans certaines propriétés, certaines des façons dont nous pouvons atteindre ces principes sont une. Visualisez le travail complet. C' est très important avec la moissonneuse. Nous voulons l'installer sur un mur géant ou sur un site Web, ou où tout le monde peut y accéder pour que nous puissions regarder le flux de travail. Et quel est le problème avec cela ? Nous constatons évidemment que nous avons le problème dans les tests et que nous devons travailler avec eux. Limiter les travaux en cours. C' est l'une des principales clés à cet égard, c'est que nous voulons limiter le travail que nous continuons à accomplir. Nous ne voulons pas que les orteils aient tout ce travail en cours parce qu'à ce moment-là, tout le monde s'est répandu beaucoup trop mince et nous ne faisons pas beaucoup de progrès. Nous ne pouvons pas voir le flux parce qu'il n'y a pas de flux. Tout le monde s'est arrêté et Onley a fait de très, très minuscules pas vers le produit final. On essaie toujours de rendre ça un peu agile. Nous essayons toujours d'accélérer le processus de développement. Donc, chaque fois que nous voyons quelque chose comme ça, nous voulons arrêter toute inclusion de l'arriéré et essayer de travailler à travers les bogues actuels avant introduire plus dans le processus. Gérer à nouveau le flux. Nous voulons examiner le flux et le gérer. Nous voulons voir où sont les problèmes et quel changement ces problèmes ne se rompraient pas. Stratégies de processus, réunion explicite. On ne veut pas juste expliquer à quelqu'un, tu sais,c'est comme ça tu sais, que c'est fait. C' est comme ça que nous faisons, un peu comme ça. Nous voulons avoir un morceau de papier avec toutes nos politiques, des détails que nous pouvons donner aux personnes que nous voulons qu'elles soient plus faciles d'accès et explicitement écrites . On ne veut plus de zone grise. Nous voulons quelque chose qui soit très, très explicite, très facile à trouver et très facile à suivre à nouveau. Cela fait que tous nos ingénieurs suivaient le processus et si nous savons qu' ils suivent parfaitement le processus, nous savons comment changer le processus parce que tous les ingénieurs ne suivent pas notre politique , peu importe la façon dont nous apportons des changements à la politique, il ne va toujours pas la suivre et aucun changement ne se produira, donc nous devons nous assurer qu'ils la suivent. La seule façon de le faire est de le rendre très explicite, en veillant à ce qu'ils puissent le lire et l'appliquer. Ensuite, nous pouvons apporter des changements sur la base de cela et enfin améliorer la collaboration. Ce que nous entendons par cela, c'est que nous voulons améliorer comme un groupe améliorerait collaborativement aide mauvais juste là. Nous voulons nous améliorer ensemble. Nous ne voulons pas faire de petits changements de haut en bas, ce qui signifie que le leader regarde tout. Ça dit que nous faisons ce changement. Nous voulons nous améliorer en tant que groupe. Donc vous voulez avoir des réunions de groupe, voulez soulever des problèmes, nous voulons avoir, peut-être amener les parties prenantes aussi. Et nous voulons avoir ces petites réunions des collaborations sur la façon dont nous allons nous améliorer . Tout le monde devrait être impliqué pour que nous puissions continuer à améliorer le processus parce que peut-être nous , disons, nous en tant que gestionnaire de programme, nous ne comprenons pas les problèmes ici et les tests. Donc, nous essayons de l'implémenter, vous savez, changements dans les tests par ce que nous pensons que les tests sont bien, cela ne va pas vraiment nous aider, parce que si nous avons amené certains des ingénieurs de test, ils sont va mieux nous expliquer pourquoi il y a un goulot d'étranglement. Peut-être qu'ils disent qu'on est trop assis sur le pipeline et qu'on n'a pas assez de gens pour s'en occuper. Peut-être qu'il y a des processus est à la fin de l'état d'analyse, où vous êtes en train de trouver la conception. Peut-être que ce sont des erreurs de développement. Les développeurs sont juste leur crayon fouettant tout, et ils ne font pas de bon code. Nous voulons parler aux ingénieurs d'essais et nous parlerons à tous les ingénieurs pour comprendre ce problème. L' amélioration de la collaboration est donc une très grande partie. Mais commun est une sorte de façon vraiment, vraiment soignée de développer du code. Et c'est un plaisir d'attendre de regarder tous les visuels et de continuer à améliorer chaque jour fondamentalement 13. Démarrage 2 à 5 Lean: Parlons de la start-up lean, qui est un autre modèle agile. Le démarrage maigre est très, très intéressant, et c'est quelque chose qui est relativement nouveau et quelque chose que vous ne pouvez vraiment faire qu'avec la technologie. Le lean startup est ce genre de façon expérimentale de construire des produits. Par expérimental, je veux dire ça littéralement. Vous faites des expériences pour voir si votre produit peut réellement faire de l'argent sur le marché. Donc, ce que nous faisons, c'est que nous allons à cette idée d'apprendre, construire des mesures. Prenez les mesures que nous avons appris construire, etc., et nous essayons de créer un produit le plus rapidement possible et le moins possible pour voir s'il y a un marché. Donc, ce que nous faisons, c'est que nous faisons une sorte de supposition. Nous faisons une hypothèse si vous aimez la méthode scientifique, et nous essayons de déterminer si cette hypothèse ou cette hypothèse est vraie. Donc, ce que nous faisons, c'est nous construire une expérience. Nous construisons un site Web, nous construisons un service et nous voyons si les gens s'y intéressent. Nous utilisons ensuite cet intérêt comme mesure, et nous ajustons en fonction de ces mesures. Un exemple très populaire de cela est de la société Zappos, Zappos a été fondée en 1999 alors que l'Internet commençait à peine prendre de la vapeur. Beaucoup d'achats en ligne n'étaient toujours pas très populaires. époque, cependant, le Foundered est allé dans un centre commercial local essayant de trouver des chaussures, et il ne pouvait pas trouver les chaussures qu'il voulait. Et c'était fondamentalement tout. Soit il a acheté des chaussures dans ce centre commercial, soit il n'a pas acheté de chaussures. C' était comme ça à l'époque. Alors il a pensé, Hey, construisons un site web qu'on peut mettre des chaussures de partout pour qu'on puisse toujours trouver la paire de chaussures qu'on veut. On est allés à la caméra graphique du centre commercial, a pris un tas de photos et on leur a posé tous sur le site. Maintenant, au lieu d'acheter un inventaire à l'avance, il a construit le site Web, donc il a supposé que les gens achèteraient des chaussures en ligne. Il a construit le site et ensuite il a juste mesuré combien de personnes obtiendraient des ventes. Et au lieu d'acheter l'inventaire et de construire l'ensemble du produit, ce qui ferait, c'est si quelqu'un passait une commande, il examinerait la commande. Trouve ce qu'ils voulaient ? Conduisez à la balle locale par cette chaussure, mettez-la dans une boîte et envoyez-la à cette personne. Il en va de même de ce processus très manuel. Il n'y avait pas d'inventaire. y avait rien d'autre que lui qui était toute la logique de l'entreprise. Il est devenu très, très, très populaire. Il s'est rendu compte qu'il avait quelque chose de vraiment grand sur les mains. Sa métrique a été confirmée que cela allait faire beaucoup d'argent, et à cause de cela, cause de l'intérêt qu'il était alors ouvert aux investissements. Il était ouvert à changer son processus pour en faire un véritable site Web pour gagner de l'argent. Et il a fini par être l'une des entreprises les plus prospères de toutes les lignes à partir des deux milliers de personnes. Ainsi, à travers ce processus, ce processus de démarrage allégé, il a pu investir un minimum de risque pour voir si une proposition ou une idée d'entreprise était viable. Et c'est pourquoi c'est très populaire, parce que nous pouvons utiliser cette startup lean pour le faire exactement, c'est de savoir si nos idées valent peine et qu'elles vont gagner de l'argent. Donc c'est la startup lean. Il n'y a rien d'autre avec celui-ci. La façon dont vous le construisez est que vous utiliseriez un autre comme un style mêlé. Ou vous pouvez utiliser un peu fondamentalement juste codage et pirater façon de faire démarrer quelque chose et ensuite vous le mesurez juste. Et après que tu aies compris que c'est ah, vas-y. Donc nous avons cette idée de go and no go signifiant Continuer ? Adoree, arrête ! Si c'est il y a, nous développons le logiciel. Nous utilisons l'une des autres méthodes. Si c'est un non aller quoi ? Nous venons d'arrêter le produit là-bas et nous espérons venir avec des idées plus tard. Mais le démarrage maigre vraiment intéressant d'apprendre.