On peut considérer deux types d’entreprise et de processus agiles :
- l’entreprise semi-agile : la demande et le produit ne sont pas gérés de manière agiles, ce n’est seulement qu’à la frontière avec la technique que l’agilité démarre.
- l’entreprise agile : tout les processus de création de valeur par l’entreprise sont agiles, de la réflexion à la réalisation

A ces deux types d’entreprises correspondent deux types d’exigence en terme de pratiques et processus.
L’ignorance des pattern agiles importants, ou l’emploi trop appuyé d’anti-pattern agiles,  doit plutôt être vu comme une incitation à :
- envisager la nécessité d’un travail autour de l’application de la méthodologie (travail dans le sens de…)
- à contrario envisager l’emploi d’une autre méthodologie agile (XP, concepts lean etc) si la résistance au changement est trop importante

Dans tout les cas, ne pas oublier que :
- les méthodes agiles ne font qu’agréger des pratiques ‘du bon sens’ issues de l’expérience
- c’est bien la méthode qui est au service de l’homme et pas l’inverse ; donc de facto, constituez votre trousse à outil agile et votre ensemble de règles basées sur les méthodes agiles

Biblio :
http://www.entreprise-agile.com/HistoAgile.pdf
http://www.mountaingoatsoftware.com/system/presentation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project-Management.pdf
http://www.agileopencalifornia.com/wiki/index.php?title=Semi_Agile_Projects
http://productmanagementjournal.blogspot.com/2009/08/agile-thinking.html
http://www.agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm
Transition vers l’agilité – Livre blanc – 2e édition 2011 – Valtech

Si les frameworks d’aujourd’hui (Grails, Spring, etc) sont des gloutons en terme de mémoire, cpu, et espace disque, c’est en théorie pour la bonne cause, c’est à dire pour embarquer les constructions techniques qui amèneront les bonnes pratiques, les mécanismes métiers clés (transaction, injection, découpage en couche etc) et la qualité de fonctionnement. Toutefois c’est parfois très frustrant d’embarquer toute cette lourdeur pour le déploiement d’applications simplistes. Ce n’est pas pour autant qu’il faille envisager le pire sur ces cas d’usages, c’est à dire le retour aux années 2000 (jsp, servlet)…

Voici venu le temps des framework web évènementiels basés sur cette volonté de simplicité. On peut même dans certains cas parler de langages et même de Domain Specific langage tant la spécialisation peut être marquée. Voici quelques exemples.

NODE.JS
Node.js est le cas typique du framework évenmentiel. Le langage de développement est javascript, l’environnement d’exécution V8 (google javascript engine v8) dont la particularité est de compiler le javascript en code machine. La simplicité est au rendez vous.
Lancer un serveur web :

var http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello Worldn');
}).listen(8000);
console.log('Server running at http://127.0.0.1:8000/');

Un autre exemple typique consiste dans l’implémentation d’un serveur socket.
Plus d’infos : http://nodejs.org/
Une refcard est disponible chez dzone, et elle insiste à bon escient sur l’asynchronisme.

Sinatra
Sinatra est nouvelle bonne surprise du monde ruby (toujours en avance, rappelez vous ROR).
Un framework web évènementiel profondément simple dans l’usage. Dommage par contre, vous ne pourrez pas l’utiliser sur les serveurs mutualités proposant ruby, car une installation de module est nécessaire.
Le framework est uniquement orienté web mais est par contre très complet (cf doc).

Le hello world web est SIMPLE :

require 'sinatra'

get '/' do
'Hello world!'
end

http://www.sinatrarb.com/

Spark
Enfin le meilleur pour la fin et le dernier né : Spark.
Enfin un petit framework évènementiel créé en java et inspiré de Sinatra.
Qui dit java dit pourquoi pas Groovy, alors à vos claviers.

Le hello world reste simple :

import static spark.Spark.*;
import spark.*;

