Pratiques de développement: impliquer, tester et livrer… toujours!

Le site VENTUREBEAT nous présentait, récemment, un article sur les 10 meilleures pratiques à adopter selon plusieurs leaders du marché, se basant sur de grandes entreprises telles que Google et Pinterest. Ces recommandations sont très intéressantes d’un point de vue développeur et cela m’a donné envie de ressortir les éléments s’adressant à tous les acteurs dans un projet TI. Résultat : trois recommandations : impliquer, tester et livrer…

Impliquer tout le monde
Dans un contexte de consultation, il est souvent difficile d’impliquer et d’informer les différentes ressources dans l’ensemble d’un projet, car celles-ci vont et viennent au gré des divers contrats.

Considérant cet enjeu, il est capital d’utiliser une approche permettant de diffuser la connaissance et de recueillir l’avis et les commentaires de toute de l’équipe de façon régulière, idéalement sur une base quotidienne.  Cette approche, en plus de permettre une gestion plus serrée des problèmes, permet aussi d’augmenter l’implication et le sentiment d’appartenance des divers acteurs impliqués.

L’intégration d’une méthodologie de type agile permet aussi la révision des besoins et la mise en place de correctifs plus rapidement, permettant d’éviter certains dérapages coûteux, particulièrement dans les projets gouvernementaux où l’étendue de ceux-ci est grande et le nombre d’acteurs est souvent élevé.

Tester tout
Depuis quelques années, l’utilisation des tests automatisés s’avère un incontournable à la réalisation d’applications de qualité. Il est extrêmement coûteux (en temps, en argent et en motivation) de refaire manuellement les tests unitaires pour chaque modification mineure du code. Les tests automatisés deviennent donc un «must» si on veut livrer un logiciel de qualité, en respectant le budget et les échéanciers.

Un bon mantra à adopter pourrait être «Ne jamais repousser les tests». Il est impératif d’atteindre une couverture de code de 100% avec les tests unitaires automatisés et de maintenir ce niveau de couverture tout au long de l’évolution de l’application. Il est beaucoup trop facile pour un développeur ou un chargé de projet, notant un retard dans les échéanciers, de repousser la réalisation des tests. C’est absolument à proscrire car les tests ne se réaliseront probablement jamais et le risque d’introduction de bugs dans le code s’accentue.

Les tests automatisés permettront aussi d’identifier les problèmes potentiels et les bugs plus tôt dans le cycle de développement. Comme le mentionne Jeremy Green dans l’article de VentureBeat: « Early bugs are usually easy bugs. »

Des spécialistes en assurance qualité (QA) doivent aussi faire partie de l’équipe de projet afin de réaliser les tests de haut niveau. Les spécialistes QA doivent être impliqués et avoir un sentiment d’appartenance au projet afin d’éviter des frictions avec le reste de l’équipe et des délais inutiles. Il est capital de ne pas confier la réalisation de l’ensemble des tests à l’équipe de développement, ceux-ci étant trop familiers avec l’application pour réaliser certains jeux d’essais comme, par exemple, les essais fonctionnels.

Livrer tout le temps
On le voit depuis plusieurs années déjà, les cycles de livraison des produits, sites web et apps sont de plus en plus courts. Certaines compagnies se dirigent vers des produits où les numéros de version disparaîtront complètement pour l’usager (pensons entre autre aux produits Office online pour lesquels Microsoft vise une mise à jour deux fois par an comme le rapporte ce billet paru sur le site c|net.

La tendance du marché est claire, on doit livrer plus rapidement. On doit découper une application en composantes unitaires et livrer une nouvelle version pour chacune de ces composantes. Chacune de ces livraisons doit cependant être testée, documentée et présentée au client. Grâce à ces livraisons rapides, le client sera en mesure d’acquérir de l’expérience dans votre application dès le début, réduisant ainsi les besoins en formation. Mais principalement, cela donnera une base de discussion entre le client et l’équipe de développement qui vous permettra d’identifier les éléments applicatifs qui ne répondent pas correctement aux attentes du client et de les corriger rapidement, sans impacts majeurs sur l’architecture du logiciel. Cet aspect est très bien expliqué par Stephanie Volftsun :

«Fail Fast. In coding (and in life), I want to know at the earliest possible point that something is broken or not working, rather than let it sit and propagate further. Go all in, fail quickly, fix what’s broken, and keep on keeping on»

Il est clair que les clients d’applications en 2013 sont beaucoup plus demandants qu’ils ne l’étaient il y a dix ou même cinq ans. Les utilisateurs sont habitués à des applications de qualité, sans bug, rapides et qui évoluent rapidement afin d’intégrer de nouvelles fonctionnalités. Si une équipe n’est pas en mesure de répondre à ces demandes de sa clientèle, son application n’aura tout simplement pas le succès escompté.

Advertisements

Laisser un commentaire

Entrer les renseignements ci-dessous ou cliquer sur une icône pour ouvrir une session :

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l’aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s