De retour de vacances, je me retoruve avec quelques e-mails à traiter. le grand question : LIFO ou FIFO ???

Mon conseil est d'utiliser la méthode LIFO: vous allez rapidement découvrir qu'il est plus efficace de traiter les derniers messages arrivées en premiers, ceux-ci étant probablement le résultats de nombreux échanges (discussion thread), et toutes les informations seront traitées en une seul fois ...

Ok, mon application de test "LinkSquare - LinkedIn Client For WP7" est passée à travers le cycle de certification du Marketplace Microsoft. Elle est disponible en download via l'application Zune ou directement sur votre mobile.

N'hésitez pas à me contacter pour me donner un feed-back ou des idées d'améliorations.

Voici comment naviger vers une page dans une application Windows Phone.

Naviguer vers une page se fait via la code suivant:

NavigationService.Navigate(new Uri("/ContactDetail.xaml", UriKind.Relative));

Pour passer un paramètre, il suffit d'utiliser la notation "?Param=value" :

NavigationService.Navigate(new Uri("/ContactDetail.xaml?ID=1234", UriKind.Relative));

Pour récupérer ce paramètre dans la page ContactDetail:

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
        {
            base.OnNavigatedTo(e);
            String id = NavigationContext.QueryString["ID"];
}

Pour commencer, une référenciel des themes de Windows Phone 7. Pour développer malin, et alliquer le même theme partout (ex: PhoneFontSizeMedium qui donnera une police 17pt).

Ensuite, toujours concernant les themes, un visuel des couleurs par défaut de Windows Phone 7. Toujours voulu savoir la différence entre RoyalBlue et PowderBlue ?

Voici une méthode relativement simple :

1. Dans l’onglet « Insert », sélectionner « object »
2. Choisir « OpenDocument ». Un nouveau document embarqué va être ouvert
3. Copier/coller le code dans ce nouveau document
4. Fermer le document.

Le document étant séparé du document parent, la police, couleur, formatage est conservé et n’a pas d’impact sur le document parent.

Simple et facile.

Je suis resté bloqué sur une erreur étonnante ce matin : Après avoir débuté un projet de dev sous SharePoint, lors de l’exécution le JIT me retournait l’erreur FileNotFoundException lors de l’ouverture du site.

