Bien démarrer un projet SCRUM

Comment bien démarrer un projet en mode agile comme SCRUM ? L’idée de ce billet n’est pas de détailler toutes ces tâches mais de les présenter dans un cas concret.

Les rôles de chacun dans un projet SCRUM

Pour rappel Scrum définit seulement 3 rôles :

  • Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet. C’est la personne qui la personne à qui on donne une mission, un mandat, pour mener à bien un projet. On lui délègue des pouvoirs, des moyens et la responsabilité du succès du projet.
  • L’Equipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système.
  • Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive.

La séparation MOA et MOE

Je rajoute un quatrième rôle que je nommerai l’exécutif, qui représente l’organisation commanditaire, ou autrement dit la MOA, et les intérêts des parties prenantes du projet (utilisateurs, fournisseurs, direction,…). Il en en étroite liaison avec le produit owner qui représente la MOE.  C’est l’exécutif qui a le pouvoir d’arrêter ou non le projet. Le product owner doit alors demander l’autorisation de continuer le projet après chaque phase. Il a donc le contrôle du projet.

A noter que ce rôle n’est pas préconisée par les méthodologies agiles qui ne font de séparation entre MOA et MOE, mais par mon expérience elle est utile pour les projets avec une séparation « contractuelle » entre ces deux entités. Il est cependant recommandé de s’efforcer au maximum de décloisonner ces deux entités qui doivent collaborer étroitement tout au long du projet. En particulier les utilisateurs et opérateurs doivent interagir avec les équipes de développement tout au long du projet (voir DevOps)

La phase d’élaboration

Cette phase permet de s’assurer que l’on dispose de toutes les autorités nécessaires pour initialiser le projet, que l’on dispose d’informations suffisantes pour définir le périmètre du projet, que les modalités de livraisons ont été convenus, et que des candidats ont été retenus pour constituer l’équipe projet.

  • Nommer un exécutif et un product owner : c’est une condition préalable pour s’assurer que le projet est justifié par l’entreprise
  • Recueillir les retours d’expérience passés: il  est possible que d’autres projets menés par entreprise aient permis de tirer des leçons concernant les faiblesses ou les points forts des processus, techniques ou outils utilisés; les personnes ou les équipes justifiant cette expérience préalable doivent être consultées
  • Composer et nommer l’équipe projet: composer l’équipe projet, SCRUM master et développeurs, estimer le temps et l’effort pour chacun de ces roles
  • Préparer les objectifs et enjeux du projet: l’exécutif expose au product owner les informations qu’il dispose (objectifs, raisons, normes, contrat, exigences qualité, critères d’acception, délais, cout, risques …)
  • Définir l’approche projet: le product owner évalue et valide avec l’exécutif la manière dont le projet doit être abordé avant d’être planifié (solution de livraison possibles, confirmer les objectifs, périmètres, contraintes, tolérances, interfaces ..), l’approche agile par SCRUM doit être également validé par l’exécutif.
  • Planifier la phase initialisation: la phase d’initialisation (premier incrément SCRUM) est planifié.
  • valider la phase avec l’exécutif: l’exécutif doit autoriser le démarrage de la phase d’initiation; sans cette autorisation le projets est arrêté.

La phase d’initialisation

La phase initialisation (Sprint Init) a pour but de doter le projet de fondations suffisantes pour mieux comprendre le travail à faire. Voici une liste de tâches pouvant être intégrée dans la phase d’initialisation.

  • Préparer la stratégie du projet: le product owner définit les objectifs, la procédure, les outils ainsi que le rôle et la responsabilité de chacun pour les domaines suivants: risques, qualité, communication, gestion des incidents …
  • Valider les objectifs et les enjeux du projet: le Product Owner présente et valide avec toute l’équipe les objectifs et les enjeux du projet : il doit partager les points qui ont vu dans la phase précédente avec l’exécutif comme par exemple: concurrence, Dead Line et contraintes « imposées » par le client …
  • Découper le projet en livraison et priorisation: le Product Owner présente sa vision du contenu des livraisons du projet, objectifs, jalon et utilisateurs et définit les priorités;
  • Découper les livraisons en Sprint et priorisation: le Product Owner présente un découpage « grossier » du contenu des livraisons avec la priorisation des Sprints.
  • Rappeler des principes de Scrum: un rappel collective à l’équipe et le Product Owner par le Scrum Master ne fait jamais de mal
  • Mettre en place de l’architecture technique: l’environnement technique doit être définit et prêt dés ce premier sprint, avec au minimum un environnements de développement et d’intégration opérationnel (installé et configuré), règles de développement, gestion du code source avec les règles de fonctionnement, le processus de sauvegarde et idéalement un processus d’intégration et de test automatisé
  • Mettre en place le management visuel: l’équipe prépare les  indicateurs visuels du projet: scrum board (user stories, product backlogs, sprint backlogs, burn down chart, identification du sprint courant et contenu) que l’on peut compléter par une partie : problèmes techniques ou organisationnel et actions à faire suite au sprint précédent .
  • Réunion de planification collective: Le product Owner présente les exigences fonctionnels et non fonctionnels des livraisons et l’équipe chiffre avec la technique de Planning Poker et ordonne en  taches. Le découpage permet de valider ce qu’il va y avoir dans chaque Sprint. le Product Backlog est alors constitué et affiché par ordre de priorité.
  • Réunion de planification du Sprint 1: la durée de la réunion doit être de 2h par semaine de Sprint (soit 4h pour un sprint de 2 semaines). On doit définir:
    • le quoi: le produit owner revoit avec l’équipe de développement l’objectif du sprint et le Product Backlog. L’équipe vérifie les estimations, confirme qu’elles sont exactes et sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint
    • le comment: L’équipe fait ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Les tâches de développement sont centralisées dans le Sprint Backlog
  • valider la phase avec l’exécutif: le product owner demande à l’exécutif d’autoriser le démarrage de la phase suivante; sans cette autorisation le projets est arrêté.

Sprint 1

  • Daily Scrum Meeting: Le point quotidien de l’équipe avec le Product Owner; le  tableau du reste à faire Burndown Chart est remis à jour. Les obstacles rencontrés, doivent être priorisées par le product owner, qui doit les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive.
  • Développement et tests: l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog;la tache doit être validée, testée et documentée avant être considéré comme terminée. Le pair programmation peut être mis en place pour veiller à la qualité du code d’une exigence donnée.
  • Réunion de planification du Sprint 2: Dans la dernière semaine du Sprint, l’équipe, le Scrum Master et le Product Owner préparent le Sprint suivant, comme pour le pour Sprint 1
  • Fin du développement du Sprint 1: les taches doivent être développées, testées et disponibles sur l’environnement d’intégration
  • Revu de Sprint: Prévoir une heure par semaine de sprint (soit 2h pour un sprint de deux semaines) ; L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la version et adapter au besoin le plan et le Product Backlog. L’équipe de développement présente au Product Owner idéalement accompagné d’utilisateurs, les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe, il accepte ou refuse les fonctionnalités présentées.
  • Rétrospective de Sprint: Prévoir une durée de 45 min par semaine de Sprint (soit 1h30 pour un Sprint de 2 semaines) : l’équipe et le Scrum master  analyse les obstacles du Sprint 1 et les axes d’amélioration.
  • Mise en place physique du tableau des obstacles: C’est la tâche qui permet de ne pas oublier de mettre à jour la liste des obstacles.
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective): Cette mise à jour dépend des retours de la rétrospective.
  • Calculer la vélocité du Sprint 1: Combien de temps l’équipe a-t-elle passé à développer (et tester) des fonctionnalités pour la release ?

