Mobile Dev Day 2014 : Soft’it en force !

.equipe main .detail div .profil {
width: 22%;
float: left;
margin-right: 2.6%;
margin-bottom: 2.6%;
border: 1px solid #ccc;
position: relative;
background: #ec6707;
font-weight: 400;
}

.equipe main .profil .photo {
width: 100%;
height: auto;
position: relative;
display: block;
z-index: 100;
border-bottom: 5px solid #ec6707;
}

.equipe main .profil .texte {
margin: 0 auto;
top: 0;
height: 100%;
width: 100%;
padding: 8%;
position: absolute;
z-index: 101;
color: #ec6707;
}

.equipe main .profil .texte h3 {
margin-bottom: 35px;
margin-top: 0;
font-family: « Georgia »,arial;
font-weight: normal;
font-size: 1.375em;
cursor: default;
}
.equipe main .profil .texte span {
text-transform: uppercase;
font-size: .75em;
font-weight: bold;
cursor: default;
}

@media screen and (max-width: 800px) {
.equipe main .detail div .profil {
width: 31.6%;
margin-right: 2.6%;
}
}

@media screen and (max-width: 600px) {
.equipe main .detail div .profil:nth-child(odd) {
margin-right: 2.6%;
}

.equipe main .detail div .profil {
width: 40%;
}
}

@media screen and (max-width: 400px) {
.equipe main .detail div .profil {
width: 100%;
margin-right: 2.6%;
}
}

« LA » conférence annuelle Microsoft dédiée au développement mobile se tiendra ce jeudi 27 novembre, à Mons en Belgique.

Une journée d’inspiration !

Le Mobile Dev Day est un événement annuel dédié au développement mobile sur plateforme Microsoft. Développement mobile au sens large du terme, de l’embedded jusqu’aux tablettes en passant par les Windows Phone. Créé à l’initiative de 4 passionnés, cet événement se veut convivial, avec des sessions atypiques

10 speakers, 11 sessions, 8 MVPs, et un top développeur de chez Microsoft Corp.

Les thèmes abordés seront les suivants : Mobile, UX Design (« User eXperience » design), Cloud Computing et Internet of Things (objets connectés).

La diversification des sujets, associée aux pointures du monde MS, permet d’amener des conférences originales et singulières :

  • « Le développement d’applications Google Glass en C# avec Xamarin » : plus besoin de développer en Java pour utiliser les Glass !
  • « IoT, toilet flushes and scalability » : comment connecter son Twitter à ses toilettes, et tweeter à chaque (grosse) commission ???!
  • « Mais c’est quoi le Random ? » : dompter l’aléatoire via du hacking
Des sessions plénières et 2 tracks : Français et Anglais. A noter que Scott Hanselman, Rudy Huyn et plusieurs autres MVP speakeront…ça promet !
Nous serons 4 membres de l’équipe Soft’it à faire le déplacement pour suivre la conférence :
Marien Monnier

Marien
Monnier

Aimerick Suzanon

Aimerick
Suzanon

Philippe Beroucry

Philippe
Beroucry

Pier-Lionel Sgard

Pier-Lionel
Sgard

Nous tenterons de vous faire partager cette journée autant que possible via Twitter ou Facebook de Soft’it. Puis des articles seront écrits par l’équipe après la conférence pour vous résumer tout ça.

Pour nous suivre : 

window.twttr = (function (d, s, id) {
var t, js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src= « https://platform.twitter.com/widgets.js »;
fjs.parentNode.insertBefore(js, fjs);
return window.twttr || (t = { _e: [], ready: function (f) { t._e.push(f) } });
}(document, « script », « twitter-wjs »));

Pour plus d’infos sur l’événement :

Et un aperçu de la version 2013 :

Introduction à la gestion des cycles de vie des applications (ALM)

Introduction à la gestion des cycles de vie des applications

(Application Lifecycle Management – ALM)

       ….

Evidemment, dit comme cela, cela peut paraître un peu abrupte voire déconcertant … Cycles de vie des applications  – Application Lifecycle Management. Mais sous ce nom se cache en réalité l’une des meilleures pratiques logicielles dont l’objectif est de fournir un logiciel de haute valeur et de haute qualité, et ce d’une manière très efficace, rapide et fiable

