Au sommaire de notre brochure
Vous trouverez dans cette brochure des éléments clés sur l’agilité qui
témoignent de nos com...
édiTo
par Joseph Glorieux
Directeur Général
OCTO Technology
(Suisse)
Nous mettons notre expertise
Agile à votre dispositio...
Un changement clé pour la transformation
digitale
La transformation agile est aujourd’hui un facteur essentiel de réussite...
Mon projet est-il
vraiment AGILE ?
publié sur
Que la réponse soit «Bien-sûr !» ou «Honnêtement, je n’en sais rien.»,
se po...
Rituels Agiles
Stand up
Point quotidien de l’équipe.
k Un standup quotidien est réalisé à heure
fixe
k Les interventions a...
Management visuel partagé
La salle projet reflète l’état du projet
k L’équipe utilise un support visuel pour
organiser les...
Et du coup, il est agile mon projet ?
Avoir un outil à sa disposition n’est que
le premier pas ! Il faut encore l’adapter ...
Accéder à cet article en ligne ...
http://goo.gl/4v3uth
DevOps
le mouvement qui tend à
«Agilifier» votre DSI
publié sur
La communauté « DevOps » nous
invite à repenser la frontiè...
> Standardisation enfin car la production
veut s’assurer que certaines règles (sécu-
rité réseaux, configuration des fichi...
Améliorer la collaboration
Atteindre cet objectif ne se fera pas sans
douleur et trouve des leviers d’amélioration
dans 4 ...
Lean Startup
(des Patterns des géants du
Web)
publié sur
La création d’un produit est très sou-
vent vouée à l’échec. Ains...
Expérimenter pour Valider
Une partie de
l’approche se base
sur le Minimum Viable
Product. Quel est
l’ensemble minimal
de f...
Ils mettent évidemment au préalable en
place les outils et processus de récolte de
cette donnée.
Les plus utilisées sont b...
Et chez vous ?
Le Lean Startup n’est pas dogmatique.
C’est avant tout prendre conscience que le
marché et le client ne son...
Déployer l’agile à large
échelle
c’est jouer sur les
frontières de l’entreprise
publié en février 2014 dans l’ (suisse)
Pa...
. Frontière étude vs métier
Développer un logiciel avec une équipe
agile sans le métier revient à construire un pro-
duit...
La scalabilité horizontale ou comment dépasser les
frontières d’un seul projet
Si réaliser les étapes précédentes sur un
p...
. Les processus
Quand on parle de processus autour de la
gestion et du pilotage des projets, on les pré-
sente généraleme...
La mise en place d’une gestion de por-
tefeuille avec un processus en flux de type
« Kanban » peut permettre d’avoir une a...
. Le product management
Les changements à opérer sur la dimen-
sion du produit ont déjà été explicités lorsque
nous avons...
J’y vais demain : 7 conseils
pour entamer une
transformation agile
publié en février 2014 dans l’ (suisse)
Les chantiers à...
) Créer une équipe dédiée au changement appuyée par le
top management
La transformation doit être portée par une
équipe i...
) Procéder étape par étape et mesurer !
Les géants du web sont obsédés par la
mesure au point que l’introduction de chan-...
Les événements
OCTO technology à Genève
UN VOYAGE VERS L’ENTREPRISE AGILE
Petit-déjeuner du mercredi  décembre 
à Gen...
En répondant à ces questions, OCTO vous
propose un voyage vers l’entreprise agile. Il
n’est pas question ici de XP, Scrum,...
Dans un projet traditionnel (en cascade),
son activité gravite naturellement autour de
la rédaction des spécifications fon...
Dans un contexte de faible croissance où
la qualité n’est pas un sujet négociable et où
seules les entreprises capables d’...
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
Prochain SlideShare
Chargement dans…5
×

Brochure Vers l'entreprise Agile

1 116 vues

Publié le

Fervents partisans des méthodes agiles depuis 2006, nous croyons fermement, chez OCTO Technology, à la nécessité d’adapter nos méthodes de développement informatique à cette méthodologie.

L’agilité n’est plus aujourd’hui l’appanage de quelques startups ou entreprises de la Silicon Valley, c’est une transition nécessaire à la survie sur le long terme des départements informatiques.

