Construire un paquet Debian

Dans l’article précédent, nous avions vu comment préparer un dépôt debian viable de façon a faire des installation et des déploiements sur une plateforme debian [3].

Nous allons nous intéresser dans ce présent article sur comment alimenter notre dépôt et donc comment nous allons procéder pour construire un paquet debian.

Structure du paquet debian

Un paquet debian [4] n’est initialement qu’un tar.gz dont l'extension est .deb, construit à l’aide de la commande dpkg-deb (il existe d’autre approche comme jdeb [5]) qui sera déployé à la racine /. Cela signifie qu’il sera nécessaire lors de la conception du paquet de reproduire l’arborescence cible si l’on souhaite déployer des fichiers dans des répertoires précis du système.

Ainsi par exemple si l’on souhaite construire un paquet permettant de déployer un binaire dans le système, on créera un répertoire du nom du paquet dans lequel on trouvera le chemin /usr/bin/monBinaire:

/home/moi/monPaquet/usr/bin/monBinaire

Ainsi quand l’on construira le paquet, celui ci déposera monBinaire dans /usr/bin.

Cette démarche est valable pour tout fichier déposé statiquement dans le système. A noter que lors de cette étape, dpkg, le composant procédant à l’installation, fait le listing des fichiers déposés et défini le paquet (et ses éventuelles versions futur) comme responsable du cycle de vie du fichier dans le système. Ceci a pour intérêt de détecter lors de l’installation d'éventuels conflit entre paquet qui seront à traiter par des primitives particulières quand cela est possible [2] (ce ne sera pas le cas dans cet article). Pour que dpkg puisse clairement identifier le paquet, celui ci doit obligatoirement contenir un fichier de control contenant toutes les informations sur l’identité, la version, l’utilisation du paquet. Vous verrons plus loin dans l’article ou le déposer et comment le construire

Par contre si nous avons ici un moyen simple et efficace pour déployer des fichiers, nous n’avons rien pour dynamiquement configurer l’installation en fonction du système courant.
En effet, souvent, lors de l’installation, il est nécessaire de prendre en considération au mieux des besoins et de l’environnement en initialisant des fichiers de conf selon les autres applications présentes, le contexte réseau éventuel ou même des préférences utilisateurs.

La première approche est alors d’apporter statiquement des configurations par défaut et de les modifier après l’installation. Cette approche fonctionne si et seulement si l'application ne nécessite pas une synchronisation particulière avec d’autres applications du système qui nécessite un redémarrage (par exemple la prise en compte d’un plugin par une application amené par deux paquets différents qu’il faut nécessairement redémarrer)

Les fichiers du responsable

Pour répondre à ce problème spécifique, en plus du fichier de control (obligatoire) et il est possible de définir des fichiers du responsable (postinst, preinst, postrm et prerm). Ces fichiers sont à placer dans un répertoire DEBIAN de notre paquet. Notre paquet devient alors:

(/home/moi) ./monPaquet/usr/bin/monBinaire(/home/moi) ./monPaquet/DEBIAN/control (obligatoire)(/home/moi) ./monPaquet/DEBIAN/postinst (optionnel)(/home/moi) ./monPaquet/DEBIAN/preinst (optionnel)(/home/moi) ./monPaquet/DEBIAN/postrm (optionnel)(/home/moi) ./monPaquet/DEBIAN/prerm (optionnel)

Ces fichiers sont alors exécuter automatiquement par l’outil dpkg [6] pendant l’installation ou la suppression.

Par exemple la phase d’installation exécute les phases suivantes:



De la même façon la suppression d’un paquet exécute les fichiers du responsables comme suit:



Enfin leur combinaison permet d’obtenir le comportement que l’on aura lors d’une mise à jour:



A noter que les scripts peuvent être des simples fichiers qui s'exécutent indifféremment du contexte (pas de la phase) mais qu’il est possible de leur attribuer des spécificités selon que l’on fait justement par exemple une installation ou une mise a jour. Pour cela il est conseillé de s’appuyer sur un squelette de script par défaut ou skeleton [7] (que je ne détaillerai pas ici).

