{"id":8947,"date":"2022-10-02T09:54:41","date_gmt":"2022-10-02T08:54:41","guid":{"rendered":"https:\/\/arexo.be\/?p=8947"},"modified":"2022-10-09T10:27:54","modified_gmt":"2022-10-09T09:27:54","slug":"quand-scrum-rencontre-low-code","status":"publish","type":"post","link":"https:\/\/arexo.be\/fr\/quand-scrum-rencontre-low-code\/","title":{"rendered":"Quand Scrum rencontre Low-Code"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Scrum est un Framework permettant de concr\u00e9tiser la gestion Agile d\u2019un projet. Depuis plusieurs ann\u00e9es, il s\u2019est fortement r\u00e9pondu et est devenu un indispensable pour certains types de projets. <\/p>\n

Pour rappel, Scrum est utile pour des projets complexes. Il n\u2019est pas une m\u00e9thode mais bien une boite \u00e0 outils pour une organisation. <\/p>\n

Low-Code de son cot\u00e9, est une solution qui permet de d\u00e9livrer des projets informatiques dans des d\u00e9lais tr\u00e8s courts. Livrer des projets rapidement peut \u00eatre une bonne chose mais peut \u00e9galement amener vers un travail moins pr\u00e9cis que s\u2019il avait \u00e9t\u00e9 r\u00e9alis\u00e9 en plus de temps.<\/p>\n

Aujourd\u2019hui nous pouvons mettre plusieurs \u00e9l\u00e9ments sous la loupe avec Scrum et Low-Code, nous les avons list\u00e9 ci-dessous :<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Sous la loupe<\/h4>\n

1) Scrum est plut\u00f4t destin\u00e9 \u00e0 des projets complexes, Low-Code rend la plupart des projets tr\u00e8s simples.<\/strong><\/p>\n

<\/strong><\/p>\n

Comme nous l\u2019avons \u00e9voqu\u00e9 plus haut, Scrum est un Framework Agile qui va d\u00e9composer le travail complexe est une succession de travaux plus simples, effectu\u00e9s en plusieurs \u00e9tapes jusqu\u2019\u00e0 livraison du r\u00e9sultat escompt\u00e9.<\/p>\n

Avec le Low-code, le volet d\u00e9veloppement de cette d\u00e9composition est tr\u00e8s sommaire par ce que le travail des d\u00e9veloppeurs consiste surtout \u00e0 faire interagir des modules d\u00e9j\u00e0 existants, ce qui permet de transformer des projets techniques complexes en projets simples.<\/p>\n<\/p>\n

2) Scrum pr\u00e9conise un product backlog par produit.<\/span><\/strong><\/p>\n

<\/span><\/strong><\/p>\n

Gr\u00e2ce \u00e0 Low-Code, une Scrum team peut travailler sur plusieurs product backlogs. En effet, habituellement, une Scrum team travaille sur un seul P.B \u00e0 la fois.<\/p>\n

Avec le Low-Code, une Scrum team est dans la possibilit\u00e9 de travailler sur plusieurs product backlogs en m\u00eame temps.<\/p>\n<\/p>\n

3) La Timebox pr\u00e9conis\u00e9 par Scrum d\u2019un sprint de r\u00e9f\u00e9rence est d\u2019un mois mais avec Low-Code, celle-ci peut \u00eatre r\u00e9duite jusqu\u2019\u00e0 une semaine.<\/strong><\/p>\n

<\/strong><\/p>\n

Scrum met en place des r\u00e9unions r\u00e9guli\u00e8res destin\u00e9es \u00e0 garantir la bonne compr\u00e9hension des besoins des clients au travers des p\u00e9riodes de validation les impliquant activement. D\u2019autres r\u00e9unions se focaliseront l\u2019am\u00e9lioration du cadre de travail des d\u00e9veloppeurs.<\/p>\n

Ces r\u00e9unions d\u00e9terminent le d\u00e9but et la fin d\u2019une p\u00e9riode de travail appel\u00e9e Sprint.<\/p>\n

Selon la litt\u00e9rature, la dur\u00e9e d\u2019un sprint doit \u00eatre la plus courte possible pour permettre des r\u00e9unions r\u00e9guli\u00e8res et suffisamment longues que pour livrer des incr\u00e9ments amenant de la valeur ajout\u00e9e.<\/p>\n

Avec le Low-Code, la v\u00e9locit\u00e9 de l\u2019\u00e9quipe (la vitesse avec laquelle il d\u00e9livre ses incr\u00e9ments) est tr\u00e8s fortement augment\u00e9e. Si on n\u2019adapte pas la timebox (la dur\u00e9e) du sprint, nous risquons de perdre en efficacit\u00e9.<\/p>\n<\/p>\n

