Cookies verzekeren het goed functionneren van onze website. Door gebruik te maken van deze site, gaat u akkoord met ons gebruik van cookies. Meer informatie OK
U bent hier: Home / Blog

Blog

« Het probleem van België »

Brussel

Op de Franse nationale feestdag of all days publiceert de Financial Times een meer dan boeiend artikel dat in een handig tabelletje netjes een overzicht geeft van de belangrijkste Europese landen en het aandeel van hun hoofdtstad of hun « hoofdstedelijk gewest » in het Bruto Nationaal Product.

Het Bruto Nationaal Product per inwoner is een goed, alhoewel niet volledige, graadmeter voor welvaartcreatie.

Geen verrassingen: Londen is absoluut koploper. De regio Londen is rijker dan alle andere deelgebieden. London beheerst de Britse economie op een ongezien niveau in vergelijking tot andere grote Europese landen. Het is goed voor maar liefst 1/5de van het Britse Bruto Nationaal Product.

Ter vergelijking : Berlijn staat in voor een « schamele » 5% van het Duitse BNP. De Franse, Zweedse, Spaanse, Italiaanse en Nederlandse hoofdsteden scoren stuk voor stuk veel matiger dan het Verenigd Koninkrijk.

Iemand benieuwd naar de Brusselse score?

Onze hoofdstad, correctie ons Brussels Hoofdstedelijk Gewest, staat op de tweede plaats (Eerlijkheidshalve dienen wij hieraan toe te voegen dat Luxemburg niet is opgenomen in de recentste cijfers van Eurostat) en komt meteen na Londen in de rangschikking. Na Londen is het Brussels Hoofdstedelijk Gewest dus de tweede rijkste regio van Europa (Luxemburg even buiten beschouwing gelaten). U leest het goed, niet Vlaanderen maar Brussel is onze rijkste regio in Bruto Nationaal Product.

Opgelet: het BNP houdt geen rekening met wie woont in de regio, maar wie er werkt en produceert. Dus is het effect van de pendelaars niet te onderschatten in dit soort studie. Met andere woorden wie in Oost- of West-Vlaanderen woont, maar in Brussel werkt, telt dus mee voor de de Brusselse rijkdom. Op zich vrij logisch natuurlijk.

Het Centrum voor Informatica voor het Brusselse Gewest is m.a.w. actief « there where it happens » en dat maakt onze job elke dag meteen een flink stuk boeiender. De meeste van deze « verrijkende » projecten binnen het Gewest staan nu ook netjes opgelijst op www.smartcity.brussels. Uw smart Brussels project verdient hier zeker een plaatsje. Neem dus gerust contact met ons op mocht dat nog niet het geval zijn.

Want, rijkdom creëren is één ding, smart zijn is eigenlijk nog veel beter...

Zou onze blog in Vlaanderen trouwens even enthousiast worden gelezen als in het Brusselse?

Lectures de vacances

Lectures de vacances

Il est des lectures à priori fort peu informatiques et pourtant il est significatif de voir à quel point la technologie peut s’immiscer dans la littérature, à fortiori quand celle-ci s’intéresse à la vie de gens comme vous et moi dans la première moitié du 21ème siècle.

C’est la réflexion qui me vient à la lecture de la trilogie de Virginie Despentes, Vernon Subutex (dont deux volumes sont actuellement parus). Outre une foule de personnages aussi paumés qu’attachants et la description de Paris vécue au plus près, les réseaux sociaux sont presque un personnage en soi, car ils permettent de connecter de façon littérale des personnages au départ dispersés. Comme Despentes le déclare dans une interview « Dans le premier tome, Facebook était une véritable machine fictionnelle, comme un outil dont le personnage principal et l’auteur se servent, l’un pour trouver un toit le soir, l’autre comme ressort dramatique. Le deuxième tome est un roman en forme de sociographe : la visualisation d’un réseau social. »

L’auteur, à m'instar de tous ceux qui sont dans la cinquantaine (et je m’inclus donc dedans), appartient à cette génération qui a connu l’avant internet, et a une conscience très aiguë de ce que cela a bouleversé dans nos comportements de tous les jours. D'autre part, nous sommes encore assez jeunes pour ne pas être tout à fait perdus dans l’emploi de la technologie et chacun cherche à sa manière à se l'approprier, que ce soit via la réanimation du passé (« Dites, vous vous souvenez de ça ? »), le partage du présent ou le forum politique - je n’en veux pour preuve que les discussions enflammées en cours sur la situation en Grèce - le tout avec le recul sans doute dû à l'âge (enfin ça, ça reste à prouver...) .

De la dématérialisation vers la rematérialisation ?

Vernon Subutex peut se lire comme un roman sur les victimes (en l’occurrence un disquaire et des musiciens) de la dématérialisation des supports mais aussi une tentative de recouvrer justement un peu de cette matérialité dans les rapports humains et de ressouder d’abord virtuellement et ensuite concrètement un groupe d’amis que la vie avait séparé. Il y a d’ailleurs un côté délicieusement utopique dans Vernon Subutex… On pourrait y voir un salutaire rééquilibrage consécutif à un temps qui nous a vu nous ruer à corps perdu dans les mondes virtuels !

Mais foin de toutes ces considérations, Vernon Subutex est un sacré bon roman, d'une acuité impressionnante et Despentes, au delà des étiquettes marketing "punk, rock, trash et porno" s'avère une écrivaine (je dirais même plus, une auteure) remarquable.

Sur ce, bon été et bonnes lectures, quelles qu’elles soient !

Vernon Subutex, Virginie Despentes, tomes 1 et 2, éditions Grasset.

