VISER LA PERFORMANCE EN MODE AGILE Part III (Team Empowerment)

Aucun d’entre nous n’est plus intelligent que l’ensemble d’entre nous.
Kenneth Blanchard

La formule de Norman Maier : E = Q x A.

Efficacité de la décision = Qualité de la solution x Adhésion.

L’empowerment est une des clefs fondamentales pour développer la performance des entreprises car il est axé sur la capacité à savoir engager les équipes pour les responsabiliser et susciter un travail collectif.  (Claire Leduc)

Comment faire ? 

Partager l’information : vision, mission et objectifs

• Partager un maximum d’informations concernant l'organisation et le service à l’ensemble des collaborateurs.

• Lorsqu’un manager/leader partage ses informations, ses bonnes et mauvaises nouvelles, il commence à gagner la confiance de ses collaborateurs et de son équipe.

• Le manque de clarté est néfaste à la responsabilisation des collaborateurs et au développement de leur motivation. 

Autonomiser en fixant des limites claires

• Il est primordial de fixer clairement les nouvelles règles du jeu, les nouvelles responsabilités étant précisées par un ensemble de limites clairement énoncées

• Au niveau individuel, le manager/leader et le collaborateur peuvent définir conjointement un ensemble d’objectifs et de projets destinés à donner le cadre de leur partenariat. 

• Les règles, Les limites et la structure ont paradoxalement besoin d’être clarifiées très précisément pour permettre plus de liberté d’action et d’initiative de la part des collaborateurs

Travailler et décider en équipe

• L’équipe devient l’organe de décision. Travailler et décider systématiquement en équipe permet un niveau de performance et des résultats au-delà des objectifs

• Le réflexe le plus fréquent du manager qui fait face à un problème à résoudre ? Chercher tout seul la meilleure solution pour ensuite au mieux la proposer, au pire l’imposer à son équipe par mail ou présentation ?

• Les idées du groupe auront toujours une longueur d’avance sur celles d’un leader ou d’un expert technique élaborées dans son coin

  • La formule de Norman Maier : E = Q x A.

• Efficacité de la décision = Qualité de la solution x Adhésion.

Activités clés et degrés d’empowerment

Source :https://www.amazon.com/Keys-Empowerment-Release-Astonishing-Results/dp/1576751600

Le résumé en détails : http://excellenceop.fr/empowerment-en-equipe-12