Sprint 2

  • Daily Scrum Meeting
  • Développement et tests
  • Réunion de planification du Sprint 3
  • Fin du développement du Sprint 2
  • Revu de Sprint
  • Rétrospective de Sprint et comparaison avec les rétrospectives précédentes
  • Mise en place physique du tableau des obstacles
  • Mise à jour des définitions de fini pour une tâche et pour le Sprint (en fonction de la rétrospective)
  • Calcul de la vélocité du Sprint 2 et comparaison avec le Sprint 1

Il y a exactement les mêmes tâches entre le Sprint 1 et le Sprint 2 : Seul le contenu change, les résultats du Sprint 1 vont influer sur le Sprint 2 et ainsi de suite jusqu’au dernier Sprint.

A noter que le dernier Sprint correspond à la confirmation que la livraison du produit a été accepté  et que le projet peut être clos pour être passé en maintenance.

Centre de services, régie et forfait

Il est bon parfois de rappeler certain principe. Quand on parle de centre de services en informatique, on parle du point de contact entre les gens du métier qui ont la connaissance fonctionnelle (c’est la maitrise d’ouvrage), et les services informatiques, qui ont la connaissance technique des infrastructure ou des application (c’est la maitrise d’œuvre), pour traiter des demandes pour un projet ou un service donnés. En externalisant ces services, cela constitue une manière efficace d’organiser les projets en termes de réactivité, de montée en charge ou en compétences techniques, de qualité et de transfert de savoir-faire. On parle alors de sociétés de services en informatique (ou du numérique) ou plus vulgairement d’ESN ou antérieurement SSII.

On distingue deux types de services:

Centre de services orienté Compétentes

Traditionnellement, quand une entreprise confie un projet informatique à une société de services en informatique (SSII ou ESN), le projet est réalisé dans les locaux du donneur d’ordre, par un ou des salariés de la SSII délégués sur place et facturés au nombre de jours passés. On parle alors de régie. Cela concerne la mise en place d’un ensemble de profils dotée de compétences bien identifiées.

Les critères de qualité et d’efficacité de ce centre de service sont principalement:

  •     la disponibilité des équipes (recrutement),
  •     la capacité à monter en charge,
  •     les compétences des ingénieurs (profils, formation, évolution),
  •     leur motivation et leur implication.

Les compétences demandées peuvent être techniques (MOE) ou métier, on parle alors d’assistance à la maitrise d’ouvrage ou AMOA.

Le pilotage du projet se fait par le client sur une période donnée.Un taux journalier (TJ) est négocié pour ces intervenants sur cette période. Certaine régie peuvent être « forfaitisée » avec un engagement de résultat. Dans ce cas aucune facturation ne peut se faire en cas dépassement, voir des pénalités de retard peuvent être encourues si le contrat le prévoyait.

Centre de service orienté Projet

Depuis quelques années, la plupart des SSII (ESN) ont développé une approche alternative à la demandes de leurs clients. Celle-ci repose sur la constitution de centres de services, regroupant des ingénieurs ou techniciens spécialisés sur une technologie ou un secteur d’activité, et intervenant sur des projets de développement applicative. Concentrant ces spécialistes dans un centre de service, cela permet d’améliorer les méthodes de développement et de mutualiser les profils sur plusieurs projets, bref d’optimiser les couts.

Ce centre de services s’engage sur un ensemble de projets au Forfait, en termes de délais, coûts, qualité. Il est dédié au développement d’applications sur toutes les phases de développement, depuis l’analyse, la spécification fonctionnelle, la réalisation, jusqu’au déploiement, avec un engagement basé sur les charges et de couts, les délais et la qualité des livrables. La gestion de la qualité doit s’assurer de la satisfaction du client tout au long du projet.

La facturation se fait sur un coût global, le périmètre précis et une date de livraison ont été définis et négociés. Chaque évolution est facturée comme un avenant au projet. La encore des pénalités de retard peuvent être encourues si le contrat le prévoyait.

Centre de service orienté Maintenance

Le Centre de Services Maintenance, traite des demandes de type TMA ou TRA.

  • maintien en condition opérationnelle des applications : corrections et évolutions,
  • amélioration de la performance et de la qualité des applications,
  • évolutions techniques et fonctionnelles,
  • support à différents niveaux.

Il fonctionne sur le même mode d’organisation que le Centre de Services Projets. Des indicateurs de qualité de services (SLA) peuvent être mis en place entre le client et le fournisseur pour mesurer la qualité des livrables et la tenue des engagements. Des revues périodiques permettent de s’assurer du bon fonctionnement.

 

 

Qualité logicielle et logiciel libre

D’après la définition de Wikipédia, « la qualité logicielle est une appréciation globale d’un logiciel, basée sur de nombreux indicateurs: la complétude des fonctionnalités, la précision des résultats, la fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité, l’extensibilité, la compatibilité et la portabilité, la facilité de correction et de transformation, la performance, la cohérence et l’intégrité des informations ».

quality survey

Indicateurs de qualité logicielle

La norme ISO 9126 définit six groupes d’indicateurs de qualité des logiciels :

  • la capacité fonctionnelle:  capacité qu’ont les fonctionnalités d’un logiciel à répondre aux exigences et besoins explicites ou implicites des utilisateurs. ;
  • la facilité d’utilisation, qui porte sur l’effort nécessaire pour apprendre à manipuler le logiciel: facilité de compréhension, d’apprentissage et d’exploitation ;
  • la fiabilité: capacité d’un logiciel de rendre des résultats corrects quelles que soient les conditions d’exploitation (dont la tolérance aux pannes) ;
  • la performance: rapport entre la quantité de ressources utilisées (moyens matériels, temps, personnel), et la quantité de résultats délivrés: temps de réponse, débit et extensibilité ;
  • la portabilité: aptitude d’un logiciel de fonctionner dans un environnement matériel ou logiciel différent de son environnement initial (facilité d’installation et de configuration).

La recherche en informatique