P.S. Ce n’est pas un hasard si je lis ce livre sur une liseuse électronique, ce qui permet d’emmener l’équivalent de plusieurs rayons de bibliothèques avec un poids et encombrement minimum....pensez-y avant de boucler vos valises ! 

Se préparer aux Containers et aux Microservices

rouages


Avec la mise sur pied d'un service d'intégration et déploiement continus, le CIRB s'est doté d'une équipe orientée DevOps, qui lui donne les moyens de poursuivre son évolution en matière de qualité des livrables et de mise à l'échelle de l'infrastructure. L'utilisation de containers et le développement de microservices en est la suite logique.
 
Fin des années 90, notre Data Center était composé d'autant de serveurs physiques que d'applications déployées. Début 2000, nous introduisions la virtualisation des serveurs. Dans un premier temps, nous considérions qu'une machine virtuelle s'utilisait à l'identique d'une machine physique. Sur chaque machine virtuelle, nous installions l'application et toutes ses dépendances. Progressivement, les serveurs physiques ont été reliés en cluster et nous sommes passés à l'ère du premier cloud. Les machines virtuelles pouvaient se déplacer "toutes seules" d'un serveur physique à l'autre en fonction de la charge. Nous avons pu isoler les serveurs virtuels dans des réseaux devenus eux-mêmes virtuels, de sorte qu'aux alentours de 2010, notre offre de services s'est étendue : IaaS, Paas, SaaS. Chaque serveur virtuel réembarque un système d'exploitation : Linux, Windows, AIX, … et sa licence. Notre paradigme était l'isolation de chaque application et ses dépendances dans un OS complet sur son serveur.
 
Depuis plus de 4 ans, nous nous sommes lancés, au CIRB, dans la voie de l'intégration et du déploiement continus. Nous avons pu le faire grâce à ces choix judicieux posés au fil du temps en matière d'infrastructure et d'organisation. Cette automatisation nous permet de redéployer le même serveur virtuel à répétition, mais aussi de répartir l'application et ses dépendances sur plusieurs serveurs.
 
Pour accélérer les déploiements, dans une approche DevOps, nous souhaitons nous assurer que le même produit composé d'un ensemble de services soit promu à l'identique et déployé de la même manière sur les différents environnements. Voilà pourquoi depuis près d'un an, nous utilisons des containers. Un container peut être construit en superposant instantanément, par construction, plusieurs couches logicielles, sans donc devoir passer par une phase de "setup, next, next,…". Il démarre très rapidement (une, deux secondes) et consomme peu de ressources car au lieu d’instancier un nouveau serveur virtuel, il utilise le système d'exploitation sous-jacent, tout en étant isolé et en pouvant communiquer dans un réseau privé avec d'autres containers. Cette technologie est disponible sous Linux. Microsoft annonce sa disponibilité dans sa prochaine release d'OS Server et l'a déjà intégrée à Visual Studio et Azure. Le format des containers devient interchangeable sous l'égide de l'Open Container Project, dans lequel vous retrouvez tous les grands acteurs y compris Vmware, Microsoft, RedHat ou The Linux Fundation.
 
Légers et performants, les containers peuvent être déployés, mis à jour en quelques secondes sur le poste du développeur, dans nos fermes vCloud voire chez d'autres providers : Azure, S3, OVH…. On parle vraiment de mise à l'échelle automatisée de l'infrastructure en fonction de la charge. Cela était impensable avec de simples machines virtuelles.
 
L'apport des containers pousse inévitablement à un autre regard sur le développement et la gestion des configurations.  En scindant l'application non pas en web-services mais en micro-services, encore plus petits, autonomes entre eux, ceux-ci peuvent être reconstruits, arrêtés, redéployés en autant d'exemplaires que nécessaire, automatiquement au fil de l'eau selon la charge, sans interruption de service. La mise en œuvre des micro-services, de leur développement à leur déploiement pour délivrer des services, demande de nouvelles approches de programmation et une plus grande maturité des outils de déploiements que les projets monolithiques. Pour préparer cette étape, le service d’intégration et déploiement continus, en relation avec les équipes projets et opérationnelles, concentre une partie de ses efforts sur l’orchestration.

Envie de rejoindre l’équipe ? Le CIRB recrute ;-)

La vélocité d’une équipe

entente de groupe

Ce blogpost s'inspire du modèle retravaillé de Mitch Lacey (Mars 2012), The Scrum Field Guide : Practical Advice for your First Year,  ainsi que d'Anis Berejeb (juin 2009), Le cauchemar de l’estimation (www.berejeb.com).

Introduction

Une équipe de développement logiciels peut s'apparenter à un moyen de transport : avant d’opter pour l’un ou l’autre choix, il est nécessaire d'évaluer leur efficience.  Pour les moyens de transport, cela concernera l'économie de carburant, l'importance des distances à parcourir, la fréquence d’utilisation voire le nombre de moyens de transport à emprunter par trajet, etc. Pour les équipes de développement logiciels, nous parlerons d’efficacité quant à la quantité de travail qu’elles peuvent terminer sur une période donnée et déterminée à l’avance.

Cette mesure est appelée vélocité (ou vitesse de développement, rapidité de développement, etc.) et son unité est généralement le point de récits utilisateurs (demandes utilisateurs).

Pour faire simple, la vélocité constitue le nombre moyen de points de récits utilisateurs qu’une équipe de développement peut réaliser sur une période de temps déterminée ("course de développement"), telle que définie par l’équipe de développement logiciels dans le critère "réalisé", aussi appelé critère "terminé" (K.Schwaber et J.Sutherland, Le guide SCRUM, Juillet 2013, p.16; C. Aubry, La vélocité n’est pas une mesure de productivité, Novembre 2007, www.aubryconseil.com).

