mardi 8 mai 2007

SQL Server 2005 - au coeur de la bête

Comme dirait Patrick G., "c'est pas gagné!"...
Bon alors quand on renomme une procédure dans SQL Management Studio, le nom est modifié dans sys.objects, mais la définition n'est pas modifiée dans sys.sql_modules. Ca fait que lorsqu'on fait un transfert par SSIS, si par malheur on transfère cette procédure renommée, on va avoir des problèmes, voire une procédure dupliquée, d'où crash de SSIS...

dimanche 6 mai 2007

Recette: que faire avec du nutella

Des tas de recettes (roulé, lait au chocolat, truffes,...) à voir sur le site de l'internaute

samedi 5 mai 2007

5 éléments de négociation et 3 éléments pour souder une équipe

  1. Comprendre : comprendre la proposition et les options disponibles. Savoir ce sur quoi on peut lacher.
  2. Empathie : comprendre les émotions des personnes impliquées
  3. Confiance : typiquement il faut penser et dire: "je comprend qu'il y a un problème, et nous sommes là autour de la table pour le résoudre"
  4. Contribution : cahcune des parties doit contribuer à la définition du problème.
  5. Consensus : la meilleure issue d'une négociation est une négociation gagnant/gagnant
  1. Confiance : faire confiance à son équipe et leur parler ouvertement du problème
  2. Loyauté : toujours protéger son équipe vis à vis des donneurs d'ordre. Une trahison tue la loyauté
  3. Délégation : toujours déléguer autant que possible à ses collaborateurs
Une bonne chose est d'avoir l'intégralité de l'équipe de développement au lancement du projet et au cocktail de fin!

vendredi 4 mai 2007

le mythe du pourcentage

Dire qu'une tâche est complétée à 87,29% n'a aucun sens. Une tâche est finie ou pas. C'est du binaire. Exit donc les outils de pourcentage de ms project. Ce que je préconise est de découper chaque tâche en unités suffisamment fines pour qu'on puisse les associer à un suivi binaire.

jeudi 3 mai 2007

gestion des modifications

Les changements sont inévitables. Sachant cela, il faut absolument être capable de savoir ce qui a été changé.
Le processus de gestion des changements est le suivant:
  • qu'est ce qui peut être modifié
  • comment sont demandés les changements
  • qui peut les accepter ou les refuser
  • comment les approbations et les refus sont-ils consignés?
  • comment sont implémentés les changements et comment leur implémentation est notée?
Une manière de faire:
  1. une fois le cahier des charges signé, toute demande de changement doit m'être adressée par email (nature, raison, urgence)
  2. une commission avec le chef de projet technique valide ou invalide les demandes
  3. la réponse à donner à une demande ne doit pas excéder une semaine.
  4. les changements urgents ou importants doivent être soumis au responsable technique
  5. les changements acceptés sont présentés à la réunion de développement ou assignés directement par des tickets.
Un système de ticket me semble être une bonne solution pour suivre les modifications.

mercredi 2 mai 2007

Gestion des risques

Dans les petits projets, la gestion des risques est intégrée dans le rôle du chef de projet.
Il est bon de faire un document type feuille de calcul incluant: description du risque, frequence/impact, sévérité, spectre d'action, action prise (accepter/réduire...)

lundi 30 avril 2007

reindexer toutes les tables SQL server

exec sp_msforeachtable @command1="print'réindexation de ?' dbcc dbreindex ('?')"

dimanche 29 avril 2007

Créer un budget

Avant tout il faut être pessimiste. Ne prévoir aucun profit et toutes les pertes possibles. Prévoir une grosse marge d'erreur.
Si des modifications de la demande ont eu lieu, il faut noter le changement de façon à pouvoir en tenir compte lors d'une comparaison par rapport au budget initial.
Il y a deux types de coûts:
  1. les coûts tangibles:
    • Capital: hardware, software, bureaux...
    • personnel (salaires)
    • Location (grue)
    • Consulting, avocats...
    • Consommables (dynamite, cdrom,...)
    • Divers : (formations, téléphone, ...) souvent inclus dans les couts de personnel
  2. et les coûts intangibles:
    pas quantifiables. On parle ici du bon vouloir, relations, ambiance, contacts.
Une fois les coûts budgétés, on met en place un suivi de budget régulier pour éviter les dérapages.

samedi 28 avril 2007

La plannification d'un projet

