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é
The Eight Most Common Big Data Myths
L’agilité c’est avant tout une vision de l’organisation qui remet le client au centre. Comprendre le client, ses besoins, ses désirs est loin d’être facile et lorsqu’il n’est pas accessible directement, ses représentants (aka: les Product Owners) ont bien du mal à adopter la bonne vision.
Avec l’avènement du Big Data, on a cru voir une solution miracle à ces problèmes. Enfin, nous allions comprendre nos clients, prédire leurs moindres rêves.
À travers cet article (en anglais), Joerg Niessing(@JoergNiessing), INSEAD Affiliate Professor of Marketing, et James Walker, Partner Demand Analytics, Strategy& démystifient les Big Data en s’attachant à nous en révéler 8 croyances fausses.
Une lecture à ne pas rater pour qui veut mieux comprendre cette hydre à 8 têtes !
The Case for Scrum Dying in a Fire
Pour ceux d’entre vous qui suivent l’actualité Agile sur Twitter vous avez peut-être entraperçu tout un débat entre Ron Jeffries, et Gilles Bowkett au sujet de Scrum.
Gilles a manifestement rencontré un de ces monstres de Scrum-But que l’on préférerait éviter, une pure forme d’Agile Washing (qui ne lave pas plus blanc que blanc!). Et de fait, de son point de vue, Scrum n’est bon qu’à périr dans les flammes…
En réponse aux articles de Gilles, Ron a publié une série de billets sur son blog. S’ils sont tous intéressants, je n’en retiens que le dernier qui s’attache réellement au problème de Scrum-But auquel on a tous certainement pu assister.
Dans ce billet Ron, prend un peu de hauteur et revient sur la nature de Scrum et sur les raisons qui peuvent expliquer que nous puissions si facilement en voir l’idée dévoyée.
Si vous avez pu vous aussi, vous posez des questions sur des implémentations de Scrum plus que hasardeuses et vous demandez comment cela peut bien fonctionner, c’est une lecture que je ne peux que vous conseiller!
No. Agile Does Not Scale (but agility scales quite well, thank-you-very-much)
L’agilité à l’échelle est une des problématiques du moment des agilistes. Les différents frameworks à l’échelle qui sortent essayent tous de l’adresser et ce plus ou moins dans le respect du manifeste d’origine.
Dans son article, l’avis de Jurgen Appelo est que l’Agilité au sens du Manifeste Agile ne scale pas, il n’était pas fait pour à l’époque.
Par contre l’agilité tout court (avec un petit "a"), celle d’un système complexe est toujours possible, et elle, scale. Et pour réconcilier les 2, il suffirait de faire évoluer le manifeste en conséquence.
Un point de vue intéressant que je vous conseille de lire dans sa globalité en suivant le lien.
Hierarchies remove scaling properties in Agile Software projects
A l’approche du ScrumDay 2015, qui mettra clairement en avant les problématiques d’Agilité à l’échelle, je trouve intéressant de se replonger dans cet article de Vasco Duarte(une des voix les plus écoutées du mouvement #NoEstimates).
Dans cet article, Vasco Duarte amène une réflexion intéressante qui ouvre le chemin d’une autre vision de l’Agilité à l’échelle. Pour cela, il étudie plus particulièrement une problématique, celle de la communication.
Avec l’accroissement des tailles des équipes, les besoins en structuration et en communication (notamment pour synchronisation ou information) augmentent de manière évidente. Et cela plus particulièrement au sein d’équipes Agiles, qui se veulent capables de s’adapter au changement au moindre coût et au plus tôt.
Pour ce qui est des besoins de structuration, la mise en place d’une hiérarchie forte a été la réponse classiquement adoptée en entreprise (ce qui a permis jusqu’à aujourd’hui le développement d’entreprises de plusieurs centaines de milliers d’employés).
Pour ce qui est de la communication, je laisse Vasco Duarte vous montrer les impacts pernicieux de la hiérarchie qui nuisent à notre capacité à la faire grandir (et en conséquence posent la question de la pertinence de la hiérarchie pour "scaler").
Au passage, je vous recommande de jeter un oeil aux commentaires pour y découvrir une idée intéressante sur le rôle des réseaux informels de communication (basés sur les relations sociales), lorsque la hiérarchie vient empêcher celle-ci de bien s’exprimer.
Craftsmanship
Sortie de AssertJ 2.0.0 – Craftsmanship
La toute nouvelle mouture d’AssertJ est une majeure et contient de nombreuses nouvelles fonctionnalités très intéressantes. L’une d’entre elle retient tout particulièrement notre attention : cette nouvelle fonctionnalité vous permet de délimiter très précisément le code dont vous vous attendez à ce qu’il lance une exception. Un exemple sera plus parlant qu’un grand discours :
@Test
public void should_throw_exception() {
Throwable thrown = catchThrowable(() -> { throw new Exception("boom!") });
assertThat(thrown).isInstanceOf(Exception.class)
.hasMessageContaining("boom");
}
Évidemment, l’utilisation des lambdas en java 8 sera un plus non négligeable pour la lisibilité. Adieu donc le paramètre expected sur l’annotation @Test de JUnit.
Nous vous invitons à consulter la release note et à mettre à jour vos poms au plus vite.
Front
Angular 2.0: Mais pourquoi pas Dart ?
La semaine dernière, nous remontions l’information indiquant que la team Angular a décidé d’abandonner AtScript pour TypeScript dans le développement d’Angular 2.0.
Mais une question se pose : pourquoi ne pas choisir Dart ? Après tout, il s’agit d’un langage développé par Google et il aurait pu être cohérent que le framework de Google utilise le langage de la même entreprise.
En effet, TypeScript est développé par Microsoft, dont les relations avec Google n’ont pas toujours été cordiales.
Cet article tente d’apporter une réponse à cette question et revient sur les forces de TypeScript comparé à Dart.
Back
Quel futur pour Spring ?
Spring, le framework Java mainstream par excellence et utilisé par une multitude de projet continue d’évoluer.
Parfois critiqué pour ses choix ou sa complexité, Spring reste néanmoins incontournable pour bon nombre d’entreprises.
Dans cet interview, Juergen Hoeller (co fondateur de Spring) revient sur le passé de Spring et sur la direction prise par le framework.
Juergen répond avec détails aux questions suivantes:
- Pourquoi tant de projets dans Spring ?
- Comment sont fait les choix à l’intérieur de l’équipe ?
- Quelles sont les relations avec Pivotal, et notamment Cloud Foundry ?
- Comment se compare Spring avec d’autres frameworks plus jeunes comme Play ?
- Quelles évolutions attendre avec Java 8, Docker ou encore les microservices ?
Le coin de la technique
Adieu Google Code – Technique
Jeudi dernier, Google a annoncé l’arrêt de son service Google Code. En ligne depuis 2006, le service avait pour but de fournir un service d’hébergement de code gratuit pour la communauté. Afin de faciliter la transition, Google met à disposition un outil afin de pouvoir transférer les sources vers d’autres services d’hébergements comme Github ou BitBucket par exemple. Enfin cette migration devra être faite avant le 26 Janvier 2016, deadline imposée par Google.