Un moyen de transport n’en est cependant pas un autre, à l'instar d’une équipe de développement logiciels. Il y a une difficulté supplémentaire et non des moindres : une équipe de développement logiciels n'est pas "emballée" ou "étiquetée" avec une estimation de vélocité comme pourrait l’être une voiture pour sa consommation de carburant, par exemple.

La question qui se pose : comment prédire dans une certaine mesure la future vélocité d’une équipe de développement logiciels ?

Bien que nous pourrions utiliser la vélocité d’une autre équipe pour nous donner un point de départ pour notre future vitesse de développement, nous ne pouvons dire qu’une équipe dans l’entreprise est en quelque sorte plus efficiente, efficace ou rapide car elle a une vélocité plus élevée qu’une autre équipe : chaque équipe estime en effet différemment, selon ses propres bases de connaissance, critères et acquis, l’arriéré du produit.
On en arrive à une conclusion rapide (et un peu trop facile) : prédire la vélocité est une tâche difficile, surtout si l’équipe est nouvellement constituée et/ou béotienne dans le cadre du travail SCRUM.

Le modèle de travail

L’équipe de développement logiciels doit fournir au propriétaire du produit une estimation de ce qu’elle peut accomplir sur la course au développement. Une équipe de développement logiciels n’ayant pas encore participé à un calcul de vélocité ou n'ayant pas encore été actif dans le cadre de travail SCRUM se trouve rapidement confrontée à trois possibilités : l’utilisation de données historiques, l’estimation à l’aveugle et l’utilisation de données réelles.

Pour quelles raisons les équipes de développement logiciels ont-elles très souvent tendance à éviter ou à éliminer l'option des données historiques ainsi que celle de l’estimation à l’aveugle ?

Le souci des données historiques

Le rejet de l’option des données historiques est principalement du au fait que l’équipe n’a pas préalablement travaillé ensemble (et plus particulièrement dans un cadre de travail SCRUM). Il lui semble donc irréaliste et impossible de se baser sur l’historique d’une autre équipe de développement logiciels.

Toute équipe diffère logiquement d'une autre. La multitude des facteurs de différenciation est trop importante et ne peut générer un résultat réaliste: pensons notamment à la nouveauté de l’équipe de développement logiciels, à sa composition, à l’environnement politique, à la taille et à la complexité du projet, sans parler du propriétaire du produit et des clients associés :

  • La nouveauté de l’équipe de développement logiciels affectera sa vélocité dans sa réflexion.
  • Le calcul de vélocité dépendra de la qualité de composition de l'équipe.
  • Celle-ci pourrait encore être attachée à certaines approches dites traditionnelles (tel le modèle en cascade, le modèle en V, etc. - Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).
  • L’environnement politique peut aussi constituer une variable importante pour le calcul de la vélocité. Au fil du temps, les entreprises évoluent, modifient leur structure, leur stratégie et leur direction. Le plan annuel ou stratégique d’une société est peut-être devenu obsolète, les responsables clés peuvent avoir changé de rôles, changé la dynamique de l’environnement. Parfois ces changements sont évidents, parfois il sont beaucoup plus subtils. Tenir compte des données historiques doit permettre de prendre en compte toutes ces informations, ce qui peut être difficile à réaliser.  
  • Taille et complexité du projet sont tout autant à prendre en considération. Les équipes de développement logiciels, qu’elles soient nouvelles ou établies, qui s'occupent d'un projet qui a une technologie différente ou qui change de complexité ne peuvent s’appuyer sur ces données historiques.
  • Enfin, le dernier facteur concerne le propriétaire du produit et le client. Alors qu’en théorie ceux-ci ne devraient pas être considérés comme des variables, ils en sont et non des moindres. La vélocité en est donc affectée; la relation développée ou naissante devra s’approfondir tout comme les nouveaux membres de l’équipe devront développer au fil du temps cette approche (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).

L’utilisation de données historiques doit tenir compte au minimum des facteurs détaillés ci-dessus. Le calcul de la vélocité d’une équipe établie vous donne une idée de départ, mais utiliser ces données en tant que vélocité estimée et réelle pour sa propre équipe peut se révéler lourd de conséquences et demande prudence.

Ouvrir les yeux sur l’estimation à l’aveugle

Dans l’éventualité où il est impératif de fournir une estimation type avant tout autre travail d’ensemble, l’estimation à l’aveugle est une possibilité à ne pas négliger. Pour ce faire, il est nécessaire de réaliser un travail d’arrière-plan préalable avant « prédication » de la vélocité de l’équipe de développement logiciels.
Quelques étapes-clés d’une estimation à l’aveugle sont à respecter :

  • l’estimation de l’arriéré du produit  (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7),
  • la décomposition d'un récit utilisateur de référence,
  • la détermination d'une approximation de point de réalisation par heure,
  • l'identification d'une capacité de base de l’équipe de développement logiciels,
  • l'estimation d'une vélocité théorique de l’équipe de développement logiciels,
  • la communication de cette dernière comme un éventail de travail évolutif (entendons : non-fixe).

D’autres facteurs peuvent entrer en compte selon l’appréciation de l’équipe même. Déterminer ces quelques chiffres permet de faire une supposition, qui n’est qu’une idée. Certains spécialistes diront : « Débarrassez-vous-en, ils sont artificiels, il s'agit juste d'une béquille pour vous aider à démarrer ».

Estimer l’arriéré du produit

La première étape dans cette technique qui peut servir de base de calcul primaire de la vélocité de l’équipe est d’estimer l’arriéré du produit (que nous pourrions comparer à un carnet de commandes).
Dans l’arriéré du produit, avec l’équipe de développement logiciels, il est nécessaire d’identifier un récit utilisateur type, que l’équipe de développement logiciels estime à deux points de développement (pour rappel : c’est l’équipe de développement logiciels qui estime les récits utilisateurs, une bonne pratique d’estimation est d’utiliser la suite mathématique logique de Fibonacci).