Le fichier de control

Voila maintenant que l’on a construit la structure du deb, il reste finaliser le debian en définissant dans le détail le fichier de control.

Le fichier de control est comme dit sommairement au début de cet article, la pièce d’identitée du paquet debian a construire.

Il se constitue des champs suivant [8] (directement extrait de la documentation):

Package: hello
Version: 2.9-2+deb8u1
Architecture: amd64
Maintainer: Santiago Vila <sanvila@debian.org>
Depends: libc6 (>= 2.14)
Conflicts: hello-traditional
Breaks: hello-debhelper (<< 2.9)
Replaces: hello-debhelper (<< 2.9), hello-traditional
Section: devel
Priority: optional
Homepage: http://www.gnu.org/software/hello/
Description: example package based on GNU hello
      The GNU hello program produces a familiar, friendly greeting.  It
      allows non-programmers to use a classic computer science tool which
      would otherwise be unavailable to them.
      .
      Seriously, though: this is an example of how to do a Debian package.
      It is the Debian version of the GNU Project's `hello world' program
      (which is itself an example for the GNU Project).

• Le champ « Package » contient le nom du paquet. C'est le nom par lequel les outils de gestion de paquets peuvent le manipuler. Il est habituellement similaire mais pas nécessairement le même que la première chaîne composant le nom de l'archive Debian.
• Le champ de « Version » donne le numéro de version du composant.
• Le champ « Architecture » indique pour quel processeur ce binaire particulier a été compilé.
• Le champ « Depends » donne une liste des paquets qui doivent être installés afin d'installer ce paquet avec succès.
• La ligne « Section » indique la section où le paquet Debian est conservé sur les sites FTP de Debian.
• Le champ « Maintainer » contient l'adresse électronique de la personne actuellement responsable de la maintenance du paquet.
• Le champ « Description » fournit un bref résumé des fonctionnalités du paquet.

Bien sur tous ces champs suivant une nomenclature et de standards pour permettre de normaliser l’utilisation des paquets. Entre autre par exemple il est important de respecter certaines règles d'écriture du numéro de version afin de permettre des mises à jours conforme a l’attendu (voir les schémas du chapitre des fichiers du responsable sur les phases du cycle de vie d’installation, désinstallation et de mise à jour des paquets).

Chaque champs peut avoir son importance même s’ils ne sont pas obligatoire. Il convient donc de bien les étudier afin de prévenir ou de gérer les conflits entre paquets.

Construction du paquet debian

Pour finir cet article, il fait maintenant finaliser le packaging en construisant le .deb. Pour cela il suffit d’appeler la commande dpkg-deb:

dpkg-deb --build $REPERTOIRE_DEBIAN $REPO_DEBIAN/

avec REPERTOIRE_DEBIAN contenant le chemin du debian a packager et REPO_DEBIAN le répertoire de destination ou mettre le deb final (on privilégiera directement le dépôt debian)

Voila le paquet est construit et déposé dans un dépôt, il ne reste qu'à l’installer après une mise a jour du dépôt et un apt-get coté client.

Références

[1] http://blog.valouille.fr/2013/10/creer-un-paquet-debian-vide/
[2] https://www.debian.org/doc/manuals/debian-handbook/sect.package-meta-information.fr.html
[3] https://www.debian.org/doc/manuals/debian-faq/index.fr.html#contents
[4] https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html
[5] http://tcurdt.github.io/jdeb/
[6] https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts
[7] https://lists.debian.org/debian-mentors/1998/04/msg00004.html
[8] https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html#s-controlfile

QQOQCCP

Cet article sera court car il traite d’une approche simple mais efficace pour la préparation de projet mais aussi pour la rédaction d’article. Je m'étais intéressé à la question quand j’ai eu a faire ma thèse mais depuis j’avais un peu perdu le besoin, du coup me voici avec un article méthodologique de base mais qui pourra toujours servir.