Je contrôle la plannification en:
  • découpant les tâches complexes en sous-tâches quantifiables
  • donnant de la visibilité à des tâches ambigües
  • donnant un point de référence unique pour tous
  • anticipant les aléas
Il doit impérativement figurer dans un planning:
  • Ce qui doit être fait par un cahier des charges fonctionnel et un cahier de spécifications
  • Quand cela doit être fait : par un échéancier
  • Qui doit le faire : d'où un budget du projet
  • Comment le faire : par un cahier de spécifications techniques et un cahier de tests
Il ne faut pas forcément remplir tous ces cahiers avant le début du projet. Un draft du cahier des charges fonctionnel de l'éch"éancier et du budget sont un minimum.

L'art de plannifier
Règle num. 1: ne pas promettre quelque chose qu'on ne peut pas tenir. Si on est obligé de donner une estimation il faut donner un échéancier réaliste ou demander un peu de temps pour le construire.
Règle num 2: Eliminer toutes les incertitudes. Eclaircir tous les points obscurs.
Règle num 3: Prévoir des temps morts pour pouvoir gérer les modifications et aléas. Il vaut mieux les disséminer plutôt que de les grouper à la fin.
Règle num 4: Spécifier le niveau de détail optimum. Pour moi c'est une semaine. Sinon on passe son temps à surveiller le travail des autres.
Règle num 5: Prévoir l'imprévisible. Peut-être en mettant en place la gestion des risques.

Mettre en place un diagramme de Gantt n'est utile que si ce dernier m'aide à créer, surveiller et communiquer une plannification. Sinon ça ne sert à rien d'en faire un.

vendredi 27 avril 2007

quelques erreurs à éviter en réunions et avec des collaborateurs

Pour les réunions:
s'il s'agit d'une information qui ne demande pas de réaction, je privilégie les mails.
Une réunion doit avoir des objectifs clairs et précis et se terminer dans le temps imparti.

Avec les collaborateurs:
  • Erreurs d'indulgence : ne pas éviter à tout prix les conflits.
  • Erreurs de sévérité : savoir mettre de l'eau dans son vin
  • Erreurs de première et dernière impression: noter au fur et à mesure ce que fait chaque collaborateur pour se prémunir des collaborateurs qui ne travaillent qu'à l'approche des primes.
  • Erreurs de représentation : ne pas se raccrocher à des décisions qui ont marché auparavant sans tenir compte de l'évolution du contexte.

mercredi 25 avril 2007

Analyse des besoins

les donneurs d'ordres sont de 3 types:
  • Ceux qui payent les factures: managers impliqués par des objectifs commerciaux
  • Les utilisateurs finaux : c'est eux qui savent le mieux ce dont ils ont besoin, même s'ils ne savent pas très bien l'exprimer. C'est à moi de comprendre ce qu'ils veulent.
  • Les experts : on peut en avoir besoin dans certains projets pointus.
L'analyse des besoins se fait auprès des donneurs d'ordre. Il faut recueillir les besoins, mais pas excessivement. Il faut juste en recueillir suffisament pour que les objectifs soient clairs. Les besoins sont recueillis par des interviews, des quesitonnaires ou par observation des procédures actuelles. En cas de désaccord entre les différents donneurs d'ordres, il faut obtenir un concensus, à savoir:
  • Faire une liste des besoins qui sont en conflit
  • L'organiser par priorité
  • Mettre en adéquation avec le calendrier et scinder la liste en deux par rapport à ce que mon équipe peut produire dans le temps imparti.
  • Les donneurs d'ordre peuvent alors changer les priorités de leur demandes
  • Une fois le concensus a été atteint, le travail peut commencer

Mise en oeuvre de la documentation: j'utilise la méthode SMART et MoSCoW
  • Spécifique : un objectif doit être spécifié sans ambigüité
  • Mesurable : le délivrable doit être quantifiable. Autrement, on ne pourra pas savoir qu'on l'a délivré.
  • A(chievable) : toute tâche doit être réalisable
  • R(elevant) : les spécifications ne doivent pas contenir plus d'information qu'il n'en faut.
  • Testable : les besoins doivent être testables pour qu'on puisse prouver qu'ils ont été satisfaits.
et
  • Must have : sont fondamentaux et indispensables
  • Should have : sont importants mais le succès du projet n'en dépend pas.
  • Could have : on peut s'en passer sans impacter le projet
  • Won't have this time round : ça sera pour la V2
J'ai trouvé un site http://www.dsdmfrance.com/ qui parle d'organiosation en gestion de projet adapté à l'informatique. A regarder...