Dès ce récit utilisateur trouvé et dès son estimation, il est nécessaire de passer tout l’arriéré des récits utilisateurs (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7).
La technique d’estimation préférentielle utilisée par l’équipe est la planification par poker. Toutefois, toute autre technique d’évaluation déjà connue peut être utilisée. Il est cependant important de ne pas mélanger les différentes méthodes d’estimation.

Décomposer le récit utilisateur de référence

Lorsque l’arriéré du produit est estimé en points, il convient de réaliser une liaison entre le temps exprimé en heure et le récit utilisateur.
Cette liaison sera la deuxième échelle permettant de visualiser à long terme une planification et d'établir un calcul de la vélocité.
Pour ce faire, il est nécessaire de prendre un récit utilisateur de référence à deux points (il peut être identique ou non au récit utilisateur précédent). Dans ce récit utilisateur, la découpe en tâches est nécessaire.

Lorsque l’équipe de développement logiciels a identifié les tâches pour la réalisation du récit utilisateur de référence, il faut estimer le nombre d’heures de ces tâches. A nouveau, la planification par poker permet de parvenir à des estimations réalistes. Une différence est notable : le travail s’effectue sur des heures et non sur un nombre de points.
De nombreux spécialistes de la méthode d’évaluation dans le cadre de travail SCRUM plaident pour une limite de maximum 13 heures par tâche (certains s’entendent qu’une tâche est égale à une journée de travail - Claude Aubry, Ne plus mesurer les tâches d’un sprint en heures, Février 2007, www.aubryconseil.com). Si ce n’est pas possible, cette tâche sera elle-même découpée afin de ne pas dépasser ce nombre (ou la journée de travail). A nouveau, la suite mathématique logique de Fibonacci est utilisée. Elle sera limitée à 13 (1,2,3,5,8,13).

Cette découpe est un peu plus complexe que la découpe en points car l’équipe estimera son propre travail et non pas une valeur métier sur un nombre de points. Dès lors, si un membre de l’équipe estime que la tâche peut se réaliser en 4 heures, il ne pourra pas choisir ce nombre d’heures mais devra prendre soit 3 ou 5 heures. Cette suite permet donc de maintenir un niveau de précision correct sans l’être trop.

Approximation horaire

Lorsque toutes les heures pour chaque tâche comprise dans le récit utilisateur de référence sont additionnées, nous pouvons alors extrapoler que tout récit utilisateur de 2 points vaut ce nombre d’heures. Prenons l’exemple que le récit utilisateur de référence vaut 15 heures : nous pouvons estimer que tous les récits utilisateurs précédemment jugés à 2 points devront être terminé en 15 heures. Cette estimation grossière est aux fins de l’estimation à l’aveugle.
Dès cette estimation réalisée, nous pouvons calculer une évaluation globale et non fixe de l’ensemble du projet en heures. Si le projet comporte 240 points dans son arriéré produit, nous pouvons estimer que le projet demandera environs 1800 heures de travail. A nouveau, s’il s’agit d’une nouvelle équipe dans un cadre de travail nouveau, ces données seraient trop incertaines. Le rapprochement de points vers le nombre d’heures permet de donner une estimation initiale. A nouveau, il ne peut être utilisé comme cadre de référence ou comme valeur précise (mais ce travail est utile, si si, je vous l’assure ! Nous le verrons par la suite…) !

La capacité de l’équipe

Pour déterminer la capacité de l’équipe, il est au préalable nécessaire de déterminer la période sur laquelle portera la course au développement. Cette période ne peut dépasser un mois (K Schwaber et J. Sutherland, Le guide SCRUM, Juillet 2013, p.9). L’échelle de temps de cette période est l’heure (Claude Aubry, Mon enquête sur les estimations, Novembre 2013, www.aubryconseil.com).
Chaque membre de l’équipe de développement de logiciels donne le nombre d’heures qu’il tient à disposition par semaine pour contribuer au projet. Ce nombre ne compte pas les activités qui interfèrent avec le temps de projet dédié. Cette estimation de contribution au projet est rentrée sous 2 formes : le meilleur des cas (le plus haut rendement) et le pire des cas (le plus bas rendement).
Les estimations les plus pessimistes sont additionnées. Ilf aut ensuite multiplier le nombre obtenu par le nombre de semaines de la course de développement. Faites à l’identique pour le meilleur des rendements. Ces deux nombres sont représentatifs quant à la capacité de l’équipe : celle-ci fournira au minimum autant d’heures et au maximum autant d'heures.

Estimer la vélocité de l’équipe

Lorsque tous les facteurs sont connus, estimer la vélocité de l’équipe n’est plus qu’une affaire de mathématiques. Il sera nécessaire de déterminer une vitesse de développement en éventail (à savoir une vélocité élevée et faible, afin de garder une période de développement et non une valeur précise).
Cette dernière se calculera avec le nombre d’heures de l’équipe de développement logiciels dans le pire des cas (plus bas rendement), divisée par la nombre de points par heure : le résultat sera la vélocité estimée à petite vitesse. Ce sera identique pour la vélocité à grande vitesse en remplaçant le premier nombre.
Nous pouvons maintenant communiquer que notre vitesse de développement est comprise entre telle et telle capacité ; l’arriéré du produit pourra être absorbé entre tel et tel mois.

L’utilisation des données réelles