(using(SPSite  site = new SPSite(“http://demo”))

Quelques recherches plus tard, il semblait que cela soit dû à des problèmes de droits. Mais tout était correcte de ce côté.

La solution était plus étonnante :

•  J’ai changé la platforme cible de de Any à 64x (mon serveur de dev est en 64bits)
•  J’ai changé la version de .Net de 4 à 3.5

Et la solution recompile correctement  …

Un Scrum Handbook est disponible sur le site web de Jeff Sutherland.

http://bit.ly/iNi7YU

Murder board est un terme initialement utilisé par l’armée américaine. Il s’agit de mettre les aspirants  instructeur s en situation réel, non pas face à des recrues, mais face à des instructeurs chevronnés. Ceux-ci vont simuler des situations/événements et évaluer le comportement des aspirants.

Quel rapport avec la gestion de projet ?

Les organisations ont généralement plusieurs projets en concurrence dans leur pipe-line. Comment sélectionner celui qui sera réalisé en priorité ? Une des méthodes et le Murder board, soit un comité qui pose une série de question au représentant du projet (généralement le sponsor, mais cela peut aussi être le chef de projet), afin de mesurer le bénéfice de la réalisation de celui-ci. Le but ultime étant de démontrer l’inutilité du projet. La même méthode étant utilisée sur les projets concurrents, celui apportant le plus de bénéfice à l’organisation (économie réalisée,  augmentation de la productivité, gains de part de marché…)

En terme PMI, on perlera de Benefit measurement method (comparative approach)

La planification traditionnelle (waterfall) d’un développement logiciel peut être comparée à un voyage en voiture. Le chef de projet s’appuie sur une méthodologie et les expériences passées afin de définir un plan expliquant, étape par étape, les directions à prendre, les différents obstacles qui vont être rencontrés et comment les appréhender, et le rôle des membres de l’équipe (je conduis, tu tiens la carte, qui s’occupe de la subsistance …). La distance étant connue, une règle permet de calculer le coût. Les limitations légales de vitesses étant connues, le temps du parcours peut être calculé. De plus, la qualité (se rendre du point A au point B) fait partie des spécifications initiales. Le triangle du projet est donc connu.

Lorsque l’équipe de projet démarre son voyage du point A, la densité du  trafic peut déprendre  de l’horaire. La vélocité calculée peut-être, sur certains tronçons, bien en deçà de la vélocité planifiée. De plus, l’équipe peut faire face à des obstacles non planifiés : le plan me dit de prendre la première sortie au rond-point, mais des travaux m’en empêche. Que faire, et le plan qui ne donne pas de solution. La voyage prend du retard … De plus, le plan, basé sur l’expérience d’un trajet  passé, indique un raccourcit. Problème : entre-temps la signalisation a été changée, et la route n’est plus utilisable. Les coûts et délais prennent l’ascenseur. Tout cela sans imager un changement dans la qualité (tout compte fait, après trois jours de voyage, le client décide de faire un léger détour par une région limitrophe …), et la rendement de l’équipe (le chauffeur, un membre de l’équipe,  se fatigue après 2 heures de conduite, et perds sa concentration). Le modèle traditionnel montre donc ses limites.

Le chef de projet ne comprend pas : il a utilisé une méthodologie réputée, et l’a suivi à la lettre. Puis il se tourne vers l’équipe de projet, qui forcément n’a pas suivi le plan … Alors que celle-ci a simplement dû faire face, durant la vie du projet, à une série de problèmes l’empêchant d’avancer. Et elle a fixé ces problèmes, tout en suivant, le mieux possible, le plan définit.

Comme l’a dis Eisenhower : “No battle was ever won according to plan, but no battle was ever won without one” .

Un mixe d’une technique d’estimation (temps) des tâches et des mathématiques des probabilités donne une règle relativement simple :
• Dans 99,73% des cas, la tâche sera terminée dans le temps estimé +- 1 déviation standard
• Dans 95,44% des cas, la tâche seta terminée dans le temps estimé +- 2 déviations standard
• Dans 68,26% des cas, la tâche sera terminée dans le temps estimé +- 3 déviations standard

La probabilité que l’estimation initiale soit correcte est donc très faible.

Prenons donc l’exemple d’une tache A : réalisation d’une application mobile.

La technique d’estimation de la tâche est la technique dite des trois points : l’estimation est effectuée par trois sources différentes. Cela donnera trois valeurs :
1. Optimiste (38 jours) : Dans notre exemple, un développeur qui désire ardemment effectuer ce développement et donc qui inconsciemment sous-estime la tâche afin d’obtenir le travail
2. Pessimiste (57 jours) : Dans notre exemple, un développeur qui ne désire pas effectuer ce développement et qui donc surestime la tâche afin qu’elle ne lui soit pas attribuée.
3. Moyenne (45 jours) : L’estimation normale

La formule pour obtenir l’Expected Value est la suivante :
(Optimiste + Pessimiste + (4 * Moyenne)) / 6
Soit :
EV = (38 + 57 + (4 * 45)) / 6 = 45.83 jours

La formue pour obtenir la Deviation Standard est la suivante :
(Pessimiste - Optimiste) / 6
Soit :
SD = (57 – 38) / 6 = 3.17 jours

Pour reprendre la règle ci-dessus :
• Il y a 68,26% de probabilité que la tâche soit effectuée entre 42.66 et 49 jours
• Il y a 95,55% de probabilité que la tâche soit effectuée entre 39.49 et 52.17 jours
• Il y a 99,73% de probabilité que la tâche soit effectuée entre 36.32 et 55.34 jours