mardi 24 avril 2007

recette du lassi

  • 6 yaourts natures
  • 1/2 litre d'eau glacée
  • 120 g de sucre
  • 1/4 de cc eau de rose ou 1 goutte extrait de rose ou mangue
  • 1 pincée de cardamone moulue
  • colorant alimentaire rose

lundi 23 avril 2007

quelques règles de gestion de projet

Le chemin critique:
Dans l'ensemble des têches 'un projet, il y a des tâches qui sont sur un chemin dit critique. Elles sont indispensable à la délivrance du produit et le moindre retard sur une de ces tâches retarde l'ensemble du projet. Ces tâches ne devraient donc être modifiées qu'ne dernier recours.

Le mythe des ressources supplémentaires:
Rajouter un, deux ou trois développeurs ne divise pas par 2, 3 ou 4 le temps de développement d'un projet affecté initialement à un seul développeur. Il y a en effet des temps de mise au courant, de communication, des risques de travail en doublon, de versionning du cahier des charges différent, etc.
D'où deux choses à retenir:
1) les petites équipes autonomes sont plus réactives et efficaces que les grandes équipes bureaucratiques.
2) Si je dois rajouter des ressources à un projet, il faut essayer de les y introduire pendant des périodes de creux. Sinon cela risque de diminuer la productivité de l'équipe actuelle pendant un moment....

samedi 21 avril 2007

Mes 10 règles pour réussir une gestion de projet

  1. Connaître mon objectif
  2. Connaître mon équipe
  3. Connaître les décideurs
  4. Passer du temps sur la planification
  5. Promettre d'en faire moins et délivrer plus. C'est toujours mieux que l'inverse
  6. Décomposer le projet en tâches quantifiables
  7. Je vais toujours vers le but sans diverger.
  8. J'ai une approche flexible qui permet d'inclure de petits changements au projet, mais je sais résister aux trop gros changements.
  9. Je teste dès que possible, le plus souvent possible. C'est comme ça qu'on élimine les erreurs
  10. L'objectif est que le client soit satisfait. Je peux sacrifier un un peu de méthodologie au contentement du client

vendredi 20 avril 2007

jouons avec les plots

Voici quelques exercices avec des plots. De quoi avoir le tournis!


On peut jouer aussi avec des caisses.

pompes

Voici quelques variantes pour les pompes. Avec des caisses pour se surélever.

saut en longueur

Voici un exercice pour tonifier les sauts!

Triple saut

Entrainement à l'extension et au saut:

mercredi 18 avril 2007

Un gateau au fromage blanc polonais

Avant de me mettre au régime, je conserve cette recette sur le blog, pour des jours meilleurs...
  • 2 fromages blancs egouttés
  • 200g beurre
  • 8-10 oeufs
  • 1 pot de crème fraiche
  • 325g de sucre glace
  • 1/2 citron
  • 1cc vanille liquide
  • 2cs fécule
  • 2 paquets de petits beurre
  • 1bte de pêches au sirop
Faire fondre le beurre. Le mélanger avec les petits beurre broyés.
Mettre 90% du mélange au fond du gateau dans du papier sulfurisé.
Mettre au frigo 15 minutes

Battre les oeufs en neige.
Mixer la moitié des autres ingrédients pdt 5 minutes.
Mixer l'autre moitié des autres ingrédients pdt 5 minutes.
Introduire la moitié de la neige dans le mixé.
Puis cuire à 180deg 30 minutes
Egoutter le sirop des pêches, couper en fines lamelles.
Mettre les pêches au dessus du gateau, puis la 2ème moitié des blancs puis les 10% restant des petits beurre.
Cuire à 180deg 15 minutes
Laisser refroidir puis mettre au frigo quelques heures

lundi 16 avril 2007

Stop à la réunionite!

Avant de convoquer une réunion
  • Pourquoi une réunion? Je fais un ordre du jour avant d'envoyer les convocations. Je le relis une heure après.
  • Je dois connaitre à l'avance les actions à faire entreprendre
  • Une grande messe ne doit pas se substituer à des entretiens plus ciblés et plus courts.
  • Je fais (faire par qqun de confiance) un compte rendu
  • Je laisse parler chacun de manière équitable
  • Je commence à l'heure et finis en avance par rapport au planning pour prévoir les impondérables.
  • Ne pas diverger. Revenir à l'essentiel.
  • A la fin, je reprends les points, les décisions et les assignations, personne par personne.

- page 3 de 5 -