L’équipe de développement logiciels peut prévoir sa future vitesse moyenne de développement. Pour certains, il y a un gros avantage dans cette méthode, à savoir l’utilisation de leurs propres données sur le projet en cours ; pour d’autres, il y a un gros désavantage : l’incertitude sur le laps de temps de la période de collecte de données. Refléter le fait et non la fiction l’emporte bien souvent sur l’inconvénient. Pour rassurer les responsables d’équipes de développement logiciels, il est toutefois utile de fournir une prédiction basée sur les méthodes précédemment citées en mettent en évidence le fait que seules les données réelles pourront donner une vélocité plus précise.

Pour réaliser l’estimation à l’aveugle, il est nécessaire de disposer de données réelles d’au moins 3 courses au développement. Cette collecte d’informations se réalise sur plusieurs points : collecter et calculer la vitesse de développement sur au moins trois courses au développement, calculer la vitesse moyenne et communiquer celle-ci comme nouvelle estimation, coordonner la capacité de l’équipe sur l’arriéré du produit.

Collecter les données réelles

La collecte de données de l’équipe de développement logiciels permet d’avoir une idée précise de la rapidité de développement fournie. Celle-ci est mensuellement affichée sous forme d'un graphique et discutée au sein de l’équipe de développement logiciels.
Calculer la vitesse moyenne de développement est maintenant réalisable. Toutefois il est nécessaire de ne pas la communiquer dans l’immédiat. Les raisons sont simples :

  • une nouvelle équipe
  • instabilité des données réelles sur un laps de temps plus pérenne
  • malentendus possibles sur des objectifs découlant d’un nombre prédéterminé

Lorsqu’on communique un délai fixe, on s’attend au fait que la tâche demandée dans le délai soit accomplie, sans report...

Prenons un exemple : notre bus doit passer à l’heure et non en avance ou en retard, sinon nous aurons la frustration soit de l’avoir raté, soit de devoir attendre un laps de temps plus long que ce qui est annoncé. A contrario, si j’indique un laps de temps (par exemple entre 5 et 10 minutes au maximum), la frustration ne sera pas présente - à condition que ce laps de temps soit effectivement respecté ! (Claude Aubry, Bacs, prévisions et incertitudes, Février 2015, www.aubryconseil.com )
La fourchette de temps permet donc de communiquer un délai raisonnable, si cette fourchette et l’échelle de temps le sont tout autant. L’idée est donc de sortir d’un laps de temps imposé pour passer dans l’éventail de planification : une proposition pessimiste, et une optimiste.

Pour en revenir à l’estimation à l’aveugle : dans un premier temps, ne communiquez pas cette échelle de grandeur hors de l’équipe de développement logiciels. Lorsque la collecte de données est terminée sur le laps de temps défini de 3 courses au développement, il est nécessaire d’additionner le nombre de points définis comme terminés sur chaque course au développement. Par la suite, divisez ce nombre par le nombre de courses de développement. Le nombre obtenu est le nombre moyen de points que vous pourrez sortir (la fourchette étant le nombre le plus petit et le plus grand). Si un trop grand écart est constaté, il est nécessaire de se rapprocher de la moyenne obtenue.

En conclusion

Il est nécessaire de prendre un laps de temps concret pour calculer la vitesse de développement d’une équipe. Privilégiez au maximum  une fourchette de développement, un éventail de temps, une période plutôt qu'une estimation proposant un nombre précis ou une décision précise (Claude Aubry, Vélocité, productivité et rock’n roll, Mai 2011, www.aubryconseil.com).

Les différentes méthodes de calcul présentées présentent chacune des avantages, des inconvénients et des spécificités. La plus préconisée est le calcul d’une vélocité sur des données réelles, mais c’est aussi celle qui demande le plus de temps pour gagner en certitude. Il faudra prévoir tout d'abord un calcul réalisé sur une estimation théorique puis une estimation sur des données réelles (David Baumier, Evaluer une équipe Agile, Janvier 2014, www.developpementagile.com).

Toutes ces méthodes de calcul de vitesse de développement font partie intégrante du cadre de travail SCRUM et facilitent la vie du responsable de produit, du responsable du cadre SCRUM au sein de l’équipe mais aussi celle des dirigeants pour la planification d’une livraison complète du produit. La souplesse de calcul et la fourchette gagnante permettront de modifier rapidement le planning si nécessaire...

Avenir numérique : demandez le(s) programme(s) !

Un labyrinthe

Alors que la saison invite plutôt à faire des plans pour les vacances, tous les niveaux de pouvoir convergent pour faire des plans sur l'avenir numérique de leur périmètre respectif.

Ainsi, la Commission européenne a dévoilé le 6 mai dernier son plan d'action pour construire un marché unique numérique (Digital Single Market), qui se décline en trois piliers et 16 actions :

  • 8 actions pour améliorer l’accès aux biens et services numériques dans toute l’Europe pour les consommateurs et les entreprises,
  • 5 actions pour une concurrence plus équitable
  • 3 actions pour numériser l'économie.

Quelques semaines plus tôt, Alexander De Croo annonçait le 20 avril 2015 son propre plan « Digital Belgium » qui se décline lui aussi en 5 piliers et 19 actions :

  • 6 actions pour renforcer l'économie digitale, et tout particulièrement rattraper le retard de la Belgique dans le domaine de l'e-commerce, notamment en assouplissant la réglementation en matière de travail de nuit,
  • 3 actions pour améliorer les infrastructures numériques,
  • 3 actions pour développer les compétences et l'emploi dans le domaine numérique,
  • 3 actions pour renforcer la confiance dans la sécurité numérique,
  • 4 actions pour stimuler les pouvoirs publics numériques.

Quant à la Région bruxelloise, comme annoncé dans l'accord de gouvernement, elle a lancé le 3 juin dernier, à l'initiative de Madame Bianca Debaets, secrétaire d'État de l'informatique régionale et communale et de la transition numérique, et avec l'aide du CIRB, sa grande convention du numérique, baptisée pour la circonstance Brussels Smart City Summit, qui se voulait une consultation de tous les stakeholders en préparation d'un plan d'action dans cinq domaines :

  1. Smart & Social
  2. Smart & Safe
  3. Smart & Services
  4. Smart & Infrastructure
  5. Smart & Mobile

