jeudi 1 novembre 2012

Changement d'horaires mal géré

J'utilise tous les jours l'application Alarmes de mon Windows Phone 7 pour me réveiller à 6h55 (et pour sonner d'ailleurs toutes les 6h).
Or, lors du changement d'horaires, j'ai été très surpris car l'application n'a pas fonctionné.
Heureusement, je me suis réveillé tout seul juste un peu plus tard.

Fan de cet OS de Microsoft pour smartphone (interface claire, intuitive, facilement personnalisable, peu de bugs), j'ai été assez déçu, car je me souviens que l'iPhone a eu le même souci.

mardi 7 août 2012

Visual Studio 2012 RC - première impression.

Je viens juste d'installer Visual Studio 2012 RC qui est sortie le 31 mai dernier (avec donc un peu plus de 2 mois de retard...).

J'aurai pu vous parler des divers évolutions (ce que je ferais surement dans des prochains posts), mais je voulais juste vous donner ma première impression :
Personnellement, je suis un peu déçu sur le look graphique très terne.

Jugez par vous même :

 En haut Visual Studio 2012 RC, et la version précédente Visual Studio 2010.




Je vois bien l'envie de s'orienter vers Metro, mais je trouve finalement que l'interface y perd en lisibilité.
D'un autre côté, j'ai l'impression que plus de choses sont affichés à l'écran grâce à une police et des boutons moins gourmands en place.
Mais, le manque de couleurs détériore la lisibilité.

Je compte l'utiliser pendant quelque temps, je vous ferais d'autres retours sur l'outil, mais n'hésitez pas à donner votre avis.

samedi 4 août 2012

Non duplication de code - Design Patterns - Chaîne de responsabilité

Il arrive souvent que du code soit dupliqué.
Cette pratique est à bannir car à chaque évolution, le développeur est obligé de modifier l'ensemble des copies du code.
La bonne démarche consiste à mettre à disposition le code dupliqué à un seul endroit, et de l'appeler autant de fois que nécessaire.
Ceci arrive souvent avec l'implémentation de la chaîne de responsabilité
La chaîne de responsabilité (ou chain of responsability) est un design pattern.

Vous pouvez trouver une implémentation de ce dernier sur le site dofactory.com.

Ce dernier permet donc de consulter un ensemble d'objets pouvant répondre à une même requête, tout en construisant la chaine d'objets consultés dynamiquement.


 
Chaque objet consulté implémente donc la même interface que la classe Handler. Ces objets sont souvent sollicités de même façon
  • Il teste la requête pour savoir si elle le concerne.
    • Si oui, il exécute sont traitement.
    • Si non, il transmette au suivant. 
Pour illustrer, lorsqu'on vous demande quelque chose soit vous savez et vous traitez, soit vous ne savez pas alors vous transmettez la demande à votre chef. Ce dernier fera de même avec la demande, ainsi de suite jusqu'à trouver la personne compétente pouvant la traiter.
Malheureusement ce schéma (souvent présent), est majoritairement dupliqué dans chaque classe dérivant d'Handler.

Afin d'éviter le copier-coller, sachant que chaque informaticien devrait être payé à la ligne de code qu'il n'écrit pas, j'utilise une classe intermédiaire évitant cette duplication.

En reprenant l'exemple de chez dofactory cela donne  pour la classe intermédiaire :

Et par conséquent les handlers concrets donnent, par exemple pour ConcreteHandler1 :
pour les autres, il suffit de changer le ConcernTest

Évidemment dans l'exemple ici,  l'Action est identique, mais dans une utilisation réelle cette méthode serait spécifique.

Nous avons donc réussi notre objectif, à savoir éviter de dupliquer la méthode HandleRequest.

mercredi 4 juillet 2012

Quelle date doit annoncer le SCRUM product owner pour la livraison d'un nouveau produit?

Je suis tombé sur un article écrit par Sébastien Boyer :
Comment le Scrum Product Owner peut définir la date d’une livraison(release) d’un nouveau produit ?

Il pose bien cette problématique: comment alors même que le principe de SCRUM est de faire une guidance globale et en parallèle itérative, comment donner une date de sortie du produit?

Soit, nous avons un accord pour une date et dans ce cas, il y a une volonté de l'équipe d'y inclure le plus grand périmètre de fonctionnalités.
Soit il y a un accord/objectif sur un périmètre de fonctionnalités, dans ce cas la date sera celle qui permettra d'obtenir ces objectifs au plus tôt.

Tout ceci semble donc effectivement perturbant car nous n'avons pas d'engagement fort date-périmètre.

Pour ma part, je pense qu'il y a deux axes qui aident dans ce domaine.

Premier, les reviews permettent de présenter le résultat à tous.
Si le sponsor ne vient pas, il faut tout mettre en place pour lui communiquer les résultats.
S'il ne vient jamais, il y a un risque important pour le projet (un sponsor qui ne suit pas son projet ne présage rien de bon quelque soit la méthode).

Le second, est le principe d'adaptabilité de l'agilité. Il y a une tendance à avoir toujours des œillères et de ne pas vouloir utiliser les méthodes classiques. Il n'y aucune raison de ne pas faire une estimation globale du projet initial à la méthode cycle en V et de communiquer dessus, en expliquant que c'est une estimation. Celle-ci sera revue à chaque itération, et les sponsors seront informés!
Le fait de casser l'effet tunnel et la communication autour, fait qu'il y a moins de surprise au final.

En général un sponsor impliqué et informé, lorsque les échéances approchent ou le budget diminue, arrive plus facilement à faire des choix... 


La communication  est primordiale

L'oeuf ou la poule?

L'ascension des nouvelles technologies (Internet, les ordinateurs nomades, les smartphones...) a changé beaucoup de choses.
Aujourd'hui, nous sommes toujours en contact tout le temps avec tout le monde, l'information, nos e-mails, nos applications, nos e-amis...et pour une bonne raison nous avons aujourd'hui des services qui n'existaient pas auparavant.

Parallèlement à cela, le rapport des professionnels vis à vis de leur public a changé :
Nous sommes également en contact permanent avec eux, et de plus nous pouvons nous exprimer directement.
Certains le déplorent. Nombre de marques ont l'impression de ne plus être maîtres de leur communication. D'autres, bien au contraire, incitent leurs clients, que dis-je leur fans, followers, à communiquer sur eux.
Ceci a d'ailleurs permis l'arrivée de "nouveaux" métiers comme évangélistes ou community managers. Je ne m'étendrai pas sur ce dernier point qui est un autre vaste sujet.

Cette constatation va de paire avec une autre, celles de l'évolution des méthodes de travail (dans le secteur de l'informatique).
Effectivement, il y a une croissance très nette des méthodes agiles et des outils qui leurs sont associées.