Le problème n’est pas nouveau: depuis les années 1970 la recherche en informatique s’est intéressée à l’idée décrire du code à partir de spécifications et d’en prouver sa validité à partir de logique mathématique. Cela a donné lieu à un foisonnement de recherche qui visent à employer les méthodes formelles pour s’approcher de cet objectif: il a fallu plusieurs décennie pour arriver aux exploits d’aujourd’hui qui sont la production d’une chaine de compilation certifié, la vérification de code ou la certification d’un noyau de système exploitation.

Mais la complexité du code développée aujourd’hui et la vitesse avec lequel il change, oblige à la mise en place de tests systématiques, et une lisibilité, maintenabilité et évolutivité du code qui ont fait également l’objet de nombreux recherches dans l’architecture, et le processus de développement et de maintenance des logiciels avec le besoin de fournir des mesures exploitables. Le logiciel libre est un moyen qui s’est généralisé parmi les chercheurs pour partager leurs résultats et faciliter les contributions.

On peut se référencer pour cela au livret bleu du logiciel libre sur la qualité logiciel de Systemics (voir référence en bas) dont cet article est largement inspiré et qui liste les grands projets de recherche dans le domaine.

L’informatique embarqué critique

Malgré ces exploits, l’utilisation de ces méthodes restent anecdotiques dans le monde industriel, qui y ont recours que dans des environnements hautement critiques. Dans ces domaines des normes obligent les industrielles à un effort de qualification (et donc couteux) pour des exigences de fiabilité (transport, avionique) ou de sécurité (carte à puce, télécommunication): l’activité de programmation y est soumise à des règles très contraignantes (et donc très couteuses): voir l’article sur la norme DO 178 .

Dans ces environnements, les industriels ont besoins de s’appuyer sur des standards pour la certification et aux  preuves formelles pour poser les bases de la qualité logiciel.

L’informatique en milieu industriel non critique

Dans le contexte non critique, on trouve des niveaux d’exigence divers: SI d’entreprise et d’administration, transaction bancaire sensible, informatique embarquée non critique.

Ces cas sont caractérisés par une grande quantité de codes, une inter connectivité entre les systèmes croissante et un large recours aux tests, avec une combinatoire impossible à couvrir de manière exhaustive que ce soit pour des méthodes manuelles ou automatisées.

L’enjeu devient donc d’optimiser les moyens de tests pour minimiser les risques; on a alors recours à des méthodes qui visent à ce que le code ait un niveau jugé suffisant pour répondre aux besoins, plutôt que de le valider par les méthodes formelles. Pour cela on cherche à garantir le processus de développement par l’utilisation de bonnes pratiques, en corrigeant et en traçant par exemple les erreurs pour éviter toute régression. La qualité du logiciel est améliorée en industrialisant le processus de développement avec des métriques et différents types de tests. On parle alors de forge logicielle. Ces forges ont été largement répandues par le développement de logiciel libre. On parle alors d’ingénierie collaborative qui caractérise le monde du logiciel libre avec les technologies associes: forges logicielles, démarches agiles, cloud, intégration continue …

Les méthodes agiles et les logiciels libres

L’apparition des processus agiles ont été popularisé dans les année 1990 par les grands acteurs du Web. Contrairement aux méthodes traditionnelles qui visent à anticiper et découper au maximum les différentes étapes de développement, les méthodes agiles visent sur la communication tout au long du projet entre les différents intervenants. Avec le DevOps, le processus est même traité en un seul flux depuis les besoins utilisateurs  jusqu’aux opérations (exploitation).

La qualité logicielle est alors traitée différemment: les processus traditionnels tentent de mesurer et valider en aval alors que les méthodes agiles en font un pré requis permanent tout au long du projet: l’imprévu est alors partie intégrale de la qualité logicielle.

Parmi les pratiques popularisées par les méthodes agiles, la principale est le développement piloté par les tests (TDD) : les tests, généralement automatiques, sont écrits avant même la réalisation de la fonctionnalité, ce qui force le développeur à réfléchir en permanence sur la qualité de son code, en plus d’éviter les régressions. Les plateforme d’intégration continue permettent de rejouer les tests unitaires et de non régression pour constituer de véritable chaines de qualification en continue.

Une autre pratique est celle du pair programming: l’idée étant que deux développeurs travaillent sur la même machine qui garantir de façon plus efficace le code produit; bien que cette pratique reste assez rare (car couteuse),  le « peer-reviewing » est plus répandue : cela consiste à inspecter le code produit par les pairs ce qui est plus efficace que les tests car cela permet d’éliminer de 80 à 95% des anomalies contre 30% par les tests.

Ces pratiques se sont largement répandues grâce à la disponibilité des logiciels libres (Git, jenkis, xUnit…) mises à disposition par les communautés des développeurs.

Utilisation des logiciels libres

Un autre facteur de qualité est le démocratisation de l’utilisation de logiciels libres et ouverts: plutôt que de grand projets centralisé avec du code source gardé secret, de plus en plus de projets en logiciel libre sont intégrés comme briques logiciels ; l’intérêt est que ces briques sont alimentées par des contritions venant de toute part et accessible à quiconque ce qui est gage de qualité car potentiellement ils sont revus par des milliers de personnes. Le défi étant alors de les intégrer ensemble sur des systèmes différents.

Les métriques

Autres éléments importants, les métriques qui permet de mesurer la qualité logicielle d’un code source. Le document en référence, « métriques et critères dévaluation de la qualité du code sources d’un logiciel« , vise à introduire les métriques et les critères fréquemment utilisés pour caractériser et évaluer la qualité d’un code source. Une attention toute particulière  a été portée sur l’importance et les limites de ces paramètres. Voici la liste des métriques qui ont un intérêt élevé:

Métriques standards:

  • Complexité cyclomatique:  mesurer la complexité d’une fonction (max 10);
  • Couverture de code: proportion  du  code  source couverte par des tests,   généralement  automatisés (80%)
  • Afferent and efferent coupling: mesure respectivement le nombre de références vers une classe et le nombre de types que la classe « connait » (max 20)
  • Instability: niveau de résistance au changement
  • Abstractness: niveau d’abstraction par rapport aux autres classes
  • Distance  from  main  sequence: équilibre du module entre l’abstractness et l’instability (max 0.7)
  • Lack of Cohesion Of Methods (LCOM): niveau de cohésion d’une classe
  • Relational Cohesion:  nombre moyen de relations internes à un module (entre 1.5 et 4)
  • Specialization index: degré de spécialisation d’une classe (max 1.5)
  • Number of coding rules violations : violation des règles de codage dépendantes du    langage ou des technologies utilisés

Critères supplémentaires:

  • Maintenabilité: directement liée à l’architecture logicielle, elle doit être simple et efficace
  • Évolutivité: l’architecture logicielle doit permettre une bonne évolutivité
  • Fiabilité:  nombre de défaillances rencontrées dans un intervalle de temps donné. inclut également la tolérance aux pannes.

Les outils open source

Voici une sélection d’outils non exhaustive pour une bonne qualité logicielle selon les bonnes pratiques décrits précédemment: agilité et travail collaboratif

 

