- Mobile
- Web
- Services
- À propos
- Contact
Développement mobile
Développement agile
Toujours commencer par le Backend (si nécessaire)
Si un backend est nécessaire et doit encore être développé, il n'est pas logique de commencer tout de suite le développement de l'application, car de nombreux domaines et processus de l'application dépendent fortement du backend. Il a été prouvé dans la pratique qu'il est possible de donner au backend un délai d'environ 1 à 2 semaines. De cette façon, le backend a toujours une longueur d'avance dans le développement.
Dans le cadre d'un projet concret, par exemple, vous donneriez au développeur principal un délai d'environ deux semaines pour développer l'interface d'enregistrement et de connexion des utilisateurs. Après cela, le développeur de l'application commencerait par le développement de l'application au bout de deux semaines et mettrait d'abord en œuvre exactement ces fonctions, tandis que le développeur du back-end programme déjà les fonctions et interfaces suivantes.
Si l'on développe pour plusieurs plates-formes, par exemple iOS et Android, on pourrait, dans un souci de minimisation des risques et des coûts, prévoir ici aussi une compensation supplémentaire. Par exemple, le développeur iOS serait le premier à mettre en œuvre l'enregistrement et la connexion. Le développeur Android met en place ces fonctionnalités une semaine ou deux plus tard. De cette façon, vous pouvez identifier et corriger les bogues et les problèmes de l'interface principale pendant le développement d'iOS. De cette façon, vous évitez que deux développeurs ne puissent continuer à travailler au même endroit parce qu'il y a un problème d'interface, par exemple. De cette façon, vous apprenez rapidement les problèmes d'une plate-forme et pouvez transférer les solutions aux autres plates-formes.
Prototypes et modèles à cliquer
Selon le projet d'application, il peut être judicieux de tester d'abord la conception de l'application sur un prototype au lieu de développer directement l'application. Cette approche est particulièrement recommandée si le client n'est pas "app-savvy", c'est-à-dire qu'il n'a aucune expérience du développement ou même de l'utilisation d'une application et qu'il a des difficultés à imaginer les UX/flux de travail/vues de l'application en fonction de la conception créée. Ou, si c'est une application très complexe. Mais nous y reviendrons dans un prochain article.
Le développement de l'application à proprement parlé
Une fois les premières interfaces dorsales en place et les graphiques individuels pour la conception disponibles, le développement de l'application peut commencer.
En tant que développeur d'applications expérimenté, on s'appuie sur une approche agile ou itérative. Les termes "agile" et "itératif" sont actuellement sur toutes les lèvres - ce qui n'est pas étonnant, car cette façon de travailler a plus que fait ses preuves. Mais qu'est-ce que cela signifie exactement ?
Tout simplement : contrairement au "passé", un projet n'est plus développé en une seule pièce de A à Z et ensuite présenté au client (méthode dite de la "cascade"), mais est plutôt mené pas à pas ("itératif") afin d'"approcher" la solution optimale en échange constant avec le client.
Le client est impliqué dans le processus de développement de l'application, ce qui ne présente que des avantages. En tant que développeurs d'applications, nous divisons le projet en sprints/phases (appelés itérations), dont chacun est présenté au client comme une version de test exécutable à des moments prédéterminés. Le retour d'information explicitement souhaité par les clients est ensuite directement intégré dans l'itération suivante.
Exemple : Développement itératif / agile d'une application de taille moyenne.
- Il est développé en sprints de 1 à 2 semaines - c'est-à-dire que toutes les 1 à 2 semaines, il existe une version de test exécutable, que le client peut installer et tester sur son iPhone/iPad.
- Le client teste et donne son avis, tandis que la prochaine intégration est en cours de développement.
- Il existe un processus prédéfini, par exemple un système de tickets ou des réunions, la manière dont le retour d'information est donné, afin que celui-ci puisse être rapidement et facilement intégré dans le processus de développement.
- Les nouvelles demandes de changement sont les bienvenues
- Le client classe les demandes de modification par ordre de priorité, de sorte qu'il soit toujours clair si une modification ou une nouvelle fonction a une priorité plus élevée du point de vue du client/produit.
- Dans le nouveau sprint suivant, les changements dont la priorité est suffisamment élevée pour être inclus dans le sprint sont mis en œuvre jusqu'à ce que l'effort estimé remplisse les ressources pour la période.
- Conséquence: en raison de l'effort accru pour les changements, moins de nouvelles fonctionnalités sont mises en œuvre. C'est également logique, le simple fait que le client ait un retour d'informations ne donne pas à la semaine plus de jours, mais est souvent oublié dans la planification du projet.
En raison de la brièveté des boucles de rétroaction et de la hiérarchisation des priorités, les composants construits de l'application sont également vraiment terminés le plus rapidement possible et tous les composants ne sont pas "presque terminés" à 95% à la fin du projet.
Grâce à une grande transparence, le client peut toujours décider lui-même si les changements ou le respect de certains délais sont plus importants pour lui.
S'il n'y a pas de changements, l'application sera terminée à la date prévue - S'il y a des changements, l'application sera terminée plus tard. Cependant, il est possible, par exemple, de publier une version anticipée, puisque les fonctions sont exécutables, et de livrer plus tard les demandes de changement avec une mise à jour.
Les avantages en bref
Le développement d'une telle application peut sembler difficile à calculer et donc financièrement risqué pour des oreilles non informées. En fait, c'est le contraire qui est vrai. Pour illustrer cela, je voudrais comparer la méthode classique de la chute d'eau avec l'approche moderne et agile.
- À tout moment, le client a une application tiède en main. Si vous le souhaitez, il peut être lancé sur le marché avant la date prévue, tandis que les touches finales sont apportées en arrière-plan lors de sprints ultérieurs.
- Transparence maximale de l'état d'avancement du projet grâce aux versions d'essai.
- L'état de développement actuel de l'application peut être consulté à tout moment
- La quantité de changements à venir est toujours gérable, au lieu d'être confrontée à une très longue liste à la fin, ce qui met en péril toutes les échéances, comme c'est le cas avec la méthode de la cascade.
- Les composants intégrés sont finis plus tôt et peuvent donc être livrés plus tôt, au lieu que tous les composants soient toujours "presque" finis.
- le client est considéré comme faisant partie de l'équipe et ses commentaires sont les bienvenus - en particulier du point de vue du client, un critère de qualité important
- à la fin le résultat souhaité au lieu d'une surprise
On peut comparer cela à la procédure selon la méthode de la cascade
- Description du projet par concept ou exigence/ fiche de spécifications
- Plusieurs semaines ou mois de développement sans contact avec les clients ni retour d'information
- En fin de compte, il devient souvent évident pour le client que les détails doivent être résolus différemment - ce qui se traduit par une longue liste de demandes de changement - avec les coûts et les effets de temps correspondants
Inconvénients de la méthode de la cascade
Les coûts de retour d'information sont plus élevés et moins prévisibles. Et : ce n'est pas parce qu'il n'y a pas de retour d'information de la part des clients pendant le processus que cela signifie que les clients n'auront pas de demandes de changement dès qu'ils auront testé l'application eux-mêmes pour la première fois... et le "surcroît d'effort" que représente un retour d'information arrive de toute façon et le plus souvent deux fois à la fin.
Obtenez gratuitement un devis