AGILITY/MANAGEMENT/ORGANISATION
Petite réflexion de Ron Jeffries sur Scrum : connaître les bases, les respecter, maîtriser les rôles, l’importance du développement incrémental.
http://ronjeffries.com/articles/2015-03-29-increment-culture/
Une culture forte, un aspect qui ressort de plus en plus quand on aborde les nouvelles manières de s’organiser/travailler.
C’est ce qu’a mis en place Atlassian pour essayer de rester toujours en phase avec un marché qui évolue constamment.
Et quand on parle culture, on ne parle pas que de salle de massage, de coca a volonté ou encore de babyfoot … il faut aussi prendre en compte des valeurs, des objectifs communs : de la créativité, de la qualité, de l’écoute, de l’amélioration, de la reconnaissance, etc.
http://www.infoq.com/articles/coding-culture
Quel est le rapport ente le Systema, le développement logiciel, les méthodes « Agiles » et Jean François Zobrist : la complexité !
Chacun à sa manière va traiter de la complexité, en essayant soit de la maîtriser, soit de s’y adapter.
Mais en essayant de contrôler la complexité, on a tendance à plutôt l’augmenter, et c’est pourquoi il faudrait peut-être au final suivre la route du « embrace the suck ».
https://medium.com/@ygrenzinger/why-software-industry-should-embrace-the-suck-4b10f0abe1dd
TECH
La documentation est toujours un sujet qui fait débat dans le développement logiciel.
Wiki, JIRA, specs, commentaires dans le code, le code en lui-même … comment peut-on faire pour mettre fin à la documentation obsolète, suivre facilement les évolutions fonctionnelles et techniques et pourquoi elles ont été réalisées ?
Certains ont décidé d’utiliser les messages de commit de Git : commits atomiques, règles d’écriture, US branches … ça demande pas mal de rigueur !
Et pourquoi pas un outil qui pourrait récupérer les messages Git et en faire une documentation complète ? (Peut être que ça existe déjà, à voir …)
https://about.futurelearn.com/blog/telling-stories-with-your-git-history/
Écrire du code de qualité n’est pas une chose aisée. La définition même de qualité de code peut différer d’une personne à l’autre.
Ken Beck, lui, préconise de suivre les 4 règles suivantes : le code produit doit passer les tests, expliciter ce qu’il fait, sans duplication et être le plus simple possible.
Qu’en pensez-vous ?
http://martinfowler.com/bliki/BeckDesignRules.html
Le monde de l’IT est en constante évolution. Et il y a toujours un sujet, parmi les autres, qui sort du lot : AngularJS, Agilité, Devops, Scaling Agile, Microservices … .
Et en ce moment, ce sont les microservices qui ont la côte.
Voici une analyse qui tente d’expliquer pourquoi.
http://radar.oreilly.com/2015/04/4-reasons-why-microservices-resonate.html
Toujours du microservice, mais un peu plus technique cette fois-ci.
Après un rappel des principes derrière les microservices, l’article aborde quelques patterns à suivre si vous souhaitez vous lancer : aggregator, proxy, branch, asynchronous messaging …
Mais, avant tout, n’oubliez pas la simplicité
https://www.voxxed.com/blog/2015/04/microservice-design-patterns/
Et maintenant un petit peu de DevOps (d’un point de vue outillage ;))
Après Docker, Docker Compose.
A la base nommé Fig, puis racheté par Docker, Docker Compose propose de regrouper dans un seul et unique fichier toutes les commandes nécessaires au lancement et paramétrage de conteneurs Docker.
Petit point négatif, impossible de « redémarrer » ses conteneurs, tout est supprimé et recréé à chaque fois que l’on lance la commande.
https://docs.docker.com/compose/
http://w3blog.fr/2015/02/28/docker-compose-remplace-fig/
ET SINON
Et voici maintenant une piqûre de rappel sur l’entreprise libérée, sous forme de récapitulatif ;).
Moins de hiérarchie, plus de servent leaders !
http://www.co-construire-avenir.org/publications/dossier/lentreprise-liberee-radiographie-dune-notion-en-vogue
Un retour d’expérience d’une startup qui fonctionne en télétravail, sans réunions et sans niveaux hiérarchiques.
Bon ok c’est un cas particulier, mais les principes derrière leurs pratiques sont réels : nous connaissons notre métier (heureusement j’aurais envie de dire !), les interruptions cassent la productivité, le temps passé en moins dans les transports peut être utilisé de manière plus productive, embaucher les bonnes personnes.
http://qz.com/260846/why-our-startup-has-no-bosses-no-office-and-a-four-day-work-week/
Pour finir, Une parodie de pub pour la smartwatch d’Apple
https://www.youtube.com/watch?t=232&v=mkODFbp2hjc
Enjoy