VISER LA PERFORMANCE EN MODE AGILE Part II (Les principes de l'agile manifesto)

Les 12 principes de l'agile manifesto :  que vous travailliez en méthode Scrum, Kanban ou autre, il est important de ne pas les perdre de vue.

Satisfaire le client

En livrant rapidement et régulièrement des fonctionnalités

à grande valeur ajoutée.

Accueillir positivement les changements de besoins

Même tard dans le projet les processus agiles
exploitent le changement pour donner un avantage
compétitif au client.

Livrer fréquemment

Avec des cycles de quelques semaines à quelques mois et une
préférence pour les plus courts.

Des réunions journalières.

Les utilisateurs ou leurs représentants et les 
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Réaliser les projets avec des personnes motivées. 
Fournissez-leur l’environnement et le soutien dont ils
ont besoin et faites-leur confiance pour atteindre les
objectifs fixés.

Privilégier le dialogue en face à face

La méthode la plus simple et la plus efficace pour 
transmettre de l’information à l'équipe de développement
et à l’intérieur de celle-ci est le dialogue en face à face.

Mesure d’avancement

Un logiciel opérationnel est la principale mesure d’avancement.

Un rythme de développement  soutenable. 

Ensemble, les commanditaires, les développeurs
et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.

La maîtrise technique et une bonne conception.

Une attention continue à l'excellence technique et
à une bonne conception renforce l’Agilité.

La simplicité

L’art de minimiser la quantité de travail inutile.

Des équipes auto-organisées.

Les meilleures architectures, spécifications et 
conceptions émergent d'équipes auto-organisées.

Devenir plus efficace

À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

sources : http://agilemanifesto.org/ 

https://www.softfluent.fr/blog/expertise/2017/05/17/Les-12-principes-du-manifeste-agile

VISER LA PERFORMANCE EN MODE AGILE Part I (Le Rôle du facilitateur)

Satisfaire le client en délivrant régulièrement un logiciel opérationnel et à grande valeur ajoutée, favoriser la collaboration, l’excellence technique et la simplicité, en encouragent un rythme soutenable. l’ensemble étant sous-tendu par la mise en place d’une politique d’amélioration continue.

« favoriser, encourager et soutenir » sont donc les mots d’ordre du manager agile. il devient un facilitateur au service d’une équipe qui doit parvenir à s’auto-organiser.

Faciliter, cela consiste à aider un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions, atteindre un consensus…

La posture de facilitateur vise à améliorer le fonctionnement d’un groupe pour garantir l’atteinte des objectifs. 

Plusieurs principes guident cette posture : le respect des contributions de chacun, que ce soit dans le monde des idées ou dans le monde des actions. 

Le manager quitte sa position « haute » de celui qui réfléchit et décide pour les autres au bénéfice d’une position « basse » qui aide les collaborateurs à réfléchir et décider.

Sources : 

http://www.managementvisuel.fr/manager-facilitateur-le-manager-du-21eme-siecle/

https://business.lesechos.fr/directions-ressources-humaines/management/gerer-et-motiver-son-equipe/quand-le-manager-devient-facilitateur-6232.php

La check-list Code Performance

La check-list Performance

Quelques points à vérifier :

• Les objets sont dupliqués uniquement lorsque cela est nécessaire. Si vous devez dupliquer des objets, envisagé de mettre en œuvre Clone et décider si le clonage profond est nécessaire.

• Pas de boucles d'attente avec des traitements lents -> favoriser des méthodes en asynchrone et les Threads. 

• Évitez les gros objets en mémoire ou utilisez la classe String pour contenir de gros documents qui devraient être manipulés avec de meilleurs outils. Par exemple utiliser StringBuilder/StringBuffer au lieu de String.

• Ne laissez pas le code de débogage dans le code de production.

• Évitez les System.out.println (); dans le code, -> enrouler les logs dans une déclaration de conditionnement booléen comme if(DEBUG) {...}

• "L'optimisation qui rend le code plus difficile à lire ne doit être implémentée que si un profiler ou un autre outil a indiqué que la fonctionnalité doit être optimisée. Ces types d'optimisations devraient être bien documentés et le code qui effectue la même tâche devrait être conservé". - UNKNOWN.

Quelques bonnes pratiques concernant l'utilisation des exceptions

Ne jamais ignorer une exception

//traitement susceptible de lever une exception

        }catch(Exception ex){

            ex.printStackTrace(); //il faut pas ignorer

        }

Ne pas utiliser la clause throws de manière exhaustive

public void funAction() throws A, B, C { // trop d'exceptions sur le throws
    //corps de la méthode
}

Les exceptions ne sont pas faites pour le contrôle de flux

