Pour info, voici les quelques lignes de directions que je me suis donné.
Développer l’important pour l’user, laisser le superflu au panier et savoir dire non au développement inutile.
Positiver quant aux nouvelles améliorations et contraintes des systèmes et navigateurs. (même celles d’IE)
Travailler en équipe réduite mais polyvalente. Deux, trois, quatre ?
Eviter la réunionite d’après coup. Préférer la discussion avant projet.
Ecrire le projet avant de le coder. Puis rapide FeedBack user, puis partir dans ce sens.
Coder, faire tester par les users après développement. (rétroaction immédiate des derniers codes, idéale pour réorienter, affirmer ou améliorer le projet.)
Mettre en place l’important dans la composition d’un squelette, agencer, "ergonomiser", le reste est superflu et s’ajoute ensuite.
Ne pas forker les codes du coté d’écrire. Préférer coder des boucles en 100% SPIP. Ne pas utiliser de php dans les squelettes. Ajouter l’administration des profils et abonnements du coté public et utilisateurs.
Garder le code le plus simple possible, nommer clairement les boucles, séparer les boucles importante avec de l’espace et commenter le tout.
Communiquer les développement au travers cette rubrique et non au travers des e-mail ou de la messagerie instantanée. Être ouvert aux remarques des users.
Ne pas attaquer 5 développements à la fois. Se focaliser sur les retours de bugs avant de commencer tout nouveau développement.
Sortir les cotillons, la grosse bouffe, le champagne, après chaque victoire sur un bug ou à chaque fin de création de projet. S’auto-motiver.
Plus facile à dire qu’à faire. Mais qui ne tente rien n’a rien.
