Depuis quelques mois je m’auto-forme en développement web + php pour exécuter une petite web app que j’ai en tête. Rien de dramatique, simplement un petit outil qui me faciliterait la vie en interne, et qui n’a pas vocation a être vendue ou distribuée.
Je commence a me dépatouiller au niveau du code petit à petit, mais j’ai du mal à m’organiser, et savoir dans quel ordre faire les choses, par quel bout prendre le truc pour arriver à un produit fonctionnel…
Comment vous-y prenez-vous au démarrage d’un projet complètement nouveau ?
Avez-vous des ressources concernant cet aspect du projet? y-at-il des best practices?
Par exemple (suppositions, en fait je n’en sais rien!) : wireframe et HTML d’abord, puis le gros du CSS, puis les scripts / PHP / Database à proprement parler?
Pour l’instant mon approche est très « bordélique », j’essaye plein de trucs, je teste des petits bouts de fonctions au fur et à mesure, etc… et du coup j’ai du mal à avoir une vision globale du projet…
Mais il doit y avoir une méthode + structurée à suivre non?
Vos avis et ressources seraient très intéressants à avoir…
J’ai googlé « réussir son projet web pdf » essaye, il vaut ce qu’il vaut. IL y a surement mieux mais c’est assez carré et large.Il va au dela de la technique.A Mon sens la conception en avance de phase est aussi importante que l’exécution.
je fais un Trello de mes tâches (pas seulement de développement mais aussi d’organisation du projet en général);
je dessine les cas d’utilisation des utilisateurs (l’utilisateur se connecte, l’utilisateur crée son compte, etc.) du point de vue des utilisateurs;
Je crée un diagramme d’activités ou diagramme d’états (de l’état ‹ connecté › l’utilisateur va à l’état ‹ affichage liste d’amis ›, etc…) pour l’appli front-end (appli utilisateur) et un autre pour le back-end (appli serveur : si je reçois ça je renvoie ça, si la requête est mal formée je dois la traiter correctement et pas seulement afficher une exception dans la console );
à partir du diagramme d’états je dessine sommairement des écrans de mon appli;
Je choisis quel framework, langage, base de données (MongoDB, MySQL, reThinkDB, etc. ?), techno est idéal pour cette appli;
Je crée mon Modèle Conceptuel des Données ou schéma de base de données;
Je crée l’API serveur (back-end) à partir du MCD et du diagramme d’états du back-end et je la teste à fond;
je développe les apps mobiles (front-end) à partir de mon diagramme d’états/activités;
je valide les app front-end avec mes cas d’usages des utilisateurs du point 2).
Tu remarqueras que le développement n’arrive qu’aux points 7) et 8) … jamais avant … au risque de tout changer en cas d’incohérence découverte durant le parcours …
Backlog : tout les post-it avec les tâches à faire. A faire : une extraction de "cas utilisateur"du backlog pour la journée par exemple. En cours : c’est ce que tu es entrain de faire. Terminé : c’est ce que tu a terminé.
Et tu le fais sur de vrai post-it.
Comme cela tu as le plaisir d’écrabouiller de tes propres mains, les post-it fait une fois la tâche terminée c’est plus sympa qu’avec Trello qui fait la même chose.
BONUS:
Utilise « Planning Poker » en gros tu attribue à chaque « Cas utilisateur » un poids 3, 5 ou 10 selon la difficulté / temps nécessaire que la tâche exigera selon toi. (c’est le plus difficile dans la méthode , il ne faut pas trop sous estimé et ne pas trop sur estimé).
En fonction des tâches les unes par rapport aux autres cela te permettra d’extrapoler et de voir quand ton projet pourra se terminé.
Classe aussi tes tâches en Bloquant ,Majeur, Mineur.
Avec tout ces indications une vision du déroulement du projet devrait pouvoir se détacher.
C’est inspiré d’une méthode utilisé des les ESN , elle s’appelle « SCRUM » qui veut dire mêlée en rugby.
Un aperçu IRL:
Le plus important: garder en tête que l’idée de départ sera modifiée en fonction de l’évolution du produit. On dit souvent « les clients ne savent pas ce qu’ils veulent », en fait c’est normal, une idée n’est jamais figée et évoluera à partir des conversations et des confrontations de l’idée au réel.
Donc ça ne sert à rien de vouloir tout spécifier au début ou même de vouloir tout imaginer. Plutôt cerner le cas d’utilisation le plus important et le réaliser le plus rapidement possible. Il n’y pas besoin de login, de gestion multi-compte, de faq, etc. si ce ne sont pas les aspects primordiaux du produit. Il s’agit d’optimiser la création de valeur, et de vérifier la faisabilité du projet avant de passer 3 mois à se rendre compte que ce que l’on cherche à faire n’est pas possible.
Une fois le cas d’utilisation le plus important réalisé, réfléchir à comment on envisage la suite du produit par rapport à l’objectif initial.
En méthodologies agiles, cela correspond à la réalisation de sprints, à la fin desquelles on re-priorise le travail restant en fonction de ce que l’on a appris avec le sprint précédent.
En termes de coût, code > prototype html/css > wireframe > sketch papier. Il est possible de sketcher certaines parties de l’interface et de coder certaines autres. S’il y a des incertitudes sur l’interface, il est intéressant de sketcher. Si il y a des incertitudes sur le côté technique, il est intéressant de coder.
Concrètement, deux outils pour aider à avancer:
les mockups pour visualiser à quoi ressemblera l’interface
les « user stories » qui décrivent les besoins utilisateurs, en des termes orientés besoin utilisateur (« en tant qu’utilisateur de l’appli, je veux envoyer un fichier à mon comptable pour lui permettre de traiter ma facture »).
à partir des user stories, il s’agit d’écrire le code minimal qui répondra aux exigences la user story. Si la story nécessite une base de données, alors on crée la base de donnée la plus simple possible qui fasse ce qu’on veut. etc.
Une fois ceci fait, on passera a la suivante. etc jusqu’à la fin du projet.
);