Ainsi la question est comment rédiger un article ou identifier les éléments clefs d’un projet? Et bien en appliquant la règle des 7 questions: QQOQCCP [1] ou en 9 selon le cas [2] :

• Qui : Identification des acteurs
• Quoi : Solution apporté pour répondre au problème, il s’agit de la solution fonctionnelle
• Ou : Ou sera produit la solution et ou est le problème
• Quand : Quels sont les dates butoir du projet...
• Comment : définition de la mise en oeuvre, il s’agit de la solution technique non fonctionnelle
• Combien : en or ou en euro… bien sur c’est évident mais pour un projet… on peut aussi compter en jour
• Pourquoi : Identification du facteur déclenchant, en termes plus simple, c’est quoi le problème, A quoi on va répondre?
• Pour Qui : Définition des Use Case
• Avec Quoi : Définition des moyens de mise en oeuvre de la solution

Ici cela recoupe l’analyse d’un projet mais dans le contexte de la rédaction d’article, il n’est probablement pas nécessaire d’aller aussi loin et tous ne serviront pas forcément ni seront les même selon les sujets. Il me semble pourtant que pour tout article il est systématiquement nécessaire de traiter les points suivant:

• Pourquoi?
• Pour Qui?
• Quoi?
• Comment?
• Avec Quoi?

Bien sur comme il est dit dans l’article [2], le diable est dans les détails, et c’est effectivement lorsque l’on néglige quelques chose que cela nous explose à la figure. Donc même si dans le cadre d’article, ça ne parait pas forcément pertinent, se poser de bonnes questions, ne sera un luxe

Références

[1] https://www.piloter.org/qualite/qui-quoi-comment.htm
[2] http://www.rocketprojet.com/qqoqccp-recueil-besoins-9-questions/
[3] http://www.espacefrancais.com/les-types-de-plans-du-discours-argumentatif/

Faire un dépôt debian

Un dépôt debian est un répertoire distant dans lequel se trouve des paquets debian [2] . Ces paquets sont accessible via les commandes apt [1] du système debian et la conjonction des deux mécanismes (apt+dépôts) permet l’installation et la maintenance des applications présent dans le système

Procédure d’installation debian

Lors de l’installation d’un paquet, on appellera la commande

apt-get install tee

La composant apt va télécharger depuis le dépôt via ftp ou http l’outil tee et le depackagera dans le système (pour les plus curieux sur la structure du paquet debian et son processus de déploiement : [4] mais je rédigerai un article à cet effet ).

L’installation n’est possible que si apt ne connait le contenu du dépôts. Pour cela, il est nécessaire de mettre à jour le référentiel connu de apt du dépôt distant en téléchargeant le package spécial : Packages.gz qui liste les paquets présent dans le dépôt. Il reste a appliquer la commande suivant:

apt-get update

Il manque encore une information importante: La localisation du dépôt qu’il est nécessaire de renseigner dans le fichier de configuration sources.list d'Apt (dans le répertoire /etc/apt)

Cependant pour renseigner ce fichier, il nous faut connaître la structure du dépôt et comment celui-ci se construit.

Structure d’un dépôt

Un dépôt debian n’est qu’un répertoire contenant des paquets debian. Ce répertoire va contraindre le nommage du dépôt. Pour que le dépôt soit viable, il doit contenir au moins un fichier Packages.gz cité plus haut dans un répertoire bien spécifique [6] . Ce répertoire est accessible via un chemin contenu dans le dépôt commençant par “dists” qui va spécifier divers informations facilitant le classement des paquets. Par exemple, il va être possible de distinguer les paquets propre à des architecture cibles différentes et des paquets pour les architectures  amd64, armhf, i386, etc.