Quelles sont les différentes étapes de l’ALM ? 

D’un point de vue du développeur, il est courant de penser que le cycle de vie d’un logiciel commence et s’arrête lors du checkout et du commit des modifications du code. 

La réalité est tout autre, comme nous le voyons tous les jours, et couvre beaucoup plus. 

Le cycle de vie des applications commence à partir de la création du projet jusqu’à la livraison en production, comprenant plusieurs étapes dont le développement n’est qu’une petite partie parmi, entre autres, les tests, les documentations et la génération d’installateurs. 

L’ensemble de ces opérations permet de livrer un logiciel de haute valeur et de haute qualité pour le client.

Ce schéma montre le pipeline de déploiement idéal. On y retrouve l’ensemble des opérations automatisées à mettre en place lorsqu’on parle d’ALM.
Le processus est entièrement automatisé, capable de fournir un feedback détaillé de son statut et de celui de ses opérations, et de s’interrompre à chaque étape en cas de détection d’anomalies.
Bien loin de ce déroulement idéal, le plus souvent, il est fréquent que la plupart de ces opérations soient manuelles, partielles et sans fournir de réel feedback.
Même si maintenant il est largement admis que le code source doit être hébergé dans un outil de contrôle de version, et que chaque développeur doit faire des check-out et commit réguliers, il est encore très rare de trouver une plateforme d’intégration continue réelle automatisée, qui gère ne serait-ce que la compilation automatique et le déroulement des tests unitaires. 
A la place, il est fréquent qu’il y ait des flux allant dans toutes les directions, sources de risques et de problèmes à venir, comme le montre le schéma ci-dessous  : 

Quel est le problème avec la livraison de logiciels ? 


  1. Les opérations sont nombreuses, souvent manuelles et sur différents environnements techniques mal maitrisés,
    • Le corollaire est que ces opérations dépendent de quelqu’un (responsable déploiement, chef de projet, expert quelconque). La question est donc : que se passe t’il lorsque cette personne est absente
    • extrêmement répétitives, ces tâches sont une plaie sur le long terme,
    • la réalisation d’une documentation souvent lourde est nécessaire,
    • une courbe d’apprentissage lente pour l’ajout de nouveaux membres à l’équipe,
    • des besoins humains supplémentaires sont nécessaires à l’équipe

  2. Le code source et les paramétrages ne sont pas nécessairement stockés dans le même endroit, mais peuvent être générés à partir de partout et par n’importe qui, n’importe quand : qui contrôle quoi ?
  3. Aucune vraie traçabilité,
  4. Des délais de livraison très long : il peut se passer des jours entre la validation et le déploiement,
  5. Des erreurs sont plus enclines à apparaître. 
En bref : lorsqu’il y a des opérations manuelles, il devient vraiment difficile de répéter, de cadencer et de mesurer la livraison. 

Quels sont les objectifs de l’ALM ? 

Comme vous l’aurez compris maintenant : implémenter l’ALM c’est principalement se concentrer sur l’automatisation de la grande majorité (sinon la totalité) des opérations ; afin d’assurer la création de valeur et des livraisons fiables, rapides et cadencées.
L’idée maîtresse est de réduire les temps de cycle.
Plus le temps de cycle est court, plus le client pourra être satisfait (par plus de fonctionnalités ou même par des corrections de bugs). L’objectif est de favoriser les feedbacks rapides.

Comment? 

Etant donné que cet article est seulement une (très) courte introduction, nous ne plongerons pas plus à fond dans les détails ici. 
Nous énumérerons simplement les différents sujets à couvrir. Ceux-ci seront expliqués plus en détails dans de prochains articles :
  1. Configuration et installation d’un outil d’intégration continue (TFS, Hudson, CruiseControl), 
  2. Mettre au cœur de l’outil l’analyse de qualité (règles de gestion, Sonar, FxCop) ainsi que les tests, le tout avec de l’automatisation, 
  3. Mettre sous contrôle de source tous les paramètres ou fichiers de configuration pour tous les hôtes cibles, 
  4. Lister toutes les autres opérations manuelles, les automatiser et les chaîner entre elles,
  5. Modifier le processus de développement pour s’appuyer davantage sur les tests d’acceptation,
  6. Réduire les délais de feedback (testeurs, clients ….). 

