Comment estimer un projet TI?
Ou répondre à son patron quand il demande combien de temps il
faut pour faire une tâche.
Premièrement, il faut distinguer deux concepts: l'estimation et l'engagement (objectif, cible).
Les cas d'utilisation sont vraiment fantastiques pour décrire la tâche d'un utilisateur, ses interactions et les réactions non techniques d'un système.
J'entends, bien sûr, le niveau de détail requis pour une tâche exécuté par un seul utilisateur, en une seule session et apportant un avantage d'affaires. Si plusieurs utilisateurs sont impliqué en séquence, il s'agit d'un processus d'affaires et il existent d'autres outils plus approprié que les cas d'utilisation. Par exemple, le BPMN, les diagrammes d'activités ou autres techniques.
D'un autre côté, se logger dans un système ne constitue qu'une étape d'un cas d'utilisation, sans avantages d'affaires. Il s'agit de doser le niveau de détail d'un cas d'utilisation et d'avoir des alternances entre les actions de l'utilisateur et les réaction de la machine. En passant, les réactions de la machine (système) peuvent être appelé des contrats d'opération (Larman) et permettre d'identifier les événements système et continuer la conception détaillé de la logique du système.
Il y a des cas où les cas d'utilisation sont nuisibles. Quand on se retrouve avec des cas d'utilisation où l'usager fait une seule action et le système prend toute la relève, le cas d'utilisation n'apporte rien. Par exemple, dans le cas de sortir de rapport (a moins d'interactions complexes de préparation) ou de lancement de traitement sans interaction avec l'utilisateur (conversion, transfert, calcul, lot de traitement, traitement périodique...).
Dans un tel cas, deux options sont préférable. Soit on documente un d'opération système, soit on utilise le concept de cas d'utilisation opération.
Operation système
Si on utilise le concept d'opération système, chaque événement est décrit séparément, comme un contrat d'opération, avec son déclancheur, ses préalables (intrant, paramêtres et contraintes), ses résultats et son traitement des erreurs.
Larman décrit le contrat d'opération système comme une suite d'activité, sans action d'un utilisateur, que le système doit effectuer.
Le contrat d'opération:
- doit avoir un ou des déclencheurs
- doit produire des résultats (sorties, transformation d'environnement, messages d'erreurs...)
- peut avoir des paramètres d'appels
- peut avoir des préalables (contraintes d'environnement ou de paramètres)
- doit exécuter quelque chose
- peut avoir des conditions à respecter lors du traitement (invariants)
- peut avoir des contraintes de résultat
D'ailleurs, ce contrat d'opération peut (doit) être utilisé pour définir la production d'un rapport ou d'un traitement, mais aussi pour décrire chaque étape système d'un cas d'utilisation. Cette description est très utile pour les développeurs.
Le contrat d'opération système peut aussi être utilisé pour décrire des réactions à des événements dans des systèmes embarqué ou des systèmes événementiels.
Cas d'utilisation opération.
En fait, c'est le même type de documentation qu'un contrat d'opération système, mais on peut alors regrouper plusieurs opérations dans un même cas d'utilisation et on garde le principe de RUP qui veux que toutes les fonctionnalités soient intégrés dans les cas d'utilisations.
On prévoit deux gabarits différents, pour les cas d'utilisation inter-actif et les cas d'utilisation opération systèmes.
Ce que j'appelle mécanisme technique, est la documentation d'une séquence d'action lié à une infrastructure technique.
Par exemple, on indiquer qu'une classe doit être persisté. Le mécanismes technique de persistance d'une classe simple indique l'ensemble des classes impliqué, incluant la classe à persister, une collection (cache) des classes de ce type logique, les DAO, le mécanismes général de demande de persistance, l'appel à la BD, les traitement d'erreur et de défaillances... pour la sauvegarde, la récupération et la recherche. Une façon de documenter cela est de prendre une classe logique réelle et d'indiquer, concrètement, les actions. Au fond, on donne alors un exemple et on donne un nom à cet exemple. On doit utiliser des diagrammes (statiques et dynamiques), du texte explicatif et du code. Finalement, on donne un nom officiel à ce mécanismes.
De plus, toute déviation sur le principe du mécanisme doit être documenté. Par exemple, si notre classe logique a un attribut collection d'une autre classe, comme une facture avec ses items. On a alors un autre mécanisme.
Le même principe s'applique pour documenter l'affichage Web d'un attribut d'une classe ou sa saisie. Par exemple, différents mécanismes de validation doivent être documenter (avec validation sur serveur, sur Browser ou Ajax).
Le même principe s'applique pour les collections "Factory-Cache", comme la classe "ListeDeFactures", qui permet de récupérer une facture, sans s'occuper de la persistance.
Ainsi, on fait le pont de la conception d'architecture vers le code.
La conception détaillé, en plus de représenter la structure des classes et des opérations, représente les standards d'utilisation des mécanismes architecturaux et assurent une uniformité dans le code.
Finalement, si une telle documentation n'existe pas, on peut répertorier de tels mécanismes (leurs donner des noms génériques) et identifier le code existant qui représente cela. Au lieu de laisser chaque développeur coder en regardant n'importe quel code actuel, on lui indique que la persistance doit s'effectuer comme dans la méthode XXXX...
Des tests unitaires automatiser peuvent venir compléter cette documentation.
L'introduction d'ISO9000 devait améliorer les entreprises... mais ça n'a pas toujours (souvent) donnée de bon résultats.
Une petite histoire (elle n'est pas de moi, mais voici ce que j'en ai retenu:
Lors de la 2e guerre mondiales, les américains ont construit une piste d'atterrissage sur une petite ile du pacifique. Par la suite, de nombreux avions de ravitaillement ont apporté des vivres et des marchandises sur l'ile, créant une certaine prospérité sur l'ile.
Voyant cela, des gents de l'ile voisine ont décidé de construire une piste artisanale avec des pierres et des bouts de bois, le même look que sur l'ile voisine, et ont attendu que la richesse leur arrive... avec peu de résultat.
Les entreprise qui on crut qu'en obtenant une accréditation ISO9000, elle allaient obtenir des gains, n'ont rien obtenu, sauf une lourdeur et des coûts. Elles disent qu'il est normal que ça coûte plus chère parce qu'il sont ISO. C'est faut, ce n'est pas normal. Il doit y avoir des gains.
Elles n'ont rien comprise.
ISO9000 incite à prendre conscience des façons de faire et à AMÉLIORER ces façons de faire, constamment, dans l'axe de la qualité, de la réponse rapide et de la réductions des coûts.
Le mouvement agile va certainement apporter quelque chose à certaines entreprise.
Cependant, sans en comprendre les principes fondamentaux, on ne peut avoir de gain sérieux.
Voici donc certains de ces principes:
Avoir une culture de la qualité, préventive, pas réactive:
Donc, éliminer les bugs à la source, le plus tôt possible. Le "test drived development", les revus par les pairs, la conception commune sur tableau blanc, une souplesse.
Avoir en vue le gain pour le client, garder la souplesse et livrer le plus vite possible ce qui a de la valeur.
S'adapter en tout temps aux circonstances, être adapté et évolutif. Rester souple.
Réduire les pertes le plus possible. Est-ce que tel document est vraiment utile? Est-ce que cette fonctionnalité a vraiment une valeur.
Il faut également un changement de mentalité de la part des participants. Ils doivent avoir deux préoccupation à cœur, tout les jours: livrer et améliorer ses façons de faire, tout les jours.
Chez Toyota, on demande deux choses à un ouvrier, chaque jours: livrer des pièces et trouver de meilleures façons de le faire. Le second point étant bien plus important que le premier. Ça garde l'ouvrier éveillé, fier qu'on lui demande de se servir de sa tête et de sa créativité.
Demandez aux développeurs de livrer du code, mais plus important encore... d'améliorer tout les jours, leurs façons de faire. À la longue, on réduit les défauts et on augmente la productivité. Mieux, on leur demande de demeurer des humains, pas de devenir des machines.
À compter de Février 2008, une série de formations en analyse TI sera offerte.
Il s'agit de cours sur:
- Les processus: découvrir, documenter et optimiser les processus d'affaires
- Les cas d'utilisation
- La modélisation du domaine
- Les règles d'affaires
- Les mesures et l'estimation
- La conception d'interfaces utilisateurs
En offrant ces cours de soir, un consultant peut continuer à servir (facturer) ses clients et investir dans ses connaissances.
De plus, la formule offre, pour chaque sujet, une introduction générale d'un soir, suivis de 3 soirées d'approfondissement dans les 3 semaines suivantes. Donc, un total de 4 soir de formation par sujet.
Les prix sont imbattables: l'introduction à 60$ et chaque soirée de cours à 90$. Le repas et les notes de cours sont mêmes inclus.
Plus de détail sur www.reponse.ca, consulter le calendrier des cours du soir ou de jour
Bientôt, des cours en conception, en architecture et en gestion de projet seront disponibles.
Le concept de règle d'affaires est là depuis plusieurs années. Cependant, il semble de plus en plus populaire ces temps-ci.
On peut les utiliser pour
Le livre "Business Rules and Information Systems" prend le soin de bien définir ce qu'est et ce que ne devrait pas être une règle d'affaires. Il donne des conseils quant à la rédaction (le texte), l'organisation, la vérification et la validation des règles d'affaires. Il vise le lien qui s'établit entre les gens d'affaires et les responsables du développement informatique. Il va jusqu'à discuter de méthodes d'implémenter les règles d'affaires définies lors de l'analyse.
Une très bonne lecture.
Un petit livre, "Java RAMbo Manifesto", prône pour l'utilisation maximale de la RAM.
Il affirme que ne plus utiliser des outils comme Oracle, permet d'augmenter la performance d'une application de 1000 fois!
L'auteur, Peter Wayner, indique que dans bien des cas, l'ensemble des données d'une application peut résider en mémoire vive. Par exemple, 200 utilisateurs, ayant un panier de 10 items, peuvent représenter 234Ko. Une goute d'eau dans un serveur moderne.
Comment fermer le serveur?
Il suggère d'enregistrer tout le modèle, en utilisant le mécanisme de sérialisation. C'est très performant et simple à mettre en place. Les données sont alors écrites dans un fichier, qui peut être rechargé de la même façon.
En cas de changement dans le modèle de classe (amélioration), il faut prévoir un mécanisme de conversion.
Comment survivre à une panne?
Il préconise l'utilisation de journalisation: le modèle est chargé en mémoire et tout objet, qui est modifié, inclut une sérialisation (restreinte à cet objet) dans un fichier journal. En cas de panne, on recharge le modèle initial et on rejoue le journal.
Pour un système ACID, on ne confirme une modification à un objet, que si l'objet a été effectivement journalisé. Les modifications sont plus longues, mais les lectures sont pure RAM. Les modifications sont de toute façon plus rapides qu'avec un serveur SQL.
Conclusion
Ce n'est pas une solution applicable dans toutes les circonstances, mais ça vaut la peine d'ajouter ces principes à notre coffre à outils.
Hélas, le livre n'est plus disponible neuf.
www.wayner.org/books/rambo/
Mozart est certainement l'un des plus grands compositeurs.
Pourtant, il n'écrivait sa musique, que dans les moments où il était criblé de dettes...
Il nous faut souvent un coup de pied au c... pour faire le travail.
Les projets informatiques
Dans tout projet, dans toute équipe de développement, il faut un minimum de pression, le plus souvent possible. Il faut cependant éviter que cette pression devienne excessive.
Des projets dont la date de livraison est dans quelques mois, n'ont cette pression, que durant les dernières semaines, menant à de la négligence, du stress, ...
Un facteur aggrave souvent cette situation en informatique: du à un définit d'attention souvent présente (Ted, SDA, Aspenger, ...), les informaticiens ont une difficulté supplémentaire.
Dans le cas du déficit d'attention, les interactions nerveuses sont moins efficaces que chez un individu "normal". Certains stimulant, comme le café, le sucre, le Rithalin, ... compense cette inefficacité et augmente la concentration. L'adrénaline a le même rôle, ce qui peut expliquer l'augmentation de concentration lors des fins de projet.
Dans les méthodes de développement à itération courte (XP, Scrum, ...), l'effet de fin de projet se produit régulièrement (on maintient Mozart dans la pauvreté).
Déficit d'attention
Les enfants, atteints de déficit d'attention (avec ou sans hyperactivité), gardent généralement ce problème à l'age adulte. La concentration peut être présente, quand la stimulation est extrêmement forte. On parle alors de souper/hyper concentration. La créativité a le même effet stimulant.
Il est possible qu'une des sources de la créativité, soit le décloisonnement des champs d'activité ou de connaissance. Le lunatique passe si vite d'un sujet à l'autre, qui transpose les bonnes idées d'un domaine à l'autre.
Et les relations humaines
Le syndrome d'Asperger inclut une incapacité à décoder les émotions subtile (une fonction des amygdales, une zone précise du cerveau). Comme ce syndrome se situe dans un continuum, partant du déficite d'attention jusqu'à l'autisme... on retrouve donc le fameux syndrome du Nerds (le bollé).
Par contre, ces individus ont une énorme capacité de concentration, une créativité très productive et un intérêt ciblé pour les technologies. Ils sont une ressource précieuse pour une équipe de développement. Spock n'était pas le capitaine de l'Entreprise, parce que le manque d'émotion l'empêchait de prendre des décisions sans avoir toutes les données, mais il avait sa place à bord.
En informatique, le même problème peut parfois être résolu en 20 fois moins de temps, par une solution simple et facile à tester... La créativité est importante et aucun processus ne peut la remplacer.
Sélection des projets
On sélectionne souvent les projets ainsi :
Cerner les problèmes et les opportunités
Définir des projets
Analyser les projets
Produire des estimations et des analyses couts/bénéfices
Choisir les projets les plus rentables
Analyser toute la solution
Concevoir toute la solution
Développer toute la solution
Livrer $ récolter les résultats, les bénéfices
La règle du 80-20
Il est fréquent que l'on puisse affirmer que 20 % des fonctionnalités apportent 80 % des bénéfices.
Alors, il est probablement plus efficace de diviser un projet en phases (sous projets), en mettant les fonctionnalités les plus rentables, dans les premières itérations. On obtient ainsi, plus rapidement, les bénéfices.
En mettant en production, la partie la plus rentable d'un projet, on récolte l'argent, qui paie le reste du projet.
Un exemple de découpage
Prenons un projet de 2 ans de développement, qui doit se payer en 2 ans. Donc, la 4e année, on récupère sa mise initiale.
Supposons que le projet coute 100K$.
Il coûte 4K$ de développement par mois.
Il rapportera 4K$ par mois.
20% des fonctionnalités: un investissement de 20k$ sur 5 mois.
Donc, 80%$ des bénéfices, à compter du 6e mois: 3K$ de revenus par mois.
Du 6e au 24e mois: 54K$ de revenus de plus que prévu.
Les deux années suivantes ( année 3 et 4): 72K$
Grand total, on on arrête le projet à 20% des fonctionnalités: 126K$ pour 20K$ d'investissement... un taux de rendement de 600%. On peut également dire que la rentabilité est atteinte en 7 mois!!!
Maintenant, au lieu de poursuivre le projet avec la phase suivante (beaucoup moins rentable), on prend un autre projet, pour faire le 1er 20% le plus rentable....
Ne terminez pas vos projets!!!
Les méthodes agiles visent justement à livrer le plus tôt possible, les fonctionnalités les plus rentables.
Ces méthodes préconisent des livraisons d'une qualité telle, qu'elles peuvent être mises en production et utilisées par le client, même s'il ne poursuit pas le projet.
Bien sûr, l'ajout des autres fonctionnalités au projet demandera à modifier une partie du code existant. Cependant, ce sur cout s'amortira largement par l'utilisation plus rapide et les revenus que le client en tirera.
Un autre bon livre sur l'optimisation du processus de développement. Très inspiré du travail réalisé chez Toyota.
Le texte est facile à lire, moins formel que le livre "Agile Management for Software Engineering".
On y retrouve les même principes de "juste à temps", de gestion de la qualité, de gestion agiles des équipes, de réduction d'inventaire...
Qu'est-ce que l'inventaire, en informatique ?
Il s'agit de tout le travail effectué, depuis le moment où un client commence à nous décrire son problème, jusqu'au moment où on livre le produit fonctionnel. Il s'agit du temps facturable, pour lequel le client n'a pas reçu le produit.
Bien sûr, en réduisant cet inventaire, quand le client change d'idée, on perd bien moins... nous sommes alors plus apte au changement.
L'une des auteurs provient du milieu manufacturier.
Amazon
Amazon
"Getting Things Done (TM), The art of Stress-Free Productivity"
"Pret pour l'action"
S'organiser, ne rien oublier et réduire son stress...
Bien des gens ont entendu les concepts de gestion du temps. Cependant, le passage à l'acte est parfois difficile. Cet auteur a l'art d'expliquer le pourquoi et le comment des trucs qu'il présente. Sa méthode est simple, logique et efficace. Il va un peu plus loin que la simple gestion du temps et est à la fois pragmatique et simple.
À appliquer comme gestionnaire d'équipes, mais aussi à titre de professeur, d'étudiant ou d'humain.
En résumé:
1- Utiliser un nombre limité de panier IN.
Comment mesurer la taille d'un logiciel ?
Surement pas en nombre de ligne de code... ça ne veut plus rien dire.
Il existe des méthode, comme les poins de fonction FPUG, qui mesure le nombre de fonctionnalité élémentaires offerte au client.
L'une des plus simple et des plus souple, utilise les points de fonctions COSMIC FFP.
Point de fonction COSMIC FFP (CFFP)
Cette unité de mesure, se dévinie comme un transfert d'information qui entre ou sort d'un système et de données qui est sauvegardé ou restauré d'une mémoire persistance (bd, fichier, ...).
Par exemple, l'entrée d'un numéro de téléphone correspond à un groupe de données. Quand l'utilisateur l'entre, on a un CFFP. Quand on l'affiche, un autre CFFP. Quand on l'enregistre ou qu'on l'extrait d'une bd, un CFFP pour l'un et l'autre. On n sépare pas le numéro de téléphone en plus petit élément.
Pour calculer le nombre de CFFP d'un écran de saisie... c'est simple.
Les cas d'utilisation comme outil de mesure
Certaines organisation utilise le nombre de cas d'utilisation, comme unité de mesure de taille fonctionnelle. Sauf qu'il y a trop de variation dans la taille des cas d'utilisation pour qu'une telle mesure soit fiable. On peut compter le nombre d'étape de cas d'utilisation, ce qui est plus fiable. Finalement, on peut compter les mouvement de données à chaque étape, et on obtient alors une taille fonctionnelle en CFFP. Ha ha!! Peu importe alors comment on découpe les cas d'utilisation, on arrive à la même mesure (approximativement).
Sauf qu'au début, on d'un projet, on ne sais pas tout ca.
Poser des hypothèses
Voici les hypothèses que l'on peut poser en début de projet: on va avoir 15 cas d'utilisation, ayant en moyenne 20 étapes et en moyenne 12 CFFP par étape. Ces hypothèses (ici, les chiffres sont fictif), nous permettent alors de comparer ce projet à un autre. Si on connait notre productivité (temps requis de développement, par point de fonction) on peut estimer un effort de projet et bien d'autre choses.
Ajuster nos estimation avec les chiffres réels
Au fur et à mesure que le projet avance, on vérifier nos hypothèses et on les remplace par de véritables chiffes. On a le nombre de cas d'utilisation réel, le nombre d'étapes, ... Est-ce que l'on s'est trompé sur la taille, une moyenne, le taux de productivité... les ajustement sont faciles.
Il s'agit d'une méthode simple, ne reposant pas sur des jugement de valeur (complexité ou cote de cas d'utilisation).
Le "Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results" de David J. Anderson, est une bonne introduction à la théorie des contraintes, appliqué au développement informatique.
L'auteur transpose les concepts qui ont révolutionné le monde manufacturier, en terme de réduction d'inventaire, de production juste à temps, de qualité totale, ...
On peut vraiment comprendre en quoi certains éléments des méthodes agiles applique les principes que Toyota a rendi si célèbres. Dans le milieu manufacturier, ces concepts ont réduit d'au moins 30% les coûts de production, tout en augmentant énormément la qualité des biens produits. L'informatique doit suive cette voie.
L'un des concepts important du livre, selon moi: ne plus voir le développement d'un logiciel, comme strictement un projet, mais comme une machine à transformer les besoins des clients en un produit utile. Comment ? En optimisant la façon de faire, en ayant un feedback presqu'immédia, en réduisant l'inventaire (temps d'analyse, de conception, de programmation) par des itérations courtes. Si le client change d'idée, cela entraine peu de coût. Si un problème de spécification de glisse... il est plus rapidement détecté, puisque le développeur l'utilisera dans la semaine qui suit.
Comment repérer un goulot d'étranglement ? Il y a une pile de travail en avant et on attend après ce travail, pour faire la suite. Simple! Ensuite, il faut optimiser ce goulot, car toute heure perdu ici, est une heure perdu pour l'ensemble de la machine (usine). Comment l'optimiser ? En lui fournissant de l'aide, en s'assurant que tout ce qui lui parvient est impécable, ... De toute façon, le reste de l'organisation a du temps en surplus, puisqu'ils ne sont pas des goulot d'étranglement.
amazon.ca
"Agile Software Development" d'Alistair Cockburn
L'un des meilleurs livre sur la gestion de projet et sur l'optimisation des ressources, de développement informatique. L'auteur fait ressortir les coûts de la communication humaine (de face à face à l'écrit).
Facile à lire, permet de ne pas tomber dans la soupe de sur-documentation!
www.amazon.ca
Qu'est-ce qu'une inspection ?
L'inspection est l'une des méthodes de révision par les pairs. Cependant, elle a comme particularité d'avoir été très bien définie. Pour appeler une revue: une inspection, il faut respecter certaines choses.
Un sommaire du processus d'inspection
Il faut avoir une réunion préparatoire, où le matériel à inspecté est présenté aux participants. On y définie aussi les objectifs d'inspections. On remet aux participant, le matériel à inspecter, mais aussi les outils requis (gabarit, grille d'inspection, check-list, ...).
Chacun fait une révision individuelle et note les anomalies rencontré.
Une réunion d'inspection est alors tenu, où on retrouve un modérateur, un lecteur (qui présente le matériel), un scribe, les inspecteurs et l'auteur. La réunion sert à identifier les anomalies, pas à discuter des solutions. Tous apprennent les uns des autres, jusqu'où on peut aller, dans la recherche des anomalies (beaucoup plus loin qu'on ne le croix).
Le lecteur présente, en le reformulant, le matériel (déjà, cela permet de repérer des problèmes d'interprétation). On note les anomalies. Cependant, aucun patron ne devra utilise cela pour évaluer quelqu'un, car cela réduirait beaucoup l'efficacité de l'inspection.
Un bilan est fait, à la fin de la réunion et le matériel d'inspection (gabarit, check-list, ...) est amélioré, s'il le faut.
Après la réunion, un responsable (souvent, le modérateur) s'assure que les anomalies ont été adressées et valide s'il faut refaire une autre inspection.
Touts les participants doivent avoir été formé aux inspections. Un inspecteur devient vraiment production, à compter de la 3e inspection, avant, il doit être accompagné dans sa démarche.
Le transfert de connaissance
En plus d'atteindre souvent des niveau d'efficacité de 80% à 90%, les inspections, sous cette forme, sont un fabuleux outils de transfert de connaissance. Les nouveaux apprennent comment faire les inspections, le type d'erreur à éviter. De plus, un auteur sait mieux à quoi s'attendre et fera d'avantage de prévention, au niveau des anomalies.
De plus, la mise à jour, en équipe, des gabarits et liste d'inspection, permet d'augmenter le niveau de maturité de l'entreprise.
J'ai déjà fait l'expérience d'enseigner les cas d'utilisation et d'ajouter une inspection. Le résultat est spectaculaire: une grande amélioration en situation d'examen, suite à cette activité d'inspection.
Cette technique s'applique sur tout ce qui peut être lut pas un humain: besoins d'utilisateur, spécifications, diagrammes UML, architecture, programmation, script de test, ...
Ici, il s'agit vraiment d'une réflexion personnelle.
Il me semble qu'il y a deux façons distinctes de percevoir le développement de logiciel.
Dans un cadre de projet.
On identifie la porté (scope), on estime (sur quelle base?), on planifie, on réalise et on livre.
Les problèmes commencent avec la portée: le client doit choisir, une fois pour toutes, ce qu'il veut. Tout changement est un problème. Ensuite, on estime, sans vraiment savoir sur quoi. On ne sait pas à quelle vitesse l'équipe (la machine) va produire. On force alors cette équipe à se conformer à un objectif artificiel. On investit une énorme somme d'argent, qui ne paiera qu'à la fin du projet. On livre, en ayant mis une foule de contraintes artificielles.
Dans un mode de production continue
Une autre approche: l'équipe de développement est une machine à produire des morceaux d'application.
La gestion n'est pas la même. Le gros système n'est plus ce qui est livré. On livre des pièces, qui s'assemblent pour faire un tout. Ici, la gestion consiste à définir quelle est la "pièce" qui est le plus utile, pour le moment actuel, au client. C'est le client qui fixe ce genre de priorité. On fournit une vue d'ensemble, au début, à l'équipe. Ensuite, on ne lui livre qu'un bout de spécification à la fois.
Comment s'assurer que l'équipe ne perd pas son temps ?
On demande à l'équipe, combien de temps (le coût unitaire) du morceau à produire. Ensuite, on optimise localement, la qualité, la communication, le savoir, ... On ajuste le processus, on l'optimise continuellement. L'équipe atteinte alors un optimise de productivité et de qualité. Peu d'argent dort en terme d'inventaire (des spécifications qui dorment, c'est de l'argent investi qui ne rapporte pas avant longtemps).
Si on a un optimise de productivité (délais et qualité) de l'équipe, qu'on livre ce dont le client a le plus besoin... on a un optimum d'affaires.
Oui, mais quand le projet sera-t-il terminé ?
À chaque bout de produit livré, le projet peut se terminer. Dans la réalité des projets planifiée, quand un projet est terminé, on en recommence un autre...
Par contre, en mode production continue... l'équipe reste d'une taille raisonnable, n'attend pas de décision administrative et n'a pas de boom à fournir (engagement, fin de contrats, perte de connaissances, ...).
Regardons un peu plus comment les Japonais produisent des voitures de qualité à coût raisonnable. Je sais que la programmation n'est pas de la fabrication... mais en quoi est-ce qu'un mode projet aide à la production de savoir ?
Au lien d'un mode projet, pourquoi ne pas choisir une mode continue, avec les techniques d'amélioration continue: on optimise sans arrêt notre méthode de développement.
Comment augmenter l'efficacité des formations et séminaires ?
Les formations traditionnelles ne sont qu'une des formes de transfert de connaissance. Il en existe bien d'autres.
En entreprise, l'une de ces formes pourrait être les midi-conférence. L'employeur ne paye que le formateur et le matériel. Les participants apportent leur lunch et ne sont pas payé.
À raison d'une formation par semaine, le rythme est raisonnable et n'est pas pénalisant pour la vie privé des participant.
Cela implique de prendre plus de temps pour passer à travers une formation. Mais, est-ce vraiment un problème ou un avantage? Les séminaires sont chères, alors ils sont trop condensés, trop de matière vue en trop de temps. Le taux de rétention (assimilation superficielle, mémorisation et intégration réelle) est bas. Même 5 min après la formation, un simple test indique que ce taux est bas. Il est dommage que la plupart des formateurs ne font qu'un sondage de satisfaction, au lieu de mesurer l'efficacité de la formation.
Un rythme plus lent est préférable. Cependant, le temps (45 à 60 min) est trop restreint pour que les participants aient le temps de poser des questions, de produire des résultats et d'être évalués. À une formation par semaine, il faut assurer une continuité.
C'est pourquoi il faut d'autre forme de support, complémentaire à ces formations. Par exemple, le formateur peut tenir un blog, avec une entrée, résumant la séance de formation et posant des questions. Les participants peuvent alors y ajouter leurs questions et commentaires. Le groupe peut alors faire des échanges. Le formateur supervise le tout (utilisation de RSS).
De plus, un wiki collectif, portant sur la formation, peut être maintenu par le groupe, supervisé par le formateur. Le formateur place une structure, mais les participants doivent complété, par les connaissances qu'ils ont acquis. Le formateur supervise et commente le tout. Des discutions peuvent alors commencer.
Il faut prévoir des mécanismes de rémunération du formateur, pour le support fournis, mais la formule me semble intéressante. Le rapport coût/rétention risque d'être plus élevé que dans les formations traditionnelles. Surtout si une partie de l'apprentissage s'effectue sur le temps des employés (avec satisfaction, en plus). Même quand un participant lit et écrit, suite à une formation, sur les heures de travail, il le fait probablement dans une période moins critique de son travail.
Le livre "UML 2 and the Unified Process, second edition" de Arlow Neustadt est un bon petit livre sur la notation UML 2. Il montre bien les différents diagrammes. Pour en juger, je vérifie généralement la couverture faite du diagramme d'activité, qui change passablement dans UML 2. Ce livre couvre bien le sujet et présente les diagrammes dans un contexte (méthodologie) réaliste.
Cette approche est plus facile que d'utiliser un livre de référence, classant les diagrammes par ordre alphabétique (je rigole).
À voir sur amazon.ca 
Bonne lecture.
L'idée de ce blog: donner de l'information sur les méthodes de développement logiciel.
Les meilleures idées se cache autant du coté des méthodes planifier (génie logiciel, CMMI, SEWBOK, ...) que du coté des méthodes agiles. La difficulté est souvent d'extraire le principe actif d'une recette de grand-mère. C'est ce que je vais tenter de faire et d'ouvrir quelques fenêtres.
Je m'intéresse au Génie logiciel, aux méthodes agiles, aux techniques de développement, à l'utilisabilité (ergonomie) et à la psychologie.
J'espère que les informations présentes aideront le plus de monde possible.
"Comme l'eau, l'information doit circuler, sinon, elle croupis".