Le CIRB avait lui-même déjà fait une série de propositions dans son Livre Blanc subdivisé en quatre défis (une région connectée, sécurisant, durable et ouverte) et sept chantiers.

Certaines communes bruxelloises s’y sont également mises : ainsi, la ville de Bruxelles vient de lancer son site Internet http://smartcity.bruxelles.be/fr et de gagner le Belfius Smart City Award pour sa plate-forme Open Data, avec l'ambition clairement affichée de jouer un rôle de pilote au sein d'une région-métropole.

Il faut aussi tenir compte des plans de simplification administrative au niveau fédéral et au niveau régional, qui doivent s'articuler avec tous les autres.

Et pendant ce temps-là, les pouvoirs publics tentent de tenir la tête hors de l'eau pour mettre en œuvre les plans antérieurs, entre autres pour transposer et mettre en œuvre :

(et j'en oublie certainement) et sans oublier la stratégie Europe 2020.
                                                                                                                                                                                                                                      
Bientôt, il nous faudra un plan pour nous y retrouver parmi tous ces plans !

Aïe - tech …

pré fleuri

Hum… ça vous fait sourire hein ? … Je suis presque certain que vous savez déjà où je veux en venir ! .. Aïe, la technologie, ce n’est pas facile au jour le jour, n’est ce pas? Le wifi, le bluetooth, l’usb 3.0, le web 2.0, iOS, Androïd…. C’est clair que ce n’est pas la simplicité dans son état le plus glorieux ! Mais bon… Que vous dire, sinon que ce n’est pas de ça dont je voudrais vous parler, mais du côté ‘aïe’ plutôt que du côté 'tech' ! …

La fée papillon

Que faites-vous lorsque Madame essaie une robe dans un magasin ? Assis, vous surfez sur votre smartphone ou debout, aux aguets, vous regardez cette belle dame qui se débat avec ses bretelles ? Et dans le métro ? Et dans le train ? Et dans le jardin ? Pourtant, à chaque fois, il y avait certainement une expérience intéressante à vivre… Mais, non, trop tard, c’est passé ! Le temps perdu ne se rattrape jamais… Papillonnons donc !

Tranche de mozzarella

Et si à la place de surfer dans le canapé, devant la télé qui fonctionne pour des prunes, vous alliez dans le jardin, avec une assiette de tomates-mozza préparée avec une bonne huile d’olives, quelques épices bien senties, un petit rosé bien frais et installé tranquillement sous le parasol ? (à condition que le soleil soit de la partie, nous sommes en Belgique tout de même !)

On est bien, non ? Tranquille… Sentez le vent amener les divines odeurs de votre assiette … Résistez un peu avant de dévorer, humez, regardez, appréciez…. Miam ! :oD

One week in your life

Maintenant que nous avons fini cette assiette, je vous propose de répéter l’expérience pendant une semaine. Non pas partir sur un régime tomates-mozza pendant 7 jours, mais plutôt … profiter d’une semaine de vacances pour … déconnecter vraiment !!!! Vous déconnecter des emails, des réseaux sociaux, du web, des appels et sms ‘pro’... Bref, dire au revoir au Aïe-tech pendant une semaine entière.

Gardez un gsm ‘toucon’ sur vous, car on ne sait jamais ce qu’il pourrait arriver… mais laissez le reste dans un tiroir :)

On en reparle ?

La réunion

plage de la Réunion

La Réunion est une île du sud-ouest de l'océan Indien. Heuuuu... non non non ! On verra cela une autre fois :)
La réunion est un rassemblement de personnes motivées par un sujet précis (par ex. le projet Intranet) et dont le but est de se mettre d’accord sur certains points, d’en faire avancer d’autres, de prendre des décisions.

Dans certains cas, il peut s’agir de réunions d’information, où une personne explique quelque chose pendant que les autres … écoutent attentivement !

On peut aussi pratiquer le brainstorming (dites bwèèènschto’minn’) où chacun balance tout ce qui lui passe par la tête sur un sujet tandis qu’une personne du groupe tente de prendre note entre deux fous rires.

Une réunion d’équipe peut aussi se mettre en place, très régulièrement de préférence, afin de passer en revue une série de points courts (suivant un ordre du jour) et d’y trouver des solutions/idées.

N’oublions pas la réunion ‘tasse de café dans mon bureau’ qui permet un échange rapide et désordonné d’informations entre deux cafés et une tranche de rigolade (soyons réalistes, m’enfin !)

Un dernier point : les réunions les plus courtes sont les moins longues ! … Long : c’est lassant, on perd vite le fil et notre concentration, les pv font des km ! A oublier ! Ou alors, c’est très structuré et ça reste plutôt dans l’idée d’une réunion d’information.

Enfin, sachez que la personne qui dirige la réunion l’anime aussi ! … Eh oui, il faut mettre du fun dans le Muppet Show :o)

Comment cela se passe ?

En général, très bien ! Il suffit d’être bien organisé ! Qu’est-ce que veut dire ‘être organisé’ dans le cadre d'une réunion ?
On ne peut pas faire plus simple, il faut :

  • un ordre du jour (ou OJ, les différents points à aborder)
  • le PV (le résumé de la réunion précédente)
  • une personne désignée pour la prise de note
  • du café, du thé (du temesta, c’est selon)
  • de la bonne humeur