Conclusion 

Cet article n’est que le premier d’une série d’articles introduisant les principes de ALM (intégration continue, déploiement continu…etc). Il vise à présenter simplement ce qui est en jeu tout en abordant les grands principes du cycle de vie des applications.
Dans les prochains articles, nous expliquerons plus en détail avec de cas concrets d’utilisation et d’implémentation, les scénarios de mise en place de l’ALM.

Liens utiles

ALM (sur wikipedia) : pour une explication simplifiée.
Intégration Continuela définition par M. Martin Fowler
Déploiement Continu : la définition par M. Martin Fowler

Une partie de l’équipe Soft’it présente au Microsoft DevOps Day !

.equipe main .detail div .profil {
width: 22%;
float: left;
margin-right: 2.6%;
margin-bottom: 2.6%;
border: 1px solid #ccc;
position: relative;
background: #ec6707;
font-weight: 400;
}

.equipe main .profil .photo {
width: 100%;
height: auto;
position: relative;
display: block;
z-index: 100;
border-bottom: 5px solid #ec6707;
}

.equipe main .profil .texte {
margin: 0 auto;
top: 0;
height: 100%;
width: 100%;
padding: 8%;
position: absolute;
z-index: 101;
color: #ec6707;
}

.equipe main .profil .texte h3 {
margin-bottom: 35px;
margin-top: 0;
font-family: « Georgia »,arial;
font-weight: normal;
font-size: 1.375em;
cursor: default;
}
.equipe main .profil .texte span {
text-transform: uppercase;
font-size: .75em;
font-weight: bold;
cursor: default;
}

@media screen and (max-width: 800px) {
.equipe main .detail div .profil {
width: 31.6%;
margin-right: 2.6%;
}
}

@media screen and (max-width: 600px) {
.equipe main .detail div .profil:nth-child(odd) {
margin-right: 2.6%;
}

.equipe main .detail div .profil {
width: 40%;
}
}

@media screen and (max-width: 400px) {
.equipe main .detail div .profil {
width: 100%;
margin-right: 2.6%;
}
}

Chez Soft’it, on aime la technique mais surtout la qualité. Un des axes d’amélioration de la qualité les plus pertinents du moment est la réconciliation/le rapprochement entre le développement et l’exploitation (« ops » en anglais) : le DevOps.

Cela permet de penser un développement dans son ensemble : de la réalisation à la livraison.
Le mouvement « DevOps » a pour objectif de casser les silos existants entre ces 2 étapes, tout en se basant sur une approche agile.


Microsoft et Cellenza organise le « Microsoft DevOps Day« , le 25 novembre 2014 au centre de conférence de Microsoft (Issy-les-Moulineaux).

1 journée pour parler du DevOps et ses origines, puis pratiquer de l’IaaC (« Infrastructure as a Code »), Continuous Delivery (déploiement continu) et du Monitoring. Pour finalement terminer sur le rôle et le futur de Microsoft dans le milieu du DevOps.

Evidemment quelques membres de l’équipe Soft’it seront présents.

Ikbal Benakila

Ikbal
Benakila

Laurent Jacques

Laurent
Jacques

Pier-Lionel Sgard

Pier-Lionel
Sgard

Jérôme Veneziani

Jérôme
Veneziani

Si vous ne pouvez pas y assister, l’équipe tweetera demain et fera quelques feedbacks/résumés des confs dans les jours/semaines à venir. Stay tuned !

window.twttr = (function (d, s, id) {
var t, js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src= « https://platform.twitter.com/widgets.js »;
fjs.parentNode.insertBefore(js, fjs);
return window.twttr || (t = { _e: [], ready: function (f) { t._e.push(f) } });
}(document, « script », « twitter-wjs »));

Le chemin vers la qualité est-il unique ? (Part 1 : la Méthodologie)

le chemin 1

Scrum, Crystal Clear, eXtreme Programming (XP) … De plus en plus, nous nous éloignons du cycle en V. Ou en tout cas, nous essayons de le faire.