Références:

Outils collaboratifs en ligne

Les outils collaboratifs en ligne deviennent incontournable pour la gestion de projet. De très nombreuses solutions existent. Outre les solutions complètes proposées par les géants de Web (Google, Microsoft…), il existe de très nombreux outils simples et pratiques qui pour certains ne nécessitent aucune connexion préalable. A noter également la suite d’outils très complètes composée de logiciels libres, proposée par Framasoft, association qui tente de « degoogoliser » internet en proposant pour chaque service une alternative avec des logiciels libre. Cette approche est intéressante car on a vu c’est dernières années une concentrations des services en lignes à quelques géants du Web (GAFAM) qui n’hésitent pas à utiliser les données, pourtant privées, des utilisateurs pour mieux cibler leurs besoins. L’association propose des alternatives à chaque outil centralisé par ces géants.

réseaux sociaux

Les agendas collaboratifs

Les outils suivants sont gratuits et nécessite une inscription préalable. Ils sont souvent associés à d’autres services (partages de documents, stockage,…) qui peuvent être payant.

> L’agenda selon Google associé à Gmail, Docs et Drive

Disponible sur web et mobile, Google Agenda est l’une des applications incontournables proposée par Google, rattachées au service de messagerie Gmail, et au côté des Google Docs, Google Drive et  Google Plus.  Elle permet de créer des agendas, de les partager avec les utilisateurs de son choix, y compris avec des personnes qui n’utilisent pas Google Agenda. Plusieurs utilisateurs peuvent consulter et modifier le même agenda.

> L’application calendrier selon Microsoft

De même Microsoft propose la solution Outlook rattachée à la messagerie et au gestionnaire de tache, et associée à l’ensemble des outils de l’éditeur: Word, Excel, PowerPoint, OneNote, et également OneDrive et Skype, il devient la solution ultra complète et incontournable (mais payante pour certains services).

> L’agenda de Yahoo Mail

L’agenda accessible depuis Yahoo Mail propose des fonctionnalités similaires aux solutions décrits précédemment. Il dispose également d’un espace de stockage de 1 To.

> L’agenda de Framasoft, l’alternative libre

A cotés des géants du Web cités précédemment, Framasoft met à disposition une solution libre Framagenda  basé sur le logiciel nextcloud avec un service en ligne de gestion et de partage de calendriers. Leur mot d’ordre: « ne partagez plus votre planning (ni vos contacts) avec la NSA ! ». L’outil propose les mêmes fonctionnalités que ceux décrit précédemment.

Stocker et partager les documents

Les outils suivants sont gratuits et nécessite une inscription préalable. Ils permettent le stockage de documents sur le Web (Cloud) et leur partage

> L’incontournable Google Drive

Google propose un service de stockage et de partage de fichiers incontournable. Il regroupe la suite bureautique Google Docs, Sheets et Slides,  permettant de modifier les documents, feuilles de calcul, présentations, dessins, formulaires, etc. Google propose la solution G Suite pour les professionnels (et donc payante) avec un espace de stockage illimité et des outils d’audits et de signature numérique des documents.

> OneDrive, la solution de Microsoft

De son coté, Microsoft propose le même service incontournable, associé à l’ensemble de ses services en ligne : Word, Excel, PowerPoint et OneNote. Le service peut s’utiliser à travers un navigateur web, ou à travers le gestionnaire OneDrive qui permet une synchronisation avec les supports et les outils installés sur le poste associé, ce qui permet de travailler hors connexion en toute sécurité sur les documents partagés.

> Dropbox, le plus populaire

L’autre figure incontournable du Web est Dropbox qui fournit un outil de stockage et de partage simplifié multi plateforme. Il propose plusieurs déclinaisons de son offre selon les contextes d’utilisation (grand public, pro, entreprise) avec des fonctionnalités différents et payantes.

> Box, tourné vers les entreprises

Box propose les mêmes offres que ses consœurs avec une orientation plutôt orienté entreprise et donc payante. Elle s’intègre avec de nombreux progiciels en ligne dont Office 365 avec une authentification via Active Directory. L’offre offre de nombreux outils de business intelligence, gouvernance des données et preuve électronique.

> Framadrive, la solution libre avec ownClould

Framasoft propose une solution de stockage et de partage de documents basé sur le logiciel libre ownCloud. L’association, dont les financements dépend de dons, limite volontairement le nombre de comptes disponibles (actuellement le nombre maximum a été atteint). Leur principe repose sur le degré de confiance qu’on peut accorder à une société privé (par exemple Dropbox) dont les clauses d’utilisation peuvent être changées jusqu’à s’autoriser l’usage des fichiers que vous leur confiez. La solution libre est une alternative car le code source peut être facilement audité pour vérifier les failles et degrés de fiabilité du système

Outils collaboratifs avec inscription

Après avoir balayer les outils en ligne indispensable , voici une sélection d’outils collaboratifs divers. Ces outils nécessitent une inscription préalable sur un compte.

> La gestion de projet avec Trello et autres

Trello est un outil de gestion de projet en ligne pour la  gestion de tâches. Il est constitué d’une liste de listes remplie de cartes, gérées par l’équipe. Les cartes sont assignables à des utilisateurs et sont mobiles d’une planche à l’autre, traduisant leur avancement.

De nombreuses autres alternatives existent:

  • Asana est une application web conçue pour permettre le travail d’équipe sans email.
  • Azendoo est une application web de gestion de projets et de tâches collaboratives.
  • Basecamp est un outil Web de gestion de projets
  • Framaboard l’alternative libre de Framasoft pour la  gestion de tâches basé sur Kanboard
  • Phabricator est une suite d’application web d’outils de développement de logiciel
  • ppulse est un outil de gestion de projet complet et rapide, avec gestion de tâches, discussions, partage de documents, wiki,
  • ProjeQtOr l’alternative libre pour la gestion de projet
  • Wrike est un fournisseur privé d’accès internet de gestion de projet

> Partage de disponibilité

Vous créez une page de planification personnelle. Vous connectez vos calendriers et définissez vos préférences hebdomadaires de disponibilité. Vous partagez votre lien avec n’importe qui demandant une réunion. Ils choisissent un temps disponible et un email est envoyé à tout le monde avec la confirmation de la réunion. Calendly est très simple à utiliser, il peut se connecter à Google Calendrier, Office 365 et Outlook.

autres alternatives:

> Chat avec Framateam / mattermost

Framateam est un service de tchat libre qui permet de communiquer avec son équipe en notifiant ses collaborateurs, de conserver les conversations et d’y faire des recherches.

Autres alternative:

> Questionnaires avec Frameforms / Drupal Webform

Framaforms est une alternative à Google Forms, qui vous permet de créer rapidement des questionnaires.

Autres alternative:

> Cartes mentales avec Framamindmap / Wisemapping

Framindmap permet de créer et partager des cartes mentales ou heuristiques. Dans cette version web, il faut être enregistré.

