Nous travaillons en mode agile, cela signifie notamment que nous travaillons de manière itérative et incrémentale. C'est-à-dire que nous répéterons certaines étapes chaque sprint pour construire brique par brique un projet qui réponde vraiment aux besoins de nos clients.
C’est quoi un sprint ?
C’est un espace-temps de 2 semaines qui représente un cycle de développement. Chaque cycle est planifié avant de le commencer et on fait un point d'étape à la fin pour vérifier que tout est bon avant de se lancer sur le prochain.
D’ailleurs, c’est l’heure de votre premier sprint de développement ! Mais il manque une dernière étape avant de vous lancer.
Et oui, c’est l’heure du sprint planning, autrement dit, la planification du travail à accomplir. Car il vous faut vérifier que vous avez tout ce dont vous avez besoin et organiser votre travail afin de commencer sur de bonnes bases.
Toute l'équipe du projet est présente durant le sprint planning. C’est le moment de faire les présentations avec :
Amad, le responsable produit ou PO pour Product Owner
Kim, notre UX/UI designer
Samira, la lead développeuse iOS
Bilal le développeur Android
Zoé la développeuse back-end
Sébastien le responsable qualité ou aussi appelé QA
Vous, le développeur iOS
Dans notre POC, un écran sera représenté par un ticket. Ce ticket c’est la tâche de travail que vous allez devoir développer. En agilité on appellera ce ticket une User Story ou US.
Validez une maquette
Pour accompagner chaque écran, une maquette dessinée par Kim vous sera fournie et elle vous sera d’une grande aide.
C’est quoi une maquette ?
Encore une excellente question !
C’est la ressource graphique qui représente ce à quoi l’application doit ressembler visuellement une fois codée.
Il est important en tant que développeur ou développeuse iOS de les comprendre et de pouvoir les valider avant même de vous lancer dans le développement. Cela vous évitera de perdre du temps et de faire des allers-retours avec la personne chargée de réaliser les maquettes.
Voici les maquettes des 2 écrans que vous allez réaliser :
Voici une petite check-list pour vous aider à y voir plus clair :
1. Comprendre l’interface
Cela peut paraître bête mais si vous ne comprenez pas la maquette il ne faut pas hésiter à poser un maximum de questions. Assurez-vous de savoir quelle information sera affichée à tel endroit ou encore quel type de composant est dessiné. Est-ce un bouton ou un simple texte ?
2. Valider la faisabilité des composants
Ce n’est que vos débuts de développeur ou de développeuse mais vous allez très vite savoir ce qui vous semble facile ou non à faire, voire des fois même impossibles à réaliser. C’est à ça que peuvent servir les POC, mais il est important d’identifier les éléments de l’interface qui vous semble compliqués voire irréalisables.
Mais Samira vous confirme que c’est tout à fait à votre portée.
3. Valider les Human Interface Guidelines d’Apple
Comme mentionné au chapitre précédent, il est difficile de connaître toutes les guidelines. Vous pouvez aller vérifier par exemple ici celles sur les labels ou les listes. En lisant la partie Content des listes, vous pouvez lire “Keep item text succinct so row content is confortable to read.” Ce qui veut dire en français, qu’il faut éviter d'écrire un texte trop long pour chacune des cellules ou lignes de la liste. Dans notre cas, il semble que le texte soit un peu long. Vous proposez de réduire la longueur en écrivant uniquement le nom de la personne.
Voici la nouvelle maquette de l'écran de la liste après modification.
4. Vérifier la cohérence avec le reste du projet
Lorsque l’on ajoute une nouvelle fonctionnalité à un projet, il est important de garder une cohérence entre tous les écrans. Par exemple, si tous les boutons cliquables sont en bleu, sauf s’il y a une bonne raison pour un cas spécifique, les autres boutons du même type doivent être en bleu aussi. Cela pourrait perturber l’utilisateur sinon.
Dans nos maquettes, tout semble en harmonie.
5. Valider les différentes tailles d'écran
Il est important de connaître le comportement des éléments qui composent l'écran en fonction de la taille de celui-ci. En effet, si vous êtes sur un écran plus grand ou plus petit que celui sur lequel vous développez, que va-t-il se passer ?
Dans notre cas nous avons 1 taille d'écran, ce qui nous permet de comprendre que les éléments doivent grandir en fonction de la taille.
Maintenant que nous avons validé les maquettes, place aux tickets.
Validez votre ticket de développement
Tout comme pour les maquettes, il est important d'être vigilant sur les tickets des fonctionnalités à développer avant de se lancer pour éviter de perdre du temps.
Voici les 2 tickets que l’on vous demande de réaliser :
| Ticket 1 | Ticket 2 |
Titre | Écran liste POC 1 | Écran detail POC 1 |
Description | En tant que visiteur de l’exposition je souhaite avoir le détail liste de femmes qui ont eu un impact dans la tech avec le nom et une image. | En tant que visiteur de l’exposition je souhaite avoir des informations détaillées sur une femme de la tech que j’aurai précédemment sélectionné dans la liste afin d’apprendre à mieux la connaître. |
Ressources | Maquette de l'écran
| Maquette de l'écran sans la barre de navigation
|
Priorité | 2 | 2 |
Estimation | 3 | 3 |
En tant qu'équipe agile, il y a aussi une check-list pour les User Stories. Elle a été constituée avec l’accord de tous les membres de votre équipe agile. On l’appelle la DOR ou Definition Of Ready. Elle garantit que les développeurs ont tout ce qu’il faut pour se lancer dans le code. Cette check-list peut donc être différente d’une équipe à une autre.
Voici celle de votre équipe :
1. La User Story ou la tâche est bien définie et comprise par l'équipe.
Comme pour les maquettes, c’est important qu’il n’y ait pas de quiproquos dans la réalisation de la fonctionnalité. La description doit être claire et le comportement de l’application explicite.
2. Toutes les ressources nécessaires sont disponibles pour accomplir la User Story ou la tâche.
S’il y a besoin de ressources graphiques comme les maquettes, il faut que vous y ayez accès pour commencer à coder. Mais cela peut être aussi de la documentation ou des données.
Ici, pour remplir la liste, vous avez besoin d’avoir les informations sur toutes ces femmes. Amad le Product Owner, ajoute donc à la story du listing les données que vous aurez besoin d’afficher sur chacune des personnalités.
3. La User Story ou la tâche est indépendante et peut être travaillée de manière isolée.
Pour vous permettre de réaliser l'entièreté d’une tâche, il est important que celle-ci puisse être indépendante. C’est-à-dire, que vous n’ayez pas besoin d’attendre une autre équipe pour finir votre tâche par exemple.
Dans notre cas, un ticket représente un écran, ce qui rend son développement plus facilement indépendant. De plus vous êtes seul pour les faire et vous avez en votre possession toutes les informations nécessaires.
4. La User Story ou la tâche a été estimée et priorisée par l'équipe.
Toute User Story doit avoir été estimée car il est important de savoir combien de temps cela va prendre pour pouvoir faire un planning qui se rapproche de la réalité. La priorisation c’est l'équipe Produit qui s’en charge afin de déterminer l’ordre de sortie des fonctionnalités.
Tout est bon, on va pouvoir passer à la suite, la planification !
Planifiez votre travail
Il est temps maintenant de voir comment vous allez vous organiser pour réaliser ces 2 tickets. Ne vous inquiétez pas, votre lead développeuse va vous aider !
Samira vous conseille de commencer par la page de détail pour finir par le listing.
Pourquoi on commence par cette page ?
Ce sera plus facile pour vous d'apprendre à faire d’abord des éléments simples comme du texte ou des images que de travailler directement sur des composants plus complexes comme les listes.
Maintenant c’est l’heure du découpage. Il y a toujours plusieurs façons de le faire, mais voici ce que Samira vous propose :
Détail :
Positionner les éléments pour avoir le squelette de la page en commençant de haut en bas et de gauche à droite.
Customiser les éléments de la page pour qu’ils soient comme sur les maquettes.
Listing :
Créer la structure de données qui représente une personnalité.
Stocker dans un tableau la liste des femmes à afficher.
Mettre en place une liste qui va parcourir le tableau.
Customiser les cellules de la liste pour les faire correspondre à la maquette.
Ajouter la navigation pour afficher la fiche de détail de la personnalité sélectionnée depuis la liste.
À vous de jouer
Contexte
Nous n’avons pas fini la planification ! Il y a 2 autres tickets qui n’ont pas encore été validés, c’est celui de la deuxième version de l'application. Elle contient le même nombre d'écrans, c’est-à-dire, celui de la page détail d’une femme et celui de la liste des femmes. Comme pour les autres User Stories, un ticket est associé à un écran.
Voici leurs contenus :
| Ticket 1 | Ticket 2 |
Titre | Écran liste POC 2 | Écran detail POC 2 |
Description | En tant que visiteur de l’exposition je souhaite avoir le détail liste de femmes qui ont eu un impact dans la tech avec le nom et une image. | En tant que visiteur de l’exposition je souhaite avoir des informations détaillées sur une femme de la tech que j’aurai précédemment sélectionné dans la liste afin d’apprendre à mieux la connaître. |
Ressources | Maquette de l'écran Liste de photos des femmes Code couleur :
| Maquette de l'écran sans la barre de navigation Maquette avec les dimensions et couleurs Code couleur :
|
Priorité | 2 | 2 |
Estimation | 3 | 3 |
Et les maquettes associées :
Consignes
Dans ces 2 nouvelles User Stories et maquettes, il y a 2 soucis que Samira a identifiés, à vous de les trouver pour pouvoir passer au développement. Petit indice, il y en a un par ticket.
Vérifiez votre travail à l’aide cet exemple de corrigé
L’estimation n’a pas été précisée pour le ticket du listing.
Il est écrit sur le ticket de détail : “Il n’y a que les couleurs blanc, noir et violet”. Or du orange a été utilisé pour écrire le nom de la personnalité.
En résumé
Pour valider une maquette, les HIG d’Apple sont une référence.
Il est important de poser toutes les questions de compréhension avant même de se lancer dans le développement d’une fonctionnalité.
La Definition of Ready est une sécurité pour l’équipe afin d'éviter d’oublier quelque chose avant de se lancer dans le code.
Une façon de prioriser peut aussi être par le commencement des tâches les plus simples pour aller vers celles qui sont les plus compliquées.
Ça y est ? Tout est prêt ? Alors c’est parti, on se lance dans les lignes de code et SwiftUI ! Mais avant cela, testez vos connaissances dans le quiz clôturant cette partie !