Pourtant, si l’on se rappelle la conférence « Petite histoire d’une méthodologie agilement établie » donnée à Paris Web, ce n’est pas si vrai que ça. A la question « Combien d’entre vous n’appliquent pas d’agilité dans leur entreprise ?« , un bon nombre de mains se sont levées.

Incidemment, la question qu’on a pu entendre était « Quelle est la vraie bonne méthodologie à appliquer ?« .

Et Alexandre Jakubiak tout comme Julien Oger -tenant la conférence citée plus haut- se sont bien gardés de donner une réponse toute faite. Ils ont même prévenus l’audience qu’ils nous présenteraient « la solution qui leur correspondait le mieux ». Ce qui remet beaucoup de choses en perspectives.

Tout d’abord, ils ont voulu bien évidemment éviter le cycle en V. On comprend très vite ses limites avec la fameuse phrase client : « C’est bien ce que j’ai demandé, ce n’est plus ce que je veux. » (i.e. la lenteur de cette méthodologie fait que les besoins du client vont évoluer avant qu’il ait pu mettre la main sur la solution).
Mais rejeter cette méthodologie en bloc n’est pas nécessairement productif non plus : son approche prédictive (bien que trop orientée projet) a ses vertus.

Opposées, la ou les méthodologies agiles, considérée plus réactive intégrant notamment le client plus tôt au processus de développement. Son principal inconvénient reste le nombre de solutions déjà existantes.

Première chose : éviter à tout prix le Big Bang. Mettre en place Scrum -par exemple- dans son ensemble (outils et pratiques) d’un coup au sein de son équipe est suicidaire. Au mieux, on retournera au cycle en V (plus rassurant car déjà connu) en un sprint. Au pire, l’équipe implosera.

La solution choisie a été d’y aller progressivement. Surtout de préalablement faire un tour de l’existant, regarder ce qui serait le plus simple, qui apporterait le plus… et le plus simplement en interne.
Leur conclusion fut de partir de Crystal Clear puis de piocher dans toutes les méthodologies existantes ce qui leur correspondait et les implémenter au fur et à mesure.

Tout ne fut pas simple de l’aveux même de ces messieurs. La méthodologie parfaite n’est qu’utopie. Il faut, dans la mesure du possible, rester souple et ouvert à l’évolution. De même, chaque équipe, chaque société a des besoins différents.
Cela peut être lié à la taille de l’équipe, des projets, des langages utilisés ou même de l’expérience (on fera passer plus facilement de jeunes développeurs à une nouvelle méthodo que des seniors habitués au bon vieux V).

Chez Soft’it, nous utilisons Scrum en interne, notre Scrum. Nous avons dû adapter certaines règles pour que notre fonctionnement soit plus limpide : il n’y a pas de Scrum Master fixe par exemple, il change à chaque Sprint. Cela permet de responsabiliser chaque personne travaillant sur les projets et en plus de ne pas laisser cette pression toujours sur les épaules d’une même personne.

Nous appliquons également plusieurs pratiques de l’eXtreme Programming (XP) : le « Pair Programming« , par exemple, pour les nouveaux arrivants et sur des phases un peu complexes; ou la revue de code (« Code Review ») après chaque story réalisée.
Nous faisons également du testing et avons une usine logicielle pour l’intégration continue. Cependant, la TDD (« Test Driven Development », également part d’XP) n’est pas une obligation chez nous.

S’arrêter à une méthodologie et l’appliquer « By the book », même le cycle en V, est impossible. Le faire est source de frustration ou de goulot d’étranglement bien plus que de facilités dans un projet.

Savoir écouter les besoins en interne et externe, tirer le meilleur de ses retours d’expérience heureux et surtout malheureux, vous guidera bien plus vers votre méthodologie qu’un livre à appliquer à la lettre.

L’agilité contient un principe fondamental : l’amélioration continue. Pensez à réserver du temps pour prendre du recul sur votre organisation, et à construire ensemble la méthodologie qui vous correspond.

[ALT.NET] Des katas et du chocolat : le Coding Chocolate !

Coding Chocolate : le nouveau Coding Dojo made-in ALT.NET et Soft’it (et le 7ème de la saison 2014), organisé le mardi 2 décembre à partir de 19h, dans les locaux de CLT Services (34 boulevard de Sébastopol 75004 Paris).

