Esprit d’équipe
Cal Evans évoque l'esprit d'équipe à travers cette discussion que l'on a tous déjà eu un jour :
L'autre : Merde, c'est fait. Ils ont décidés de prendre <solution X> au lieu de <solution Y>. C'est tellement débile ! C'est le pire qu'on pouvait faire! Je me demande comment je vais supporter une telle merde !
Cal : Tu étais consulté pour le choix ?
L'autre : Oui.
Cal : Alors maintenant que la décision est prise, il ne te reste plus que deux, et seulement deux options : soit tu acceptes la décision, soit tu démissionnes.
Une belle tranche de vie de développeur, comme on aimerait en vivre moins souvent.
http://blog.calevans.com/2010/09/16/man-up-a-developers-responsibility-to-their-team/
Etre un héros c’est bon pour les films
Le projet prend du retard. La date de livraison approche à grands pas. A ce rythme là, vous ne serez pas prêt et décidez d'allonger vos journées de travail. Rapidement, celles-ci se transforment plutôt en nuits de travail. Vous êtes éreinté mais le projet est livré en temps et en heure. Vos responsables et votre client sont satisfaits et un agréable sentiment de fierté vous emplit : vous êtes un héros !
Pourtant à y regarder de plus prêt votre action était-elle si héroïque que cela ? Tout a un prix et vos longues heures de travail nocturne vous ont mis les batteries à plat. Le stress engendré par la crainte de l'échec n'a rien arrangé à cela, au contraire. Bien entendu, l'euphorie d'avoir sauvé la situation vient momentanément compenser cela mais qu'en est-il sur le long terme ? Vos efforts vont plomber les jours suivants le temps de vous refaire une santé. Il faut vous rendre à l'évidence : vous ne pourrez pas toujours sauver la situation en agissant ainsi.
Agir en héros et réussir à sauver une situation mal engagée est toujours gratifiant et généralement valorisé par votre encadrement mais n'est-ce pas une manière désespérée de pallier à des problèmes plus profonds ?
Ce temps dont vous avez manqué pour terminer le projet à un rythme confortable n'est-il pas dû à une mauvaise estimation des tâches ou à des problèmes imprévus ? Dans ce cas, quelque chose qui était pertinent s'il fallait deux heures pour le faire l'est-il toujours si vous y avez passé deux jours, et cela même si au final cela fonctionne ? Il faut essayer de prendre du recul. Il est souvent préférable de revoir ses priorités plutôt que de laisser une tâche déborder de manière trop importante.
Une tâche peut généralement être modifiée ou simplifiée sans que cela n'impacte de manière significative le projet. Il est également possible avec la pression que vous subissez que vous soyez tout simplement en train de passer à côté d'une solution astucieuse. Les héros ne sont solitaires que dans les bandes dessinées. Quand vous vous sentez bloqué, demandez l'avis de vos collègues. Des yeux neufs verront probablement des choses que vous ne voyez plus avec l'habitude.
Il arrive même que la bonne solution soit d'abandonner purement et simplement la tâche. Cela ne fait jamais plaisir de faire un trait sur les efforts déjà effectué mais c'est parfois la chose la plus raisonnable à faire.
Il arrive également que la cause du problème soit un manque de méthodologie ou d'outillage de l'équipe. Dans ce cas, être un héros ne fait que masquer le problème. Il vaut mieux alors l'attaquer à la base en identifiant et en éliminant ses causes.
Le sentiment de fierté et d'importance que l'on ressent lorsqu'on a été le héros d'un projet est très agréable mais il est dangereux aussi bien pour soi que pour son équipe. Laissez donc les héros au cinéma et mettez en place un rythme de travail raisonnable au sein de votre équipe. Tout le monde y trouvera son compte.
Le Livre blanc Industrialisation PHP dans le numéro de janvier de PHP Solutions
Le magazine PHP Solutions distribue notre livre blanc sur l'industrialisation de PHP sur le CD-Rom qui accompagne son numéro de janvier.
Au sommaire de ce numéro, vous trouverez également :
- Le Web service (partie 2)
- Testez votre projet
- L’intégration du .Net à PHP
- Rédiger et optimiser le contenu d’un site pour les moteurs de recherche
- Édition de documents OpenOffice ODF avec PHP
- Création de fichier de logs
- Votre boutique en ligne
- La puissance des démarches descriptives
- Envoyer des mails en PHP
- Symfony 1.3 : nouvelles fonctionnalités et envoi d’emails
- Manipuler les répertoires avec PHP
- BeEF Exploitation
A noter que l'article "Le Web service (partie 2)" a été écrit par notre collègue Christophe Villeneuve.
Un projet sans développeur ?
Bien sûr, difficile d'imaginer un projet informatique sans développeur. Même bien conçu et bien supporté, il est difficile de se passer de celui qui produit le code, et convertit les objectifs fonctionnels en instructions PHP. Le titre de ce billet est provocateur. Il ne s'agit pas de s'en passer totalement : même les générateurs de code doivent être programmés par quelqu'un....
Pourtant, il y a un bon nombre de tâches qui échoient, faute d'autre interlocuteur, aux développeurs. Par exemple quand il faut déployer (qui connait l'application?), quand il faut tester (idem), quand il faut suivre la qualité d'application des conventions de code (qui va relire ce fatras?), quand il faut diagnostiquer un bug (Si ca plante, y'a que lui pour avoir l'explication).
Par défaut, tout cela revient directement jusqu'à celui qui a produit le code, car c'est lui qui détient ultimement la connaissance. Cela signifie qu'il devient rapidement un passage obligé pour nombre de phase de vie de l'entreprise, alors même que le code a quitté son giron depuis longtemps. Or, il n'est pas toujours possible de retrouver le développeur, pour de multiples raisons (affectation à une nouvelle mission, démission, mort, vacances, calendrier chargé...)
C'est ici que savoir se passer du ou des développeurs se révèle une pratique indispensable. Si les équipes d'administration doivent faire l'installation durant la nuit, un script de déploiement automatique permettra de le faire sans interroger l'auteur du code. Et cela sera même critique dans le cas où l'intervention se fait en urgence : montée en charge subite, retour en arriève de version, etc.
On peut assurer de nombreuses tâches comme ceci :
- tests unitaires automatiques (phpunit alltests.php)
- analyse statique (pmd)
- déploiement (phing, capistrano)
Dans ces situations, même en l'absence de développeur, on peut vérifier la qualité du projet, obtenir un diagnostic de la situation ou installer une nouvelle machine. Certes, les tests unitaires ne couvriront surement pas toutes les situations, mais ils permettront de vérifier les situations les plus simples, et même par une personne étrangère au projet ou non-technique.
Du point de vue individuel, c'est aussi une phase importante dans le cycle de vie du projet. Quand on travaille sur du code dans un projet, il est important de savoir s'en séparer, de couper le cordon ombilical. Si on est le seul à maîtriser une application, on devient indispensable, et on risque aussi de finir enchaîné à des corrections et évolutions infinies.
À chaque fois que j'ajoute une nouvelle fonctionnalité, je me demande à moi-même : comment mes utilisateurs pourront-ils faire des modifications sans passer par moi? Fouiller toute l'application? Faut-il manipuler du code? Lire une documentation? Changer une configuration ? Moins j'obstruerai la progression, mieux cela sera pour eux.
Et pour moi aussi. Car je ne compte pas rester toute ma vie sur le même projet.
Parution du livre blanc « Industrialisation PHP »
Livre blanc Industrialisation PHP
Alter Way, intégrateur Open Source de référence a publié aujourd'hui son premier livre blanc. Acteur de l'industrialisation PHP, l'intégrateur, qui réunit au sein de ses équipes les plus grands experts PHP français renforce sa contribution documentaire au monde du Libre et démontre la capacité de PHP à entrer dans son ère industrielle.
Signée par les auteurs de ce blog, cette publication propose un état de l'art du monde PHP en abordant notamment les thèmes de la qualité de code, les outils et méthodes d'ingénierie logicielle, les techniques avancées.
Le livre blanc est scindé en trois parties :
- Le constat de la situation et les solutions actuelles : audit expert, conventions de programmation, frameworks, formations, IDE de développement ;
- Les nouveaux outils : tests unitaires et fonctionnels, usines de développement, outils de conception, analyse statique, déploiement automatique ;
- Les nouvelles méthodes : méthodes agiles, intégration continue, audits croisés, collaboration avec les utilisateurs.
Alter Way s'inscrit à tous les niveaux dans une démarche d'industrialisation de PHP :
- Alter Way Formation : une session sur la thématique « Bonnes Pratiques », une autre sur l'optimisation PHP qui aborde les moyens de gagner en performance sur les plate-formes LAMP ;
- Alter Way Hosting : conception d'architecture et optimisation des plate-formes PHP ;
- Alter Way Consulting : audits de sécurité et de performance, coaching technique autour de PHP ;
- Alter Way Solutions : mise en œuvre de projets basés sur une méthodologie éprouvée, l'utilisation de frameworks, d'outils de tests et montée en charge, des ressources formées aux bonnes pratiques.
Il était une fois ce blog
La vie est parfois étonnante. Alors que je codais mes premières lignes de PHP vers l'an 2000, j'ai cherché un hébergeur pour le site d'une association dont je faisais partie. Mon choix s'était porté sur Nexen qui, à l'époque, proposait un hébergement gratuit avec PHP. De son côté Damien Seguy, faisait partie des trois créateurs de la société Nexen.
Quelques années plus tard, Damien et moi nous sommes rencontrés à l'AFUP dont il est l'un des membres fondateurs et dont j'ai été le trésorier. Il y a un an, Nexen a rejoint le groupe Alter Way tandis que de mon côté, j'y suis arrivé en janvier dernier. Bref, tout nous prédestinaient, Damien et moi, à collaborer ensemble.
Au delà de notre complicité, c'est notre passion pour le logiciel libre, le développement et plus particulièrement PHP qui nous a rapproché. Ce blog a pour but de traiter à quatre mains des problématiques d'industrialisation des développements PHP.
Nous aborderons le sujet sous différents angles. Nous parlerons bien sûr des outils mais également des méthodes et des problématiques business.
Livre blanc
Suivez nous sur Twitter
Catégories
Blogroll
Lectures
- APPLICATION.INI CheatSheet for your Zend Framework Application
- GraphicsMagick Image Processing System
- Comment veiller et faire de la médiation numérique efficacement avec Google reader et Diigo | Bibliobsession
- Writing Robust Bash Shell Scripts
- Open Jail - The Jailer Project Web Site
- Finding and Purging Big Files From Git History
- Git Immersion
- URL Design
- How to Improve Communication Between QA and Development
- Les frameworks c'est bien, développer "en dehors" c'est mieux