Gestion de projets agiles : Comment construire quelque chose de numérique

1. Introduction: Bonjour et bienvenue. Voici un résumé très rapide de ce cours. Il s'agit d'un cours qui ne vous apprendra pas à coder. A ne vous apprendra pas à concevoir une interface utilisateur brillante. Il ne vous montrera pas comment faire de la publicité et de le lancer pour devenir virale sur Internet. Désormais, ce cours vous fournit une vue d'ensemble de bout du cycle de vie du développement logiciel Agile que vous pouvez appliquer à tous les produits numériques vous envisagez de développer. Il explique également quels membres de l'équipe et quels ensembles de compétences vous devez pointer avec vous pour réussir. Je m'appelle Alex. Je suis basé à Londres, Royaume-Uni et au cours des dernières années, j'ai travaillé en tant qu' élite senior et chef de projet dans de grands projets de transformation numérique, généralement pour les banques, les consommateurs, les clients du commerce de détail et des soins de santé. À la fin de ce cours, vous connaîtrez la différence entre développement logiciel Agile et Waterfall. Vous comprenez les rôles et responsabilités clés des membres de l'équipe et d'une équipe de développement agile, y compris le vôtre sous forme de chef de projet. Et vous serez en mesure d' expliquer chaque phase du cycle de vie du développement logiciel Agile, qui comprend la phase d' idéation, élaboration des exigences, conception et la construction de vos logiciels et montrant qu'il est testé régulièrement et qu'il arrive à le lancer sur le marché. Le cours est très destiné aux débutants, il correspond à celui qui s'intéresse au développement de logiciels. Vous êtes peut-être déjà un développeur ou un concepteur junior désireux de passer à un poste de gestion de projet. Ou peut-être êtes-vous un innovateur avec une excellente idée d'outil numérique. Mais vous ne savez pas par où commencer ou quelles compétences sont requises, auquel cas ce cours est fait pour vous. Si cela semble intéressant, commençons et commençons directement. 2. Développement de cascade: L'approche dans le monde du développement logiciel tend donc à être deux idées clés pour des approches clés du développement de logiciels. L'un est l'approche en cascade et l'autre est l'approche Agile. Waterfall est une méthodologie séquentielle où la tâche est un peu plus linéaire. Par contre, l'agile est une méthodologie très itérative, qui comprend un processus cyclique et collaboratif. C'est un débat très houleux sur ce qui est le meilleur et ce qui est mieux. À mon avis personnel, cela dépendra largement la préférence pour votre projet, vos compétences et de la nature du projet. Et si vous avez besoin d'un processus itératif ou d'un processus séquentiel. Néanmoins, il y a certainement un biais, je dirais 20 en tant que développement agile dans le développement logiciel. Par conséquent, nous nous concentrerons là-dessus aujourd'hui. Néanmoins, plongeons très rapidement dans la cascade pour que vous ayez également une compréhension. Le modèle cascade est définitivement le modèle le plus ancien et le plus simple. En gros, nous avons terminé une phase , puis nous commençons la page suivante. C'est très simple, très simple. conséquent, ou à titre d' exemple sur cette diapositive, vous voudrez peut-être effectuer toute l'analyse du projet d'abord puis ensuite, et seulement ensuite, vous commencerez votre développement principal. Ce sont certainement certains avantages qui peuvent être, qui peuvent être argumentés pour les développeurs et les clients ont convenu assez tôt ce qui sera réellement construit. Au tout début, vous définissez l'analyse, vous définissez la portée du travail. Et cela rend la planification un peu plus simple. la même manière progresse assez facilement mesurée. Vous avez tout ce travail en tête. Et par conséquent, vous pouvez très facilement dire combien cela a déjà été construit. Par conséquent, le logiciel peut être conçu complètement et très soigneusement en fonction de la compréhension complète de tous les livrables logiciels. Mais encore une fois, c'est la théorie. Et il y a certainement beaucoup d'inconvénients qui ont été observés dans la pratique réelle. Le plus important peut-être, je dirais que c'est le manque d'efficacité des exigences. Si vous commencez, lorsque vous commencez un nouveau projet, la réalité est que vous ne savez rien. Vous ne connaissez pas la complexité, vous ne savez pas encore comment construire quoi que ce soit. Vous ne savez pas ce que veut le client, comment le marché va réagir. Donc, peu importe ce que vous analysez au tout début, peut-être pas significatif à la toute fin une fois que vous lancez le produit. Une fois encore, tous les petits détails qui peuvent être laissés de côté, détails qui peuvent être complètement erronés. Ils retarderont ensuite l'ensemble du processus que l'on veut découvrir. En conséquence, un projet est non seulement retardé, mais devient très coûteux. De plus, une fois que vous lancez quelque chose après une longue période d' analyse, de développement et de test, il se peut que le produit soit finalement complètement indésirable ou peut-être dépassé au moment où il de la vie. La possibilité qu'un client ne soit pas satisfait du produit logiciel livré est donc très élevée. Et encore une fois, cela devient coûteux. 3. Développement agile: Donc, quand il s'agit d'agile, une brève leçon d'histoire ici est en quelque sorte autour de 2000, 2001, les gens se sont réunis, les développeurs de logiciels se sont réunis et ils ont beaucoup partagé la frustration de l'actuel état des choses, comment le développement de logiciels était abordé. Et surtout, ils sont tous d'accord pour dire que la planification et la documentation excessives du développement de logiciels sont inefficaces. Et ce qui compte vraiment, c'est de plaire leurs clients et cela se perd. En conséquence, ils ont introduit et mis au point le développement logiciel agile. Le développement logiciel agile tend ou cherche à diviser tous les travaux de développement en étapes plus petites. Et vous créez votre application, votre produit en une série de cycles. Donc, encore une fois, plutôt que de tout construire puis de lancer, vous vous concentrerez uniquement sur une certaine fonctionnalité que vous lancez ensuite , puis que vous continuez chaque cycle comme indiqué sur cette diapositive, nous allons incluez que vous effectuez des étapes similaires comme une cascade, que vous planifiez, que vous effectuez les tests de développement et que vous examinez. Mais encore une fois, surtout, vous expédiez ensuite, puis vous lancez chez les clients très tôt. Par conséquent, chaque version fournit un terrain de test où vous êtes censé rapidement obtenir des commentaires du client, du marché réel. Sur cette base, vous pouvez ensuite itérer et modifier votre produit en fonction des besoins réels du client et du marché. réalité, la principale considération En réalité, la principale considération ici en matière d'agilité est que le client est au cœur de l'équipe de développement et le client travaille très, très étroitement ensemble. Ils collaborent et c'est le client que les clients peuvent voir et utiliser le produit dès le début et, par conséquent, peuvent fournir des commentaires. Et sur la base de cela, les choses changent tout le temps. n'y a pas de plan linéaire qui est suivi. Mais après une publication rapide, c'est le client qui fournit ses commentaires et le plan est adapté en conséquence. Il y a quelques principes clés que nous avons élaborés en conséquence. d'autres termes, nous voulons nous concentrer sur les individus et les interactions plutôt que sur les processus et les outils. Ce sont les gens, les clients qui, au cœur de tout, ce n'est pas traité ou des outils ou que vous avez peut-être établi, nous adapterons les choses tout le temps de la même manière. C'est un logiciel qui fonctionne, des trucs réels qui fonctionnent et qui sont utilisés. C'est plus important que la documentation trop complète, les plans de projet, etc. Absolument, il est important d'écrire les choses pour partager les connaissances, mais le logiciel de travail est la chose la plus importante. J'ai déjà fait allusion à cela. La collaboration client est essentielle. La réalité de la vie, c'est le client ne sait pas ce qu'il veut. Ils n'y arriveront probablement pas correctement la première fois et ils changeront d'avis. Et donc travailler dur avec les clients, mais c'est en quelque sorte la réalité du travail. Il ne sert absolument à rien d'avoir un contrat en place et de s'en tenir au contrat. Quand il s'avère qu'un client n'est absolument pas intéressé a été écrit. Qu'est-ce qui y est écrit ? Oui. Il s'agit donc de s'adapter aux commentaires des clients pour investir ce qu'ils trouvent. Au lieu de s'en tenir à quelque chose qui a été négocié il y a de nombreuses années. Et cela m'amène vraiment au dernier point. Nous sommes juste, vous voulez réagir au changement. Vous ne souhaitez pas suivre un plan mis en place il y a quelque temps, mais plutôt répondre à ce que le client a perçu. Si vous êtes plus intéressé, ces principes se penchent sur le Manifeste Agile créé par les développeurs de logiciels en 2001. C'est un élément fondamental de la clé d' développement logiciel efficace qui est utilisé tout le temps dans tous les grands projets. Dans le logiciel. 4. Cérémonies agiles: J'ai vraiment envie de parler des cérémonies Agile, ce qui est un mot très chic pour les réunions. Je vais simplement aborder 44 cérémonies clés de réunions clés qui sont utilisées dans le cadre du développement de logiciels. Et quelle planification de sprint, de planification de sprint. Il y a beaucoup plus de détails derrière cela, mais assez abstrait, assez élevé, cela signifierait que vous planifiez ce que vous allez construire dans la semaine prochaine. Ainsi, tous les développeurs, analystes, concepteurs, etc., en particulier les clients et les chefs de produits , se réunissent et décident de la prochaine fonctionnalité, la prochaine chose que nous allons faire. Vous voulez construire ? Une femme s'y engage dans le cadre de cette séance de planification. Et l'objectif est de construire quelque chose dans les deux prochaines semaines et de mourir. Et encore une fois, suivi d'une sortie que nous avons vue que nous venons de voir. La prochaine chose est de diriger le stand-up quotidien. Vous devrez vous lever. Cela dit, je pense que la plupart des équipes le font réellement. Mais dans le nom, c'est quotidien et c'est l' équipe qui se réunit. Et l'accent est mis sur la communication, la communication régulière au sein du stand-up quotidien. Et ce n'est qu'une séance de 15 minutes chaque matin, vous communiquez ce que vous avez fait hier, ce que vous comptez faire aujourd'hui. Et surtout, si vous rencontrez des problèmes de risque que vous rencontrez lorsque vous avez besoin d'aide. Ainsi, chaque développeur, analyste, concepteur, quel que soit le membre de l'équipe fonctionnelle, dans cadre de la réunion. Par conséquent, vous recevez rapidement des mises à jour de chaque membre de l'équipe et comprenez où se trouve tout le monde et si quelqu'un a besoin d'aide. En matière de communication, la communication visuelle est importante. Vous souhaitez visualiser ce qui est réellement en cours de construction. Vous souhaitez obtenir des commentaires assez rapidement. Par conséquent, vous avez une démo de sprint qui peut se produire chaque semaine et se produire toutes les deux semaines environ. Mais l'idée derrière cela est encore une fois, vous voulez partager puis il est allé échouer souvent vous voulez obtenir des commentaires très souvent dans un bassin qui veut itérer. Ainsi, une démonstration de sprint peut aller d'un développement réalisé à un nouveau design, à un nouveau design, certains commentaires des clients que vous avez peut-être reçus. L'idée est que, dans toutes les différentes fonctionnalités, diverses fonctions au sein de l'équipe, vous souhaitez avoir un partage transfrontalier avec membres de l'équipe ce qui se passe. Enfin, il y a une rétrospective. Tout ce qui dit, c'est que l'équipe se réunit après certaines périodes. Cela a tendance à se produire après un sprint terminé. sprint peut durer une semaine, deux semaines, quatre semaines maximum. Mais l'idée est que l'équipe se rassemble et discute de ce qui s' est bien passé dans ce cycle de travail et de ce qui doit être amélioré. Encore une fois, c'est un outil de communication. S'assurer que les gens collaborent, s' assurer que tout le monde est heureux, s' assurer que l' équipe fonctionne efficacement. Et vraiment, toute utilisation d'un risque peut être atténuée dans tous les écarts futurs. 5. Les membres et les compétences de votre équipe: Donc, les théories, la note, la méthodologie sont géniales. Aucun d'entre eux n'a d'importance. Si vous n'avez pas vraiment quelque chose à mettre en pratique. Pour mettre quelque chose en pratique, il faut de vraies personnes, une équipe. Dans cette section, nous vous donnerons un aperçu rapide de ce à quoi ressemble une équipe Agile typique. Bien sûr, ne vous trompez pas comme toujours. Cela dépend de la taille des dépenses, de la complexité et de la maturité de votre projet. Mais l'idée est d'avoir une idée des membres typiques de l'équipe. Donc le même logiciel très célèbre est facile, les gens sont chauds et tout ira bien. Je trouve personnellement que c'est vrai. Investissez donc dans votre équipe. Jetons un coup d'œil. D'abord et avant tout dans le monde Agile, c'est le Scrum Master d'un mot de fantaisie. Si vous le souhaitez, vous pouvez lui pardonner de dire au chef de projet, chef de programme. Il y a des nuances à cela, mais pour une sorte de vue d'ensemble de haut niveau, je pense que nous pouvons dire que peut-être le cas d'un Scrum Master est responsable de répéter une colle entre tout le monde, entre tous les les parties prenantes, les gens, les développeurs, les analystes, les concepteurs déclinent le client, etc. C'est alors que le processus de planification a été géré. Ils pilotent plusieurs versions, ils facilitent la planification des versions. Ils sont responsables de la planification de toutes les cérémonies Agile que nous avons mentionnées. Ils donnent accès à des outils et à des personnes. Et à titre d'exemple, tout ce qui résulte d' une réunion de stand up quotidienne, fait, les actions dont ils sont responsables jusqu'à ce qu'ils trouvent le bon propriétaire. Scrum Master fournit également un rapport sur l'état du projet dans toutes les directions vers le bas et vers le haut. Ils appellent cela le support de la publication coordonnée. Ils sont responsables des évaluations des risques. Regardez donc, comme vous pouvez le constater, c'est un travail très diversifié, ensemble de responsabilités diversifié qui est difficile à définir. Mais ils veulent vraiment aider à protéger l'équipe et à débloquer tout problème et s'assurer que les processus Agile sont suivis pour être efficaces et efficaces dans votre développement. Chaque produit avec un propriétaire de produit, quelqu'un qui est responsable la vision de la vision à court et à long terme. propriétaire du produit est donc généralement le PDG du produit. Ils sont responsables du marché et de l' rentabilisation de tout type d'analyse concurrentielle. Ils ont tendance à être des experts de l'industrie, connaissant complètement l'industrie et les clients. Ils ont une idée du retour sur investissement et du bénéfice net. Ils représentent leurs clients. Souvent, plus qu'autrement, c'est le propriétaire qui répond aux exigences. Quelqu'un qui donne la priorité au travail et représente donc ce que le client, du moins ce qu'il pense vouloir. C'est donc une personne cruciale et cruciale au sein de l'équipe. Les analystes commerciaux sont souvent très proches du propriétaire du produit. Parce que, comme je l'ai mentionné, les exigences sont souvent déterminées par la partie du corps là-dessus. Mais c'est vraiment actuel au nom de l' analyste commercial qui est responsable de toutes les solutions analytiques. Ils augmentent la valeur commerciale en collaborant avec le propriétaire du produit. Ils créent un arriéré de produits, ce qui, encore une fois, c'est un mot fantaisiste de dire un ensemble d'exigences. Ils peuvent développer une analyse de rentabilisation en travaillant en étroite collaboration avec la partie Maja. Et surtout, ils écrivent les exigences. Ils ne s'arrêtent donc pas au haut niveau, mais ils entrent dans les détails, les écrivent tous et les transmettent au reste des équipes. Souvent, le plus souvent, les exigences doivent toujours être faites en équipe. Mais c'est l'affaire hors de cette responsabilité de les rédiger en faisant, par exemple, un plan de sprint. Enfin, ils peuvent soutenir les pratiques Agile. Ils ont encouragé l'amélioration des services et, bien sûr ils deviennent des experts dans certaines fonctions. Le concepteur UX et UI, il existe une différenciation importante entre l'UX et l'interface utilisateur. Us Designer, par exemple, peut mener des recherches sur les utilisateurs. Ils créent une persona utilisateur, qui est une représentation de cette recherche utilisateur. Ils peuvent déterminer l'architecture d'information d'un produit numérique. Ils peuvent esquisser les flux d'utilisateurs, ou ils peuvent esquisser à quoi ressemble une application, ce à quoi un design, un design pourrait ressembler, aimer, ressembler. Et ensuite, sur cette base, ils créent des prototypes qui sont testés. Par contre, mais pas toujours exclusivement, un concepteur d'interface utilisateur le place dans une conception d'interface utilisateur réelle. Moi, le design haute fidélité a l'air bien et il ressemble au produit final développé par l'équipe de développement. Dans l'ensemble, responsables de la cartographie du parcours, les flux de bout en bout sont en cours de définition et les conceptions sont responsables d'être assis avec les clients. Essayez de comprendre ce qu'ils recherchent. Et en faisant beaucoup de tests , puis en traduisant cela en une conception réelle. Un développeur, encore une fois, sous un nom , développe certaines fonctionnalités, mais je pense qu' il y a des responsabilités supplémentaires. Cela est souvent négligé. Les développeurs jouent un rôle crucial dans l' estimation de la taille de toute nouvelle exigence dans toute évaluation de la faisabilité technique. Ils ont aidé à comprendre ce qui peut être fait, dans quel délai, à quel point et peut être complexe, ce qui peut être nécessaire, etc. Ils se moquent donc avec une équipe, aident à mettre en œuvre les éléments en retard. Ils s'assurent que les tests sont effectués pour tout ce est fait est en cours de conception et de définition. En plus du développement réel, ils assurent également le contrôle de la qualité. Il n'est pas seulement en cours de développement, mais il est également testé en profondeur avant d'entrer dans la phase d'expédition vers le marché. Et j'ai mentionné les tests, j'ai mentionné avant qu'ils ne soient testés sont souvent négligés. Il est absolument crucial de tester votre application, tester vos nouveaux contrats à terme avant d'être expédiés sur le marché. Ainsi, la qualité des testeurs d'assurance qualité garantit l'assurance. Ils sont chargés de rédiger des plans de test, ce qui a permis d'accepter globalement les nouvelles fonctionnalités. Ils l'ont fait mentalement. Et ils automatisent également cette approche globale. Les développeurs et les testeurs travaillent en étroite collaboration et intègrent continuellement base de code avec ces versions manuelles et automatisées qui testent fonctionnellement et tests de régression, etc. Et nous aborderons plus tard les détails des tests simplement parce que je pense que c'est tellement important. Mais encore une fois, les tests mesurent la qualité qu'ils trouvent en premier lieu pour améliorer la qualité. Et ils ont appliqué un problème de qualité car et les meilleures pratiques sont mises en œuvre tout le temps. Maintenant, ne vous trompez pas. Ce ne sont là que quelques exemples. Les équipes sont petites et grandes en fonction la maturité, de la complexité et de la taille de votre projet Vous aurez besoin d' architectes de solutions pour définir le paysage technologique global. Vous devez disposer de certains environnements dans lesquels vous pouvez tester, écrire, coder, puis déployer. Vous voulez vous assurer que les versions sont effectuées de manière automatisée. Vous voulez probablement quelqu'un qui gère vos données. Vous avez besoin d'une équipe opérationnelle, chercheurs, de rédacteurs. Vous voulez vous assurer que le produit de bout est sûr et sécurisé. Et encore une fois, quand il s'agit, vous pourriez avoir besoin de certains avocats , de conseils de conformité et ainsi de suite. Donc, ça ne s'arrête pas vraiment là. Mais ce qui est important, c'est que l'équipe interfonctionnelle typique, peut-être composée de ces membres de l'équipe Agile qui ont été mentionnés. Nous avons oublié le plus important et nous avons insisté à quelques reprises et nous devrions donc encore une fois. C'est votre client. Vous devez être aussi proche que possible de votre client. Vous concevez pour votre client, pas pour vous-même. Et c'est l'erreur numéro un. Nous voyons tout le temps. Nous pensons savoir ce que veut le client, mais en réalité, nous ne faisons que répondre à nos propres besoins et à notre réflexion. Oui, bien sûr, il y a d'autres personnes comme moi et devrait donc être la bonne chose que nous construisons. Croyez-moi, vous ne savez pas et vous vous tromperez ou le bâtiment. Faites donc en sorte que votre client effectue des recherches client tout le temps, des tests avec clients et de la manière agile dont nous avons discuté, lancez souvent tôt, faites-le tout tout le temps et apprenez des erreurs. Découvrez les commentaires qu' un client vous fournit. 6. La phase d'idée: Ok, nous avons tout le temps parlé du cycle de vie du développement logiciel. Et c'est très simple car il pourrait être visualisé comme ça. Vous avez une idée. Vous souhaitez vous engager dans une phase de découverte où vous développez l'idée d'utiliser davantage exigences définies et que vous développez. Donc, premier ensemble de dessins. Vous le construisez, vous le testez, puis vous le lancez. Encore une fois, nous sommes dans le monde Agile ici. Ne confondez donc pas cela avec la méthodologie de la cascade, mais vous envisagez plutôt un certain avenir que vous construisez. Oui. Ensuite, vous fournissez une version et vous le faites encore et encore et encore. Nous avons déjà dit que tout bon commence par une idée. chances que vous en ayez un ou que vous n'en ayez absolument aucune, tous deux parfaitement bien. En idée. Cela arrive rarement lorsque vous vous asseyez simplement, vous devez y travailler. Et si vous n'avez pas assez d' idée, c'est très bien. Le meilleur point de départ est de vraiment entraîner tous les jours et de penser, vous savez, quel est le problème et quelle est la solution potentielle dans ma vie quotidienne ? Vous voulez vraiment vous demander tout le temps, pourquoi faisons-nous les choses d'une certaine manière ? Existe-t-il un meilleur moyen de résoudre un problème ? Et si vous pouvez identifier un problème ou une sorte d' inefficacité du marché, si vous voulez. Vous êtes déjà à mi-chemin. Maintenant. Il y a plein de façons de trouver des idées sympas et ça irait certainement au-delà du cadre de ce cours pour les explorer toutes, je vais mettre quelque chose dans la description si je le peux. Mais ce que j'aime et que j'utilise toujours, c'est la création et l'utilisation du parcours client. Le parcours client n'est vraiment rien d'autre un processus qui examine en quelque sorte ce que subit l'utilisateur. Supposons, par exemple, qu' un utilisateur consulte votre site Web de commerce électronique que vous construisez. Au tout début, il y a une journée de découverte. Ils doivent savoir que votre site Web existe, veut posséder ou ils peuvent être un navigateur, ils passent par ce qui peut être acheté sur votre site Web. Ils y réfléchissent. Ils font une évaluation du genre, est-ce que ça vaut la peine de faire cet achat et de mon temps ? Et ensuite, ils finissent par faire leur achat là où ils sont potentiellement très anxieux jusqu'à ce qu'ils voient leur auto-confirmation finale que le paiement a été effectué. Et c'est l'expérience de bout en bout. Vous souhaitez rechercher chacune de ces étapes sur le site d'action que subit l'utilisateur. Ainsi, par exemple, au stade de la découverte, vous êtes dans une sorte de phase de conscience. Vous essayez de vous renseigner sur le service que vous fournissez. L'action peut être que vous ouvriez l'application, le site Web que vous pouvez voir le tutoriel, et le genre d'émotion de l'utilisateur à ce stade est qu'il est curieux, puis le bébé, mais sceptique en termes de ce que vous essayez de les vendre. Mais ils sont curieux. Alors qu'ils sont inconscients à l'étape de l'achat ultérieurement, ils sont maintenant convaincus de votre produit et vous vendez le jour même. Ils ont envie de l'avoir. Et l'action consiste à effectuer le paiement, puis à passer à la caisse. Mais l'émotion ici est bien plus que ce qu'ils ne sont stressés et ils cherchent affirmer qu'ils devraient absolument indéfiniment effectuer ces paiements par points d'achat et, espérons-le, le seront paiements par points d'achat et alors. par la suite, je suis heureux de l'avoir fait. Et le point que j'essaie de faire valoir ici est dans le parcours client lui-même, c'est une capacité à comprendre ce que l' utilisateur ressent, ce qu'il compte et surtout ce que vous pouvez améliorer dans le cadre d'un parcours existant. Ou plus important encore, ce que vous pouvez créer un nouveau parcours et un nouveau produit ou un nouveau projet est quelque chose qui peut ravir le client, qui le rend heureux en ce qui le rend heureux en comprenant les différents processus, quelles sont les différentes étapes, en comprenant ce que traverse le client , c'est votre capacité, votre opportunité d'améliorer et de rendre ce processus très fluide. 7. La phase de découverte (technologie): Maintenant, avec une idée en tête pour votre projet, vous voulez vous assurer d'entrer dans une étape de découverte avant de créer quoi que ce soit. L'idée derrière l'étape de la découverte est d'étoffer vos besoins, jouer avec le premier ensemble de designs pour visualiser à quoi pourrait ressembler un produit. Vous n'êtes probablement pas surpris quand je dis que vous pouvez même tourner, devrait probablement même être testé avec clients déjà à ce stade. Et pour déterminer comment l'application va réellement être construite, quelles technologies vont être utilisées ? Dans cette optique, nous commencerons par la présentation de la solution. À ce stade, c'est l'architecte de solution du leader technologique et les différents développeurs qui se réunissent. Et ils veulent transmettre et déterminer la vue d'ensemble de la solution. Il fournit un aperçu de la façon dont chaque composant va être construit et mastiqué qui va être bien construit. Un aperçu de la solution est donc un squelette d'un programme, d'une caractéristique d'un projet en manquant un élément important dans cette architecture de projet, vous risquez de mettre en danger le succès de l'ensemble de votre projet. Nous ne pouvons pas assez insister sur ce point. Une architecture appropriée permettra d'économiser beaucoup de temps, d'énergie et de coûts à l'avenir. Vous voulez vous assurer que c'est bien. Désormais, toute conception d'architecture comprend généralement plusieurs couches au sein de l'application, telles que la couche de présentation en haut. C'est ce que l'utilisateur a tendance à voir que l'interface utilisateur supporte des composants, la conception de l'interaction, c'est ce que l'utilisateur réellement tendance à voir lors de l'utilisation de votre produit. Ci-dessous se trouve une couche métier qui implique ou inclut toute la logique métier ou les processus, tous les flux. Enfin, en dessous , se trouve la couche de données, qui inclut à son tour toute votre ancienne logique de données, la base de données elle-même, etc. Cela, à son tour, est en train d'être emballé. Vous voulez vous assurer que la sécurité est en place, quel que soit le type de configuration. Nous n'allons pas entrer dans les détails ici est évidemment un travail très complexe, et c'est généralement fait par un architecte de solutions, par le responsable technique et par les différents développeurs de votre équipe qui, ensemble, transmettez et imaginez comment votre produit est construit d'un point de vue de la couche technologique. Comme toujours, doutez de nombreuses approches et technologies dans leurs langages de programmation qui peuvent être utilisées pour construire une conception technique de niveau aussi élevé ou dans une pile technologique courte. Et comme toujours, ils ont tous des points forts et des lacunes. Certains sont moins chers à utiliser, mais peut-être moins performants. D'autres peuvent prendre beaucoup plus de temps à mettre en œuvre. Il pourrait même être exagéré ou être plus performant. En conséquence. La pire possibilité est de s'appuyer sur une pile technologique mourante ou peu fiable. Nous voulons donc nous assurer que vous ne le faites pas. Si vous commettez cette erreur, vous devrez peut-être reconstruire l'application entière. Ou vous payez une prime pour les développeurs qui vont de l'avant. Et encore une fois, sans entrer trop dans les détails, il y a tellement peu de principes clés que je veux souligner quand il s'agit de la pile. Et c'est-à-dire que vous souhaitez construire sur la base des principes suivants. Il doit être efficace. Oui, votre application doit donc effectuer les tâches et exécuter les fonctions dans n'importe quelle condition. Il doit donc être fiable avec n'importe quel type de charge, n'importe quel type d' utilisateurs se trouvant sur votre plateforme. Il doit être flexible. La solution choisie doit être facile à changer. Vous pouvez modifier des éléments et cela ne devrait pas influencer automatiquement l'ensemble du projet, manière négative. Vous devriez pouvoir l'étendre. Vous voulez donc pouvoir ajouter autant de fonctions que vous le souhaitez pour une application 2D. est important de noter qu'il doit être évolutif. Il devrait toujours être possible de le prolonger. L'architecture devrait permettre un développement direct et plusieurs threads parallèles. Enfin, la testabilité. Vous devriez absolument pouvoir tester facilement l'architecture, ce qui signifie que le nombre d'erreurs diminue et que sa fiabilité augmente. Encore une fois, c'est le travail de l'architecte de solutions. 8. La phase de découverte (conception et Roadmap): Aller, entrer dans une sphère complètement différente en termes de travail. Précédemment mentionné la conception UX. Encore une fois, il s'agit de la visualisation de ce à quoi pourrait ressembler le produit. Oui, donc dans la phase de découverte, nous commençons par créer des conceptions et des écrans, et nous commençons à attribuer chaque fonction et chaque donnée. Il est tout à fait normal qu' ils vivent dans plusieurs endroits. Tu n'as aucune idée de l'endroit où il est assis en ce moment, tu joues juste autour. Et le plus souvent, ce processus se déroule sur des tableaux blancs, sur papier ou, comme vous pouvez le voir actuellement à l'écran, une sorte d'outil de gribouillage où vous pouvez vous assurer de pouvoir jouer assez rapidement et changez les choses rapidement sans prendre trop de temps. L'idée ici est que vous voulez apporter des modifications, vous voulez le faire maintenant plutôt que plus tard dans le processus. Actuellement, il est beaucoup moins cher d'effacer quelque chose. Plus tard, dans la bibliothèque, vous devez réécrire le manteau entier. D'accord. Les flux de travail sont les voies d'accès, les utilisateurs peuvent se déplacer dans votre application. Oui, donc encore une fois, vous voulez considérer chacune des choses que l' utilisateur doit faire sur un certain écran, nombre de clics qu'il faut pour terminer une action. Vous voulez vous assurer que chaque clic est un additif à deux qui ne prend pas trop de temps ou de travail pour accomplir quelque chose. Lorsque vous rencontrez des problèmes avec votre flux de travail, mettez à jour ces filaires. Donc, ce que nous voyons et ces gribouillis sont appelés filaires là-haut, puis recommencez les tests avec un client, veillez à ce que cela fonctionne avant d' entrer dans des conceptions plus complexes. Ce que vous avez tendance à faire ici, c'est également utiliser des prototypes. Le modèle click-through est donc endroit où vous assemblez tous ces filaires et avez la possibilité les parcourir comme s'il s'agissait d'une vraie application, mais sans avoir fait de développement réel. Encore une fois, si c'est un moyen fantastique de tester quelque chose au téléphone très rapidement pour des tests plus réalistes et obtenir des commentaires tout de suite. Il s'agit d'une façon fantastique de comprendre quels sont vos besoins. C'est ce qu'un analyste commercial intervient. Par exemple, disons qu'une UX est en danger déterminé une sorte de conception UX sur le côté gauche. Comme vous pouvez le voir, nous avons un menu partout où barre de recherche nous avons une sorte de filtre en haut, vous avez diverses choses. Cliquez donc sur des ateliers ou une place de marché ou tout ce peut se trouver dans cette application particulière. Ainsi, il était facile de transmettre actuellement visuellement besoin d'être mis plus en détail en 3D, ce qui devient l'arriéré des exigences. Ainsi, un analyste commercial travaillera avec le propriétaire du produit, avec les concepteurs, avec les développeurs pour s'assurer de la vision et que les conceptions sont maintenant mises en place dans les exigences réelles. Et ils sont définis avec des détails plus anciens qui sont nécessaires pour que le développeur puisse construire. Enfin, et encore une fois, un aspect complètement différent du travail est la feuille de route du produit. C'est ce qu'intervient un propriétaire de produit, le PDG du produit. Et au cours de la phase de découverte, vous voulez avoir une idée quelque peu. Il n'est pas nécessaire que ce soit trop précis, mais vous voulez avoir une idée des thèmes hautement prioritaires qui aideront chacun à réellement concentrer son temps et son énergie pour faire quelques choses. Va bien, produit agile, feuille de route est l'idée derrière cela en tant qu'outil de navigation. Oui, cela aide les équipes à se concentrer sur l'endroit où elles se trouvent, où elles vont, mais leur donne également la liberté de corriger le cours au besoin. Par exemple, si nous sommes un élément clé en ce moment, nous comprenons ce que nous construisons au cours des prochains mois. Mais c'est toujours la liberté de changer et adapter ce qui peut être construit au Q2, Q4. Donc, une feuille de route produit agile est une stratégie de haut niveau visualisée, et elle est axée sur les résultats plutôt que sur les résultats et les discussions, thèmes et les époques plutôt que sur les fonctionnalités. Rien n'est donc défini à ce stade. Donc, la visualisation et l' indication de ce qui va arriver. Cela permet également de communiquer la stratégie produit avec les autres parties de l' organisation et avec un client. Et assurez-vous d' obtenir l'adhésion de votre équipe et des parties prenantes clés. Dans l'ensemble, il s'agissait d'un aperçu rapide des diverses activités que vous pourriez faire pendant la phase de découverte. Comme toujours, il y en a beaucoup plus. Cela dépend du projet. Mais regardez, il est absolument essentiel de s'assurer que vous disposez d'une base technologique solide d'une base technologique solide et d'une vue d'ensemble des solutions. Vous voulez vraiment visualiser à quoi ressemble le produit final et le tester auprès des clients. Très tôt. Vous souhaitez avoir une idée des exigences qui seront élaborées dans les premières semaines à venir par l'analyste commercial. Et vous voulez vous assurer que le PDG du produit, le propriétaire du produit, est en mesure de transmettre la vision et l'endroit où nous allons, non seulement dans les prochaines semaines, mais avec une vision à long terme. dit et à quoi ressemblera le produit final. Si cela est fait en plus de toute autre chose que vous pourriez devoir faire, nous entrons dans la phase de facturation. 9. La phase de développement: Ok, construit probablement l'une des les plus intéressantes et périodes les plus intéressantes et les plus intenses du projet, sans doute la phase d'idéation et de découverte, ainsi que la phase de lancement vers la fin, prend beaucoup de temps plus court que la phase de construction, peut aussi bien représenter 70, 80 % du projet de bout en bout que vous gérerez la phase Bill et, par conséquent, incroyablement important, mais aussi là où la plupart des choses vont mal. J'ai donc besoin d'être amélioré. Il s'agit d'un processus long et ne veut pas être négligé. Nous allons jeter un coup d'œil sur le travail quotidien de l'équipe, qui se trouve dans le monde Agile que vous allez suivre. Ce flux de travail est à nouveau de haut niveau, c' est-à-dire que vous avez l'arriéré d' exigences que vous avez déjà établi. Et donc, chaque jour, vous allez vraiment choisir l'objet que vous allez aborder. Vous allez le mettre dans OpenFlow. Et puis, au fil du temps, cela doit être sélectionné pour être en cours de développement, je suis en cours de développement. Il est inscrit dans la colonne Assurance qualité où elle est testée. Une base là-dessus. Si c'est passif, et s'il n'est pas passé, il revient à l'état en cours. Le plus souvent, cela se produit physiquement sur un mur, sur un tableau blanc ou similaire, bien sûr, peut également être fait numériquement. Mais souvent, ce n'est qu'un tas d' affiches qui sont transmises d' une colonne à l'autre. Et c'est un excellent moyen pour les équipes de visualiser le travail accompli. Et les bases de données, en particulier en faisant un stand up pour visualiser et transmettre à tout le monde ce sur quoi on travaille activement. Et très rapidement, vous serez en mesure voir s'il y a un obstacle, s'il y a un tel bloqueur. Pourquoi un certain ticket, pourquoi certaines exigences ne vont pas de l'avant ? Il s'agit donc du flux de travail global de bout en bout. Vous répondez à une exigence et vous vous frayez un chemin à travers les différentes étapes du flux de travail. Et le point de vue de l'analyse commerciale médiocre C'est maintenant l'objectif de rédiger les histoires d'utilisateurs, les exigences qu'elles sont, appelées histoires d'utilisateurs. Et à titre d'exemple, si vous prenez, par exemple, le menu, qu'il s'agisse maintenant de certaines fonctionnalités, certaines exigences. Vous avez tendance à l'écrire dans le format suivant, c' est-à-dire le, vous définissez pour qui il s'agit. Dans ce cas, il s'agit donc d'un utilisateur qui s'est déjà verrouillé dans votre application en tant qu'utilisateur authentifié, vous définissez ensuite l'objectif de cet utilisateur particulier. Donc, dans ce cas, je veux accéder au menu latéral qui est l'objectif souhaité. Et ensuite, vous dites, pourquoi ? Alors quoi, qu'est-ce que c'est, alors quoi ? Et donc vous définissez cela de manière à ce que dans ce cas, je puisse voir n'importe quelle sorte de fonctionnalités supplémentaires qui peuvent être disponibles dans, au sein du produit. Encore une fois, le diocèse de l' entreprise a quitté ce travail. Cela va beaucoup plus en détail, mais à un niveau élevé, il est répertorié comme une histoire d'utilisateur. Où trouver qui est l'utilisateur ? Que veuvent-ils faire, quelle est l'action et pourquoi ? Quel est l'objectif ? En tant qu'utilisateur authentifié, je souhaite accéder à un menu latéral afin de pouvoir voir toutes les fonctionnalités supplémentaires qui retouchent une sorte de tâche de très haut niveau pour l'analyste commercial. la même manière, un concepteur UX que nous avons déjà abordé a défini divers flux de travail. Les baies, les écrans UX, les écrans américains expérimentés qui peuvent regarder vers le haut, ressemblent à ceci. À ce stade, pouvez-vous gribouiller et certainement rien que vous voulez expédier et lancer sur le marché réel. C'est donc maintenant à ce stade le genre de tâches pour les concepteurs de mettre cela dans quelque chose d'un peu plus brillant, dans une interface utilisateur réelle. Ainsi, il peut, par exemple, devenir quelque chose comme ça. Oui, vous passez d'une interface UX et cela est ensuite interprété par les concepteurs comme de l'interface utilisateur final sinon les développeurs vont en fait reprendre et développer Naturally. Nous devons également construire, nous n'allons absolument pas y aller dans ce cours particulier. Beaucoup de façons différentes de construire du code, passant par différentes langues et ainsi de suite. Il y aura un cours complètement différent, tout à fait différent. Nous allons donc devoir ignorer ça. Mais encore une fois, gardez à l'esprit que nous suivons la méthodologie Agile dans notre exemple particulier. Oui, nous allons donc passer en revue le flux de travail d'analyse, facturant le tout pour une certaine fonctionnalité et ils le publient très rapidement afin que nous obtenions immédiatement les commentaires du client. Avant de le faire, il y a un aspect que je veux souligner, c'est le test. Nous n'aborderons donc pas le développement aujourd'hui, mais je pense que les tests sont quelque chose que nous voulons rapidement jeter un coup d'œil avant la sortie d'un avenir. Il devrait faire l'objet d'un examen approfondi de la nourriture, et il devrait le faire tout le temps dans l'idéal, cela devrait être fait automatiquement. Jetons donc un coup d'oeil là-dessus. 10. La phase d'essai (1): Donc, en testant, j'ai déjà mentionné à maintes reprises à quel point je trouve des tests cruciaux et tout à fait importants et que dans n'importe quel cycle de vie de développement logiciel. Heureusement, la technologie de nos jours nous permet une durée de vie beaucoup plus facile des tests de capsules et beaucoup d'entre eux peuvent être automatisés, alors que certains aspects, bien sûr, doivent encore être effectués manuellement par le les développeurs, tous les tests, les équipes d'assurance de la qualité ou même les affaires en dehors de cela, quels que soient les gestionnaires de parc et ainsi de suite. Si nous examinons l'application, tests sont toutefois cruciaux Examinons donc les différents types de tests qui sont généralement effectués. L'un est le test unitaire, généralement dans un travail dégénéré effectué par les développeurs. Ils utilisent des tests manuels ou automatisés et s' assurent que chaque unité de son logiciel répond aux exigences du client. Une fois de plus, vous pouvez soit tester ces cas de test, principalement ceux qui nécessitent bien sûr beaucoup de temps. Cela prend beaucoup de temps, c'est répétitif et nécessite donc beaucoup d'efforts. bonne nouvelle, c'est les outils d' automatisation des tests automatisés de nos jours, ils peuvent vous permettre d' enregistrer et d'enregistrer un test, et donc vous pouvez le rejouer autant de fois que nécessaire sans aucune sorte de plus. intervention humaine. Ainsi, chaque fois qu'une nouvelle froideur développée et déployée avant le déploiement, est développée et déployée avant le déploiement, un développeur doit rédiger son test unitaire et exécuter les tests unitaires, veillant à ce que cette nouvelle pièce de code a été rigoureusement testé en fonction de l'exigence. Ensuite, les tests d'intégration, absolument cruciaux. Considérez-le comme des modèles individuels qui sont d'abord testés isolément dans le cadre des tests unitaires. Mais une fois que cela a été terminé, il y a ensuite intégré. Donc, si vous pensiez, considérez-le comme un bâtiment, une voiture, vous pouvez tester les portes, peut-être, vous savez, tester le moteur, ce coffre, quelle que soit la couleur, quelle que soit sa couleur. Mais ensuite, un par un, en intégrant lentement cela en un seul système. Par conséquent, les tests d'intégration garantissent que tout nouveau code modifie tout ce que vous ajoutez à l'ensemble du système n' affecte pas les fonctionnalités existantes du logiciel. Vous voulez vous assurer de vérifier que le comportement combiné est logique. Vous souhaitez vérifier si les exigences sont correctement implémentées ou non. Cela est souvent suivi par des tests de système, qui signifie que nous voulons tester tout un système. Tous les modèles, tous les composants sont intégrés afin de vérifier que le système fonctionne comme prévu ou non. Encore une fois, si vous pensez à l'exemple de la voiture, c'est génial que vous ayez vérifié soigneusement que chaque article a été testé à l'unité. Vous n'aviez pas vérifié qu' ils sont tous intégrés et intégrés testés lorsque vous montez la voiture. Mais enfin, n'oubliez pas toute la voiture elle-même doit encore être vérifiée pour tous les aspects, exigences, et doit être conduite en douceur, doit avoir les bonnes pauses et les bons engrenages et doit travailler sur des milliers et des milliers de kilomètres en continu. La couleur doit être logique. Le système dans son ensemble était donc un élément crucial à tester et cela se fait après les tests d'intégration dans le cadre des tests du système. J'ai peut-être mentionné le client de temps à autre dans ce cours, et sans surprise ici, tests d'acceptation des utilisateurs sont communément appelés «  UAT ». Et récompenser cela signifie, vous savez, montrer le produit ou la fonctionnalité à un client et qu'il effectue les tests avant. Ainsi, de vraies personnes, vrais clients, ont déterminé s'ils pensaient que le logiciel que vous avez créé peut être accepté dans, peut être mis en ligne. Cela n'est donc pas aussi automatisé que les exemples précédents. agit plutôt de sessions exigeantes de temps, mais j'espère que des sessions irrégulières où de vraies personnes, vrais utilisateurs se réunissent dans le cadre de petits groupes. Cela peut être de la famille en France, je peux être des premiers adoptants, qui pourraient être des utilisateurs de puissance, c'est-à-dire des personnes pour lesquelles vous payez de l'argent. Et vous voulez vraiment avoir différentes façons de tester que vous voulez parfois leur montrer le logiciel et demander ce qu'ils pensent. D'autre part, vous voudrez peut-être être très précis écrire des cas de test et fournir des échantillons très spécifiques à explorer par ces utilisateurs particuliers. Et ensuite, ils ont l' occasion de vous faire part de leurs commentaires. 11. La phase d'essai (2): Cela vous donne vraiment l'occasion d'avoir des commentaires très ouverts de la part de personnes qui vont finalement utiliser votre application, dans le monde réel. La performance est, bien sûr, un aspect crucial. Imaginez que vous construisiez un site Web, mais il ne charge pas les personnes qui ont tendance à cliquer après le 2.5e de ne pas avoir vu vos résultats. Il est donc extrêmement important de tester les utilisation normaux et les heures de pointe, mais aussi pour tester votre application IE, vous essayez délibérément de trouver des moyens de casser le système. De plus en plus d'utilisateurs êtes-vous assimilé ? Et vous voulez vérifier, est-ce que le système évolue. Il y a beaucoup de choses en retour au framework d'applications et d' architecture Oval dont nous avons parlé précédemment. Vous voulez vous assurer qu'une technologie que vous devez concevoir et envisager, en fait ce travail est capable de traiter avec tous les utilisateurs accédant à votre plateforme. L'accessibilité est généralement appelée « d' accessibilité du contenu Web ». Il s'agit d'un ensemble de recommandations internationalement reconnues pour améliorer l'accessibilité Web. C'est un exemple particulier pour la conception Web. Mais cela s'applique vraiment à tout ce que votre application ou tout ce que vous créez dans un monde numérique, vous voulez vous assurer que tout le monde peut et est capable d'utiliser votre produit final. Ce dont j'étais composé, c'est donc de m'assurer que la vision est très claire. dire que vous avez peut-être, vous savez, utilisateurs gravement malvoyants. Ils doivent pouvoir utiliser votre application. Il y a peut-être des personnes malentendantes et peut-être sourdes. Et ils doivent disposer d'outils particuliers pour accéder à la mobilité des applications. Ceux qui peuvent avoir des difficultés à utiliser une souris ou un clavier, vous souhaitez leur proposer des alternatives. Et puis en pensant, comprendre les personnes atteintes de dyslexie, d' autisme, de difficultés d'apprentissage. Encore une fois, vous souhaitez proposer une approche simplifiée pour utiliser l'application. Par conséquent, même si c'est légal ou non, vous voulez absolument penser à l'accessibilité dès le début. Si vous voulez redessiner notre besoin de redessiner rétrospectivement, croyez-moi, cela prendra du temps. Cela va nécessiter des efforts et des coûts insensés pour le faire. Considérez donc cela comme une exigence clé absolue dès le début, exécutez tous vos tests d'accessibilité dès le début de l' auto-développement. Et vous partirez à un truc volant. De la même façon. La compatibilité garantit que votre logiciel est capable de fonctionner sur différents navigateurs et systèmes d'exploitation. Aujourd'hui, nous avons des milliers de tailles d' appareils à gérer. Ils sont tous différents sur différents écrans. Pensez-y, iOS, mais surtout Android et avez beaucoup différencié les tailles d'appareils et les systèmes d'exploitation. Vous savez donc constamment vous voulez vous assurer que le nouveau logiciel que vous lancez dans n'importe quel nouvel avenir que vous lancez est compatible avec ces exigences qui peuvent être effectuées manuellement, mais de plus en plus, la plupart de ces opérations sont automatisées par le biais d'émulateurs et simulateurs où vous n'avez même plus besoin d'un appareil. Tout est fait dans le Cloud. Et vous pouvez vous assurer que le code s'exécute sur toutes ces plateformes. Et enfin, de plus en plus crucial, je pense pour tout le monde et surtout parce qu'il a reçu un certain nombre d' examens médiatiques, c'est bien sûr la sécurité de l'application. Vous devez vous assurer que vous effectuez des tests réguliers du stylo. Vous effectuez des tests de sécurité ? Écoutez, si vous avez une boutique de commerce électronique, par exemple, et que vous pouvez regarder des achats en ligne, vous régresserez les informations personnelles, les informations de carte de crédit, etc. L'utilisateur doit vous faire confiance. Et si ce n'est pas le cas, vous n'avez pas de clients. Et B, vous avez peut-être un gros problème avec les autorités. Mais vous allez voir qu'aucun moyen de sécurité ne permet d' accorder un accès autorisé pour protéger les données. Et l' accès non autorisé est restreint. Et vous voulez vous assurer que vous ne présentez aucune vulnérabilité dans votre propre code code personnalisé ou aucun code tiers. N'oubliez pas que si vos utilisateurs de différents fournisseurs apparaissent avec un tiers, vous voulez absolument vous assurer qu'ils sont également en mesure de résister à toute attaque. Encore une fois, il ne s'agit que d' un aperçu général des tests typiques effectués. Comme toujours, il y en a plus. Il est doux en fonction de votre attente, votre complexité et de la taille de votre projet en ce qui concerne la quantité que vous en faites. Mais il est essentiel que les tests soient une sorte d'aspect clé et monétaire de votre application logicielle. Cette approche. 12. La phase de lancement: Et nous y sommes presque. L'heure du déjeuner, probablement la plus intense, peut-être la partie la plus excitante de tout le cycle de vie que nous ayons regardé jusqu'ici. Vous avez probablement réfléchi à votre idée depuis des années, voire plus longtemps. Et maintenant, ces derniers mois, vous avez créé votre code, vos développements, conception et maintenant vous êtes prêt à lancer la première série de fonctionnalités sur le marché. En ce qui concerne le lancement, c'est toujours une bonne idée de commencer avec les amis et la famille. Vous avez un public un peu plus sympathique. Et vous pouvez tester et obtenir des commentaires. Très tôt. Encore une fois, je me répète, mais ne sous-estimez pas l'importance d' une sorte de commentaires amicaux initiaux des clients où vous pouvez rapidement itérer et améliorer votre produit. N'oubliez pas que lorsque vous lancez quelque chose, par exemple, dans un App Store, il s'agit toujours d'un processus que vous voulez vous assurer que l'APSA est correctement configuré pour sa version. Vous devez remplir quelques formulaires pour chaque magasin que vous allez pour soumettre un écran montre un peu de matériel marketing, une description tout à fait. Un peu de travail y a donc été fait. Et qu'il s'agisse de Google ou d'Apple, Mallory peut passer en revue toutes ces applications soumises à l'App Store. Eh bien, Apple y est tellement plus que Google. Mais il est possible qu'ils ne fassent pas pression un tas de modifications en fonction de votre configuration. Gardez donc cela à l'esprit quand il s'agit de votre chronologie. Une fois que vous êtes en direct et les produits sont disponibles sur le marché réel, il y a bien sûr plusieurs façons de les promouvoir autres que leurs amis et leur famille et en quelque sorte le bouche-à-oreille. qui est évident de nos jours, ce sont les médias sociaux. Que ce soit Twitter, Tiktok et autres. Des réseaux professionnels comme LinkedIn. Il s'agit d'une avenue de données plus pour les blogueurs et les vloggers, progresser par le marketing d' affiliation. Et bien sûr, si vous avez l'argent, vous pouvez participer à une campagne publicitaire plus complète. Faites-le lentement au début et évidemment de manière plus agressive quant au moment où vous planifiez un lancement complet. Mais une chose que je tiens à souligner, c'est que ce n'est pas la fin, n'est-ce pas ? développement d'applications ne s'arrête donc pas à la phase de lancement. Il s'agit plutôt d'un cycle d'itération continu, comme nous l'avons maintes fois souligné dans le monde du développement Agile. Vous devez donc vous assurer surveiller l'application et l'adoption par les utilisateurs. Vous voulez vous assurer que vous êtes en mesure d'accéder à tous les plantages qui ont pu être survenus. Il existe des bibliothèques qui les suivent. Ils vous indiquent ce que faisait l'utilisateur, l'appareil que nous utilisons, toutes sortes d'informations techniques qui peuvent être importantes pour reproduire le problème. Vous voulez vraiment commencer à mieux comprendre vos utilisateurs. Vous souhaitez utiliser des outils analytiques tels que Google ou Facebook Analytics. Encore une fois, cela vous aide à comprendre qui utilise l'application. Quel est leur âge, leur sexe, où ils viennent, quelles langues parlent-ils, etc. Combien de fois utilisent-ils l'application lorsque nous faisons la journée ? Combien de temps est passé dans l'application, quels écrans sont visionnés, principalement ceux qui ne le sont pas, etc. Je suis fantastique, des opportunités géniales. La création de cartes thermiques où vous pouvez voir où les gens cliquent, quels écrans. Je cliquerai le plus souvent dessus et ainsi de suite. Mais l'idée ici est que vous êtes en mesure de vous améliorer en fonction de ces analyses. Vous ne voulez pas simplement vous appuyer sur des parties du chapitre qui y sont rarement utilisées, mais vous voulez investir là où se trouve l'action, quel est le plus grand potentiel de croissance ? Et ce sont vraiment ces outils qui fournissent des informations, veillent à mesurer les performances. Je l'ai déjà mentionné, les gens ne sont pas très patients à cet égard. Vous souhaitez donc mesurer les performances techniques et la facilité du système que nous déployons, toujours une surveillance approfondie des performances en place. De cette façon, vous pouvez suivre le nombre de fois qu'une action a eu lieu et combien de temps elle a pris. Et, encore une fois, vous trouvez que c'est une bonne occasion de faire de l'espace pour l'optimisation. Vous pouvez également envoyer des alertes et un endroit pour savoir quand une action est peut-être un peu plus lente si votre serveur votre environnement est surchargé. Donc, vous êtes assez cryptique et cherchez à les réparer aussi. Et puis, bien sûr, même une sorte de surveillance manuelle lorsqu'il s'agit de regarder l'App Store, par exemple, répondent aux commentaires des clients sur les coûts. Tenez compte de leurs commentaires , assurez-vous que le chef de produit les voit bien. Et selon le, c'est le feedback clé dont vous avez besoin pour vous améliorer et ils obtiennent rapidement d'autres prochaines itérations de votre application. 13. Conclu: Cela nous amène à la conclusion où se termine le cours. J'espère que ces différentes étapes du cycle de vie du développement logiciel ont sens et que cela vous a été quelque peu utile. Ecoutez, s'il y a une chose que je dirais à la toute fin , c'est qu'une taille unique n'est pas ça. Alors que la méthodologie du développement Agile et que le processus en lui-même fonctionne et qu'il peut être appliqué de manière cohérente. Bien sûr, cela dépend largement du projet, la complexité, de la taille , du, du, du financement disponible pour vous, des compétences des gens, etc. Et chaque projet est différent. Dans l'un d'entre eux, vous pouvez être lourd, lourd sur la technologie, les systèmes back-end et le domaine commercial, tandis que d'autres, il peut être beaucoup plus axé sur la conception graphique et l'ingénierie du son et le développement là-bas. Et vous devez vous adapter au besoin. Et la seule chose que je dirais du point de vue de la gestion de projet, ou que vous soyez chef de produit ou PDG d' une petite start-up est dûment fondée sur les valeurs. Parce que vous, en tant que premier ministre, en tant que chef de projet ou quelqu'un qui n'est pas impliqué dans chaque étape, mais plutôt le lien entre les gens. Vous ne serez jamais l'expert en quoi que ce soit. Vraiment plus. C'est vous qui avez fourni une vue d'ensemble holistique, mais vous n'êtes pas un expert en domaine. Donc, dûment par ces valeurs, j'aime celles affichées à l'écran. Confiance, empathie, transparence et collaboration. Assurez-vous que les équipes peuvent s'auto-organiser, les habiliter, qu'elles puissent faire ce qui est nécessaire pour résoudre le problème. Et je pense que si vous dirigez par ces valeurs et si vous établissez cette confiance et croyez en quelque sorte aux compétences des gens, alors vous pouvez aussi construire un prodrug tueur, un produit numérique génial qui le cycle de vie du développement logiciel présenté aujourd'hui. C'était ça. J' espère que c'était amusant. J'espère que cela s'est avéré utile en cas de questions. N'hésitez pas à me contacter et nous vous verrons la prochaine fois.