Pour rappel, l’exercice consiste à prendre soit un kata de programmation, soit un sujet libre et d’essayer de le résoudre en 45min~1h.
L’objectif étant de faire cela en « pair-programming » et TDD. Après on débriefe et on discute pour nous améliorer.

Cette fois-ci, le thème de la soirée est autour du chocolat (à manger ou à boire), pour parer aux rigueurs de la saison.

C#, F#, VB, Iron Python … venez avec votre PC portable et votre IDE!

Pour vous inscrire, c’est ici : http://www.meetup.com/altnetfr/events/218757800

CLT et Soft’it sur France 2!

Nous avons récemment été contactés par une équipe de France 2 pour être interviewés au sujet de la vie en open-space. Une étude publiée récemment explique que beaucoup de salariés travaillent en environnement d’open-space, mais peu en sont totalement satisfaits.

L’avis d’une société à taille humaine, comme la notre, et le contexte de l’équipe interne Soft’it semblaient les intéresser.

Une matinée à être envahis par les caméras, à être mis en scène, filmés puis interviewés. Une expérience intéressante!

Voici le sujet qui est passé au JT de 13h le 04 novembre:

Et l’envers du décor…

Pour voir le JT complet : http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-mardi-4-novembre-2014_730477.html

Le sujet passe à la 25ème minute.

[Formation] Testing et TDD en Java…

Un des membres de l’équipe Soft’it – Rémi Lesieur pour ne pas le nommer – a réalisé lundi et mardi dernier une formation Testing/TDD à destination d’une équipe expérimentée en Java, pour une division de l’Armée française.

L’objectif de la formation était double: présenter ce qu’est le testing et la TDD (philosophie et théorie), tout en démontrant l’intérêt ainsi que le gain de temps et de la qualité.
Eh oui, c’est souvent difficile en tant que développeur de se dire qu’écrire du code pour tester du code, ça revient à gagner du temps! C’est pourtant bien le cas.

Rémi a donc abordé la logique du testing d’une manière générale en démontrant que ce n’est pas parce qu’on teste à la main, que notre code est bon et surtout pérenne (régressions non visibles).
Puis il a présenté les différents types de tests (unitaires/intégration), ainsi que la notion de mocking (voir « Dummy, Fake, Stub, Mock et Spy, les tests unitaires avec l’aide de Moq.« ).

Pour finalement attaquer le testing dans l’eXtreme Programming (XP) : le Test Driven Development (TDD).

Au total, 2 jours pour 10 développeurs/lead-techs mélangeant théorie et beaucoup de pratiques sous forme de Katas, en pair programming.

Un bon succès puisque 7 personnes sur 10 ont donné la note de 5/5, et les 3 restantes, 4/5. La formation construite sur mesure par Rémi a donc visé juste.

Si vous êtes intéressé par des formations et/ou du coaching sur du testing (et tout autre outil/méthodologie autour de la qualité), dites-le nous!

[ALT.NET] Coding Candies: des katas et des bonbons!

Le prochain événement coding dojos ALT.NET aura lieu le jeudi 18 septembre dans les locaux de CLT Services, en partenariat avec Soft’It.

Pour vous inscrire: http://www.meetup.com/altnetfr/events/205431352/

Message du co-organisateur, Jean-François Saguin, avec Rui Carvalho:

Bonjour à tous, le groupe ALT.NET fait sa rentrée avec une nouvelle session du coding.
Comme annoncé en juillet, nous allons essayer d’alterner un peu plus cette année entre des coding breakfast le matin et des événements en début de soirée (pour caler avec les agendas de chacun).
Pour changer des mojitos nous vous proposons cette fois-ci un thème orienté douceurs et friandises.
Pour rappel le but de l’exercice est d’améliorer ses compétences en programmation et tests en codant sur un problème donné. Nous travaillons donc en paires et en TDD sur une durée allant de 45min à 1H.
C#, F#, VB, Iron Python … venez avec votre PC portable et votre IDE.

Venez nombreux!

Pour vous donner une idée, allez voir les événements précédents: http://blog.softit.fr/?tag=/Altnet