Ce qui importe c’est d’avoir conscience que le chemin menant aux différents Packages.gz, va conditionner la façon dont on va référencer le dépôt coté client dans le sources.list.

Le fichier sources.list suit la syntaxe suivante [6] :

deb uri distribution [component1] [component2] [...]

• la primitive deb spécifié qu’il s’agit d’un dépôt debian
• uri est le chemin local ou réseau pour accéder au dépôt (généralement il est positionné derrière un serveur http apache)
• distribution est le système cible mais celui ci est généralement le premier sous répertoire du chemin commençant par dists.
• component* est un ensemble de sous répertoires au chemin suivant la distribution et avant le répertoire spécifiant l’architecture. Ils facilitent le classement des paquets selon leur utilisation (paquet de test, de sources, gratuit ou non, etc.)

Enfin le chemin se termine sur un répertoire spécifiant au moins une architecture.

Exemple si on considère un serveur apache exposant le chemin suivant:

(/var/www) ./debian/dists/maDistrib/all/binary-amd64/Packages.gz

Il faut spécifier dans le sources.list du client apt:

deb http://ipServer/debian maDistrib all 

Initialisation du dépôt

Maintenant que l’on a un dépôt debian, ou mettre nos paquets et comment procéder à son initialisation?

Dans la pratique les paquets debian produits sont déposés à la racine du paquet ou dans des sous répertoires de classement. Ces paquets sont ensuite indexés lors que la construction du Packages.gz a l’aide de la commande scanpackage [3].

cd $DEB_DIR; dpkg-scanpackages . /dev/null | gzip -9c > $DEB_DIR/dists/maDistrib/all/binary-amd64/Packages.gz

Voila les paquets sont accessibles il reste a mettre a jour le client (apt-get update) puis faire soit une installation ou une mise a jours (apt-get upgrade)

Nous intéresserons dans un autre article a la structure d'un paquet debian, a son cycle de vie et comment le produire.

References

[1] https://www.debian.org/doc/manuals/debian-faq/ch-pkgtools.fr.html#s-pkgprogs
[2] https://www.debian.org/doc/manuals/debian-faq/index.fr.html#contents
[3] https://wiki.debian.org/DebianRepository/Setup?action=show&redirect=HowToSetupADebianRepository
[4] Base sur le paquet bebian https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html
[5] https://wiki.debian.org/DebianRepository/
[6] https://wiki.debian.org/DebianRepository/Format

Les processus de développement ou cycles de vie du logiciel

Dans cet article faisons un état des lieux plus détaillé des cycles de vie les plus importants et les plus couramment utilisés. Après une présentation des cycles classiques comme ceux en Cascade ou en V, seront présentées des méthodes plus récentes basées sur l’agilité.

Les Classiques

Cycle en Cascade

Le cycle en cascade est typiquement un cycle de développement prédictif. Provenant du bâtiment, il part du principe que la construction nécessite, en général, un enchaînement logique ; la couverture d’une maison ne peut pas être effectuée sans avoir préalablement fait les fondations. Il définit une démarche de développement séquentiel (figure 2.9) où chaque phase conduit à la production d’un ou plusieurs livrable(s) qui doivent être validés avant d’être utilisés lors de la phase suivante.

Le modèle en cascade nécessite la définition d’un planning détaillé qui énonce toutes les étapes et réalisations attendues. Différentes activités d’analyse, de conception, d’implantation, de tests et d’intégration sont effectuées afin de converger vers l’obtention du système logiciel final.



Initialement, le modèle en cascade est un cycle de développement purement séquentiel, cependant, diverses possibilités d’itération ou de retour vers les phases amont ont ensuite été intégrées au modèle. Ces itérations permettent de vérifier les produits obtenus au fil du développement et ainsi fournir plus de souplesse à la conception.

Cycle en V

