RDP
La revue de presse hebdomadaire des technologies Big Data, Cloud et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.
Agilité
#NoEstimates – Accidental Complication or why estimates don’t work
Cet article de Vasco Duarte est un argumentaire supplémentaire en faveur du cas #NoEstimates. Pour ma part, je ne le trouve pas tant intéressant pour les arguments qu’il apporte en ce sens que pour la distinction qu’il fait entre "essential complication" et "accidental complication" c’est à dire entre la complexité inhérente à une tache et celle liée à son contexte.
En effet, bien souvent, les estimations faites en entreprise ne prennent pas en compte cette "accidental complication" alors qu’elle peut représenter l’essentiel du coût de réalisation.
Pour en savoir plus, je vous invite donc à lire l’article et ainsi à minima prendre en compte cette dimension lors de futures "estimations".
5 reasons to switch from your kanban board
Je préfère vous le dire tout de suite, je ne suis pas d’accord avec les conclusions de cet article qui présente 5 raisons pour adopter un Kanban électronique.
Si je vous le partage, c’est que les arguments avancés font partie de ceux que l’on voit régulièrement. Voici quelques réponses que l’on peut y apporter en faveur d’un tableau physique.
- Espace illimité: En pratique, l’outil électronique n’apporte rien, car si l’espace est illimité, la partie visible à l’écran est plus limitée que celle d’un tableau physique. On ne peut pas bénéficier de l’effet "radiateur d’informations"
- Informations détaillées de la carte changent: S’il est intéressant d’avoir cette information quelque part, ce n’a aucun intérêt sur un kanban. En effet, trop d’informations tuent l’information. La carte doit être visible de loin et permettre la conversation. Nous savons tous que noyés sous les spécifications, nous avons tendance à ne plus lire du tout.
- Métriques automatiques: C’est là un bon argument pour un tableau électronique en complément d’un tableau physique
- Accès illimité aux informations de l’équipe: Un faux problème. On s’en sort très bien avec un tableau physique. Pensez à utiliser des avatars. En les déplaçant avec la carte, vous savez qui a travaillé dessus.
- Update et monitoring facilités: Mauvais argument, déplacer un post-it reste beaucoup plus rapide qu’en changer le statut dans un outil. Par ailleurs, pour ce qui est du monitoring, un coup d’oeil à un tableau physique suffit généralement pour s’apercevoir qu’une tâche n’a pas bougé depuis plusieurs jours ou que les post-its sont en train de virer au rouge!
Voilà, j’espère vous avoir apporter quelques réponses si vous deviez, vous aussi défendre le tableau physique. L’outil électronique reste intéressant, mais en complément seulement.
Why Physical Task Boards Still Matter
Après l’article contre l’utilisation de tableaux kanban physiques, celui-ci par Joel Bancroft-Connors explique leur intérêt.
Vous vous en doutez, du coup je ne puis qu’en être partisan.
Ce qui est intéressant avec cet article c’est qu’il va au-delà des arguments que j’ai déjà pu rapporter au sujet du précédent article. Vous y trouverez des informations de recherche qui expliquent l’intérêt du physique. Vous y verrez aussi quelques détails pratiques pour mieux mixer le tableau électronique avec le tableau physique. Il n’y a guère que le point à propos des équipes distribuées que l’on peut éventuellement discuter. Pour ma part dans ces cas-là, je propose la duplication du tableau physique en complément de l’électronique. C’est certes plus contraignant, mais le bénéfice en vaut le coût.
Je vous souhaite une bonne lecture.
Myths Of Companies With No Management
Pour beaucoup une entreprise libérée, c’est une entreprise sans chefs. C’est cette vision un peu réductrice à laquelle s’attaque Romy Misra. Dans cet article, elle s’attache à expliquer certaines des idées reçues les mieux partagées à propos des entreprises sans management (c’est facile de ne pas avoir de chefs, plus de management signifie plus de structure, plus de chefs signifie qu’on est tous égaux, le management est toujours mauvais).
Pour qui est intéressé par le sujet, c’est donc là un avertissement fort utile afin de mieux comprendre les enjeux d’une transformation vers ces modèles d’entreprises libérées. Au passage, vous y trouverez aussi quelques pointeurs vers des organisations ayant adopté ce fonctionnement.
Mobilité
LeakCanary, chassez et colmatez vos fuites mémoires sur Android
Sur le blog de Square, Pierre-Yves Ricau nous annonce la sortie de leur dernière librairie nommée LeakCanary. Elle permet de monitorer les activités afin de détecter d’éventuelles fuites mémoires et d’afficher, le cas échéant, une notification permettant d’en trouver l’origine. Elle s’intègre très facilement dans le code existant et permet donc de détecter des fuites tout au long du cycle de développement. Elle leur a notamment permis de réduire leur OutOfMemoryException de 94% et de détecter plusieurs fuites mémoires dans le framework Android lui-même. Un guide d’utilisation et d’installation est disponible sur leur GitHub à ce lien.
Front
Sortie de Backbone 1.2.0
15 mois après sa dernière release (1.1.2), Backbone sort une nouvelle version de sa libraire RIA orientée data.
Pas de gros changements au programme, mais quelques évolutions :
- Possibilité de s’abstraire de jQuery pour la gestion du DOM. On peut maintenant utiliser du javaScript natif, jsdom ou même du D3.js. Cette évolution rentre totalement dans la logique de la librairie de découpler au maximum les composants d’une application RIA.
- Dans un environnement CommonJS, Backbone charge jQuery par défaut quand celui-ci est présent. C’est un retour en arrière par rapport à la 1.1.2 (avec notamment la popularité grandissante de browserify).
- Ajout d’un événement update lors d’une modification d’une collection.
- Travail sur la compatibilité avec ES6/ES2015.
- Divers améliorations sur le Router.
Et d’autres petites choses sympathiques ! Le mieux reste de jeter un coup d’œil sur le changelog !
Avec cette nouvelle release, Backbone ne trahi donc pas sa philosophie initiale : simplicité, stabilité et découpage.
Back
Disponibilité finale de la JDK9 fin 2016
Mark Reinhold a annoncé le planning de réalisation de la JDK 9. L’intégration des fonctionnalités se fera fin 2015. Et la version finale sera releasée fin 2016.
Au menu: Coin 2, http 2, jigsaw, etc…
Java 9 : Breaking changes en vue
Une des grandes forces de Java est sa rétro compatibilité. Il est possible de faire tourner une application développée en Java 1 sur une JVM Java 8.
Cette rétro compatibilité facilite grandement la migration des projets vers les nouvelles versions.
Et bien avec Java 9, il va falloir faire autrement. En effet, le projet de modularisation du JDK JigSaw va apporter de profonds changements dans l’architecture même de Java.
Cet article tente de répertorier les cas concrets où votre application ne pourra pas migrer sans douleur vers Java 9.
DevOps
la success story de Huawei
L’évolution d’Huawei, le géant chinois de la télécommunication, constitue une preuve concrète de l’efficacité des pratiques de Continuous Delivery et de DevOps au sein de son infrastructure IT.
Le coin de l’Alliance
XebiaLabs sera sponsor des "Belgium Testing Days" à Bruxelles les 20 et 21 Mai prochains