Autres alternative:

> Réseau social avec Framasphère / Diapora

Framasphère est un réseau social libre décentralisé. Au lieu que les données de tout le monde soient concentrées dans d’énormes serveurs, propriétés de grandes entreprises, de petits serveurs « pods » locaux peuvent être créés n’importe où dans le monde.

Il n’existe pas d’alternative proposant une solution décentralisée.

Écrire des notes partout avec Framanote / Trurl

Écrire , gérer et emporter vos notes avec vous, partout, tout le temps. C’est une alternative libre au très célèbre Evernote.

Autres alternative:

Autres outils collaboratifs sans inscription

Voici enfin une sélection d ‘outils simples et intuitif pouvant être utilisée très rapidement sans inscription préalable.

> Vidéoconférences avec Appear.in

Appear.in est un outil collaboratif qui permet de créer en un clin d’œil des vidéoconférences à partir d’un simple navigateur

autres alternatives:

> Conférence téléphonique avec OVH

Si vous avez des problèmes de communication avec la visioconférence, votre bon vieux téléphone vous permet de faire une conférence téléphonique gratuitement ! Le service proposé par OVH permet de réserver moins de 24h à l’avance une « salle » de conférence. Un courriel vous est envoyé dans la foulée avec le numéro de téléphone et le code d’accès. Il vous suffit alors de partager ces coordonnées à vos contacts.

> Tableur partagé avec Framacalc / EtherCalc

EtherCalc est un tableur collaboratif en temps réel, libre. Les données sont automatiquement sauvegardées sur internet avec un lien unique, et les collaborateurs peuvent collaborer sur le document en même temps. Tous les changements sont visualisés en temps réel.

> Éditeur de texte partagé avec Framapad / Etherpad

Un « pad » est un éditeur de texte collaboratif en ligne. Les contributions de chaque collaborateur sont signalées par un code couleur, apparaissent à l’écran en temps réel et sont enregistrées au fur et à mesure qu’elles sont tapées.

Autres alternatives:

> La planification de réunions simplifiée avec Doodle

Doodle est un site web de planification des événements, réunions, rendez-vous, etc et de sondage

Lien: doodle.com

Autres alternatives

> Le partage de liste de tâches avec Flask

Flask permet de partager avec une équipe une liste de tâches. Il suffit de créer une liste et envoyer l’url à toutes les personnes avec qui vous souhaitez la partager. Chacun aura accès à votre liste et pourra la compléter ou marquer une tâche complétée. On peut donner des couleurs différentes aux tâches et signaler comme prioritaires certaines d’entre elles. Flask fonctionne sur ordinateur ou smartphone.

Lien: Flask.io

Il existe d’autres alternatives mais une identification préalable est nécessaire:

> Le carnet de notes simplifié avec Nooot

Nooot est un outil collaboratif ultra simple.  Il s’agit d’un carnet de notes collaboratif à partager, idéal pour un brainstorming à la volée ou un texte à plusieurs mains.

> Le tableau de notes avec Framememo / Scrumblr

Framememo est encore un outil collaboratif ultra simple.  Il permet d’éditer et gérer des notes sous la forme de « post-it », type tableau scrum: à faire, en cours et fait

> Le dessin partagé avec CosKetch et Framavectoriel

CoSketch est un outil de dessin et de collaboration. Avec Cosketch vous pouvez dessiner à plusieurs sur une feuille blanche en ligne. Il dispose d’un service de tchat .

Framavectoriel est une alternative permettant de créer rapidement des images vectorielles au format SVG.

> Le partage de fichiers avec Framadrop / lufi

Framadrop est un service Web minimaliste de partage de fichiers des fichiers de manière confidentielle et sécurisée.

Line: framadrop.org

> Le partage de texte, image ou de lien sécurisé avec Framabin, pic et link

Framabin est un service en ligne libre et minimaliste qui permet de partager des textes de manière confidentielle et sécurisée. Le même service site pour les images ou pour partager un lien.

Lien: framabin.org   framapic.org   frama.link

Six Sigma, l’excellence ?

six-sigma-logoSix Sigma ou 6 Sigma est une méthode structurée de management visant à une amélioration de la qualité et de l’efficacité des processus. La méthode Six Sigma a d’abord été appliquée à des processus industriels avant d’être élargie à tous types de processus, notamment administratifs, logistiques, commerciaux et d’économie d’énergie. Depuis le début des années 2000, elle connaît un grand essor en raison de la complexité des organisations et de l’internalisation des processus qui imposent une vision mondiale des problèmes.

Origine

Six Sigma signifie la marge d’erreur d’un process. C’est une notion statistique. 1 Sigma est l’écart type (la zone autour de la moyenne). L’écart type peut être assimilé à la dispersion d’un processus. Le but est que le process de qualité est une fiabilité quasi absolue, donc qui assure une fiabilité jusqu’à 6 fois l’écart type.

Dans une démarche qualité classique on pourrait supposer qu’il suffit de s’approcher d’un taux de 99% de résultats corrects pour se sentir satisfait et estimer le devoir accompli. Le coût représenté par ce 1% de pertes de production et de manque à gagner fera la différence entre les entreprises qui réussissent et les autres. L’avantage concurrentiel repose sur ce jusqu’au-boutisme de la maîtrise de la variabilité des processus.

6 sigma est à l’origine une démarche qualité née au cœur même de Motorola. Elle a ensuite été perfectionnée par d’autres groupes industriels, comme General Electric, Allied- Signal ou Texas Instruments par exemple, qui l’ont mise en œuvre avec succès.

Principe

Six sigma s’appuie sur 3 notions principales:

  • le client: mieux connaître les attentes des clients et les facteurs clés de la qualité au sens du client et non au sens des habitudes et pratiques de l’entreprise: c’est avant tout prendre en compte la voix du client (recueil de besoins, sondage, avis..) , c’est-à-dire recueillir et analyser les avis des clients.
  • les processus: afin de connaître et maîtriser les facteurs influents de la qualité qui permettent de cibler du plus efficacement possible les actions d’amélioration des processus avec la certitude de toujours aller dans le sens de l’accroissement de qualité selon le client.
  • la mesure: des mesures fiables mesurant la performance du processus métier afin de maîtriser la variabilité des dits facteurs, et d’encadrer la variabilité des facteurs influents de la qualité au sens du client dans les limites de l’acceptable et d’éliminer définitivement les possibilités d’écarts imprévus. Bref d’accroître la satisfaction client en continue.

L’ennemie des processus c’est la variabilité qui entraine la non qualité et l’insatisfaction des clients. Donc on cherche à améliorer le processus jusqu’à ce que seuls les produits qui correspondant aux attentes, aux spécifications soient livrés : produire de la manière attendue dès la première fois en évitant ainsi les corrections, les retouches, les réparations et surtout les coûts associés. La méthode Six Sigma vise à améliorer le processus pour que ces produits soient tous bons, il ne s’agit pas de contrôler les produits, mais de s’assurer que le processus est fiable.