Le cycle en V est l’un des cycles les plus connus et utilisés (figure 2.10). C’est un cycle de type prédictif qui a été défini pour remédier aux lacunes du cycle en cascade qui manque de réactivité face aux erreurs découvertes lors de la conception, du développement ou encore de l’analyse. La structure en V du cycle a l’avantage de mettre en vis à vis les activités de développement et de tests permettant de mieux préciser les documents à
partager entre ces phases, notamment les rapports de tests et les modifications qu’il est nécessaire d’apporter pour corriger les erreurs. Ainsi, lors de la phase montante du cycle, toutes les réalisations doivent être testées et validées.


Depuis les années 80, le cycle en V est considéré comme un standard du développement logiciel et de la gestion de projet dans les industries. A la suite du cycle en V sont apparues diverses variantes telles que, par exemple, le cycle en W qui propose d’effectuer deux cycles en V successivement, le premier servant à la conception d’un prototype de l’application, le second à construire l’application finale.

Cycle en Y

Dans son principe, le cycle de développement en Y, est proche du cycle en cascade dont il reprend l’aspect descendant. Son intérêt est de séparer les préoccupations concernant les aspects fonctionnels liés au domaine métier et les aspects techniques liés aux solutions technologiques à employer pour la mise en oeuvre.

Avec le MDA, un cycle en Y orienté modèle a été proposé afin de séparer les spécifications fonctionnelles (PIM) et les spécifications techniques (PSM). Cette approche a pour avantage de fournir un modèle plus rationnel de la gestion des modèles et de l’utilisation des transformations de modèles employées lors de la phase de conception pour faire coïncider les modèles techniques et fonctionnels (employés également lors de la phase d’implantation sous la forme de génération de code).

Cycle en Spirale

Défini par Barry Boehm, le cycle en spirale est une approche itérative du cycle de développement en V. Ainsi, il en reprend l’essentiel des concepts en s’articulant autour de quatre phases importantes (figure 2.12) : la détermination des objectifs, la détermination des risques, le développement et les tests et enfin la planification de l’itération suivante.




Par contre, à l’inverse du cycle en V, le modèle en spirale met un focus plus important sur l’analyse et la résolution des risques. Ceci est nécessaire car au fur et à mesure des itérations, la réalisation devient de plus en plus conséquente. Il est donc important d’évaluer correctement le risque à chaque itération sachant que toute erreur sera d’autant plus difficile à corriger que le développement sera avancé.

Pre-agilité

Cycle avec Prototypage Rapide (RAD)

Proposé dés la fin des années 1980, le cycle de développement avec Prototypage Rapide (Rapid Application Development aussi appelé semi-itératif) se situe entre une approche prédictive et une méthode agile dans le sens où il s’agit de l’une des premières approches à introduire la notion d’itération au sein du processus de développement. La méthode RAD se structure ainsi autour de cinq phases :

1. L’initialisation pendant laquelle le périmètre du projet et les ressources nécessaires à celui-ci sont définis. Le travail à effectuer est alors organisé par thèmes.
2. Le cadrage qui va définir les besoins et les fonctionnalités du produit. Cette phase est effectuée lors de réunions se basant sur des techniques d’animation spécifiques.
3. La conception des modèles nécessaires à l’élaboration du système logiciel proprement dit. Le client est fortement impliqué dans cette phase puisqu’il a pour rôle de valider les modèles proposés.
4. La construction du système logiciel par l’équipe de développement par une approche itérative selon les fonctionnalités demandées. Le client est toujours présent afin de valider les différentes réalisations.
5. La finalisation est une phase de validation globale du livrable final par le client.

Ainsi, les deux premières phases se placent dans une approche descendante comme celle en V ou en Cascade. Par contre, à partir de la troisième phase, le cycle de développement devient itératif en permettant d’alterner conception et validation. De plus, avec l’intégration du client dans le développement, cette démarche fournit plus de réactivité.

La méthode RAD est pionnière dans l’utilisation de l’itération et d’une intégration plus importante du client dans le processus de développement. A ce titre, elle peut être considérée comme initiatrice des méthodes agiles qui sont fondamentalement tournées vers ces concepts. Les paragraphes suivants présentent les démarches et cycles proposant une approche agile du développement.

