6 experts à propos du développement agile de logiciels | Agoria

6 experts à propos du développement agile de logiciels

Publié le 05/03/14

Lors d’un récent séminaire dans le cadre de Katalict, six experts ont présenté les caractéristiques et processus de diverses méthodologies logicielles. Ensuite, lors d’un débat interactif, ils ont partagé leurs conseils pratiques quant à l’application de ces techniques.

Ces six experts sont :


La vision des experts

Carl Danneels

  • Une personne finance votre projet. À un moment donné, il faut démontrer le retour sur investissement.
  • Un contrat doit être conclu avec le client ; il faut aussi créer un climat de confiance.
  • Veillez toujours à recevoir un feed-back direct d’un propriétaire du produit qui est un collaborateur interne.

Johan Lybaert

  • La priorisation commence par les aspects qui sont les plus importants pour l’activité.
  • Vous réalisez un gain de temps de 30 à 50 % en travaillant de façon agile plutôt qu’en appliquant la méthode en cascade classique.
  • Avoir la confiance du client est important. Avec une bonne démo, vous devez pouvoir gagner cette confiance.

Nick Oostvogels

  • Kanban ne prescrit aucune itération ou "sprint planning meetings" explicites comme dans le cadre Scrum.
  • Dans un flux continu, il est important de scinder votre champ d’action au bon niveau, à savoir celui de "minimal marketable features".
  • Une "stand-up meeting" journalière n’est pas prescrite dans Kanban, mais bien perçue comme une meilleure pratique.

Jef Cumps

  • Finalement, tout est une question de gestion de projet. Chaque projet commence par une idée. Vous avez besoin d’une vision à long terme.
  • Au départ, vous établissez un plan initial comportant des estimations, mais durant l’exécution, il est nécessaire de mesurer les véritables progrès (via SPRINT).
  • Le fonctionnement agile ne réussit pas dès le premier jour dans les grandes entreprises. La méthode Scrum doit être introduite graduellement. Certains environnements ne se prêtent pas à cette méthode. Ne commencez à l’appliquer que si vous pouvez répondre à la question de savoir pourquoi vous voulez l’utiliser. Quels sont les objectifs de votre organisation ?
  • La grande force de Scrum réside dans le fait que toutes les 2 à 3 semaines, une partie de produit opérationnel est fournie et évaluée par le client. De cette manière, de la valeur client est rapidement créée, les risques sont déjoués précocement et tant le client que le fournisseur IT exercent un véritable contrôle sur l’avancement d’un projet.

Koen Van Exem

  • Il existe trois manières de développer un logiciel :
1. Développement exploratoire
2. Développement de projet
3. Développement de maintenance
  • Dans tous ces modes de développement, la planification dimensionnelle peut être utilisée, aussi bien d’un point de vue fonctionnel que technique :
1. le chemin de sable
2. la route pavée
3. l’autoroute
  • Lorsque vous utilisez un logiciel, il est nécessaire d’aller quotidiennement en production. C’est la seule possibilité de déterminer la valeur de votre logiciel.
  • Vous devez procéder de manière agile, de bas en haut, avec de petites équipes. Ensuite, vous allez expliquer au management ce que vous êtes en train de faire.
  • Dans le produit, il est possible d’installer beaucoup de marketing, de sorte que vous receviez un feed-back de la part de votre utilisateur final. Vous savez ainsi ce que vos utilisateurs finaux utilisent.

Stijn Van den Enden

  • Le fonctionnement agile suit le cycle "construire, mesurer et apprendre".
  • Ne suivez par le processus "J’ai commis une erreur, j’en ai tiré les leçons", mais inversez le cycle et déterminez ce que vous voulez apprendre et comment vous allez le mesurer et le construire.
  • Parcourez tout le cycle et examinez en continu où se situe le goulot d’étranglement.
  • Accroissez la prévisibilité et diminuer la variabilité.
  • Les erreurs dans la production sont vues par tous. Il est important d’avoir un système immunisé de sorte à conserver une confiance forte de la part de votre client.
  • La confiance entre le management et les travailleurs est nécessaire ; c’est plus qu’une question de développement de logiciels. Si vous ne faites pas preuve de sincérité, cela ne fonctionnera pas.
  • Conservez votre équipe sur une longue période, mais confiez-lui de nouveaux projets. Cela permet d’accroître la productivité et de réduire les bugs.

Réaction de la salle :

  • Au début, c’est bien de miser sur la confiance, mais quand ça tourne mal, ça tourne généralement mal aussi devant le tribunal.

La réaction des autres participants

Lors des débats qui s’en sont suivis, les participants ont pu dialoguer avec les experts. Voici un aperçu des principaux points de discussion :

Relation avec le client

  • Travaillez dans les limites d’un budget. Les "must haves" doivent correspondre au budget prévu.
  • Le projet doit s’appuyer sur une valeur et des moyens suffisants, de préférence le plus haut possible dans la hiérarchie.
  • Il doit exister une autorité suffisante dans le chef du propriétaire du produit, sans quoi cette personne devient le goulot d’étranglement. L’engagement du propriétaire du produit peut être défini contractuellement.
  • Veillez à une bonne adéquation avec les souhaits du client et effectuez votre livraison conformément aux accords passés.
  • Vous ne devez pas livrer un produit qui n’a pas été testé.
  • Le client doit être impliqué dans les projets agiles.
  • Tirez des leçons de votre relation avec le client et procédez par petites expériences.
  • Faites participer le client et demandez-lui un feed-back quotidien.

Équipe

  • Faites appel à des personnes disposant d’une expertise fonctionnelle.
  • Créez des équipes interfonctionnelles.
  • Un SPRINT doit se baser sur des itérations toutes les semaines ou toutes les deux semaines, pas plus. Il ne faut pas qu’il y ait une pression continue à livrer. Il est impossible de livrer de la qualité si vous effectuez SPRINT après SPRINT. Vous risquez alors de tomber dans une conception trop sophistiquée.
  • Veillez à ce que l’équipe marketing et l’équipe chargée de la livraison collaborent.
  • Le fonctionnement agile est une partie de la vision à long terme de l’entreprise et doit être considéré dans un contexte large. Il faut que les projets soient en adéquation avec la vision.
  • L’équipe peut effectuer un SPRINT suivant mais n’a pas de vue sur la stratégie globale. Faire le lien avec la vision à long terme est important.

Méthodologie

  • Combiner ERP/SAP et fonctionnement agile constitue un défi.
  • Il n’existe aucun environnement où vous ne devez pas fonctionner de manière agile. Il n’existe aucun environnement où vous n’avez pas besoin de la réaction du client.
  • Vous ne pouvez pas tout livrer dans le même "story point".
  • Lorsque vous n’êtes pas certain des exigences, faites des hypothèses mesurables.
  • Les architectures logicielles doivent être larges dès le début. Isolez les éléments à coût élevé avant de procéder à des changements.

KATALICT est un projet de collaboration entre Agoria et Sirris visant à accompagner les constructeurs logiciels dans le domaine de l’innovation, de l’ingénierie et de la croissance par les logiciels. Le projet est subventionné par l’Agentschap Ondernemen, dans le cadre de Vlaanderen in Actie et de la nouvelle politique industrielle flamande.


Cet article était-il utile ?

Sujets qui pourraient vous intéresser