En effet, aujourd'hui nous avons besoins de mettre continuellement à jour nos versions. Beaucoup plus facile avec le dématérialisé, plus de CD à envoyer sous presse, à distribuer...
Ce rythme fréquent de livraison est facilité par deux éléments :
  • La gestion itérative des projets ou lotissement.
  • Les outils de builds et tests automatisés.
Mais est-ce l'évolution des besoins qui a provoqué une évolution de la technique et de sa gestion, ou l'inverse?

Lorsque nous regardons un peu l'historique des méthodes agiles nous remarquons que leur début dans les années 1950s avec le Lean Thinking, et que SCRUM la méthode la plus en vogue actuellement a débuté il y a 20 ans (1992). Ces méthodologies ne sont donc pas la conséquence directe de l'évolution de la e-société.

Le contraire n'est pas vrai également, car si nous regardons en arrière et le minitel et le début de l'Internet, il existait déjà (à très faible dose) des e-communautés.

La réalité est que nous assistons à un cercle vertueux (ou vicieux) où les avancés des uns permettent les désirs des autres, et où les désirs de certains nécessites les avances des autres.

Pour ma part, c'est ce que j'ai constaté, j'ai été tour à tour moteur, ou tracté, innovateur ou suiveur, mais l'important est que tout cela m'a permis d'aller de l'avant...

mercredi 13 juin 2012

Contrat agile

Jeudi et vendredi dernier, j'ai donné une formation Scrum.
Une question est revenue régulièrement : la contractualisation.

Habituellement, nous proposons dans ce cadre des contrats itératifs reconductibles : à chaque itération le client peu le reconduire avec le contenue de backlog de sprint.
Une clause de "Money for nothing" ou "Gagnant-gagnant" en français peut être également utilisé. Le client peut arrêté le contrat à chaque itération. Les fonctionnalités non réalisées sont, dans ce cas, payés à 20% :
  • Le client est content car le produit correspond à son besoin.
  • L'équipe a été payé 20% du budget restant sans rien faire.
Du coup, j'ai poussé un peu ma recherche pour mes élèves.Elle m'a  conduit sur un modèle gratuit de contrat agile au forfait que je vous laisse consulter : http://contrat-agile.org/
Ne l'ayant pas utilisé, je n'ai pas d'idée concrète sur son utilisation. Je trouve l'intention louable, et si l'occasion se présente, je pense le proposer.

Si vous avez des retours, ou un avis sur la question n'hésitez pas.

Pewem.

Bienvenue sur mon Blog.

A l'instar d'autres blogueurs, je vous parlerais de mes centres intérêts : informatique, technologies et jeux.
N'hésitez pas à me faire vos retours.
En tout cas je vous souhaite la bienvenue sur mon Blog.

Pewem.