Unified Process UP

Tout comme RAD, UP est un cycle de développement qui se positionne entre les approches prédictives et les approches agiles. Ce cycle de vie est né de l’approche orientée objet issue de la collaboration de Ivar Jacobson, Grady Booch et James Rumbaugh. L’approche UP tente de rationaliser les processus de développement logiciel en fournissant un guide de bonne pratique fondé sur six points :

1. Avoir une démarche incrémentale et itérative pilotée par les risques et les cas d’utilisation.
2. Avoir une gestion rigoureuse des exigences.
3. Centrer le développement sur l’architecture.
4. Faire une modélisation graphique des exigences.
5. Contrôler en permanence la qualité.
6. Contrôler les changements éventuels à effectuer.

Ces six bonnes pratiques prônées par UP sont en l’occurrence ce qui permet de rattacher ce cycle de développement aux méthodes agiles. En effet, contrairement aux démarches de développement classiques, UP oriente naturellement le développement pour que celui-ci soit à même de répondre aux changements.
UP définit une démarche de développement intégrant les neuf disciplines majeures nécessaires au développement : la modélisation métier, la définition des exigences, l’analyse et la conception, l’implantation, les tests, le déploiement, la gestion des changements, la gestion du projet et enfin la prise en compte de l’environnement. Basé sur ces disciplines qui seront employées à chaque itération, le processus de développement va alors pouvoir suivre les quatre phases du processus qui consistent en :

1. Le début dont l’objectif est d’unifier les points de vue de chacune des disciplines sur l’ensemble du projet.
2. L’élaboration qui a pour objectif de définir et de valider l’ensemble des modèles permettant la conception du système logiciel.
3. La construction qui doit fournir une version documentée et fonctionnelle du logiciel.
4. La transition dont le but est de finaliser le système.

Avec Unified Software Process Metamodel (USPM), les démarches de développement se sont orientées vers la modélisation des processus en suivant le credo issu de la publication de Lee Osterweil : Software processes are software too. Traduit littéralement que les processus de développement de logiciel sont aussi une forme de logiciel. Cette publication montre la nécessité de maîtriser le processus de développement en modélisant sa structure et son évolution.

L'agilité

L’extreme programming

L’extreme programming est à proprement parler une approche agile qui propose des itérations courtes impliquant au maximum le client et cherche à recentrer le développement sur la composante humaine en revalorisant les bonnes pratiques de développement telles que le binomage, la définition au plus court de tests fonctionnels permettant de valider l'application, la promotion de styles ou de pattern d'écriture de code.
XP fonctionne autour de 5 valeurs fondamentales souvents reprise dans les approches agiles plus récentes:

• Communication
• Feedback
• Simplicite
• Courage
• Respect

Scrum

Développée en 1993, Scrum est une approche agile qui met en avant l’intérêt des petites équipes de développement. Dans ces petites équipes, sont avant tout recherchées les compétences multidisciplinaires et la capacité d’intégration sociale des acteurs. Dans Scrum, les itérations appelées Sprint sont planifiées sur quatre semaines maximum. Ces itérations sont axées sur les besoins définis par le client qui constituent alors le référentiel de travail.
Les besoins sont hiérarchisés par degré d’importance et développés selon les priorités définies par le client. Chaque jour constitue une itération pendant laquelle une réunion est organisée pour établir l’état d’avancement du projet et de vérifier que les fonctionnalités et les délais sont bien respectés.



A la fin de chaque Sprint, une réunion établissant le bilan des réalisations est menée afin d’établir l’efficacité de l’équipe et les éventuelles améliorations qui doivent être apportées. La finalité d’un Sprint est de présenter un démonstrateur au client afin que celui-ci puisse valider les réalisations. Scrum définit un certain nombre d’acteurs qui vont intervenir lors de la mise en oeuvre du processus :

