Principe 10 - Pas de place pour les Snipers !
Nous voici arrivés à la fin de nos dix principes Agile. Nous finissions sur un des principes que je trouve majeurs pour qui a mis Agile en oeuvre. Celui de la gestion de l’équipe projet.
Le développement Agile repose sur une étroite coopération et collaboration de tous les membres de l’équipe et des intervenants.
C’est une différence et même une divergence par rapport aux méthodes traditionnelles de gestion de projet, ou le chef de projet est celui qui décide et gouverne son projet et souvent de manière unilatérale. Le reste de l’équipe étant essentiellement des exécutants.
Dans un projet Agile, l’ensemble du projet est discuté et partagé avec l’équipe. Le responsable du projet reste néanmoins celui qui prend la décision finale après concertation avec son équipe.
Les principes du développement comprennent le respect des exigences et une documentation légère, et en reconnaissant que le changement est normal et acceptable dans le développement de logiciels.
Cette étroite collaboration rend particulièrement important de clarifier les exigences justes à temps et de garder tous les membres de l’équipe (y compris le produit propriétaire) « sur la même ligne » durant l’ensemble du développement.
Vous ne pouvez certainement pas aller très loin avec des spécifications importantes qui sont réalisées à l’avance et sans une étroite collaboration avec l’équipe. Cas que l’on retrouve trop souvent dans les projets en cascade. Il ne faut pas ensuite s’étonner que le projet ne ressemble pas aux spécifications et encore au réel besoin du client.
Mais contrairement à un projet en méthode traditionnelle, en développement Agile l’équipe travaille vers un objectif commun, créer un meilleur travail d’équipe, favoriser l’esprit d’équipe, et être plus fortes. À la finalité, satisfaire le besoin client.
Si vous travailler avec un responsable qu’il pense qu’il peut prendre toutes les décisions de manière unilatérale, qu’il possède la science infuse, il est temps de s’en séparer et de changer de méthode de projet !
Dans mes billets suivants, je vous présenterais, comment faire travailler une équipe ensemble avec Scrum
data-warehouse, ETL, et BI
Derrière ces termes que certains qualifient de “mots pour décideur pressés lisant 01 informatique” se cache pourtant des vrais concepts, je vais tacher en quelques phrases de les expliquer, et surtout de montrer les intérêts.
- le data warehouse (entrepôt de données dans notre chère langue maternelle) est un composant technique (le plus souvent une base de données) où sont exportées des données métiers. Imaginons une application XYZ (qui elle même utilise une base de données pour ses besoins internes), qui exporte à intervalle régulier l’état de ses données métiers.
- L’ETL (Extract Transform Load) est l’étape suivante, celle qui permet d’extraire les données des différentes base warehouse, et éventuellement les transformer.
- et finalement, il nous reste à présenter les données métiers sous forme graphique, c’est ce qu’on appelle du BI - Business Intelligence (informatique décisionnelle en bon français).
Vous pourriez vous demander “mais à quoi tout cela sert ?” et bien, c’est relativement. A traiter ses données en fonction de ses besoins, et pas en fonction des fonctionnalités de reporting que propose un logiciel. De plus, l’utilisation d’outil dédiés (typiquement pour le reporting) permet de regrouper l’ensemble des rapports sous une même interface (un portail) plutôt que de devoir se rendre sur chaque applicaiton pour y consulter les rapports proposés par les N interfaces d’administrations des N logiciels utilisés (et qui de toute façon sont rarement adaptés).
Quelques liens sur le sujet :
- Article Wikipédia sur le BI
- Article Wikipédia sur le datawarehouse
- Talend, un ETL OpenSource
- JasperReport, produit OpenSource pour créer des rapports graphiques
[OpenOffice.org] La fonction de découverte inverse ne couvrait pas les formules trop précises
La fonction de découverte inverse ne couvrait pas les formules trop précises, notamment sur des calculs de faibles pourcentages. Le correctif améliore cette fonctionnalité en lui faisant couvrir un spectre plus large de résultats possible.
[Gforge] Le problème venait d'une gestion des droits différentes selon les distributions
Après avoir demandé à ce qu'un projet passe privé, tout accès ultérieur en consultation web sur le dépôt CVS était voué à l'échec. Les permissions étaient mises à jour de façon non générique, et seule une installation en environnement debian pouvait fonctionner.
Le correctif résoud ce comportement et permet une utilisation correcte sur les distributions à base de Red Hat.
[Gforge] Le fichier était encodé en latin-1 sur un site en UTF-8
Le problème vient en fait d'une différence possible entre l'encodage du système hébergeant Gforge et des pages générées par le couple php + perl, qui sont elles en UTF-8.
Il empêchait alors l'accès aux fichiers accentués et affichait alors une erreur 404.
Il a été règlé très simplement, le correctif ne faisant qu'une ligne.
[NAGIOS] Multiplatform compatibility for playing embedded sounds
Nagios web pages include an embedded WAV file that plays an alert sound in case the supervision tool detects any hosts or services are down. Until version 3, this WAV file was presented to browsers using the mime type "application/x-mplayer2". Most browsers (or their sound plugins) recognize and correctly interpret this mime type.
However, this mime type is non standard and comes from a specific program (Microsoft Media Player). Nagios developers therefore replaced this mime type with "application/wav". While this was recognized just fine by all browsers on Linux, Windows browsers (IE and Firefox at least) did not recognize it.
This patch provides the following corrections :
- Use the officially declared mime type "audio/x-wav"
- Use the correct "autostart" parameter with the value "true" (not "1")
- Correct a typo
Many thanks go to Cédric Temple for debugging this!
[Thunderbird] Cette anomalie concerne des emails de client peu respectueux des standards
Certains clients emails, dont la suite bureautique Microsoft Office 2007, peuvent envoyer des emails incorrects.
Lors de la fabrication de l'email html, certaines images n'ont pas un type de contenu d'image Content-Type: image/* mais un contenu de type fichier binaire : Content-Type: application/octet-stream.
Par précaution, Thunderbird refusait de donner accès à une image dont le type de contenu était incorrect.
Nous avons été capable de produire un cas d'utilisation simple démontrant le problème, que vous trouverez sur le bugtracker communcautaire.
Le correctif proposé a donc consisté à détecter directement le type du fichier via son contenu au lieu de se baser sur cette information textuel que ces clients mails ne savent pas remplir correctement. Il permet alors d'afficher l'ensemble des images de l'email sans aucun problème et sans aucun risque supplémentaire de sécurité.
[Bugzilla] Crash du script bzdbcopy.pl
Le script bzdbcopy.pl fourni avec Bugzilla permet de migrer d'une base de données MySQL/PostgreSQL/Oracle vers une autre base.
Ce script lit les tables de la base source une par une pour les insérer dans la base cible. Dans le cas de tables MySQL de très grosse taille, le script plante, faute de mémoire suffisante. Ce correctif modifie le script pour que, lorsque la base source est MySQL, les tables soient lus rangées par rangées et non en entier.
[OpenOffice.org] L'export HTML de Writer peut être incorrect sur certains textes
L'export HTML de Writer peut être incorrect sur certains textes, ayant un attribut <strong>. Le problème a été identifié lors d'un copier coller entre Writer et Thunderbird.
Ce problème a été relevé sur les systèmes d'exploitations Linux & Windows, quelque soit la destination du copier-coller.
Le correctif est assez simple : il suffit d'exporter convenablement le poid de la police.
[debian-live] Give a warning when installing local packages with wrong naming scheme
If you use homemade package which don't follow the debian policy rules, the application can't handle them. Before the patch, no real informations was given, now a warning message is gift.
[KnetworkConf] Inclusion correcte de knetworkconf dans knetworkmanager
Knetworkmanager ne gère que les cartes non définies dans /etc/network/interfaces.
Lorsqu'une carte est ajoutée via knetworkconf, elle ne peut être supprimée du fichier de configuration lorsque la configuration bascule en DHCP.
Le patch permet de supprimer la carte du fichier de configuration lorsque l'on repasse en mode dhcp, et celle-ci est donc ne nouveau gérée par Knetworkmanager
[KnetworkConf] Knetworkconf casse la configuration de samba
Knetworkconf lis mais ne sait pas ecrire les paramètres de configuration de samba, la fonctionnalité étant seulement partiellement implémentée.
Le logiciel faisant partie de la suite kde3, étant en fin de vie, cette fonctionnalitée complète ne verra probablement jamais le jour et de fait la gestion des paramètres samba a été desactivée.
Préparation de la conférence « La Biennale de Paris et la Licence Art Libre »
Un rapide billet pour annoncer la préparation du débat/conférence sur « La Biennale de Paris et la Licence Art Libre », qui se déroulera le mercredi 24 septembre 2008 de 14h30- 16h30 lors de l'événement Paris Capitale du Libre
.
La Biennale de Paris a décidé en juin 2008 de mettre ses contenus sous Licence Art Libre. Lors de ce débat seront abordées des pratiques artistiques qui excèdent le seul champ de l'art. Il s'agira d'interroger le statut de l'auteur et de l'objet d'art.
- Pourquoi le copyleft issu des logiciels libres est-il pertinent pour la création contemporaine ?
- Comment un art, à la frontière de l'art contemporain reconnu comme tel, opère un retournement de situation artistique quand la copie, la diffusion et la transformation des oeuvres coulent de source.
Présentation : Antoine Moreau http://artlibre.org
Intervenants : Ghislain Mollet-Viéville, agent d'art.
Exemples d'oeuvres proto ou para copyleft (Alan Kaprow, George Brecht, Lawrence Weiner) qui rejoignent le principe copyleft de la Licence Art Libre.
Alexandre Gurita, Directeur de la Biennale de Paris.
Mise au point sur les pratiques artistiques défendues par la Biennale de Paris en phase avec la Licence Art Libre.
Jean-Baptiste Farkas, Président de l'Amicale de la Biennale de Paris et créateur d'IKHÉA©SERVICES, un exemple de pratique artistique présentant quelques similitudes avec le copyleft.
http://biennaledeparis.org/amicales
Comme annoncé en accroche, je n'ai pas beaucoup de commentaires à ajouter à cette annonce : cette réunion entre Art Libre et Art Contemporain est pour moi lourde de sens et d'espoir pour les années à venir.
Pour ceux qui ne connaissent pas la Biennale de Paris ou le collectif copyleft attitude, je vous invite tout simplement à aller visiter leur site :
La Biennale de Paris
Voir la présentation.
La Biennale de Paris, loin du ronronnement des grandes manifestations internationales, s’attache à découvrir et à défendre un art exigeant, en phase avec notre contemporanéité, avec ses évolutions politiques, économiques et sociales. Un art qui ne se contente plus de produire des objets à l’usage d’un marché, d’une mode ou d’une élite culturelle. Un art qui se définit comme une façon de penser l’art et de l’activer plutôt qu’un ensemble de produits artistiques. Un art qui ne cherche plus le spectaculaire mais qui interroge, qui essaie et qui opère. La Biennale de Paris est le dispositif où se manifeste une pensée qui ne peut trouver place dans les institutions traditionnelles, trop lourdes, trop lentes, trop timides. La Biennale de Paris n’a pas de contour. Elle est incontournable.
Copyleft Attitude
Voir la présentation.
Copyleft Attitude a pour objectif de faire connaitre et promouvoir la notion de copyleft dans le domaine de l'art et au delà. Prendre modèle sur les pratiques liées aux logiciels libres pour s'en inspirer et les appliquer pour la création hors logiciels. C'est la raison pour laquelle nous avons mis au point la Licence Art Libre.
Là-dessus, j'invite toute personne sensible à l'Art à venir s'y frotter ^_^.
P.-S. : je vous conseille aussi une parution récente d'Antoine sur le Net Art. Cette vision gagne véritablement à être découverte et partagée.
krsync: Authentification Kerberos pour rsync
Vous trouvez la gestion de l’authentification rsync un peu faible ? Si oui, vous n’êtes pas le seul, c’est pour cela que Fabrice Bacchella a écris un patch pour rsync permettant d’utiliser l’authentification kerberos. Ce patch et sa documentation sont disponibles sur ma miniforge (et oui j’en profite pour me faire un peu de pub au passage !)
Principe 9 - Les tests c'est pas pour le nuls !
'' En développement agile, le test est intégré dans l'ensemble du cycle de vie, des tests continuent tout au long du développement du logiciel.''
Le développement Agile ne possède pas une phase de test en tant que telle. Les développeurs sont fortement engagés dans les tests et l'écriture des tests unitaires automatiques pour valider leur code.
En complément d'être orienté vers une meilleure qualité des logiciels, c'est aussi important de mettre en œuvre le principe « Des petits développements, itératifs et des livraisons incrémentales ». Avec des tests unitaires automatisés, les tests peuvent être effectués dans le cadre de la compilation, en veillant à ce que tous les éléments fonctionnent correctement chaque fois que la compilation est produite. Cette compilation doit être réalisée régulièrement, au moins une fois par jour, pour que l'intégration soit réalisée au fur et à mesure.
Le but de ces principes est de maintenir le logiciel dans état dit :« livrable » tout au long du développement, afin qu'il puisse être expédié chaque fois que c'est approprié. Il s’avère aussi utile pour ne pas laisser le logiciel accumuler les anomalies et attendre le dernier moment pour les corriger (méthode traditionnelle de développement)
Le XP (Extreme Programming) cette méthodologie Agile va encore plus loin. XP recommande le développement piloté par les tests, l'écriture des tests avant d'écrire le logiciel.
Mais les tests ne doivent pas seulement être réalisés par les développeurs tout au long du développement. Il y a un rôle très important dans l’équipe : l’intégrateur. Comme nous le savons, tous "les développeurs ne peuvent pas tester le caramel !" 
Le rôle d'un intégrateur peut changer considérablement en développement agile, dans un rôle plus proche de l'assurance de la qualité que de simples tests. Il y a des avantages considérables d’avoir un intégrateur impliqué dès le début.
Cette situation est amplifiée encore par « Des besoins macro, léger et visuel » en développement agile, l'accent est mis sur la conversation et la collaboration des exigences par rapport à une approche traditionnelle d’écriture lourde des spécifications et des documentations.
Bien que les exigences peuvent être précisées en détail dans le développement agile (tant qu'ils se font juste à temps et pas tout à l'avance), il est tout à fait possible que cela puisse se traduire par une certaine ambigüité et /ou dans certains cas, les membres de l'équipe n’ont pas la même compréhension des exigences.
Alors qu'est-ce que cela signifie pour un intégrateur agile ? Une préoccupation commune des intégrateurs en particulier pour ceux qui changent régulièrement d’environnement projet - est qu'ils ne savent pas précisément ce qu'ils doivent faire comme test. Ils n’ont pas une spécification détaillée pour effectuer le test, alors comment peuvent-ils tester?
Même dans un environnement plus traditionnel de développement, j'ai toujours fait valoir que les testeurs ont besoin de spécification, et pourtant le produit pourrait encore être de mauvaise qualité, peut-être parce que les exigences ont été mal spécifiées ou parce qu'elle a été clairement mal écrite. Une spécification n'est pas nécessairement le bon produit !
En développement agile, il y a une conviction que, parfois - peut-être même souvent - ces choses ne sont réellement évidentes que quand on peut voir le logiciel fonctionner en livrant des petites livraisons incrémentales et progressives et en mesurant le progrès sur un logiciel fonctionnel, le test décisif est de voir le logiciel et alors seulement vous pouvez juger si oui ou non, il est de bonne qualité.
Les tests Agile induisent donc à plus de jugement de la part de l’intégrateur, d’une expertise de ce qui est bon et ce qui ne l'est pas, la capacité d'être plus flexible et avoir la connaissance et la vision de ce que doit être un bon logiciel. Ce n'est pas certainement une simple affaire de suivi de scénario de test, en s'assurant que le logiciel fait ce qui est écrit dans les spécifications.
C’est pour ces raisons, que les tests en Agile nécessitent une très expérience et une expertise !