public class HelloWorld {

public static void main(String[] args) {

get(new Route(« /hello ») {
@Override
public Object handle(Request request, Response response) {
return « Hello World! »;
}
});

}

http://www.sparkjava.com/

Pour finir
Ces frameworks évènementiels n’utilisent pas de système de pool de thread-worker (comme le font nos serveurs d’applications), mais des systèmes de pile (cf doc sinatra ou node.js). Le système de pile + la désynchro de la requête et de la réponse permet en théorie d’attendre des sommets en terme de capactité de réponse (cf doc node.js). A vérifier… et dans quelle mesure…

Crédits photo : Spark

Le rôle de Product Owner se définit ainsi :
« Le Product Owner est le représentant des clients et utilisateurs. C’est lui qui définit l’ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l’orientation du projet. Le terme directeur n’est d’ailleurs pas à prendre au sens hiérarchique du terme, mais dans le sens de l’orientation. » (source Wikipedia)

Il est cependant utile de compléter cette définition du Product Owner :
– il est le dépositaire mandaté dans la vision produit du ou des produits qui lui incombent
– il construit le produit en conservant une vision mesurée du retour sur investissement (ROI) de ces demandes
– il détermine les objectifs stratégiques de chaque itération et planifie ainsi l’évolution du produit

Usuellement le Product Owner gère :
– la préparation du backlog et dans une moindre mesure la vision d’entreprise du ou des produits
– la roadmap et dans une moindre mesure, par corrélation la plannification des releases
– sa collaboration avec les ‘métiers’ et l’accomplissement des évolutions ou créations
– sa collaboration avec l’équipe et le scrum master

Hors dans de nombreuses entreprises,
– les métiers sont complets, distincts et hétérogènes
– les métiers concentrent le pouvoir de décision et ont leur propre approche ROIste et ne souhaitent pas déléguer ce ‘pouvoir’
– les organisations et répartition des métiers se font en silos
– les cycles de décision et de réalisation sont réellement lents, ce qui créée concurrence entre les besoins
– les demandeurs ne souhaitent pas s’impliquer dans la réalisation
– il n’est évidemment pas possible d’avoir autant de Product Owner que de silos/produits/métiers (quid des projets transverses dans ce cas).

Ces anti-patterns agiles et cette réalité ont donc favorisé l’apparition d’un rôle, un peu plus subtil, peu spécifié, remplaçant le Product Owner ; il s’agit du Product Owner Proxy

Sur des projets transverses il est :
– l’interlocuteur unique des responsables produits
– l’interlocuteur principal (ou unique, à vous de voir) des membres de l’équipe scrum
– le gestionnaire des priorités
– la personne en charge de l’organisation des releases pluri-métiers
– le dépositaire d’une expertise métier spécifique à l’ensemble pluri-disciplinaire que forme le projet global d’entreprise (qui n’est pas l’expertise métier de tout les responsables produits ou métiers)

Il n’est pas :
– le dépositaire ‘produit’ et n’est mandaté que par le responsable produit
– acteur sur le ROI ; il est d’avantage un analyste
– le référent en terme de vision sur le produit

De l’aveu même de Ken Schwaber, Scrum ne définit pas comment utiliser le product backlog et pas plus ce que doit faire le product owner. Donc après c’est à vous de voir comment limiter ou augmenter ce rôle.

Qui peut être ce product owner ?
– un développeur senior (pour peu qu’il se soit aussi spécialisé dans la gestion de projet)
– un business analyst ou un chef de projet (pour peu qu’il soit réellement sensibilisé à développement et aux contraintes techniques et qu’il ait une réelle empathie vis à vis des développeurs)
– dans une certaine mesure,un responsable produit, pour peu qu’il soit réellement accepté en tant que tel par les responsables produits et les membres de l’équipe SCRUM

Comment consolider ce rôle de product owner proxy ?
Il faut impérativement outiller et enrichir les attributions de ce rôle clé en :
– outillant le rôle en process de gestion de de la demande
– organisant l’assistance de la part des responsable métiers ou produit dans le travail de tout les jours
– donnant des pleins pouvoirs dans la gestion et négociation de la priorisation (business value)

Les valeurs de ce product owner proxy doivent être :
– confiance totale des responsables produits
– confiance totale de l’équipe scrum
– autonomie et une capacité à prendre des décisions et à les faire accepter
– respect des besoins, respect des équipes, respect du travail réalisé

Pour le reste la base du métier, les artefacts, et les outils du Product Owner ne changent pas :
– le backlog
– la priorisation
– l’écriture des User Stories
– l’assistance aux différentes ‘cérémonies’ SCRUM

Sur des projets non transverses, le pattern du Proxy Product Owner est inutile.

En conclusion, demandeurs, responsables produits, directions, membre de l’équipe scrum, le Product Owner Proxy est votre meilleur allié. Certes, il est souvent issu de la technique informatique, mais l’aidez c’est vous aidez dans vos projets car il est le meilleur vecteur du bon accomplissement des travaux de la société car :
– il est autant sensible que les demandeurs aux objectifs business de la société
– il connait tout les besoins de la société et il est le meilleur allié pour faire progresser les projets des acteurs de la société
– il est un excellent filtre pour l’équipe SCRUM pour éliminer bruit et négocier en amont les fonctionnalités

Un peu de lecture :
http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/
http://blogs.versionone.com/agile_management/2009/08/04/agile-product-owner-by-proxy/
http://agileworld.blogspot.com/2009/09/choosing-proxy-product-owner.html
http://www.leadingagile.com/2009/03/product-owner-by-proxy/
http://softwaredevelopmenttoday.blogspot.com/2008/04/proxy-product-owner-pattern-in-scrum.html
http://www.slideshare.net/xwarzee/le-product-owner-proxy-bertrand-dour
http://agileinthemix.com/fr/2010/02/illustration-dune-organisation-en-silo-leffet-dalton/
Corpus et notes de la formation Certified Scrum Master par Petra Skapa (Xebia)

Que tester ? Comment ? Avec quels outils ?

a. tester le temps de génération et de transfert des pages (une à une)

b. tester le temps de transfert d’une page et de ces ressources

c. tester le rendu d’une page

d. tester le comportement sous traffic

e. monitorer la dispo de votre site

Tester le temps de génération et de transfert de la page seule

Sous Unix/MacOSX les commandes CURL + TIME associées le font très très bien.

Test d’un seul appel : time curl -s « http://localhost »

Tests de 1000 appels en cascade : time for i in {1..1000}; do curl -s « http://localhost;done »

Cela vous donne invariable un résultat en secondes.

Tester le temps de transfert de la page et de ces éléments en cascade

Un des outils de références est « Firebug »: http://getfirebug.com/ (il fait bien plus que cela en plus), directement intégrable dans votre browser pour une bonne vision quand aux cycles et durées de transfert.

Un outil comme « YSLOW »: http://developer.yahoo.com/yslow/, lui aussi intégrable dans votre browser, vous donnera une série de conseils quand aux optimisations à réaliser sur vos pages.

Un outil SAAS comme « GTMETRIX »: http://gtmetrix.com/ offrira les mêmes fonctionnalités dans une jolie interface.

Tester le rendu d’une page

Pas grand chose d’automatisé dans ce domaine ; les « ADOBE-BROWSERLAB »: http://browserlab.adobe.com and co ne sont pas guère qu’efficaces pour tester la qualité de rendu.

Donc rien de tel qu’un test sur un pool de browsers.

Tester le comportement sous le traffic

Simuler une exécution sous charge raisonnable mais réelle est souvent déjà un bon début. La création d’un scénario avec plusieurs thread sous « JMETER »: http://jakarta.apache.org/jmeter/ vous permettra d’atteindre ce but.

Pour simuler un afflux massif d’internet (un effet slashdot par exemple), beaucoup d’outils existent (siege, httperf, curloader,…) et vous pouvez les retrouver « ici »: http://www.linux.com/archive/feature/143896 .

Sinon quelques outils SAAS existent aussi tels : « LOADIMPACT »: http://loadimpact.com/

Monitorer la dispo de votre site

Sans pareil au prix de la gratuité : « WOOZWEB »: http://www.woozweb.com

Si vous souhaitez monitorer vos serveurs, pensez à « Hyperic »: http://www.hyperic.com/

Et bien voici une implémentation de la couche soft totalement libre et déployable sur des isntances Amazon, Xen ou simplement sur votre distribution Ubuntu.

Cela s’appelle AppScale (http://appscale.cs.ucsb.edu/) et la version 1.4 est dite compatible avec GAE Python et Java le tout en version 1.3.

Le wiki se trouve ici : http://code.google.com/p/appscale/ et c’est d’ailleurs ici que vous trouverez les informations vraiment intéressantes sur l’installation et sur l’exécution.

Bon test !

Graphs d’achitecture :

Sur PC WINDOWS utiliser VISIO avec des set d’illustrations comme ceux de http://www.visiocafe.com/

Sur Mac utiliser OmniGraffle http://www.omnigroup.com/products/omnigraffle/ qui fournit une bibliothèque de symbole et supporte très très bien le drag and drop d’images .

Définition d’écran :

Le meilleur : Balsamiq (http://balsamiq.com/)

Sinon un coup d’oeil ici : http://mashable.com/2010/07/15/wireframing-tools/

- WOOZWEB : http://www.woozweb.com (SAAS)

Etudier vos temps de réponses :

- GTMETRIX :  http://gtmetrix.com/ (SAAS)

Superviser vos platerformes :

- Hyperic : http://www.hyperic.com (un client / host + un serveur centra à installer)

Google App Engine était en effet lourdement handicapé par des limitations très contraignantes

• un recyclage obligatoire de vos applications en cas d’absence de traffic ; c’était très pénalisant du fait des délais de démarrage des applications
• des limites de temps d’exécution sur les ‘jobs’ très peu réalistes (30 sec)
• ainsi que de nombreuses autres limitations liées à la préservation d’un contexte d’exécution pour la plateforme globale

Google semble avoir entendu les protestations de la communauté et propose de fait cette version 1.4 dont les nouveautés sont listées ici : http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+GoogleAppEngineBlog+%28Google+App+Engine+Blog%29

Il s’agit en fait de :

• la possibilité de pouvoir stopper le recyclage de vos applications en préservant 3 instances de vos applications, ce même en l’absence de traffic (« Always on »)
• une API bi-directionnelle pour faciliter l’échange de données entre client et serveur web
• une fonctionnalité de renforcement de l’élasticité « Warmer request » qui permet de lisser la montée en charge
• enfin quelques efforts quand aux volumes adressables via Memcache, les apis mail etc

Personnellement et subjectivement la rapidité d’exécution  semble avoir été grandement amélioré.

Si ces nouvelles fonctionnalités semblent remettre GAE dans la course, ce sont les fonctionnalités présentées sur la roadmap (http://code.google.com/intl/fr/appengine/business/roadmap.html) qui éveillent l’attention :

• du SQL sur serveur
• un agrément SLA
• une console pro

A suivre donc…

Illustration : Google

Certaines sociétés proposent déjà des solutions SAAS pour la gestion de campagnes marketing via email avec en outre toute sorte d’api web ainsi que des connecteurs pour envois de mails de service. C’est bien, c’est plutôt efficace et solide, bourré de bonnes idées mais c’est très cher. (me contacter pour quelques références testées et approuvées dans le domaine).

Voici, venu le temps d’accueillir quelques nouveaux outils, plus simple, plus orienté et moins cher dans le domaine du routage des mails :

• SendGrid : http://www.sengrid.com ; ce service de relay mail semble router dans de bonnes conditions (je vous laisse lire le descriptif), et fournit un reporting minimal mais acceptable. Le tout est utilisable via SMTP tout simplement. Le pricing ne me semble pas prohibitif et un plan gratuit existe. La capacité (en volume) me parait assez limitée, mais gageons que le service va grandir au fil des mois
• MailChimp : http://www.mailchimp.com;  ce service vous propose, lui, le routage de vos campagnes et newsletter. Beaucoup de fonctionnalités en bonus, je trouve l’ensemble très sympa. L’offre en terme de pricing demande un peu de réflexion pour bonne compréhension, mais tout semble envisageable avec ce service à un tarif plus qu’acceptable

A n’en pas douter ces services vont se forger une réputation, bonne ou mauvaise et grossir au fil du temps. C’est une approche peut être plus low-cost. Mais il est plus que probable que ces solutions trouvent une place plus ou moins grande à côté des autres solutions, tant il est bon de ne pas mettre tout les oeufs dans le même panier du point de vue de l’email.

Illustrations : MailChimp (gauche) / SendGrid (droite)

Une carte de choix pour jouer avec Linux sur ARM

BEAGLEBOARD xM
Texas Instruments OMAP3530 ARM Cortex-A8™ Processor 1GHZ, 512MB RAM
(4USB, ethernet, dvi, microsd,port série, puce3D/HD)
Cible de choix pour Linux et Android
149$ http://beagleboard.org/

Les plus fortunés pourront regarder du côté de chez NVIDIA : http://developer.nvidia.com/tegra/tegra-devkit-features ou acheter le joli portable Toshiba AC100 http://uk.computers.toshiba-europe.com/innovation/generic/home-ac100/ à condition que les ports debian / ubuntu sur ce modèle se concrétisent.

Illustration : copyright Beagleboard