Par contre, il est très important que l’OJ soit distribué bien avant la réunion (une semaine avant, c’est bien !), sinon il est impossible de préparer la réunion correctement. Pareil pour le PV, cela évitera de prendre 15min à le relire pendant la réunion.

Commencez par décontracter l’atmosphère! Tout le monde est ok avec le PV ? On y va les p'tis gars ? C’est parti !

Que fait-on?

Fondamentalement, après toute réunion on fait un PV qu’on envoie à tous dare-dare ! Dans le PV, on retrouve ce que chacun doit faire, ce qui a été décidé et l’état d’avancement des projets discutés.
Chacun a aussi ses notes, qui lui permettent d’avancer de suite à son retour au bureau.

Kit de survie (ou ‘que doit-on éviter ?’)

  • les réunions doivent être courtes
  • chacun doit savoir ce qu’il a à faire à la fin de la réunion
  • pas d’OJ -> pas de réunion !
  • préparez vos réunions, ne venez pas en touriste !
  • évitez les réunionnites :o)

 

Bon courage !

La machine est-elle notre prochaine étape d’évolution?

un robot

La question peut sembler choquante de prime abord, mais en y réfléchissant, c’est peut être une réponse à beaucoup de questions existentielles. L’idée de ce post m’est venue en regardant l’excellent film « Automáta » d’un réalisateur espagnol peu connu, Gabe Ibáñez, avec pourtant un acteur espagnol très connu : Antonio Banderas.

Malgré la croissance fulgurante des machines, aucun programme ne semble être capable de rivaliser en complexité avec le cerveau humain : 1,4 kilo de matière grise située précisément entre nos 2 oreilles, contenant 200 milliards de neurones responsables de transmettre les impulsions nerveuses, chaque neurone formant grosso modo 10.000 connexions avec ses voisins. Même les ordinateurs les plus performants ne sont pas capables d’émuler un tel niveau de connectivité !

Pourtant sera-t-il possible, un jour, d’atteindre voire de surpasser les capacités du cerveau humain ? Lorsque des systèmes atteignent un certain niveau de complexité, il arrive parfois, de manière spontanée, qu’ils affichent des nouvelles capacités totalement inattendues et inédites... Dans les années 60, quelques programmes étaient déjà capables de simuler certains degrés de compréhension. L’idée était alors d’encourager les interrogateurs à continuer leur discussion en utilisant des techniques simples, comme faire répéter les questions.

Plus récemment, lors de tests de Turing tenus dans le cadre de compétitions de programmeurs, des routines ont presque réussi à abuser les interrogateurs (plus de 30%), de par leur capacité à tenir une conversation textuelle, à l'instar des êtres humains. Le test de Turing permet de déterminer si une machine montre de signes d’une nouvelle forme d’intelligence, l’intelligence artificielle ou IA.

Quand on parle d'IA...

L’IA est notamment sujette à controverse car la définition même de l’intelligence est si difficile à définir clairement. Cependant la définition communément acceptée de l’intelligence se réfère à la capacité de percevoir et comprendre la signification de quelque chose.

Sur base de cette définition, les ordinateurs seraient-ils capable de reproduire une version artificielle de l’intelligence ? Non ! Répondent de nombreux spécialistes en informatique. En tout cas, ces mêmes experts estiment qu’il faudra beaucoup de temps avant qu’une machine ne puisse réussir le test de Turing. Même si c’était le cas, la machine démontrerait-elle de l’intelligence pour autant ? Le débat philosophique fait rage depuis les années 50' et reste d'autant plus actuel que l’être humain est prompt à attribuer de l’intelligence à des choses anodines : poupées, marionnettes, emails automatiques de bienvenue, Siri…

Les êtres humains eux-mêmes sont immensément complexes et capables d’effectuer des opérations mentales compliquées. Pour certains scientifiques, il est donc bien possible que la force brute de la machine puisse imiter l’esprit humain mais pour d’autres, l’intelligence reste particulière dans le sens où elle implique plus qu’une simple vitesse de calcul et de gestion des informations. Il faudrait donc cesser de considérer notre cerveau comme une boite de processus qui gère des inputs (à travers nos sens) et génère des outputs (réactions musculaires), mais prendre également en considération une dimension qui gère le système vivant, la faim, la soif, la survie et la reproduction : les émotions.

Au niveau rationnel, un individu a des besoins et des ambitions qui sont fortement intriquées avec ses connaissances, d’une manière qui n’est pas présente dans les IA modernes. Quand nous commencerons à créer des systèmes intelligents qui incluront les motivations et les signaux émotionnels qui vont de pair, servant de standard pour trier, évaluer, organiser les évènements, nous aurons alors fait un pas de géant vers l’intelligence artificielle.

Et l’évolution finalement ?

L’intelligence semble correspondre à des caractéristiques cognitives spécifiques qui se sont spécialisées au fur et à mesure de notre évolution, lors de la sélection naturelle. Une alternative serait d’enregistrer les activités cérébrales dans de gigantesques ordinateurs qui procéderaient à de l’extraction de données et à des processus de modélisation pour fabriquer un émulateur cérébral. Dans ce cas, nous aurions effectivement un cerveau humain artificiel mais qui, au final, disposerait d’autant de connaissance concernant ce propre cerveau que n’importe quel humain, à savoir très peu… Des questions se posent déjà, rien qu’au niveau de l’architecture cérébrale et de son fonctionnement comme une entité unique avec de l’intuition, de l’attention, de la perspicacité et de la compréhension !

Mais la prudence s’impose quand même, si cela venait à se réaliser : un cerveau artificiel pourrait fonctionner des milliers de fois plus rapidement qu’un cerveau humain, se copier des millions de fois et, au final, fonctionner comme un groupe unifié, le tout en quelques minutes. Il pourrait s’améliorer et développer des nouvelles technologies qui produiraient richesses et pouvoir. Dans ce cas, il deviendra impératif de s’assurer de l'innocuité de l’IA : nous savons tous que pouvoir et motivations sont des choses bien distinctes...
En guise de conclusion, voici un échange très marquant entre un humain et un robot conscient, tiré du film « Automáta » :