La méthode Six Sigma peut s’implémenter dans tout type de processus et pas seulement de production, il suffit simplement que les performances du processus soient mesurables.

La méthode

La méthode se base ainsi sur cinq étapes qui se contractent dans l’acronyme « DMAIC » : Define, Measure, Analyse, Improve, Control:

dmaic_process_flow

  • D. Définir l’objectif: Définir les besoins des clients et préciser les objectifs à atteindre, cadrer le projet. Elle permet de définir le périmètre du projet, les attendus, les ressources et délais nécessaires. Quels sont les paramètres critiques (facteurs influents) au sens de la qualité pour le client ? Ce sont ceux-ci qu’ils s’agit de suivre, de mesurer, d’analyser et de traiter.
  • M. Mesurer les attentes du client: Adopter une méthode rationnelle de mesure des facteurs influente (Xi) et des attentes du clients (Yi) en garantissant le système de mesure. Collecter les données représentatives, mesurer la performance, identifier les zones de progrès. Évaluation de la performance actuelle et de sa variation (tendance, cycle…). Vérifier l’adéquation du processus avec  la performance.
  • A. Analyser les problèmes, les forces et faiblesses: réaliser une analyse de données pour identifier les facteurs Xi les plus influents sur les Yi. Utilisation des outils analytiques et statistiques pour identifier les causes de problèmes (Schéma de cause à effet). A ce stade du déroulement de la méthode, il faut comprendre les problèmes et leurs origines pour pouvoir formuler par la suite les solutions susceptibles de combler l’écart entre la situation présente et les objectifs clients.
  • I. Améliorer, innover, se différencier: Identification et mise en œuvre des solutions relativement aux Xi les plus influentes. Cette phase particulièrement importante doit permettre de tester et de valider les solutions les plus adéquates en définissant les tolérances acceptables  et le déroulement
  • C. Contrôler et garantir la qualité à long terme: en mettant en place des outils de pilotage du processus. Il est important d’éviter tout retour en arrière. L’effort doit être soutenu voire réorienté. Il est important de maintenir le processus « sous contrôle » avec de la documentation à jour, un pilotage par tableau de bord, puis un accompagnement du changement et le transfert de connaissance.

la méthode DMADV

La méthode DMADV est plus adaptée lorsqu’il s’agit de mettre en place de nouveaux processus. Cette méthode assez similaire à DMAIC se compose des phases suivantes : Define, Measure, Analyze, Design,Verify

Les 3 premières phases sont similaires à la méthode DMAIC.

  • La phase Design définit dans le détail le processus afin d’être en parfaite concordance avec les attentes des clients.
  • La phase Verify vérifie que la performance et la capacité sont conformes aux objectifs et aux attentes des clients.

Réussite d’un projet 6 Sigma

Au-delà de la méthodologie, la réussite d’un projet Six Sigma doit s’appuyer d’un conduite du changement. Souvent, par facilité ou pour gagner du temps, les entreprises tendent à mettre en place des solutions toutes faites qui répondent selon elles à des problèmes. Avec la méthode Six Sigma, l’objectif est de bien cerner le problème, à travers des analyses de processus ou de mesures. Une fois le problème bien identifié, la solution découle souvent de source. Un accompagnement avec soutien de la direction est souvent nécessaire pour éviter un blocage ou d’un enlisement. Des projets courts, montrant des résultats concrets combinés à un schéma directeur plus longs procurant des bénéfices à plus long terme, permettent de soutenir ce type d’initiative.

On est très proche du processus Lean décrit dans les articles  précédents.

Le Lean  Six Sigma

D’ailleurs une autre méthode consiste à associer au Six Sigma, le Lean. Le Lean 6 Sigma prend de plus en plus le pas sur le Six Sigma. Le Lean Six Sigma est donc l’utilisation du Six Sigma et du Lean Manufacturing.

On l’a vu précédemment, les deux méthodes, Lean et Six Sigma, sont orientées vers le client. Mais elles différent sur les points suivants:

  • Le 6 Sigma vise à diminuer la variabilité des processus afin de les fiabiliser, les rendre stables et prévisibles, s’assurer de la reproductibilité « parfaite » du processus
  • Le Lean est un mode d’organisation qui vise l’élimination des tâches sans valeur ajoutée pour le client et l’entreprise. Pour rappel, afin de réduire tout gaspillage et gagner en agilité, le Lean utilise 3 principes fondamentaux : le juste nécessaire, la remise en cause permanente (agilité) et l’intelligence collective (on lâche-prise pour mieux garder le contrôle!).

Les deux démarches sont donc compatibles et complémentaires. Elles visent à l’amélioration en  continue de l’efficience de la productivité associée à la réduction de la dispersion des processus. La démarche Lean va chercher à optimiser le processus, en adaptant les méthodologies et les outils nécessaires aux enjeux et à la situation, la démarche 6 Sigma va réduire la dispensation.

La gestion de projet en mode agile

Le Six Sigma est une démarche d’amélioration continue qui se rapproche de la gestion de projet en mode agile et permet la réalisation de projet plus rapidement et avec une plus grande probabilité de réussite. La mise en place se fait en 5 itérations suivant le DMAIC afin d’avoir une  :

  • Meilleur qualité de la communication : les exigences plus facilement clarifiées (Phase D)
  • Meilleur visibilité sur l’avancement des actions avec un management visuel (Phases M, A,C)
  • Contrôle des phases et étapes : les évaluations et revues de projet sont réalisées en continue en tant que de besoins (Phase C)
  • Détection des risques : Les risques sont détectés et évalués plus tôt et régulièrement mis à jour. (Phases M,A)
  • Motivation et confiance de l’équipe : satisfaction d’atteindre un objectif fixé par des animations à intervalle court (Phase A,I)
  • Maîtrise des coûts : le projet peut être arrêté si les gains attendus ne sont pas obtenus.(Phase C)

La méthode Six Sigma s’inspire du schéma pyramidal, avec à la base des personnes disposant d’un premier niveau de qualification et au sommet les plus aguerris au système.

Il est possible de passer des certifications pour apprendre à implémenter correctement la méthode Six Sigma.  Montez les échelons de la pyramide Six Sigma. Comme au judo, les niveaux d’expertise sont représentés par des ceintures de différentes couleurs.

Les green belts (ou ceintures vertes), consacrent une proportion moindre de leur temps au projet global d’amélioration. Arrivent ensuite les black belts, qui s’y consacrent pleinement. Ils pilotent les premiers, car ils maîtrisent la méthode dans son ensemble. Et l’on peut citer encore les master black belts qui sont les garants de la méthode et qui encadrent les black belts.