1. Le ScrumMaster a pour rôle d’aider les acteurs du développement à communiquer au sein de l’équipe ainsi qu’avec le client. Il doit s’assurer que la philosophie et les pratiques de Scrum sont correctement suivies. Par contre son rôle n’est pas à confondre avec celui du chef de projet dont il est plutôt un conseillé.
2. Le Client ou Product Owner est lui aussi acteur du développement, il a pour rôle de définir les besoins. Il doit également définir les priorités dans les fonctionnalités à réaliser. Ainsi, il participe activement à l’élaboration du produit en suivant les étapes de sa réalisation afin de pouvoir en valider la finalité.
3. Enfin, l’Équipe qui est constituée de l’ensemble des corps de métiers nécessaires à l’élaboration du produit. Ces métiers sont classiquement ceux rencontrés lors des développements logiciels classiques (Développeur, Analyste, Testeur, etc.)

Pour finir, la méthode Scrum s’appuie sur la notion de Visibilité pour qualifier et quantifier les résultats de l’équipe. Des critères de validation doivent exister afin de définir si une fonctionnalité a été complètement réalisée ou non. Des critères d’Inspection doivent être définis afin de déterminer l’existence d’écarts entre la réalisation concrète et l’objectif final. Enfin, la notion d’Adaptation permet, lors d’écarts trop importants détectés pendant des Inspections, de modifier la gestion interne de l’équipe afin d’éviter que ces écarts ne s’amplifient. Ces critères permettront alors de gérer de la dette techniques ou encore d'évaluer la vélocité de l'équipe de développement afin de planifier au mieux les contenus des livraisons futurs

On peut noter que Scrum et XP sont deux approches très proches (on note d’ailleur une forte proximité des valeurs vehiculés) qui cherchent l’une comme l’autre a remettre la vie du développeur au centre du processus. Cependant Scrum a une volonté plus marqué de fournir un processus formellement établi pour gérer le cycle de vie du logiciel alors que XP s'intéresse plus sur les bonnes pratiques. Généralement les equipes de développement pratiquant l’une pratique préférablement la seconde.

Lean

Le lean est une approche de gestion de production développé par Toyota dans les années 90. Avec un héritage assumé issu du Taylorisme, le lean se définit dans une recherche d'accroissement de la productivité, de la qualité et d'une réduction systématique du gaspillage.

Dans les approches agiles, si XP a pour propos de mettre en avant des valeurs humaines et si Scrum a pour objet de recentrer le processus autour de la production des éléments a plus haute valeur, le Lean complète ces approches en visant l’optimisation des processus eux même.

Pour cela, le lean va se focaliser sur 7 règles qui servent d’axes de progressions (qui sont probablement des questions systématiques aux rétrospectives de sprints):

1. comment reduire les dechets? (temps perdus, réduction de dette technique, etc…)
2. comment améliorer la monté en compétences?
3. decider au plus tard
4. livrer au plus tot
5. valoriser l’equipe
6. la qualité commence des la conception
7. avoir toujours une vision du logiciel dans sa globalité (maintenir le recul)

Conclusion

Les processus de développement sont nombreux et si historiquement l'approche en V a été adoptée majoritairement, les nouvelles approches comme les approches agiles tendent a s'imposer comme étant des solutions plus dynamique et adaptées aux changements actuel. Je reviendrais plus dans le détail des approches telles que Scrum et Lean qui mérite au vue de leur présence actuel d'être approfondie. De la même manière, ces dernières années, au delà des processus de développement, on a pu voir émerger le DevOps dont le but est de regarder au delà des équipes de développement en prenant en considération l'ensemble des besoins des acteurs agissant de près ou de loin dans la livraison du produit au client. Il me semble que même si cela déborde du cadre des processus de développement de l'équipe logicielle, celle ci doit prendre en compte ces nouvelles préoccupations et cela a forcément un impact sur leur activité