Définir le Professional Scrum Developer (PSD)

Tout d’abord, je vais parler du mot « Professional », professionnel en français.

Selon moi, c’est :

  • Quelqu’un qui connaît bien son métier ;
  • Quelqu’un de responsable, qui sait dire oui, mais aussi dire non. Être professionnel, c’est être conscient du délai, du coût et de la portée, sans oublier la qualité que nos clients nous demandent.

Ensuite, qu’est-ce que le « Scrum »?

Il s’agit de la méthodologie ou du cadre d’application (« framework ») qui applique les principes agiles afin d’exécuter des tâches complexes dans le cadre d’un projet de développement informatique. Le Professional Scrum Developer en connaît les rôles, les événements et les artéfacts :

Rôles

  • Chef de mêlée (« Scrum Master »)
  • Directeur de produit (« Product owner »)
  • Développeur (c’est ici que nous nous trouvons – PSD)

Événements

  • Planification du sprint
  • Sprint
  • Scrum quotidien
  • Revue du sprint
  • Rétrospective du sprint

Artéfacts

  • Produit du carnet de commandes
  • Carnet de sprint
  • Incrément
  • Définition de « Terminé » (artéfact de transparence)

 

Scrum framework – source : thescrummaster.co.uk

 


Donc, jusqu’ici nous comprenons qu’un PSD est quelqu’un qui connaît bien son métier et qui connaît également, je ne dis pas maîtrise, la méthodologie SCRUM.


 

Il ne nous reste que le mot « Développeur ».

Qui sont les développeurs dans un monde professionnel et agile? Dans ce contexte, le développeur doit maîtriser certains concepts et certaines disciplines essentiels pour le bon déroulement d’un projet ou des tâches qui lui sont attribuées. Il doit surtout avoir une bonne communication avec les autres développeurs de l’équipe et avec le directeur de produit. Je vous propose ci-dessous un résumé des trois disciplines utilisées pour le développement dans une méthode agile.

 

3 méthodes agiles utilisées par le Professionnal Scrum Developer (PSD)

Le Développement guidé par les tests

Parmi les disciplines dont nous entendons beaucoup parler lorsque nous utilisons une méthode agile, c’est le développement guidé par les tests (en anglais : « TDD » ou « Test-driven development »).

En premier, nous développons le test; en deuxième, le code pour satisfaire une spécification fonctionnelle. Pour les développeurs, nous passons du rouge au vert jusqu’à ce que toutes les spécifications soient codées.

Pour bien comprendre le développement guidé par les tests, il faut suivre les trois lois suivantes :

  • Première loi : Toujours écrire le test avant d’écrire le code de la méthode testée.
  • Deuxième loi : Dans le test, définir les comportements et les résultats attendus de la méthode testée.
  • Troisième loi : Écrire le code suffisant dans la méthode testée afin que le passage du test soit un succès.

Les tests d’acceptation

Les tests sont une autre discipline très importante pour un développeur qui travaille en mode agile. Je vais parler spécifiquement des tests d’acceptation, qui, selon moi, sont les tests qui devraient être faits en collaboration entre les parties prenantes et les développeurs. C’est pour cela que la communication est très importante pour un développeur. Il faut mentionner que ces tests sont également liés aux « critères d’acceptation » d’une histoire.

Les tests d’acceptation peuvent être automatisés, ce que je recommande. Cependant, parfois, les clients ne sont pas préparés ou, dans certains cas, sont très spécifiques. Aussi, ils peuvent-ils être exécutés manuellement.

Avez-vous entendu parler du style de tests représenté par les mots Given-When-Then ? Ces tests sont appelés également tests de spécification. C’est une discipline qui est spécifiée dans le développement piloté par le comportement (en anglais : « Behavior Driven Development » ou « BDD »), laquelle est développée par Dan North et Chris Matts. Vous trouverez quelques cadres structurés pour ce style de test, par exemple, Cucumber (flux de spécifications pour .Net).

Il est important de mentionner que les tests d’acceptation ne sont pas des tests unitaires. Les tests unitaires sont écrits par un développeur tandis que les tests d’acceptation devraient être écrits par les parties prenantes, les membres de l’assurance qualité et les développeurs.

Intégration continue

Quand nous parlons d’automatisation des tests, je pense automatiquement en intégration continue.

Le concept est simple. Ce système est déclenché par le contrôle de code source (TFS, CVS, SVN, Git) et, à chaque fois, qu’un développeur fait Valider (archiver), le système déclenche une version de l’application et il exécute tous les tests. Si tous les tests sont concluants, le code est archivé. Sinon, le code n’est pas archivé et le développeur doit corriger le code.

Intégration continue – Continuous integration – source : igm.univ-mlv.fr

 

Avec ces définitions, nous pouvons déduire que le PSD est un développeur qui maîtrise son métier (langages de programmation, orientée-objet, certains modèles de conception, etc.), la méthodologie Scrum et certaines disciplines de développement, notamment, le développement guidé par les tests, les tests d’acceptation, l’intégration continue, qui favorisent le travail dans un environnement agile.

Pour avoir la certification PSD, je recommande d’étudier le guide du Scrum, de pratiquer les examens qui se trouvent sur le site www.scrum.org et de se familiariser avec les concepts et les disciplines que j’ai mentionnés dans cet article.

Bonne chance !

 

Référence : « The Clean Code » (Robert C. Martin)