mercredi 15 juillet 2015

Organiser son code dans Visual Studio

Comment organisez-vous vos dossiers de solution dans Visual Studio ? Mettez-vous en place une organisation logique et physique de vos projets VS ? cet article vous donnera peut-être des idées :

mardi 30 juin 2015

La bonne ambiance au sein d'une équipe : moteur de productivité

J'avais envie de partager avec vous un point qui me tient à cœur personnellement : l'ambiance au travail. Je vous parle de l'ambiance au travail en général et plus particulièrement au sein d'une équipe. pour ce post, je vais prendre pour exemple je prendrai le cas d'un équipe technique c'est à dire une équipe composée de développeurs avec potentiellement un architecte technique, un tech lead, un PO, un chef de projet, etc.

La bonne ambiance est moteur de productivité

Je pense sincèrement que la bonne ambiance au sein d'une équipe sert de moteur de productivité et cela se passe inconsciemment. Voici mon raisonnement :
Globalement, quand on est dans une "team" avec une bonne ambiance, le dialogue devient spontané : aucune censure ne se fait, et du coup chacun peut s'exprimer librement, même avec un ton moqueur ou ironique, avec toujours à l'esprit d'exposer sa problématique, de poser une question ouverte sur un choix de direction technique à prendre, de demander de l'aide, de remettre en question des choix, bref tout ce qui me semble être nécessaire au bon déroulement d'un projet informatique (ou autre).

Cultivateur de bonne ambiance

