Gestion de projet pour développeur solo en entreprise

Agile
#1

Bonjour à tous, et merci de vous intéresser à ma problématique.

Contexte

En premier lieu, je vous situe le contexte, je suis développeur fonctionnaire, mais ce n’est pas l’intitulé officiel de mon poste, je suis sensé être technicien en maintenance et installation informatique. C’est un compromis pour mon départ futur (dans ~5ans, avec une reconversion les deux dernières années). Tout ça pour dire qu’il n’y a pas de poste de dév où je suis, et donc la structure n’est pas faite pour non plus.

Je travaille sur des projets de sites en intranet en PHP(symfony) et js(jQuery).
J’utilise Git, xDebug, PHPUnit, le tout paramétré sur NetBeans dans un environnement WAMP.

###Collaborateurs

Je travaille avec une consultante qui fut développeur (pas web) mais qui a arrêté voilà une vingtaine d’année. Forcément, l’aspect technique elle a un peu oublié.

Et mon chef est le chef du service des systèmes informatiques, mais il n’y connaît pas grand chose en dev non plus.

Je dois faire une application pour la cellule R&D, à ce titre, j’ai des réunions régulières avec le chef de la cellule.

###Problématique

Je souhaiterais savoir quelle gestion de projet je peux appliquer afin de m’organiser, si certains d’entre vous ont des solutions pour un dev solo.

Je suis tenté de m’inspirer de la méthode Scrum pour les itérations, le product backlog, les sprints, le tableau façon kanban etc. Et faire un mélange avec la méthode des tests en trois temps.

Est-ce une bonne idée ? Avez vous de meilleures idées ?

#2

Je n’avais jamais entendu parler de cette méthode 3T. Je la trouve assez utile pour perdre son temps en process inutiles.

Un des trucs qui me fait bondir avec cette méthode : écrire d’abord tous les tests d’une feature. J’ai même eu l’impression que l’auteur pense qu’on fait comme ça en TDD, ce qui est une aberration.

À mon avis, si tu es l’unique dev, tu n’as vraiment pas besoin de plus qu’un tableau de type kanban comme Trello.

Pour être tranquille, il faudrait aussi régler une fois pour toutes la question de qui gère les priorités, toi ou le chef X ou le chef Y, etc.

2 « J'aime »
#3

Tout d’abord merci de ta réponse,

Pour le tableau, je m’en suis déjà fait avec les trois colonnes de base (todo, wip et done), J’ai aussi un tableau excel genre product backlog, pour planifier au fur et à mesure les différentes features.

La consultante vient assez souvent, (en général un jour entier par semaine), et c’est elle qui gère les priorités d’après les spec (re)définies lors des réunions qu’on tient avec le chef de la cellule R&D.

Sinon pour les TDD classiques, tu penses que c’est une bonne idée en tant que dev solo ? J’aurais tendance à dire oui : j’ai certainement un manque de recul sur mon propre code et que ça me permettrait de fiabiliser mon application. Je vais chercher ce qu’il en est du TDD “classique”, si tu as de bons articles à ce sujet, je suis preneur ! :)

#4

Bonjour,

Le TDD est toujours une bonne solution… si tu arrives à le maîtriser. Que tu sois seul ou en équipe. L’avantage du TDD est que ça te force d’avoir une conception de ton application adaptée aux tests, et souvent plus maintenable et compréhensible. Par contre, faire du bon TDD est compliqué et mal appliqué, ça peut te retomber dessus. Donc renseigne-toi bien, notamment sur les échecs avant de te lancer dans cette stratégie.

Sinon, en tant que développeur seul, comme dit @lkdjiin, un kanban suffira et ce qu’il est le plus important, c’est de communiquer avec les utilisateurs. La consultante vient toutes les semaines, ça peut être l’occasion de faire une démo, rétro et éviter l’effet tunnel.

Je n’ai jamais vécu la situation en professionnel, mais en personnel, j’ai trouvé que j’étais bien plus à l’aise une fois mon intégration/déploiement continue en place (il y a plein d’articles sur le web, tu en trouveras surement dans tes technos). La raison est que déployer l’application prend du temps, crée des risques inutiles si manuel. De même pour les tests, si tu commences à faire des dizaines de tests, ils vont être de plus en plus long et avoir un serveur dédié aux tests te permet de restraindre la liste dans ton environnement de développement, sans pour autant refuser la qualité. Tu vas peut-être passer une semaine entière dessus, mais ensuite, tu seras tranquille.

2 « J'aime »
#5

Comme dit @kneelnrise «le TDD est toujours une bonne solution». Je suis entièrement d’accord, étant moi même un addict du TDD.

Ceci dit, il y a un truc encore plus important que le moment où (et la façon dont) tu écris tes tests : c’est déjà d’écrire des tests. Mieux vaut des tests écrits après le code que pas de tests du tout. Le TDD étant pour moi rien de plus que la manière la plus simple d’aborder ce problème :

  • pas besoin de faire un effort pour produire du code testable, avec le TDD le code est testable par définition
  • pas de risque d’oublier de tester ci ou ça, avec le TDD tout le code est testé par définition

Maintenant si tu n’as jamais fait de TDD, je ne pense pas que se lancer dans un gros projet professionnel sans l’aide d’un mentor soit une bonne idée. Comme pour toute technique nouvelle, les premiers temps on ne sait pas faire. Vaudrait peut-être mieux commencer à être à l’aise sur des projets persos.

Sinon pour de la lecture sur le sujet, je conseillerai tout ce qu’a produit Uncle Bob sur son blog et dans ses livres.

2 « J'aime »
#6

J’ai commencé à lire pas mal d’articles sur le sujet, j’ai trouvé un qui m’a l’air pas mal sur les antipatrons de TU (http://bruno-orsier.developpez.com/tutoriels/java/antipatrons-tests-unitaires/). Je continue à chercher.

Ça c’est fait, on se voit chaque semaine où la consultante vient, plus ou moins (quelques fois la consultante ne peut pas venir, alors on se débrouille autrement). Et, effectivement, ça m’a quelques fois évité les œillères de l’effet tunnel.

Je note ça.

Donc tu me conseillerais de commencer doucement sans test au travail, puis en parallèle de faire des projets persos avec TDD, et une fois le sujet maîtrisé, de basculer mes connaissances, en testant préalablement le futur code, et en testant a posteriori le code déjà implémenté ?
Ça ne risque pas d’être lourd à mettre en place ? avec un risque un risque de régression élevé dans la phase sans test ?
Ne vaut-il mieux pas que je teste en mettant dans ma todo list que les tests doivent être revus régulièrement pour les améliorer au fur et à mesure de mon apprentissage ?

Je sens que je vais remplir mon Pocket… ^^

#7

Ça va pas la tête !

:-)

Si tu me relis bien, tu verras que je te conseille si tu ne maitrises pas encore le TDD et que ce projet pro est important d’écrire tes tests après le code d’implémentation, parce que la présence des test est plus importante que la technique employée.

En parallèle tu te formes au TDD sur des projets persos.

Ensuite tu pourras utiliser cette technique sur un futur projet pro.

(et tout ça dans le cadre d’un développeur solo, hein)

1 « J'aime »
#8

Excuse moi, j’ai lu à la va-vite en pause. Je trouvais ça bizarre aussi !

Merci pour ces bons conseils !

Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s