Article publié par Xebia France le 15 juin 2011.
Catégorie(s) : Revue de presse
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
Le coin de la technique
Evénements de notre communauté en France et à l’étranger
Article publié par Christophe Heubès le 20 janvier 2011.
Catégorie(s) : Méthodes agiles
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective à travers la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un nouveau principe à appliquer afin d’atteindre ces objectifs. Ce principe a été introduit par James O. Coplien et s’intitule « Tous sur le pont dès le début ».
L’essence de ce principe est que l’ensemble des parties prenantes d’un projet doit être impliqué dès le démarrage de ce dernier.
Article publié par Yves Amsellem le 17 janvier 2011.
Catégorie(s) : Java / JEE
Parmi les piliers de l’OOP, 3 sont majoritairement implémentés par nos langages, l’héritage, le polymorphisme et l’encapsulation. Et, bien qu’à l’intérêt reconnu, la délégation ne l’est que trop rarement. Elle remplace pourtant souvent avantageusement l’héritage en réduisant couplage et graphe d’objets. Voyons comment faire de cette petite sœur injustement négligée une alliée de choix.
Article publié par Christophe Heubès le 27 décembre 2010.
Catégorie(s) : Méthodes agiles
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un nouveau principe à appliquer afin d’atteindre ces objectifs. Il constitue un aspect primordial de la fonction d’architecture et s’intitule « Penser grand, agir petit ».
Article publié par Christophe Heubès le 25 novembre 2010.
Catégorie(s) : Méthodes agiles
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un deuxième principe à appliquer afin d’atteindre ces objectifs. Alors que le premier, « Etre toujours impliqué », concernait l’architecte et son rôle, celui-ci à trait aux livrables d’architecture. Il s’intitule « Voyager léger ».
L’expression « Voyager léger » doit ici être prise au pied de la lettre. La question qui se pose est : Que doit avoir sur lui un architecte lorsqu’il fait le tour des parties prenantes d’un projet pour échanger avec chacune d’entre elles ? De quel support a-t-il besoin pour expliquer les besoins métier à l’équipe de réalisation, pour transmettre la vision du produit au métier, pour impliquer les opérations suffisamment tôt, etc. ?
Comme nous l’avons déjà vu, les dossiers d’architecture à rallonge sont un mal courant dans nos Direction Informatique. C’est le piège du « Big Design Up Front » (BDUF) ou du « Big Modeling Up Front » (BMUF). Les dossiers d’architecture épais comme des bottins ne sont d’aucune utilité parce qu’au final, quels que soient les efforts déployés pour les produire et quelle que soit la pertinence de leur contenu, ils ne sont pas lus. De tels documents ne sont pas lisibles facilement et demandent trop d’efforts et de temps pour appréhender et comprendre leur contenu. Résultat, tout le monde s’en détourne et toute la valeur qu’ils contiennent est perdue.
Article publié par Christophe Heubès le 12 novembre 2010.
Catégorie(s) : Méthodes agiles
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un premier principe à appliquer afin d’atteindre ces objectifs. Il concerne l’architecte et son rôle et s’intitule « Etre toujours impliqué ».
Le rôle d’un architecte ne se limite pas à un projet ou à une phase d’un projet. Pour être efficace, un architecte doit avoir des perspectives bien plus larges. Un architecte Lean communique en permanence avec toutes les parties prenantes de la DSI (du métier aux opérations). Il joue un rôle actif dans la réalisation des projets. Il s’assure que les leçons apprises sur les projets passés ou en cours sont sues et qu’elles sont appliquées dans tous les projets qui le nécessitent.
Article publié par Christophe Heubès le 5 novembre 2010.
Catégorie(s) : Méthodes agiles
Le rôle de l’architecture et la place des architectes au sein d’une organisation font souvent débat et sont souvent mal compris. Cette incompréhension est principalement due au fait que la contribution de l’architecture à la réalisation des objectifs métier de l’entreprise n’est pas (ou peu) visible.
Le rôle de l’architecture peut être remis en perspective si on le considère au travers du prisme de trois objectifs clés (les 3 C de l’architecture) :
Utiliser ces objectifs comme principes fondamentaux d’une « architecture lean » met l’emphase sur ce qui doit être fait sans perdre de vue le pourquoi. Cela permet ainsi de mieux positionner l’architecture au sein d’une organisation.
Article publié par Xebia France le 10 mai 2010.
Catégorie(s) : Méthodes agiles
La conférence Agile France 2010 se tiendra à Paris les 31 mai et 1er juin prochain.
Avec plus de 70 conférences et ateliers répartis sur six à sept salles en parallèle, cette conférence s’impose comme une des principales conférences sur l’agilité en Europe. Pour un prix attractif (270 €), nous vous encourageons à venir chercher de nouvelles idées, partager vos expériences et rencontrer des gens passionnés par l’agilité.
Comme en 2008 et 2009, Xebia participera à cette édition au travers de 3 présentations animées par des consultants Xebia :
Article publié par Guillaume Bodet le 8 octobre 2009.
Catégorie(s) : Méthodes agiles
Les méthodes agiles articulent le développement autour d’équipes dotées d’une grande autonomie technique – elles comprennent typiquement chacune au moins un architecte ou développeur très expérimenté, susceptible de structurer les choix de conception (nous avons dessiné le profil de cet architecte agile dans un article paru il y a quelques mois). Cette approche décentralisée des choix d’implémentation conduit naturellement à une interrogation : comment, dans ces conditions, garantir la consistance globale de l’architecture du système ?
Les méthodes agiles à proprement parler ne fournissent pas de solution clé en main dans ce domaine. C’est donc au travers du système de valeurs et des retours d’expérience que l’on cherchera à répondre à cette question.
blog.xebia.com xebee.xebia.inPage optimized by WP Minify WordPress Plugin
Complet
Twitter