Les Green et Black Belt sont des chefs de projets qui vont déployer la démarche DMAIC . Ils se distinguent par l’ampleur des projets (étendue, complexité, gains financiers), leur niveau de formation et le temps disponible pour réaliser les projets:

  • Projet Green Belt : gains intéressants, durée du projet entre 3 et 5 mois
  • Projet Black Belt : gains importants, durée du projet de 6 à 8 mois.

La maîtrise du management par projet est un pré-requis pour lancer et réaliser des chantiers lean six sigma.

Référence:

POC, Prototype et Pilote, quelles différences ?

proof-of-concept

Voici quelques définitions:

  • Une preuve de concept ou POC (Proof  Of Concept) est une réalisation expérimentale concrète et préliminaire, très courte, illustrant une certaine méthode ou idée afin d’en démontrer la faisabilité.
  • un prototype est selon la définition de l’OCDE « un modèle original qui possède toutes les qualités techniques et toutes les caractéristiques de fonctionnement d’un nouveau produit ». , mais il s’agit aussi parfois d’un exemplaire incomplet (et non définitif) de ce que pourra être un produit ou service.
  • Le pilote ou prototypage consiste à concevoir des versions intermédiaires et donc incomplètes d’un produit, conçues pour tester l’utilisation auprès des utilisateurs, et/ou les performances, avant la phase proprement de conception proprement dite.  On parle également de pilote terrain lorsqu’on ait sur des conditions proches de ceux du déploiement sur le « terrain » mais à une échelle plus réduite.

Les définition sont très proche mais quelles sont les différences?

La démarche

Le choix d’une solution informatique est souvent dépendant d’un existant technique et d’un schéma directeur. Les outils sont alors choisis avant même que les besoins n’aient été détaillés avec les métiers. Dans tous les cas, le POC, prototype, pilote consiste à tester les fonctionnalités, l’ergonomie et/ou les performances techniques d’un produit ou d’un service auprès de ses futurs utilisateurs avant d’envisager un déploiement plus large. Ce test se fait sur une durée limitée et, autant que possible, dans des conditions très proches de la réalité : on teste généralement une version incomplète de la solution avec un échantillon représentatif de la population utilisatrice…

La démarche dépend du type de solution à tester. Les tests peuvent se dérouler sur une journée ou plusieurs semaines, impliquer un petit nombre d’utilisateurs ou une population vaste, vérifier un ou plusieurs concepts.

Dans tous les cas, le POC, prototype, pilote doit répondre à des objectifs mesurables définis en amont du lancement. La démarche comporte 4 étapes clés :

  • la définition de la situation cible à laquelle doit aboutir le produit ou le service,
  • la définition des objectifs du test et de ses modalités,
  • la mise en œuvre de la phase de tests,
  • la phase de bilan qui validera les enseignements du test et permettra de statuer sur l’opportunité du déploiement.

Une valeur ajoutée

En confrontant le produit ou du service à la réalité du terrain et de ses utilisateurs sur une plus petite échelle, le POC, prototype, pilote permet de le rectifier ou de l’améliorer, et de lever le doute sur la pertinence du produit ou du service. Les parties prenantes du projet peuvent valider l’adéquation du produit ou du service à leurs besoins, ce qui modère les risques de rejet. Observer le comportement avec un test réel permet d’anticiper l’accompagnement des utilisateurs à prévoir lors du déploiement. Ainsi on le voit au travers la démarche, la valeur ajoutée de ce test se fait sur 3 angles:

  • aider à développer un engouement: Quand il s’agit d’implémenter une nouvelle solution technologique dans une organisation,  il est important de s’assurer que l’équipe ne rejette pas le projet. Concevoir un POC, prototype, pilote avec des fonctionnalités limitées permet de s’assurer que la plupart des personnes y adhère ce qui contribuera au succès du projet.
  • limiter les risques : pour rallier les parties prenantes du projet, le POC, prototype, pilote peut soulever les problèmes et les risques à un stade précoce du cycle de vie du projet. Cela est particulièrement vrai lorsque les exigences restent un peu floues. Rien ne vaut un test proche du terrain pour aider à minimiser les risques avant le déploiement.
  • obtenir le maximum de commentaires des utilisateur: Les Tests d’Acceptation Utilisateurs (UAT) permettent de vérifier le potentiel d’acceptation de la solution par les utilisateurs finaux avant le déploiement final de la solution. Les commentaires des utilisateurs finaux sont essentiels au succès du produit ou du service et permet d’anticiper les problèmes reliés à l’expérience utilisateur beaucoup plus tôt dans le projet.

La différence

Dans une article sur son blog,  fait la différence entre les  trois concepts.  Selon lui pour intégrer la solution avec succès dans votre entreprise, il faut réaliser tous les trois. Voila la démarche:

poc-prototype-pilote

  1. La preuve de Concept: un POC est un système conçu purement pour illustrer la fonctionnalité d’un ou plusieurs principes à intégrer dans un système. La convivialité avec le monde réel n’est pas envisagée car l’intégration avec d’autres technologies pourrait diluer la capacité à déterminer si le principe (idée, vision) est viable. Les résultats doivent être mesurables, afin qu’ils puissent permettre de prendre une décision (go/no go). La décision doit reposer sur des seuils comme un niveau de performance acceptable. Les résultats du test doivent permettre de valider que ça fonctionne et comment ça fonctionne.
  1. Le prototype: Le Prototype est un système plus étoffé qui tente de simuler le système complet (avec une intégration système) ou au moins la plus grande partie de celui-ci. Les prototypes sont utilisés pour tester la viabilité ou l’utilité d’un système. Le prototype permet de valider et corriger certaines hypothèses. Il faudra plusieurs itérations pour valider plusieurs hypothèses (cycles essais/erreurs). Un prototype aura  les fonctionnalités principales du produit fini, mais il ne sera généralement pas aussi efficace, esthétique ou durable. Il ne faut pas confondre prototype et Wireframe qui consiste à  déterminer les composants nécessaires dans une interface utilisateur. Le prototype est ici à un stade plus avancé et permet de valider que l’utilisation de ces composants est viable pour l’utilisateur.
  1. Le pilote: Un pilote quant à lui utilise le système de production complet et il teste par rapport à un sous-ensemble d’utilisateurs finaux. Le but d’un projet pilote est d’obtenir une meilleure compréhension de la façon dont la solution sera déployé et utilisé dans l’entreprise et à corriger la solution. Le groupe utilisateurs doit être soigneusement choisi pour recueillir les bonnes données. Les données et les outils pour les mesurer doivent être déterminés à l’avance. Enfin il ne faut pas le confondre avec la « pré-série » qui consiste à tester l’ensemble d’un processus de fabrication.

Différence avec le Lean Startup

Comme le monte un article de François sur son blog, on est alors très proche de démarche Lean décrite dans un autre article, avec le MVP. Le “Minimum Viable Product” est un concept introduit par Eric Ries et Steve Blank,  créateurs respectivement de la démarche Lean Startup et du Customer Development. Comme son nom l’indique, un MVP consiste à concevoir une “solution de vérification” aussi minimaliste que possible afin de savoir s’il a une viabilité,  mais qui doit répondre à une seule question : « Y-a-t-il un marché (des clients) pour ce produit ?« 