4) Une Scrum team peut commencer \u00e0 travailler \u00e0 partir d\u2019un scope suffisamment clair<\/strong><\/p>\n

<\/strong><\/p>\n

On affinera alors les besoins en cours de d\u00e9veloppement. Les besoins vont changer pendant toute la dur\u00e9e de la cr\u00e9ation. On peut tr\u00e8s bien changer de voies, revoir certains besoins, soumettre d\u2019autres pistes et ainsi \u00eatre amen\u00e9 \u00e0 changer radicalement le scope principal. En partant d\u2019un scope clairement d\u00e9fini, on peut commencer \u00e0 travailler sur le projet, changer et affiner les \u00e9l\u00e9ments en cours de route.<\/p>\n

Avec Low-Code on doit \u00eatre beaucoup plus pr\u00e9cis dans l\u2019expression des besoins avant de commencer \u00e0 d\u00e9velopper. Low-Code qui est une outils RAD (Rapid Application Develment) doit partir d\u2019un scope non seulement bien d\u00e9fini mais aussi pr\u00e9cis dans les besoins sinon on risque de bloquer l\u2019\u00e9quipe de d\u00e9veloppement, faute d\u2019input suffisant. On doit travailler plus en d\u00e9tail sur l\u2019expression des besoins.<\/p>\n

Scrum nous donne quelques outils, \u00e0 condition de tol\u00e9rer plusieurs coups de canifs dans le contrat.<\/h3>\n

On en a list\u00e9 trois :<\/p>\n<\/p>\n

1) Plusieurs Product Owner pour des projets simples (\u00e0 r\u00e9aliser) en parall\u00e8le<\/strong><\/p>\n

<\/strong><\/p>\n

Si l\u2019\u00e9quipe de d\u00e9veloppement travaille sur plusieurs product backlog, il faut un nombre de Product Owner au prorata pour garantir pour chacun d\u2019entre eux une livraison time-to-market (ad\u00e9quate avec les attentes du moment)<\/p>\n<\/p>\n

2) Apparition de deux r\u00f4les p\u00e9riph\u00e9riques : Head-Of Product Owner et Tech Lead<\/b><\/span><\/p>\n

<\/b><\/span><\/p>\n

Cot\u00e9 m\u00e9tier, le Head-Of Product Owner aura la vue m\u00e9tier transversale permettant de fixer des priorit\u00e9s entre les diff\u00e9rents Product Backlogs en concurrence. Il sera celui qui coordonne et optimalise et priorise le travail des Product Owner.<\/span><\/p>\n<\/p>\n

C\u00f4t\u00e9 technique, le Tech Lead est le r\u00e9f\u00e9rent technique des Product Owner d\u2019un c\u00f4t\u00e9 et des d\u00e9veloppeurs de l\u2019autre. Il fera une premi\u00e8re passe sur les solutions technico-fonctionnelle afin de garantir la conformit\u00e9 des choix avant de confirmer la prise en charge du travail de d\u00e9veloppement.<\/span><\/p>\n

<\/span><\/p>\n

3) Scrum Master tr\u00e8s exp\u00e9riment\u00e9, tr\u00e8s flexible et tr\u00e8s r\u00e9actif <\/b>
<\/span><\/p>\n

<\/b><\/span><\/p>\n

En fait, Une Scrum Team \u201clow-code\u201d va exp\u00e9rimenter les m\u00eames probl\u00e9matiques qu\u2019une \u00e9quipe de d\u00e9veloppement \u201cclassique\u201d Mais elle va les exp\u00e9rimenter beaucoup plus vite.<\/span><\/p>\n<\/p>\n

Afin de ne pas noyer la Scrum Team dans des concepts au d\u00e9triment de leur c\u0153ur de m\u00e9tier, c\u2019est \u00e0 dire la livraison d\u2019incr\u00e9ment (c\u2019est-\u00e0-dire des parties du produit), le Scrum Master doit \u00eatre suffisamment exp\u00e9riment\u00e9 pour proposer des solutions robustes rapidement et pour faire vivre l\u2019approche cl\u00e9 de l\u2019empirisme et de la co-cr\u00e9ation\u2026<\/span><\/p>\n

<\/span><\/p>\n

Conclusion<\/span><\/h4>\n

<\/span><\/p>\n

Scrum est-il un Framework qui convient pour g\u00e9rer un projet Low-Code ? <\/span><\/p>\n<\/p>\n

La r\u00e9ponse est oui si les coups de canif dont nous avons parl\u00e9 ne vous font pas peur.<\/span><\/p>\n

<\/span><\/p>\n

<\/b><\/span><\/p>\n

<\/span><\/p>\n

<\/b><\/span><\/p><\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t
<\/div>\n