- Humain : Pourquoi tu ne m’obéis pas ? Tu n’es qu’une machine !
- Robot : Qu’une machine ? Alors toi, tu n’es qu’un singe !

Le Brussels Smart City Summit, au service de la transition numérique en Région bruxelloise

Brussels Smart City Summit

Le 3 juin 2015, le CIRB organise le Brussels Smart City Summit, qui permettra aux responsables politiques et à la société civile de dialoguer avec des experts de renommée internationale sur des objectifs à poursuivre pour assurer la transition numérique en Région de Bruxelles-Capitale.

Ce sont aujourd’hui les initiatives citoyennes qui mènent la course pour moderniser notre société. Les changements technologiques et sociétaux concernent bien entendu également les services publics. Aux effets classiques de la filière numérique s‘ajoutent les effets de la dématérialisation  qui nous mène à une société « coût marginal : 0 ». L’avenir de la croissance de l’emploi et du bien-être de Bruxelles est étroitement lié à tous ces éléments. Le Brussels Smart City Summit sera l’occasion de faire converger nos énergies et nos volontés pour faire de Bruxelles une métropole internationale et numérique.

Et l’Open Source alors ?

Open source code

En voilà un joli sujet ! Il en réjoui certains pendant qu’il en fâche d’autres … c’est pourtant si facile de ne pas se compliquer la vie… il suffit de clarifier un peu tout ça ! On y va ?

A que tes sources, elles sont Open !

De quoi parle-t-on exactement ? Les sources, autrement dit, le code source (le truc vert qui défile dans Matrix et où personne ne pige rien sauf Neo) est entièrement disponible pour vos petits doigts pleins d’ardeur. Donc, de quelques dizaines de lignes à plusieurs centaines de milliers de lignes de code vous sont entièrement disponibles pour :

  • votre instruction personelle ;
  • une relecture à la recherche de faille ;
  • une compréhension des algorithmes utilisés ;
  • vous aider à vous endormir.

Mais aussi pour pouvoir le prendre et le modifier, en faire un ... Fork

For K = 1 to X; Print “M’enfin ? Mais non ! Allo quoi !”; Next … hum hum …

En réalité un fork est un nouveau soft créé depuis le code d’un autre soft. That’s all, Fork !

(mais je vous laisse quand même imaginer les débats concernant les droits d’auteur)

Et là… ça devient très intéressant ! Si vous trouvez un software Open Source qui vous convient ‘presque’, vous pouvez faire en sorte qu’il vous convienne ‘complètement’ !

Elle est pas belle la vie en Open Source ?

Évidemment… modifier c’est bien, mais documenter ce que l’on fait c’est encore mieux, où cela deviendra vite de l’Open Chaource !

Je ne vous avais pas déjà parlé de la documentation, un jour ? non ? si si ! Révisez !

Don’ be a bug, be a bunny !

Hum… C’est en effet la grosse crainte … Grosse comme un camion ! En effet, un bug caché dans le code source, et votre Fork sera difficile à (di)gérer.

Les bugs sont toujours d’actualité, cependant, le monde Open Source est peuplé de plein de petits lapins en train de coder à tout-va, tout le temps ! Tous ces bugs sont encodés dans un logiciel de gestion de … Bug. Lui même étant … Open Source :o) très souvent libre d’accès.

Le bug est donc Open ! … et oui, il est open à être résolu par n’importe qui :) Vous, moi… un autre lapin ;o)

Cette résolution sera certainement … un Patch ! Il n’y en a pas que pour les fumeurs, pour les projets et serveurs aussi ! A Patchy Server … ça ne vous dit rien ?

Potentiellement, il y a une équipe énorme derrière ces softs…. Mais qui bien souvent travaille bénévolement, et donc ça avance… pas toujours très vite !

Et oui ! C’est Free … vous avez tout compris ! Du coup, on trouve aussi des versions payantes Open Source. Et que paie-t-on ? Quelques lignes de code supplémentaires et … du service & support.

Moteur V12 7.0L 450cv.. Un carrossier est demandé à l’accueil! Un …

Jusqu’ici, vous avez déjà compris que l’Open Source n’est pas toutes roses et violettes, mais qu’avec un peu d’engrais, on peut en tirer des choses impressionnantes !

On pourrait donc voir ces logiciels, ces projets, des idées Open Source comme un gros moteur sur lequel nous allons créer une belle carrosserie qui correspondra à nos besoins : F1, Pot d’yaourt, Camion, Tank, sous-marin…. On peut tout faire ! Absolument tout !

Evidemment, pour organiser tout ça, nous allons retomber sur le Prince 2, qui aura Bel-Air de conjuguer moteur et carrosserie avec une dose de ressources humaines… afin de construire la Babel de l’Open Source.

Sla ‘n’ Olie

Résumons nous ! L’open Source est donc une sorte de Chaudron Magique, dans lequel nous pouvons trouver des idées lumineuses mais que nous devons associer à une gestion de projet rigoureuse (comme toujours) et à un suivi précis du support.

Dans le cas où nous voudrions mettre de l’huile dans les rouages, une bonne dose d’Open Mind sera nécessaire. Mais je ne m’inquiète pas : nous avons un spécialiste du Aware en Belgique !

Dans cette belle salade, je vous souhaite une belle route parsemée de beaux projets et de belles personnes :)

Sioux bientôt :)

Olivier Delvigne
IT Manager - Administration communale & CPAS de Jette

Alle blogposts