L’objectif d’un MVP est donc d’apprendre du marché, des retours des clients potentiels (la cible) afin de valider et d’invalider des hypothèses que vous aurez formulées avant de lancer votre produit. Un MVP s’attachera à valider la valeur fondamentale du produit avec la seule question: « S’il ne devait y avoir qu’une seule chose qui ferait acheter mon produit, qu’est-ce que ça serait ? »

Ainsi vous l’aurez compris, MVP et prototype sont complémentaires. Le MVP permet valider la viabilité commerciale du concept alors que le POC, prototype ou pilote permet d’en valider la faisabilité technique.

Aussi, toute approche produit doit comporter une phase de création d’un MVP puis d’un prototype avant de lancer la fabrication et le développement du produit.

Conclusion

MVP, POC, prototypes et pilotes sont donc tous d’importantes tactiques à mettre à exécution dans l’implantation de nouvelles technologies. Ce sont des moyens rationnels d’orienter le choix, en mettant dans la balance l’expérience utilisateur. Pour réussir dans cette démarche il faut procéder de façon méthodique pour qu’ils aient une valeur. Et vous ne réaliserez jamais cette valeur à moins que consciemment vous notez les résultats et transformez ces données en informations utilisables et exploitables.

Référence:

Un peu d’humour

 

Quelques dictons qui datent un peu (plus de 20 ans déjà) mais qui sont toujours d’actualité 😉

bege_humour

Les vrais programmeurs

  • Les vrais programmeurs ne commentent jamais leurs programmes : comme un programme est difficile à écrire, il doit être difficile à modifier
  • Les vrais programmeurs ne lisent jamais les manuels d’utilisation : faire confiance à ce genre de documentation est un signe de lâcheté et d’absence de confiance en soi
  • Les vrais programmes des vrais programmeurs ne marchent jamais du premier coups : mais ces programmes peuvent être modifiés pour fonctionner normalement après seulement une trentaine d’heure de débogage.
  • Les vrais programmeurs ont horreur de la programmation structurée : la programmation structurés est faite pour les névrosés contrariés qui nettoient leur bureau, taillent leurs crayons, rangent leurs affaires et rentrent à l’heure pour manger.
  • Les vrais programmeurs ne travaillent jamais de 9 heures à 18 heures : si un quelconque vrai programmeur est devant sa machine vers 9 heures du matin, cela signifie qu’il y a passé la nuit.
  • Les vrais programmeurs n’aiment pas la programmation en équipe : … à moins qu’ils soient le chef.
  • Les vrais programmeurs n’utilisent pas de générateurs d’applications ou de programmes : les outils de ce genre sont faits pour les assistés ou les fainéants.
  • Les vrais programmeurs n’écrivent pas en Basic : en réalité, aucune personne normalement constituée ne programme plus en Basic après avoir atteint la puberté.
  • Les vrais programmeurs n’écrivent pas en Fortran : le Fortran est fait pour les ingénieurs en cravate et en chaussettes blanches qui prennent leur pied en faisant de l’analyse statistique ou des simulations de réacteurs nucléaires.
  • Les vrais programmeurs n’écrivent pas en Cobol : le Cobol est fait pour les octogénaires qui continuent à programmer sur du papyrus.
  • Les vrais programmeurs n’écrivent pas en Lisp : car seuls les programmes en Lisp contiennent plus de parenthèses que de code.
  • Les vrais programmeurs n’écrivent pas en  Pascal, C, Bliss, Ada ou autre clone qui demande plus à taper le programme qu’à réfléchir.
  • Les vrais programmeurs détestent encore plus HTML : ce langage que même les Macintosh comprennent et qui est destiné à des non-programmeurs afin de leur donner l’impression qu’ils sont de vrais programmeurs.
  • Les vrais programmeurs n’aiment pas Microsoft : pour eux, Windows est un jeu d’aventures au scénario bien faible dans lequel on est toujours perdant, inconvénient qui était inexistant, même sur les Commodore 64, alors qu’ils n’étaient pas entre de vrais programmeurs.

Les sept lois de la programmation

  • Première loi : tout programme, quel qu’il soit, est obsolète dés qu’il est commercialisé.
  • Deuxième loi : tout nouveau programme coûte plus et est plus lent que l’ancien.
  • Troisième loi : si un programme est utile, il devra être rapidement remplacer par un autre.
  • Quatrième loi : si un programme est inutile, il faudra lui faire une documentation et le généraliser à tous les utilisateurs.
  • Cinquième loi : la complexité d’un programme s’accroît jusqu’à ce qu’elle dépasse les capacités du programmeur qui en assure le développement.
  • Sixième loi : tout programme, lors de son lancement, aura tendance à remplir toute la mémoire disponible.
  • Septième loi : la valeur d’un programme est inversement proportionnelle à la taille des documents qu’il génère.

Dictons

  • Si l’on ajoute un homme à un projet en retard, cela ne fera qu’ajouter du retard au projet
  • Ce n’est qu’après avoir essayé tout le reste qu’on lit la documentation. Et c’est à ce moment-là qu‘on se rende compte qu’on l’a jetée avec l’emballage.
  • La fonction  » Annuler  » n’est jamais disponible quand vous en auriez besoin.
  • Un programme informatique fait ce que vous lui dites de faire, pas ce que vous voudriez qu’il fasse.
  • Un projet préparé sans soin prendra trois fois plus de temps que prévu pour son achèvement. Un projet préparé soigneusement prendra seulement deux fois plus de temps.
  • La complexité d’un programme croîtra jusqu’à ce que le programmeur lui-même n’y comprenne rien.
  • C’est généralement lorsque le disque dur plante qu’on se rend compte qu’on a oublié de sauvegarder son fichier. Sinon, c’est en sauvegardant qu’on l’a fait planter.
  • Les ordinateurs accomplissent plus de travail que les humains. L’une des raisons est qu’ils n’ont pas, eux, à s’arrêter pour répondre au téléphone (ou à répondre aux mails).
  • Ce n’est que lorsqu’un programme est commercialisé que les plus graves erreurs sont détectées.
  • Les ordinateurs sont très bêtes, mais très rapide. Les hommes sont très futés, mais très lents. A eux deux, ils forment un couple idéal.
  • Pour savoir combien de temps sera nécessaire à l’écriture et au débogage d’un programme, faites votre estimation la plus fiable, ajoutez un, multipliez par deux et arrondissez à la dizaine supérieure.
  • Sur une installation de test fonctionne parfaitement, tous les systèmes qui en dépendent vont planter.
  • A la source de chaque erreur imputée à l’ordinateur, on découvrira au moins deux erreurs humaines (on compte ici l’erreur qui consiste à imputer la faute à l’ordinateur).