while(true){
//faire quelque chose
if(condition d'arrêt)
throw new FinDeLaBoucleException(); // ne pas utiliser les exceptions pour controler le flux
}

Attention au return dans un bloc finally !

public int methode(){
try{
return 3;
}finally{
return 4; // pas de return dans un block finally
}
}

Eviter le catch Error ou Throwable

try {

} catch (Error e) { // pas de catch Error ou Throwable
System.out.println("Une erreur est survenue : " + e);
}

Road to the Cloud (3) : Monolith Vs Microservices Applications (1)

Road to the Cloud (3) : Monolith Vs Microservices Applications

Monolithic architecture (monolithic architecture pattern)

"une seule brique avec tout les services ... et un seul WAR"

Avantages :

- Simple

- La scalabilité est obtenue à travers un cluster / load balancer

Inconvenants : 

- Le code source devient énorme a travers le temps donc difficile a lire et a comprendre ... le développement devient lent, l’environnement de développement aussi.
- Comme l'application devient énorme l’intégration continue doit être moins fréquente car il faut compilé et déployé tout le code.
- La scalabilité devient difficile car elle peut ce faire uniquement en verticale donc achat des serveurs plus performants.
- A long terme l'entreprise va être forcé à utiliser les mêmes technologies car puisque l'application devient énorme le coût du changement de technologie devient grand.

Microservices architecture (microservices architecture pattern)

"plusieurs briques indépendantes avec un système de communication entre eux ... plusieurs WARs"

Avantages :

- Une scalabilité horizontale et verticale (déploiement sur un ou plusieurs serveurs/JVMs.)
- Facile à comprendre et à gérer car chaque partie du code est presque indépendante.
- Le développement devient plus rapide car l'utilisation de l’environnement de développement et déploiements/tests deviendrons plus rapides.
- Chaque application peut être développé/amélioré et déployé indépendamment des autres.
- Les problèmes rencontrés en "run-time" sur une brique n'affecterons pas tout le système donc ça augmente la disponibilité.
- L'obligation de garder la même technologie au fil du temps n'est plus d'actualité.

Inconvenants :

- Nécessite une bonne coordination entre les équipes qui travaillent sur différentes briques.
- Il faut développer et gérer un système de communication entre les briques.
- Des scénarios de tests plus complexe.
- La transformation des transactions distribuées en use cases est assez difficile.
- Complexité de gérer et déployé des briques avec peut être différentes technologies.


Une solution pour l'existant

Pour les applications existantes qui souffrent de problèmes de scalabilité et lenteur ce qu"on peut retenir c'est que à un moment le coût de la scalabilité verticale va explosé (upgrade des serveurs pour gérer la demande qui augmente avec le "computing everywere" ...)


La solution est de faire sortir la ou les briques qui consomment le plus de ressources a fin de pouvoir les déployées séparément.

La séparation doit se faire au niveau du code aussi a fin de pouvoir l'améliorer et changer les technologies utilisées pour augmenter la performance.

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Le pourquoi: Assurer l’intégration, la performance, et la qualité du code avec les outils suivants : 

Jenkins (un "fork" open source de hudson / outil d'intégration continue).
JUnit (tests unitaires).
JMeter (test de charges).
PMD (la définition de nombreux règles qui assurent la qualité de code).

Maven (La gestion des dépendances et automatisation de la production).

A chaque "build" l'application est compilée, analysée ,testée (JUnit), déployée et re-testée (JMeter).

Les résultats des analyses sont disponible juste après :

PMD :

JMeter :

JUnit :

Maven permet d'automatiser le tout en définissant un ou plusieurs fichiers POM (pom.xml) qui contient le nom du projet, le numéro de version, les dépendances vers d'autres projets, les bibliothèques nécessaires à la compilation, les noms des contributeurs etc.

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>spring</artifactId>
<version>0.0.2-SNAPSHOT</version>
<packaging>war</packaging>
<name>test</name>

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.1.6.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>WebContent\WEB-INF\web.xml</webXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat6-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8090/manager</url>
<server>TomcatServer</server>
<path>/SpringMavenCLITest</path>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<targetJdk>1.6</targetJdk>
<linkXref>false</linkXref>
<failOnViolation>false</failOnViolation>
<failurePriority>1</failurePriority>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.10.1</version>
<executions>
<execution>
<id>jmeter-tests</id>
<phase>verify</phase>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.12</version>
</dependency>
</dependencies>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<linkXRef>false</linkXRef>
<targetJdk>1.6</targetJdk>
<rulesets>
<ruleset>/rulesets/basic.xml</ruleset>
</rulesets>
</configuration>
</plugin>
</plugins>
</reporting>

</project>

 Pour finir il faut configurer jenkins pour démarrer notre intégration continue.