Je me définis moi même comme cultivateur de bonne ambiance ;).
Chaque consultant (travailleur de façon générale, quelque soit sa position dans l'entreprise) devrait avoir en tête le matin en arrivant au travail de "spreader" une ambiance favorisant les échanges. Pourquoi ? simplement parce que l'inverse est juste horrible :
Nous passons une grande partie de notre vie au travail, une bonne ambiance est juste une partie de notre bonheur personnelle.
En tant que consultant, vous pouvez intervenir chez vos clients de façon marginale : vous venez, vous faites votre Job et vous partez. J'ai déjà vu ce genre de consultant, et je trouve cela dommage. Il ne s'agit pas de faire copain-copain avec tous les membres de vos collègues en mission; pour moi, il faut juste penser à laisser une vrai trace de son passage en mission tant professionnellement qu'humainement.

Actions concrètes sur le terrain

Voici quelques éléments qu'on peut mettre en pratique, ou au pire essayer :
Dire bonjour à ses collègues : attention, je parle de "dire vraiment bonjour", pas le truc à la vite fait façon "je te salue malgré moi". C'est mon avis perso, car certains pensent que c'est pas nécessaire, mais je vous assure que j'ai déjà vu des teams où certains ne disaient pas 'bonjour' et cela entraîne des rumeurs, une mauvaise ambiance générale,etc
Discuter de tout et de rien : ça aide à détendre l'atmosphère globalement, du moment qu'on le fait avec parcimonie. Il ne s'agit de le faire tout le temps, mais cela permet par exemple sur des équipes jeunes, qui ne se connaissent pas bien de casser des barrières. Un autre exemple avec vos managers, chefs de projet, PO, où souvent a communication est 'strict'.
Rire et faire rire : ça peut paraître bête mais l'inverse est juste horrible : imaginez quand vous traverser un openspace, et que les gens sont en mode solo, regard inquisiteur sur les passants, mines serrées, focus sur leur écran style ils bossent plus que tout le monde : c'est hyper pesant et stressant comme ambiance.

Les freins à la bonne ambiance

J'ai préféré ne pas parler des freins à la bonne ambiance, car c'est un sujet vaste et souvent polémique : je pense entre autre aux 'supers autonomes' qui ne communiquent pas trop avec les autres, les 'perturbateurs' qui pour des raisons personnelles ne favorisent pas la communication, etc. Il existe plusieurs solutions pour les gérer : en générale on favorisera la communication.

Conclusion

L'idée de ce poste est de rappeler que le plus important au sein d'une équipe reste le facteur humain. Une bonne ambiance ne fera que favoriser tout le reste, surtout votre mission. En outre, c'est en général ce qui reste après votre mission chez un client, où quand vous changer d'entreprise : on se dit souvent : "c'était top cette mission, on formait une vrai équipe, on rigolait bien et en plus on était efficace au travail".
On parle souvent de communication comme étant la base de tout au travail, et il s'agit bien de communication dont je parle ici, mais pour ma part ce n'est pas là le plus important : ce qui compte c'est justement l'était d'esprit des collaborateurs de votre équipe, votre service, voir même de toute votre entreprise qui fera la différence : si l'était d'esprit est tournée vers la bonne ambiance 'humainement', cela favorisera la communication. Je pense entre autre au fait de faire preuve d'empathie.
J'aimerai avoir votre avis sur le sujet : qu'en pensez-vous ? êtes-vous d'accord avec mes propos ? avez-vous des retours d'expérience différents qui contredisent ces idées ?

mercredi 3 juin 2015

Intentional programming

Hey ! toi qui est développeur, programmes-tu par intention ? si ce n'est pas le cas, lit cet article, ça pourrait peut-être t'intéresser...

jeudi 7 mai 2015

Aperçu de Visual Studio Code

A l’occasion de cette Build 2015, Microsoft présente plein de nouveautés pour les développeurs. J’en ai donc profité pour tester la preview de “Visual Studio Code” (ou VSCode), une version light de “Visual Studio” orienté Web.

Lire la suite

mercredi 22 avril 2015

Spotify Engineering Culture

Spotify Engineering Culture - part 2 from Spotify Training & Development on Vimeo.

ça vaut le détour !

vendredi 10 avril 2015

Un site web ASP.NET MVC 5 de A à Z - Projet et cahier de charges

<== Article précédent : Comment faire un site asp.net MVC 5 de qualité

Chose promise lors de mon dernier article, je commence donc ma série d'articles consacrée au développement d'une application web ASP.NET MVC 5 de qualité (je sais c'est prétentieux :) mais vous allez voir ça va être sympa !).

Le projet

Etant donnée que je n'ai pas de sujet en particulier, j'ai donc penser à faire quelque chose de classique. Au fur et à mesure de mon avancement j'enrichirai le projet avec des idées nouvelles selon mon humeur, ou si vous m'en proposez (et oui, je suis joueur).

Le cahier des charges

Voici mon idée : je vais imaginer Monsieur X comme étant le commanditaire de ce projet.

Monsieur X vient me voir et me dit : je veux monter une affaire (un business quoi !) et j'aimerai pour cela une application Web qui proposera mes services. Je vais également faire du commerce et vendre des produits sur ce site. Je ne sais pas trop par quelle activité je vais commencer mais je suis sûr que je ferai les 2 (sous entendus offre de services et ventes de produits). Par contre j'aimerai tout gérer directement sur le site, c'est à dire ajouter, modifier et supprimer moi même les articles et services que je propose, ainsi que la gestion des commandes, etc. J'aimerai aussi avoir une page de statistique avec des graphes pour suivre l'évolution de mes activités.J'aimerai pouvoir également renseigner mes clients directement, suivre leurs commandes, etc

Monsieur X n'a pas beaucoup de temps car il démarre à peine ses activités et il est très pris. Par contre il serait très content si le développement de son application avançait rapidement. Aussi, il reste très disponible au téléphone, donc je peux l’appeler quand je veux.

J'explique à Monsieur X qu'il est vrai qu'on est en 2015 et qu'on a pas besoin d'un roman pour démarrer les développements mais que son expression de besoins reste assez incomplète. Je lui propose donc que l'on travaille en "Agile", afin qu'il puisse me faire des retours au fur et à mesure de l'avancement des développements. Je le contacterai donc très fréquemment (tous les jours), afin qu'il me donne des informations sur des éléments qui ne me sont pas clair pour avancer.

Attention, j'ai bien expliqué à Monsieur X que s'il ne se rendait pas disponible pour répondre à mes questions, moi j'arrêterai de travailler : bon je lui ai dis ça de façon diplomatique bien-sur, c'est quand même lui le client (lol)).

On attaque par quoi ?

Heu... je sais pas ? y'a une réponse type ? je ne crois pas. Moi je dirai qu'il faut commencer par bien comprendre le besoin, même si de nature le besoin est très changeant (surtout de nos jours). Cependant, avoir une compréhension globale du besoin est indispensable. C'est comme faire un fonction mathématiques sans domaine de définition...

Comment aborder le sujet ?

Moi pour bien comprendre, j'aime bien prendre le hauteur (ou du recul si vous préférez). Pour cela, j'utilise des schémas.

Nous allons donc faire quelques diagrammes UML pour représenter e façon macro ce qu'il y a à faire concrètement.

A très vite !

Article suivant : Modélisation UML (à venir) ==>

mercredi 1 avril 2015

Avec l'arrivé prochaine d'ASP.NET 5 alias vNext, il serait intéressant de revoir nos bases sur l'actuel version d'ASP.NET MVC. Aussi le retour de chacun ne serait que bénéfique afin de comparer nos différentes approches, de comprendre certains choix techniques et d'en tirer l'essence.
Alors ? qui est intéressé ? vous pouvez même proposer un sujet d'étude pour ce site d'exemple ! proposer de voir une implémentation de votre choix !
Et non ce n'est pas un poisson d'Avril :) ! plus de 10 articles prévus au programme.
J'attends vos retours pour démarrer !!!!!!!!!!!!!!!!!!!

Article suivant : un site web ASP.NET MVC 5 de A à Z ==>

If then else

Pages