Nous vous faisons parvenir aujourd’hui dans cette brochure une compilation de quelques-uns de nos articles sur ce sujet pour vous présenter notre expérience et vous confirmer notre volonté de vous accompagner dans cette transition.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 116
Sur SlideShare
0
Issues des intégrations
0
Intégrations
29
Actions
Partages
0
Téléchargements
40
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Brochure Vers l'entreprise Agile

  1. 1. Au sommaire de notre brochure Vous trouverez dans cette brochure des éléments clés sur l’agilité qui témoignent de nos compétences sur le sujet. page > L’édito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 > Mon projet est-il vraiment AGILE ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > DevOps - le mouvement qui tend à «Agilifier» votre DSI . . . . . . . 9 > Lean Startup (des Patterns des géants du Web) . . . . . . . . . . . . . . . 12 > Déployer l’agile à large échelle, c’est jouer sur les frontières de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 > 7 conseils pour entamer une transformation agile . . . . . . . . . . . . .22 > Les événements OCTO Technology à Genève . . . . . . . . . . . . . . . . 25
  2. 2. édiTo par Joseph Glorieux Directeur Général OCTO Technology (Suisse) Nous mettons notre expertise Agile à votre disposition pour vous accompagner dans votre transition Fervents partisans des méthodes agiles depuis 2006, nous croyons ferme- ment, chez OCTO Technology, à la nécessité d’adapter nos méthodes de déve- loppement informatique à cette méthodologie. L’agilité n’est plus aujourd’hui l’appanage de quelques startups ou entreprises de la Silicon Valley, c’est une transition nécessaire à la survie sur le long terme des départements informatiques. Nous vous faisons parvenir aujourd’hui dans cette brochue une compilation de quelques-uns de nos articles sur ce sujet pour vous présenter notre expérience et vous confirmer notre volonté de vous acccompagner dans cette transition. L’agilité en profondeur Tout d’abord, être agile, c’est quoi ? Le fait est qu’il ne suffit pas de travailler par itérations de quelques semaines ou de discuter tous les matins en restant debout pour adresser les difficultés fon- damentales des développements informatiques. Au contraire, adopter l’Agilité c’est embrasser le changement à la racine de son savoir faire technique. Les chan- gements sont nombreux mais les plus essentiels sont en définitive assez simples à appréhender : Tout d’abord, il n’est pas possible de pleinement déployer l’Agilité sur un pro- jet, moins encore d’en ressentir les bénéfices, sans une adoption à large échelle des principes XP. Dans le détail, une usine logicielle, des tests automatisés, la qualité du code sans compromis (refactoring, règle des 4 yeux, etc.) ainsi que l’intégration automatisée et continue, idéalement jusqu’en pré-production, sont indispensables. La nature des relations avec le commanditaire, le métier et ses représentants ainsi que leur implication dans le cycle de développement du logiciel doit évo- luer. Il n’y a plus de place pour une relation formelle mandataire - mandaté. Au contraire, le métier et l’IT doivent travailler main dans la main. L’IT se met à nu devant le métier, se montre honnête et transparente. Le métier quant à lui doit réaliser qu’il doit s’impliquer profondément dans le développement du logiciel. Chaque heure investie à l’échelle du quotidien avec l’équipe projet par un repré- sentant du métier permettra d’économiser des jours de tests d’acceptance, de reproduction de bug ou encore perdus à cause de l’indisponibilité du système ou simplement de son mauvais fonctionnement. Page 2 / 30
  3. 3. Un changement clé pour la transformation digitale La transformation agile est aujourd’hui un facteur essentiel de réussite à la transformation digitale de l’entreprise. En effet, si le modèle et la position de l’informatique dans l’entreprise et dans la société en général n’a pas beaucoup évolué pendant ces vingt dernières an- nées, nous sommes aujourd’hui à l’aube d’une véritable révolution : la révolution digitale. Les entreprises pour lesquelles l’informatique ne vas pas devenir le premier vecteur d’innovation et la pierre angulaire de leur modèle d’affaire au cours des dix prochaines années existent, bien sûr, mais elles sont très peu nombreuses. Or la transformation digitale des entreprises repose sur quelques prérequis qu’il est impossible de court-circuiter. La transformation agile du département informatique en fait bien évidemment partie, ainsi que l’adoption des principes DevOps et Lean Startup. Nos atouts pour vous accompagner En Suisse, l’accompagnement des entreprises sur le thème de la transforma- tion agile représente près de 30% de notre chiffre d’affaire. Nous travaillons sur ce sujet pour tout type d’entreprise, des startups aux multi-nationales. Nous nous réjouissons de vous rencontrer au prochain événement que nous organisons sur ce sujet. Page 3 / 30
  4. 4. Mon projet est-il vraiment AGILE ? publié sur Que la réponse soit «Bien-sûr !» ou «Honnêtement, je n’en sais rien.», se poser cette question est un excellent exercice ! Une équipe qui a choisi l’Agile a toujours la possibilité d’apprendre et de s’améliorer quel que soit son niveau de maturité : comprendre comment un bug a pu perdurer jusqu’à la démonstration client, réussir ses rétrospectives d’itérations et en mesurer le bénéfice, etc. Les sujets peuvent être nombreux et leur résolution d’autant plus satisfaisante ! En cherchant à améliorer certains rituels agiles sur des projets de deli- very mobile, nous sommes parvenus à compiler toutes les pratiques et outils indispensables à nos projets Scrum. Nous en avons fait un document de me- sure et de suivi sur nos missions et nous souhaitons les partager ci-dessous : notre checklist d’un projet agile. Pourquoi mesurer l’agilité sur mon projet ? Il s’agit d’une démarche d’amélioration continue. Au-delà de savoir si nos projets étaient agiles, notre volonté était d’améliorer nos pra- tiques. Et pour améliorer, il faut mesurer. D’où l’idée de lister les points de méthodes appli- quables concrètement dans nos missions. La réalisation de ce travail nous a permis de partager nos expériences, nos outils et de les condenser sous une forme accessible et utilisable par tous. Le résultat est un ensemble de points qu’il est possible d’utiliser pour for- mer de nouveaux intervenants sur un projet agile, partager la connaissance et enfin s’amé- liorer en continu ! Si beaucoup de rituels agiles issus de Scrum nous semblaient indispensables, d’autres outils venus notamment du Lean nous sont apparus tout aussi pertinents. Nous les avons donc incorporés et pensons qu’ils peuvent être complétés par d’autres. Une checklist pour mon projet ! Et ça marche ? Après 4 mois d’utilisation de notre ques- tionnaire, nous sommes parvenus à réduire certaines douleurs que nous observions de manière systématique dans nos missions. Notre vision de la façon d’utiliser l’Agile a été renforcée et chacun est plus à même d’ac- compagner une équipe, mais également un client pour que son projet réussisse au mieux ! Copiez les deux pages suivantes et servez-vous en comme checklist pour vos prochaines rétrospectives → Page 4 / 30
  5. 5. Rituels Agiles Stand up Point quotidien de l’équipe. k Un standup quotidien est réalisé à heure fixe k Les interventions aux standup sont limi- tées à 1 minute par personne (la réunion reste courte) k Chaque participant s’adresse aux autres membres de l’équipe (et pas à un leader unique) Rétrospective d’itération Retour sur l’itération, sur le process, les rela- tions etc. dans une démarche d’amélioration continue k Avant le démarrage d’une itération, une rétrospective est réalisée sur l’itération précédente k En début de rétrospective, les actions décidées à la dernière rétrospective sont revues k Toute l’équipe de développement, le delivery manager et le PO sont présents à la rétrospective k Chacun arrive à exprimer des points dif- ficiles du projet k Des solutions concrêtes sont trouvées pour résoudre les points difficiles et des acteurs sont identifiés pour les mettre en oeuvre k La rétrospective a un facilitateur désigné qui l’anime. Le facilitateur ne contribue pas au contenu Démonstration de fin d’itération k En fin d’itération, une démonstration du produit est présentée au Product Owner (PO) k Les démonstrations sont préparées à l’avance (vérification préalable de cha- cune des stories) Bilan de fin d’itération Retour du client sur chaque story dévelop- pée k Lors du bilan, le PO valide/invalide cha- cune des stories développées k Lors du bilan, les métriques du projet (vélocité, avancement, etc.) sont présen- tées Planning game (planification de l’itéra- tion) Planning game : choix, priorisation et esti- mation en complexité des stories k Le PO sélectionne les stories à estimer pour l’itération et les présente à l’équipe k Le PO associe des tests de validation à chacune des stories k Un planning poker est réalisé avec toute l’équipe pour estimer les stories k Le nombre de stories à développer par itération est choisi en fonction de la vé- locité de l’équipe (somme des points de complexité validés dans l’itération pré- cédente) k A la fin du planning game, les stories sont priorisées Méthodologie Tenue de backlog Planification des itérations k L’équipe de développement et le PO partagent le même document listant les fonctionnalités de l’application (Backlog) k Les fonctionnalités à développer sont ré- digées sous la forme de User stories (ex : « en tant que ..., je peux ...») k Les fonctionnalités sont rattachées à la StoryMap du projet s’il y en a une k A partir du Backlog, on peut retrouver les tests de recette associés à chaque story Page 5 / 30
  6. 6. Management visuel partagé La salle projet reflète l’état du projet k L’équipe utilise un support visuel pour organiser les stories (Kanban board) k Les différentes colonnes du Kanban sont clairement séparées et une « Defini- tion Of Done » (DOD) est définie pour chaque colonne k Les DOD sont respectées par chaque membre de l’équipe k L’équipe utilise un bac rouge pour ré- férencer et traiter les problèmes liés au projet k Le bac rouge est traité régulièrement (application par exemple de la méthode « 5 pourquoi ») k Les informations complémentaires im- portantes du projet (prochaines dates de release, contenu de ces releases, burn- down chart, planning d’itération, tro- phées, etc.) sont affichées k Chaque itération a un objectif qui est af- fiché (au dessus du Kanban) Bonnes pratiques Développement organisé L’équipe organise son travail k Les stories sont développées dans l’ordre de priorité défini par le PO en planning game Industrialisation des développements Les processus de développement/livraison sont industrialisés k Le projet utilise une Usine De Dévelop- pement (UDD) pour l’intégration conti- nue (build, lancement des tests, vérifica- tion qualité) k La livraison au client est réalisée grâce à l’UDD k La livraison est réalisée en suivant une checklist Méthodes de développement L’équipe utilise des pratiques permettant de s’améliorer k L’équipe réalise les stories les plus diffi- ciles en Pair Programming k Tout code est validé par un autre membre de l’équipe (correction, aligne- ment des pratiques) k Les fonctionnalités de l’application sont testées unitairement et automatique- ment k L’équipe développe en Test Driven De- velopment (TDD) k Le projet possède un document avec ses normes (page wiki, feuille au mur, fichier readme, autre), de préférence de ma- nière visuelle Communication Vie de l’équipe et relation client Comment se sentent les membres de l’équipe k L’équipe s’améliore de façon continue k L’équipe a la confiance du client k La communication dans l’équipe et avec le client est facile / bonne k L’équipe favorise la colocalisation (tous les acteurs du projet sont colocalisés) Page 6 / 30
  7. 7. Et du coup, il est agile mon projet ? Avoir un outil à sa disposition n’est que le premier pas ! Il faut encore l’adapter à son contexte, que son équipe l’accepte et enfin savoir analyser ses résultats ! Adapter ses outils à son besoin Certains des points présentés ne corres- pondent certainement pas à tous les pro- jets et d’autres peuvent manquer. Un conseil que nous pourrions donner avant d’ajouter (ou retirer) un élément de la liste est de s’as- surer que cet élément fait l’unanimité dans l’équipe. N’hésitez pas à y ajouter vos stan- dards (meilleures pratiques observables sur vos missions). Une bonne communication et une formulation pédagogique des questions sont également nécessaires pour maximiser l’adhésion de chaque participant. Visualiser et analyser ses résul- tats Mesurer régulièrement sa pratique agile permet d’en suivre l’évolution et d’analyser ra- pidement les bienfaits d’une pratique. Vérifier la checklist par exemple tous les mois permet de mettre en évidence les résul- tats des actions d’amélioration entrepris par un groupe. Un(e) responsable pourra être choisi(e) pour analyser les réponses des participants du projet. De plus, il est intéressant que ce question- naire soit rempli par chaque membre l’équipe afin d’obtenir le point de vue de chacun. Cela fera éventuellement apparaître des divergences d’opinion qui pourront valoir la peine d’être discutées pour améliorer la vision commune dans le groupe. Afin de mieux visualiser les résultats et de les comparer dans le temps, nous avons créé un excel qui convertit notre Google Form en tableau récapitulatif et qui simplifie grande- ment notre analyse (voir tableau en page 8) Echanger avec son équipe Enfin, une fois l’analyse effectuée, se réunir régulièrement permet de présenter les résultats. C’est l’occasion d’échanger, de comprendre les difficultés de chacun et de choisir des points que l’on souhaite amélio- rer ou suivre avec une attention particulière. C’est aussi à ce moment que l’on peut choisir d’ajouter une nouvelle pratique observée ou encore d’arrêter d’utiliser la checklist (« On est trop forts ! »). Un dernier conseil pour que cette check list reste une pratique efficace : ne pas l’impo- ser comme outil d’évaluation de performance mais plutôt la proposer comme base de ré- flexion à des équipes motivées par l’amélio- ration de leur quotidien. Page 7 / 30
  8. 8. Accéder à cet article en ligne ... http://goo.gl/4v3uth
  9. 9. DevOps le mouvement qui tend à «Agilifier» votre DSI publié sur La communauté « DevOps » nous invite à repenser la frontière classique de nos organisation, séparant : > d’un côté les études, i.e. ceux qui écrivent le code (le «Build») et > de l’autre côté la production, i.e. ceux qui déploient et exploitent ces applications (le «Run»). Pourquoi DevOps ? Deux groupes se retrouvent dans le mou- vement DevOps et apportent un peu de frai- cheur dans ces réflexions aussi anciennes que les DSIs : > Les agilistes qui ont levé la «contrainte» côté développement et sont maintenant capable de «livrer» beaucoup plus sou- vent du logiciel valorisé par le client... mais regrettent que «la prod ne suive pas» > Des experts ou des managers de la «prod» des géants du web (Amazon, Facebook, LinkedIn, etc.) partageant leurs retours d’expérience sur leur façon d’envisager cette frontière Au delà des fractures organisationnelles, les préoccupations des études et de la pro- duction sont bien distinctes et respectivement louables. Les études recherchent plus de réacti- vité (sous la pression du métier et du mar- ché notamment) : il faut aller vite, ajouter de nouvelles fonctionnalités, réadapter les di- rections, refactorer, upgrader les frameworks, déployer rapidement pour tester. La nature même du code («Soft») est celle-ci : maléable, adaptable. A l’inverse, la production a besoin de sta- bilité et de standardisation. > Stabilité car il est souvent difficile d’anti- ciper quels impacts auront telles modifi- cations de l’infrastructure : un disque lo- cal qui devient un disque réseau mais im- pacte les temps de réponses, ou encore un changement de code qui impacte for- tement la consommation CPU et par la même le «capacity planning». Page 9 / 30
  10. 10. > Standardisation enfin car la production veut s’assurer que certaines règles (sécu- rité réseaux, configuration des fichiers de logs, etc.) sont uniformément respectées. Un objectif commun Malgré ces contraintes divergentes, ces deux groupes ont un objectif commun : faire fonctionner le système. Finalement, le dé- ploiement n’est pas le plus important dans cette problématique même si c’est certaine- ment une des activités les plus consomma- trices en ressource : la moitié du temps de la production est ainsi consommée par le dé- ploiement ou des problèmes liés au déploie- ment. C’est donc certainement le premier levier d’amélioration mais non l’unique. Damon Ed- wards et John Allspaw nous rappellent : > qu’il s’agit de partager des métriques et d’être capable de transformer des variables techniques (augmentation des temps de réponse, etc.) en variables bu- siness (baisse du CA généré, etc.). Et qu’une des clés du succès d’interprétation de ces métriques est la collaboration entre les études (la compréhension du code) et la production (la compréhension des ser- veurs, du réseau, etc.) > «qu’agilifier» le processus de développe- ment c’est bien mais que le véritable en- jeu c’est l’agilité « business » qui passe par la réduction du délai global «from concept to cash», de l’idée à la mise au produc- tion. Cela passera entre autres par des dé- ploiements plus «agiles», sur l’exemple de Flickr, qui réalise 10 déploiements quoti- diens Page 10 / 30
  11. 11. Améliorer la collaboration Atteindre cet objectif ne se fera pas sans douleur et trouve des leviers d’amélioration dans 4 axes : > de l’outillage qui permettra d’industriali- ser l’infrastructure et de rassurer la pro- duction sur la façon dont cette infrastruc- ture est utilisée par les études. C’est un des gènes du cloud : le self service. Les offres de cloud public sont matures sur le sujet mais certaines offres (VMWare par exemple) visent à reproduire ces modes de fonctionnement en interne. Mais sans forcément aller à ces niveaux de maturité, nous pouvons considérer l’utilisation d’ou- tils type Puppet, Chef ou CFEngine. > de l’architecture qui peut permettre de décorréler les cycles de déploiements, de déployer du code sans pour autant mettre la fonctionnalité à disposition des utilisa- teurs. > de l’organisationnel qui vous amènera peut-être, vous aussi, à implémenter les patterns d’Amazon «two pizzas team» et «you build it, you run it» > du processus qui permettra de fluidi- fier tous ces échanges. Comment dé- ployer plus souvent ? Comment limiter ses risques en déployant progressivement ? Comment appliquer les leçons de « flux » tirées de Kanban à la production ? Com- ment repenser les mécanismes de com- munication et de coordination à l’œuvre sur la frontière études/production ? En définitive ces 4 axes nous permettront d’atteindre les objectifs supérieurs de De- vOps : améliorer la collaboration, la confiance et l’alignement d’objectifs entre les études et la production. Accéder à cet article en ligne ... http://goo.gl/QwusM2 "DevOps, de l’intégration continue au déploiement continu" http://goo.gl/Ot1NtT
  12. 12. Lean Startup (des Patterns des géants du Web) publié sur La création d’un produit est très sou- vent vouée à l’échec. Ainsi, les chiffres montrent que 95% des produits ou startups meurent par manque de clients. Le Lean Startup est une approche de création produit qui se propose de réduire les risques d’échec en attaquant parallèle- ment les aspects organisationnels, business et techniques et cela avec des itérations agressives. Formalisée par Eric Ries, elle est fortement inspirée du Customer Develop- ment de Steve Blank.. Les principes Lean Startup Build – Mesure – Learn Tout produit ou fonctionnalité part d’une hypothèse. Cette hypothèse peut être issue de données récoltées sur le terrain ou d’une simple intuition. Toujours est-il que l’approche que prône le Lean Startup est : 1. De considérer toute idée comme hypo- thèse, qu’elle soit marketing ou fonc- tionnelle, 2. De valider toute hypothèse le plus vite possible sur le terrain. Ce dernier point est l’un des éléments centraux du Lean Startup. Chaque hypothèse − business, organisationnelle ou technique − doit être validée qualitativement et vérifiée quantitativement. Cette démarche permet de mettre en place une boucle d’apprentissage sur le produit et le client. Le Lean Startup com- bat donc l’approche qui consiste à construire un produit pendant un an et se rendre compte tardivement que des choix (marketing, fonc- tionnel, commercial) mettent l’organisation en danger. Il faut tester tout de suite et au plus vite. Page 12 / 30
  13. 13. Expérimenter pour Valider Une partie de l’approche se base sur le Minimum Viable Product. Quel est l’ensemble minimal de fonctionnalités que je dois construire pour valider mes hypothèses ? On ne parle pas ici nécessairement de code et de produit au sens technique du terme, mais de n’importe quel effort qui va permettre d’avancer sur ces hypothèses. Cela peut être un questionnaire Google Docs, une mailing list ou une fausse fonction- nalité pour tester l’appétence du marché. L’expérimentation et les leçons associées sont un actif inestimable pour le pilotage du produit et justifient la mise en place de la boucle d’apprentissage. L’obsession de la mesure On imagine donc bien que ces expé- rimentations doivent systématiquement être suivies par une mesure fiable et complète. Une approche centrée client – Go out of the building Vérifier qualitativement et valider quanti- tativement signifie bien souvent « sortir de l’immeuble », comme dirait Bob Dorf, co- auteur du fameux 4 Steps to the Epiphany. «Go out of the building» (GOOB) est au centre des préoccupations des Product Ma- nagers pratiquant le Lean Startup. Tant que les hypothèses ne sont pas confrontées à la réalité, elles restent des suppositions. Et donc des risques potentiels pour l’organisation. «No plan resist first contact with custo- mers» (Steve Blank) est ainsi l’une des devises des équipes produit : > Construire le minimum nécessaire à vali- der une hypothèse ; > GOOB (de l’interview en face à face au dé- ploiement continu) ; > Apprendre ; > Construire et ainsi de suite. Cette approche permet ainsi de rester constamment au contact du client, et donc de valider les hypothèses business (les dol- lars). Zappos, géant US de la chaussure sur le Web, est un exemple de MVP mis entre les mains des utilisateurs réels très tôt. Pour se confronter à la réalité et valider que les uti- lisateurs seraient prêts à acheter des chaus- sures en ligne, le futur CEO de Zappos photo- graphia les chaussures des magasins locaux, créant l’inventaire d’un site e-commerce de toute pièce. Ce faisant, et sans construire une cathédrale, il valida très tôt que la demande existait et que la construction d’un tel produit pouvait s’avérer gagnante. Le pilotage par la donnée Evidemment, pour apprendre du compor- tement des utilisateurs lors de ces sessions de GOOB, les Product Managers récoltent méti- culeusement de la donnée qui leur permet de prendre les décisions adéquates. Page 13 / 30
  14. 14. Ils mettent évidemment au préalable en place les outils et processus de récolte de cette donnée. Les plus utilisées sont bien connues de tous. Il s’agit d’interviews et des solutions d’analytics. Ce que le Lean Startup prône est une uti- lisation féroce de ces indicateurs pour réelle- ment piloter la stratégie produit. Sur ChooseYourBoss.com, nous avons fait comme hypothèse que les utilisateurs utilise- raient LinkedIn ou Viadeo pour se connecter, afin de leur éviter de se créer un compte et pour nous éviter de développer un système d’inscription. Nous avons donc construit le minimum pour invalider ou valider l’hypothèse : une page qui comportait les trois options, à savoir l’inscrip- tion via Linkedin, celle par Viadeo et celle par un compte ChooseYourBoss. Les deux premières fonctionnaient réelle- ment, le compte ChooseYourBoss indiquait que le compte ChooseYourBoss n’était pas encore disponible en production. Résultats : les utilisateurs ne voulant pas utiliser ces réseaux pour se connecter repré- sentent 11% de nos visiteurs. Nous n’implé- menterons donc pas dans l’immédiat la créa- tion de compte sans réseau. Nous sommes passés du « informés par la donnée » au « pi- lotés par la donnée ». Chez qui ça fonctionne ? Strator, Viadeo, Spotify, Couldwatt, Zap- pos et bien d’autres sont autant de socié- tés ou produits Web qui ont réussi à intégrer les feedbacks utilisateurs au plus tôt dans la création de produit. Dropbox a, par exemple, changé complètement son fonctionnement en simplifiant drastiquement la gestion des dossiers synchronisés. Heroku est passé d’une plateforme de développement sur le cloud à une solution d’hébergement sur le cloud. Les exemples sont nombreux et plus ingénieux les uns que les autres ! Page 14 / 30
  15. 15. Et chez vous ? Le Lean Startup n’est pas dogmatique. C’est avant tout prendre conscience que le marché et le client ne sont pas dans les réunions d’architecture, les plans marketing, les projections de ventes ou les fonctionnali- tés clés. Une fois ce constat fait, vous verrez des hy- pothèses partout. Tout consiste à mettre en place une discipline de validation des hypo- thèses en gardant pour principe de valider le minimum de fonctionnalités à un instant "t". Avant de faire la moindre ligne de code, les principales questions à se poser tournent autour du triplet Client / Problème / Solution : > Ai-je réellement un problème qui vaut la peine d’être résolu ? > Ma solution est-elle la bonne pour mon client ? > Est-il susceptible de l’acheter ? A com- bien ? Tous les moyens sont bons pour lever ces hypothèses : interviews, études de marché, maquettes, etc. La seconde étape consiste à savoir si le modèle que j’ai pu tester à moindre échelle est répétable et extensible. Comment mettre entre les mains des clients un produit dont ils n’ont jamais entendu parler ? Vont-ils com- prendre, utiliser et tirer des bénéfices de mon produit ? Les troisième et quatrième étapes tournent autour de la croissance : comment faire venir des clients et comment construire une société qui va pouvoir accueillir et faire grandir mon produit. Contrairement à ce que l’on pourrait pen- ser à la lecture de ce billet, le Lean Startup n’est pas une approche à réserver unique- ment à des sites Web grand public. Innover en validant le plus rapidement possible des hypothèses et en limitant l’investissement fi- nancier est évidemment une logique trans- posable à tout type de projet informatique, fût-il interne. Nous sommes convaincus que cette démarche mériterait d’être plus large- ment utilisée pour éviter les projets « Titanic » qui peuvent engouffrer des sommes considé- rables avec une très faible valeur perçue par l’utilisateur Pour plus d’information, vous pouvez consulter la session sur le Lean Startup lors de l’USI 2012 qui traite des deux premières étapes. Retrouver toutes les pratiques des Géants du Web sur le site dédié (www.geantsduweb.com) : pdf de l’ouvrage à télécharger, vidéo et compte-rendu de la pré- sentation « Décrypter les secrets des Géants du Web » Accéder à cet article en ligne ... http://goo.gl/v4Jakj "Youtube : USI 2012 Lean Startup" http://goo.gl/BKebya "Les géants du Web" www.geantsduweb.com
  16. 16. Déployer l’agile à large échelle c’est jouer sur les frontières de l’entreprise publié en février 2014 dans l’ (suisse) Passées les premières expérimentations des méthodes agiles au sein de l’entreprise avec un succès que l’on va qualifier de variable, d’aucuns se posent la question de comment aller plus loin, voire comment envisager une entreprise agile. Nous sommes convaincus que déployer l’Agile à large échelle, c’est jouer sur les frontières de l’entreprise et nous allons justifier cette position dans cet article. Tous les architectes techniques vous le diront, il existe deux types de scalabilité quand on parle de serveur : la scalabilité verticale (augmenter les capacités du serveur) et horizontale (distribuer sur plusieurs serveurs). Il peut être intéressant d’utiliser cette métaphore lorsque l’on parle de diffuser l’Agile plus largement. La scalabilité verticale ou comment dépasser les frontières au sein d’un projet Prenons le cas d’un projet où l’équipe de la DSI est en charge d’un développement en mode Agile. Cette équipe composée de 8 personnes fonctionne bien et se pose la ques- tion de comment aller plus loin. Les pratiques agiles supposent déjà d’améliorer l’environ- nement sur lequel on a la maîtrise et c’est une étape essentielle. Mais rapidement, on est confronté à d’autres frontières qui vont finalement limiter les avantages de l’Agile à un périmètre restreint, ici, l’équipe projet. Il est alors nécessaire de dépasser ces frontières pour aller plus loin. > la frontière entre les études informatiques et les gens du métier, > la frontière entre les études et la produc- tion informatique, > la frontière entre le métier et ses clients ou ses utilisateurs. Page 16 / 30
  17. 17. . Frontière étude vs métier Développer un logiciel avec une équipe agile sans le métier revient à construire un pro- duit de qualité en respectant un cycle en V en livrant juste plus fréquemment. Pour profiter réellement des promesses de l’Agile (qualité, adaptabilité et gestion du risque), la partici- pation du métier est indispensable. C’est en introduisant des rôles (le product owner), des pratiques agiles (les spécifications par les tests comme TDD) et en définissant clairement les droits et devoirs de chacun (« vous pou- vez changer les priorités de développements, mais nous sommes en budget contraint et donc certaines fonctionnalités devront sortir du périmètre») que la frontière peut être gom- mée. . Frontière étude vs production Ensuite, développer un logiciel avec une équipe agile intégrant le métier sans la pro- duction revient à livrer fréquemment en envi- ronnement d’acceptance. Le chemin est encore long vers un logi- ciel en production confronté à ses utilisateurs. C’est pourquoi l’envie de gommer cette fron- tière vient naturellement même s’il ne faut pas la prendre à la légère. En effet, nos organisations ont passé ces 20 dernières années à cloisonner ces deux mondes. Beaucoup des solutions permettant de redéfinir cette frontière se cachent der- rière le terme « DevOps », qui regroupe des pratiques touchant l’architecture, les outils, la méthodologie et l’organisation, visant à amé- liorer la collaboration entre les études et la production. DevOps repose sur 3 principes clés qui sont les garants d’une agilité allant jusqu’à la production : > l’infrastructure « as » code, > le « continuous delivery », > la culture de la collaboration. . Frontière métier vs clients ou utilisateurs Enfin, développer un logiciel avec une équipe agile intégrant le métier et la pro- duction revient à livrer un produit bien exé- cuté mais pas forcément le bon produit. La nuance se situe dans cette dernière frontière où la compréhension des hypothèses spéci- fiées par le métier peut être excellente tout en ne correspondant finalement pas aux attentes des utilisateurs. C’est dans certaines pratiques issues du milieu des startups («lean startup» notam- ment) qu’une diminution de cette frontière est possible. Ces approches s’échinent à décou- vrir simultanément les utilisateurs et le produit afin d’en assurer la convergence. Ainsi, sur la base d’hypothèses ou d’idées, on commence à construire le produit que l’on va confronter aux utilisateurs afin de se rassurer qualitati- vement et valider quantitativement les hypo- thèses dans des itérations courtes propices à l’apprentissage. Ceci posé, notre équipe projet peut dé- passer ses frontières en projetant l’agilité sur tout son cycle projet. Essayons à présent de transposer ces pratiques non pas à un projet mais à tous les projets de l’entreprise. Page 17 / 30
  18. 18. La scalabilité horizontale ou comment dépasser les frontières d’un seul projet Si réaliser les étapes précédentes sur un projet représente déjà un challenge, l’opérer jusqu’à la gestion du portefeuille de projet est bien plus complexe mais c’est le chemin à suivre vers une entreprise agile en capacité à accepter le changement et à s’améliorer en continu. Les frontières en question, cette fois- ci, sont celles présentes entre chaque équipe projet et entre les différentes strates de gou- vernance au-dessus de ces équipes. Gommer ces frontières va revenir à opérer simultané- ment sur toutes les constituantes de l’entre- prise. Nous proposons une lecture de ces mo- difications au travers des 5 piliers présentés ci-dessous. Instruire une transition agile dans une entreprise revient donc à travailler sur ces 5 piliers en introduisant petit à petit les concepts jugés les plus pertinents. Ces 5 piliers sont : > les pratiques d’ingénie- rie logicielle, > les processus, > l’organisation, > le « product manage- ment », > la culture d’entreprise. . Les pratiques d’ingénierie logi- cielle Ces pratiques ont déjà été évoquées lorsque nous avons parlé de « DevOps » ou BDD. Il y en a bien d’autres pour la plupart introduites via l’eXtreme Programming. Deux choses sont à retenir lorsque l’on parle d’agi- lité à large échelle. La première est que l’on a tout intérêt à diffuser les meilleures pratiques dans l’entreprise sans volonté de les imposer à tout prix. La deuxième est que certaines de ces pratiques sont obligatoires à moins de su- bir une montée en pression issue des chan- gements opérés dans les autres piliers (no- tamment l’accélération des cycles). Trois pra- tiques paraissent obligatoires : > les tests automatisés : sans les tests au- tomatisés, le temps pour réaliser les tests augmente d’incrément en incrément sans garantir la non-régression, > l’intégration continue : les probléma- tiques de « merge » notamment et d’in- tégration de toute sorte auront aussi ten- dance à nuire fortement à l’efficacité, > l’investissement sur l’homme : mettre tout en œuvre pour garantir l’expertise, la po- lyvalence et la curiosité de ses collabora- teurs. Page 18 / 30
  19. 19. . Les processus Quand on parle de processus autour de la gestion et du pilotage des projets, on les pré- sente généralement sur 3 niveaux, à savoir : > la gestion de projet, > la gestion de programme, > la gestion de portefeuille. Trois frameworks dits agiles (DAD, LeSS, SaFE) tentent aujourd’hui, à l’instar d’un PMI sur la gestion de projet en V, de fournir une description de ces processus. Aujourd’hui SaFE porte plus de promesses dès que l’on re- monte au niveau de la gestion de portefeuille. Qu’en est-il donc des processus dans ces 3 ni- veaux ? Coté gestion de projet, rien de très neuf, le processus décrit par SCRUM est aujourd’hui le plus couramment usité. On opère à la taille de la « user story » et on parle d’itération de 2 semaines. Cependant d’autres méthodes existent avec notamment « Kanban » issue du Lean qui est plus difficile à digérer au démar- rage mais plus à même de gérer une problé- matique de flux. Coté gestion de programme, le processus est opéré à partir de la «roadmap» qui se dé- cline en «release», on parle de fonctionnalités du programme et une «release» regroupe plu- sieurs itérations de multiples équipes. Les besoins de synchronisation sont évi- dents et sont adressés par la réunion des « product owner » de chaque équipe (assi- milable à du SCRUM de SCRUM) accompa- gnés d’un directeur de programme ou plutôt «product manager» et d’un super coordina- teur responsable du «release management». D’autres éléments de cohérence sont assurés à ce niveau via des rôles transversaux d’archi- tecte ou d’ergonome par exemple. Enfin coté gestion de portefeuille, il s’agit finalement d’apporter des approches agiles au niveau des décideurs. On opère sur un por- tefeuille de projets a minima annuel où l’on pilote les investissements. Page 19 / 30
  20. 20. La mise en place d’une gestion de por- tefeuille avec un processus en flux de type « Kanban » peut permettre d’avoir une ap- proche où l’on limite l’encours, et permet aussi une re-priorisation bimestrielle tout en restant dans un environnement contraint. Une méthode de cadrage agressive (maximum 2 mois) est un prérequis afin de pouvoir statuer rapidement sur l’instruction ou non des pro- grammes. Il ne semble finalement pas y avoir de révolution par rapport aux processus ac- tuels. Cependant 3 éléments sont notables. D’abord cela démontre la capacité à opérer à large échelle avec une approche agile. En- suite la réduction des temps de cycle est pré- sente à chaque étage ce qui est en vérité lourd d’impacts. Enfin, les changements qui peuvent paraître anodins sont amplifiés par leurs interactions avec les autres piliers. . L’organisation Les transformations potentielles à opérer côté organisation sont fortement liées au pos- tulat suivant : une équipe projet comprend de 5 à 12 collaborateurs. La sociologie a dé- montré qu’en dessous de 5 un groupe est trop dépendant des absences et qu’il manque de créativité. Au-delà de 12 personnes, les groupes ont tendance à se diviser et l’effica- cité chute brutalement. Si on respecte ce pos- tulat, la vraie question est d’identifier quelles sont les clés de découpage. La première idée est de regrouper les per- sonnes sous la forme de «component team» correspondant soit à un savoir-faire, soit à une strate d’architecture. Cette organisation at- teint ses limites lorsque les demandes métier touchent toutes les équipes de façon inégale tout en les noyant dans la synchronisation. Une deuxième idée, appelée «feature team», va au contraire regrouper toutes les compétences nécessaires pour adresser une fonctionnalité même si cela nécessite de tra- verser toutes les strates d’architecture. Les risques d’incohérences inhérentes à cette or- ganisation sont en partie adressés par des réunions de partage par spécialité appelées communauté de pratiques. C’est un mélange de ces deux modes d’organisation qui est observé dans les entre- prises agiles avec un ratio de 80/20 entre fea- ture et component team. Page 20 / 30
  21. 21. . Le product management Les changements à opérer sur la dimen- sion du produit ont déjà été explicités lorsque nous avons évoqué la première et la troisième frontière au début de cet article. Le vrai chan- gement de paradigme résultant de l’instruc- tion de ce pilier est le passage de la notion de projet vers la notion de produit (un pro- jet a une fin, un produit pas nécessairement). Cette transformation a bien sûr un impact di- rect sur l’organisation et sur nos 3 niveaux de processus. . La culture Si les 4 piliers précédents semblent com- plexes à faire évoluer, la culture reste le pilier le plus difficile à adresser. Une culture d’en- treprise est quelque chose qui s’est construite au fil du temps souvent à l’initiative des fon- dateurs de l’entreprise. Le changement de culture peut être à ce point traumatisant qu’il va potentiellement challenger les fondations même de l’entreprise. Illustrons cela au tra- vers de quelques traits culturels forts qui sont partagés par des entreprises que l’on va quali- fier d’avancées en terme d’agilité. Un premier trait se cache derrière le duo autonomie et responsabilité. C’est l’opposé des pratiques de type « command and control ». Ces en- treprises ont abandonné les rôles de supervi- seur pour donner plus d’autonomie et de res- ponsabilité aux opérateurs. L’autonomie et la responsabilité sont les qualités clés d’un sys- tème agile qui va au contraire péricliter dans un environnement de sur-contrôle, facteur de désengagement. Un autre trait de ces entre- prises est la notion de coopération, au sens où la coopération est quelque chose qui fait mal, que la coopération signifie dégrader sa performance individuelle au profit de la per- formance globale. Une conséquence pratique observée dans ces entreprises est la suppres- sion des objectifs ayant une portée locale et individuelle. Voilà un aperçu rapide du chemin à par- courir pour tendre vers une entreprise agile ayant intégré la dimension changement à son ADN. L’entreprise agile, en vérité, est un concept à redéfinir pour chaque organisation selon son secteur d’activité, sa stratégie et son ADN. Chaque entreprise se lançant dans cette quête aura donc tout loisir de positionner les piliers les uns par rapports aux autres à la re- cherche d’une agilité et d’un équilibre qui lui sera propre. Accéder à cet article en ligne ... http://goo.gl/L70s62 "Youtube : USI 2013 Agilité à grande échelle" http://goo.gl/7wWiL5
  22. 22. J’y vais demain : 7 conseils pour entamer une transformation agile publié en février 2014 dans l’ (suisse) Les chantiers à mener pour être agile à l’échelle de l’entreprise sont conséquents, sans commune mesure avec la relative sim- plicité à adpoter l’agilité à l’échelle d’un projet. Ils nécessitent une première mise en œuvre de l’agilité sur des projets pilotes et la compréhension des enjeux de ce chan- gement d’échelle. Il reste alors à savoir comment débuter votre transformation agile : nous vous pro- posons dans cet article sept conseils pour y parvenir. ) Établir un diagnostic Avant de se lancer dans cette transforma- tion, il est important d’être aligné sur la situa- tion de départ. C’est l’objectif d’un diagnostic formalisant à la fois les douleurs et les fiertés de l’entreprise. Le périmètre de cet état des lieux est centré sur l’IT mais il concerne aussi tous les acteurs en relation avec elle. Ce constat doit être établi de façon trans- verse et partagé avec l’ensemble des acteurs, dont le top management. ) Partager la motivation et l’urgence du changement Le changement fait peur et la transforma- tion va avoir un impact sur l’organisation, les processus mais également sur les postes, les évolutions de carrières et de compétences. Le diagnostic doit permettre de faire émerger la motivation première du change- ment (par exemple une incapacité de l’entre- prise à s’adapter aux évolutions de son mar- ché). L’alignement de l’ensemble des acteurs de l’entreprise sur l’urgence de la transforma- tion est fondamental pour se préparer et ré- sister aux fortes turbulences qui seront inévi- tablement engendrées. Page 22 / 30
  23. 23. ) Créer une équipe dédiée au changement appuyée par le top management La transformation doit être portée par une équipe impliquant les différentes directions de l’entreprise : informatique bien sûr, mais également les RH et les directions métiers. Il s’agit d’un projet pour toute l’entreprise, qui changera jusqu’à sa culture et nécessite un mandat venant de la direction qui en est le sponsor. Cet appui est primordial pour résister à la tentation du retour en arrière lorsque les équipes sont confrontées aux pertes de pro- ductivité transitoires qui surviennent lors de la mise en place de changements fondamen- taux. ) Adopter le changement par le bas et le porter par le haut L’évolution vers une entreprise agile re- quiert un changement au sein des équipes projets mais elle doit aussi concerner le ma- nagement et la gouvernance de l’entreprise. Ce changement, coordonné, doit être mené à ces deux niveaux conjointement afin que chacun comprenne les bénéfices, enjeux et contraintes de l’autre : > Au niveau décisionnaire, l’introduction de nouvelles méthodes et de nouveaux outils de pilotage du portefeuille projet (prio- risation, KPI, etc.) impactera les équipes projets. > Au niveau des équipes projets, l’adapta- tion permanente des pratiques et rituels agiles mis en place impactera la capacité à gouverner l’entreprise. Opérer le changement en le tirant unique- ment par le bas ou par le haut se fera au dé- triment de l’autre partie. ) Ne pas oublier les fondamentaux agiles Les pratiques et les outils issus de XP (tests automatisés, intégration continue, etc.) ont permis la mise en place avec succès des premiers projets pilotes : ils ne doivent pas être oubliés ni galvaudés lors de l’extension de l’agilité au reste de l’entreprise (lorsque l’attention sera portée sur d’autres priorités, que la pression augmentera ou que les turbu- lences liées au changement apparaîtront). L’humain doit être au centre de cette transformation. Les équipes doivent être com- posées de profils mutli-compétences dont la formation et le coût ne doivent pas être né- gligés. L’implication des RH est alors primor- diale. Page 23 / 30
  24. 24. ) Procéder étape par étape et mesurer ! Les géants du web sont obsédés par la mesure au point que l’introduction de chan- gement est conditionnée par la capacité à mesurer les résultats de ce changement. Au- delà de l’utilisation naturelle de la mesure pour améliorer un produit, cette démarche peut être mise en œuvre dans le cadre des changements méthodologiques et organisa- tionnels. Elle permet ainsi de : > s’aligner sur les résultats attendus d’un changement > mesurer l’impact (et la réussite) du chan- gement opéré Au final, il est possible d’opérer étape par étape, en vérifiant pour chacune d’entre elles que les résultats sont conformes aux attentes (une fois la phase transitoire passée). ) Commencer par accélérer ! Une fois les pré-requis en place (constat partagé, alignement sur l’urgence et sponso- ring), il reste à choisir les premiers change- ments à opérer. Un bon moyen de les mettre en évidence est d’augmenter le rythme des livraisons (pas- ser par exemple d’une livraison mensuelle à une livraison tous les quinze jours). Le stress imposé au processus en place laisse naturellement apparaître les points de frictions à adresser de façon prioritaire pour insuffler les premiers changements vers plus d’agilité. Accéder à cet article en ligne ... http://goo.gl/v4Jakj
  25. 25. Les événements OCTO technology à Genève UN VOYAGE VERS L’ENTREPRISE AGILE Petit-déjeuner du mercredi  décembre  à Genève Une fois passées vos premières expéri- mentations sur les méthodes agiles, une ques- tion doit forcément s’imposer à vous de façon récurrente : comment changer d’échelle ? Bien sûr, il ne s’agit pas de savoir comment lancer un énième projet agile mais plutôt de répondre aux questions suivantes : > Qu’est ce qu’une entreprise agile ? > L’entreprise agile chez moi, est-ce que cela fait sens ? Jusqu’où dois-je ou jus- qu’où puis-je aller sur le sujet ? > Comment opérer la gestion de porte- feuille de mes projets et réussir mes exer- cices budgétaires dans ce contexte ? > Comment entamer cette transformation ? Quels sont les écueils à éviter ? Page 25 / 30
  26. 26. En répondant à ces questions, OCTO vous propose un voyage vers l’entreprise agile. Il n’est pas question ici de XP, Scrum, Software craftsmanship, lean startup, TDD ou DevOps, mais bien de la manière de créer une alchi- mie réunissant ces ingrédients au travers de la gouvernance, l’organisation et la culture qu’elle soit managériale ou d’entreprise à tra- vers de quelques frameworks d’entreprise qui peuvent être utiles (par exemple SAFe). Découvrez un cadre de réflexion et les premiers éléments pour mener votre organi- sation vers ce que nous appelons l’entreprise apprenante (à défaut d’entreprise agile). "Slideshare - Vers l’entreprise agile" http://goo.gl/1VRqMI "OCTO-TV : Petit-déjeuner - Vers l’entreprise agile" http://goo.gl/jssyQZ LES BUSINESS ANALYSTS FACE A l’AGILITE : DE NOUVEAUX CHALLENGES A RELEVER Petit-déjeuner du mercredi  avril  à Genève Le business analyst (BA) joue un rôle crucial dans nos organisations. Lien essentiel entre les opérationnels et l’informatique, il identifie, analyse, valide et docu- mente les besoins métiers et participe à la mise en place de solutions. Page 26 / 30
  27. 27. Dans un projet traditionnel (en cascade), son activité gravite naturellement autour de la rédaction des spécifications fonctionnelles, réalisées typiquement en amont des dévelop- pements. Dans un contexte plus agile par contre, dans lequel les besoins peuvent être raffinés, repriorisés, réévalués, redéfinis continuelle- ment et dans lequel la notion même de spé- cification telle qu’on la connaît est remise en cause, comment continuer à valoriser les com- pétences du BA ? En abordant ces questions, c’est égale- ment le rôle des spécifications, de leur place au sein d’un projet agile et de leur lien étroit avec les tests que l’on clarifiera dans ce petit- déjeuner. Avec l’avènement de l’Agilité, le Busi- ness Analyst doit se renouveler. Découvrez les pistes qui lui permettront de travailler de ma- nière plus agile. "Slideshare - les Business Analysts face à l’Agilité : de nouveaux challenges à relever" http://goo.gl/ZnByT4 AGILE & TOP MANAGEMENT, UNE THERAPIE POUR LEUR PRINCIPAUX CHALLENGES ? Afterwork du Mercredi  juillet  à Genève Le CEO conference board a publié, comme chaque année, le podium des chal- lenges que les exécutifs européens pensent devoir adresser en 2014. Passée la surprise de ne pas trouver en tête les grands classiques tels que l’optimi- sation de la relation client ou la gestion des risques économiques et politiques, on se sur- prend à découvrir un podium ressemblant à s’y méprendre au portrait chinois d’une entre- prise agile : la qualité d’exécution, le manage- ment de l’innovation et le développement du capital humain. Page 27 / 30
  28. 28. Dans un contexte de faible croissance où la qualité n’est pas un sujet négociable et où seules les entreprises capables d’innover avec frugalité et rapidité sortent du lot, le capital humain semble revenir au centre des enjeux. Nous vous proposons une présentation des concepts et des pra- tiques les plus essentiels, qui, à notre avis, constituent le terreau de connaissances nécessaires de tout exécutif s’il souhaite se lan- cer sur la route de l’entreprise agile, ce qui, comme vous vous en doutez, nous paraît indispensable. "Slideshare - Vers Agilité et Top Management" http://goo.gl/VbKQag "Youtube : Challenges, Agile et top management" http://goo.gl/hEcfPJ

×