Agile en environnement onshore/offshore – Agile in an onshore/offshore environment

Excellent article dans la newsletter du mois de juin du chapitre PMI de Bombai en Inde (pages 16 à 18). Comment implémenter une approche agile de type Scrum dans un environnement où une partie de l’équipe est offshore? Un retour d’expérience vu depuis le coté offshore pour une fois. Voilà qui devrait intéresser beaucoup d’entre nous qui avons des équipes distribuées sur plusieurs pays et continents!

You will read a very good article in the PMI Mumbai’s newsletter on pages 16 to 18. How can an Agile approach such as Scrum be implemented with success in an environment where part of the team is offshore? An experience sharing that is coming from the offshore side this time. This shall be of interest to many of us who run teams distributed across several countries/continents.

http://64.78.9.230/sharepoint/mumbai/documents/Shared%20Documents/June_2009.pdf

Agile 2

Function Points Analysis basics

tout savoirUn bon article d’introduction et de démystification de cette technique d’estimation des points de fonction qui est très répandue pour l’évaluation des charges de développement logiciel (documentations et tests compris).

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/512/Software-Sizing-During-Requirements-Analysis.aspx

1 heure sur SCRUM – video – 1 hour worthwhile investment

http://www.betterprojects.net/2009/02/schwaber-on-scrum.html

scrum

Ken Schwaber a co-développé le processus Agile, Scrum. Il est un fondateur de l’Alliance Agile et l’Alliance Scrum et signataire du Manifeste Agile.

Dans cette heure de présentation, Ken partage un peu de son expérience pratique de Scrum. Il fournit des idées sur comment utiliser Scrum au mieux et parle aussi des raisons de certains des principes de l’approche comme timeboxing, les Équipes fonctionnelles mixtes, la transparence, …

Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto.

In this hour of presentation, Ken shares some of his practical experience with Scrum. He provides hints on how to best use Scrum and also talks about the reasons behind some of the approach’s principles like timeboxing, Cross functional Teams, transparency, …

Et n’oubliez pas, si vous n’avez que 8 minutes: http://www.pmthink.com/2008/12/agile-scrum-primer.htm

Modèles gratuits de documents projet sur IIL – Free PM Documents Templates

IIl_free_resourceshttp://www.iil.com/freeresources/templates.asp

Charte de projet Project Charter: This document formally describes and authorizes work to be performed on a project, phase or set of phases.
Documentation des exigences Requirements Overview: This report serves as a repository for the known information about a specific business opportunity or requirement. It will become a historical document, added to the project file should a decision be made to be proceed.
Registre des problèmes Project Issues Log: This form tracks all elements associated with issues including status, priority, assignment, description, resolution and more.
Matrice d’affectation des responsabilités Responsibility Assignment Matrix: This report tracks resources with tasks using a scale to indicate the specific responsibility of the resources assigned.
Plan de réponse aux risques et registre des risques Risk Response Plan and Register: This document reports risk events along with probability, impact overall risk, risk response and ownership.
Modification du contenu Scope Change: This template includes fields for description of change and justification as well as cause, technical response, effort and authorization.
Énoncé des travaux Statement of Work: This document allows you to succinctly present the description of the project including itemized descriptions of major deliverables.
Demandes de modification Plan Change Request: This report presents project requests for additional funding and/or time extensions.
Préparation de réunions Effective Meetings: This form itemizes project manager and team responsibilities in meetings as well as the process for running effective meetings.
Tableau de bord du chef de projet Project Manager’s Dashboard: This document offers a weekly ready reference covering risks, issues, daily and weekly tasks, plus other activities performed by a project manager to keep his/her project aligned and focused.

iil_logo

Modèles de Plan de Projet par Microsoft – MS Project Plan templates

Microsoft publie quelques modèles de plan de projet standards gratuitement.Certains ne fonctionnent qu’avec MS Project 2007 disponible à l’essai gratuit sur le site.

Le modèle « plan d’amélioration de processus » semble assez bien construit.

Microsoft has published a few free project plan templates. Some will work only with MS Project 2007 which is available for evaluation on the web site.

The « Process Improvement Plan » appears to be quite relevant.

  • plan annuel d’administration
  • développement d’application Internet/web
  • plan d’amélioration de processus
  • développement logiciel
  • extension de bâtiments
  • lancement de nouveau projet
  • évaluation de produit après lancement
  • fusion et acquisition
  • évaluation et consolidation de fournisseur
  • Government Annual Planning
  • Internet Web Development
  • Process Improvement Plan
  • SW Development
  • Facilities Expansion
  • New Project Launch
  • Product Evaluation Post Launch
  • Strategic Merger and Acquisition
  • Vendor Evaluation and Consolidation

http://www.easierwithproject.com/en-us/Pages/tl_resources.aspx

msproject

Quelques modèles de Project Plan par Microsoft

http://www.easierwithproject.com/en-us/Pages/tl_resources.aspx


Microsoft publie quelques modèles de plan de projet standards gratuitement. Certains ne fonctionnent qu’avec MS Project 2007 disponible à l’essai gratuit sur le site. Le modèle « plan d’amélioration de processus » semble assez bien construit.

Microsoft has published a few free project plan templates. Some will work only with MS Project 2007 which is available for evaluation on the web site. The « Process Improvement Plan » appears to be quite relevant.

Ø plan annuel d’administration

Ø développement d’application Internet/web

Ø plan d’amélioration de processus

Ø développement logiciel

Ø extension de bâtiments

Ø lancement de nouveau projet

Ø évaluation de produit après lancement

Ø fusion et acquisition

Ø évaluation et consolidation de fournisseur

Ø Government Annual Planning

Ø Internet Web Development

Ø Process Improvement Plan

Ø SW Development

Ø Facilities Expansion

Ø New Project Launch

Ø Product Evaluation Post Launch

Ø Strategic Merger and Acquisition

Ø Vendor Evaluation and Consolidation

Formation Projet / Project Management Training : Risk Doctor webinars

riskdoctorSi vous ne connaissez pas encore David Hilson, ne manquez pas cette opportunité d’écouter ses conseils. If you have not yet heard of David Hilson, join him on one of his webinars, for free.

Risk Doctor Webinars: http://www.risk-doctor.com

Des webinars gratuits d’une heure qui nécessite l’installation de WebEx player (http://www.webex.com/lp/player/download.html )

Agile ou en Cascade / Agile versus Waterfall

J’ai apprécié la comparaison terre à terre des approches et les commentaires  de la présentatrice sur la mise en place de l’approche agile pour des sociétés qui viennent d’un modèle en cascade (concept, analyse, design, construction, livraison) traditionnel. ScreenShot34 I greatly appreciated this comparaison of the two approaches. The practical comments of the author on the implementation of  the agile approach for companies coming from a traditional waterfall model (concept, analysis, design, build, deliver).

http://www.cardinalsolutions.com/CORUG/presentations/Planning%20Iterative%20Development%202006%2002%2023%20Final.pps#256,1,CORUG

by Annie Kerregan of Cardinal Solutions on project planning for iterative style projects versus Waterfall traditional projects.

« Lean » versus « Six Sigma » or « Lean Six Sigma » ?

Nous entendons souvent ces termes dans l’entreprise: Lean, Six Sigma. Ils sont quelquefois utilisés de manière interchangeable, d’autres fois opposés. En fait, ils se réfèrent à deux méthodes distinctes qui lorsqu’elles sont utilisées conjointement se complètent en Lean Six Sigma.L’article ci-dessous, truffé de pointeurs vers des documents plus détaillés, permet de mieux comprendre les différences et l’intérêt de ces deux approches.

Six Sigma?

TQM?

BPM?

BPR?

In business, we often hear the terms Lean and Six Sigma mentioned. They are often used interchangeably other times opposed. Actually, they refer to two different methods that can be combined for greater effects and then called Lean Six Sigma.The article is rich of pointers to more detailed papers to better understand the differences and benefits of the two approaches.

Il y a beaucoup de discussions et souvent de la confusion sur la différence entre Lean et Six Sigma. En général, voici l’essence des deux approches :

  • Lean = flux de processus Amélioré
  • Six Sigma = variation de processus Réduite

http://pmcrunch.com/certification/lean-versus-six-sigma/#more-357

Comparatifs Outils de PM / PM Tools comparison

compareListe de logiciel en management de projet / List of project management software reviews:

et bien sûr / plus, of course: http://en.wikipedia.org/wiki/List_of_project_management_software

Scrum en 8 minutes max / Scrum in less than 8 minutes

SCRUM: Les concepts en moins de 8 minutes

http://www.pmthink.com/2008/12/agile-scrum-primer.htm

Une excellente vidéo pour appréhender les concepts Scrum en 7 minutes et 59 secondes. A great video to grasp the concepts of Scrum in 7 minutes and 59 Seconds !
Un bon investissement. L’auteur passe en revue les fondamentaux de Scrum. Depuis la liste des besoins (le product backlog) jusqu’au contenu de version (Release backlog) et aux Sprints (découpage d’une version en plusieurs livrables). video I found the video really worth watching. The author takes us through the very basics of Scrum. Starting with a product backlog (list of requirements) to a Release Backlog (what you’ll embark on the next product release) to Sprints (breakdown of the release into multiple work packages).
Il nous parle également de 2 méthodes très utiles pour contrôler l’avancement: les « Burn Down charts » qui représentent visuellement le reste à faire pour compléter chaque livrable et version. Et le superbe concept des meeting journaliers debout pour continuer à avancer rapidement. burn down chart It also covers 2 useful methods to control progress: Burn Down charts that visually represent remaining work to be done to complete each spring and release and a wonderful concept of daily standing meetings to keep moving fast.

Théorie de la valeur acquise / Earned Value theory and techniques

earned valueEarned Value: La théorie et techniques expliquées concrètement et simplement.

Le tout à partir de l’exemple très compréhensible de la construction d’un mur autour d’un jardin…

Let’s imagine our project is to build a wall around a garden…

http://leadinganswers.typepad.com/leading_answers/2009/04/the-simple-guide-to-earned-value.html

résolution de problème en 7 étapes / 7 steps to problem resolution

7 étapes pour résoudre un problème

7 Steps problem resolution

1 Définir précisément le problème Define/scope problem
2 Décrire la situation actuelle – Collecter les données et composer l’équipe Describe current situation – Gather data and team
3 Identifier/Analyser/Confirmer la raison « racine » avec des faits concrets Identify/Analyze/confirm root cause with data
4 Implémenter (piloter/essayer) une ou plusieurs solutions Implement (pilot) solutions
5 Évaluer les résultats Evaluate results
6 Standardiser les méthodes qui marchent Standardize effective methods
7 Communiquer les résultats obtenus / Leçons apprises Communicate results / Lessons learned

1234

épeler comme un pilote / to spell like a pilot

Letter    NATO & international aviation

A         Alfa

B         Bravo

C         Charlie         ScreenShot14

D         Delta

E         Echo

F         Foxtrot

G         Golf

H         Hotel

I          India

J          Juliet

K         Kilo

L         Lima

M        Mike

N         November

O         Oscar

P         Papa

Q         Quebec

R         Romeo

S         Sierra

T         Tango

U         Uniform

V         Victor

W        Whisky

X         X-ray

Y         Yankee

Z         Zulu

Liste de lecture SCRUM / SCRUM Reading List

The « Better Projects » Scrum Reading List par Craig Brown

http://www.betterprojects.net/2009/05/better-projects-scrum-reading-list.html

books– Les bases / The Basics
– Lectures avancées / Advanced Reading
– Jalons et cérémonies / Process Milestones and ceremonies
– Les Rôles / Roles
– La gestion des exigences / Requirements Management
– Estimer / Estimating
– Planifier les releases / Release planning
– Test et qualité / Testing and Quality
– Erreurs potentielles / Scrum smells
– Amélioration continue / Personal improvement
– Implémenter scrum / Implementing SCRUM
– Encore plus… / More…

conseils pratiques sur le WBS/practical tips on WBS

trucs et astuces

Bonjour,

Voici ce que j’utilise comme principes de base lorsque je conçois ou revois le niveau de détail d’un Work Breakdown Structure (WBS):

1. Une tâche devrait être nommée avec un unique verbe actif. Exemple: Réaliser le design et développer un bout de code informatique devrait être séparé en 2 tâches: une pour le design et une pour le développement.

2. Une tâche devrait résulter en la production d’un unique livrable (une documentation, un document d’analyse, un programme informatique…)

3. Une tâche devrait être la responsabilité d’une seule personne.

4. Une tâche devrait permettre une évaluation d’effort/de temps avec un niveau de confiance très élevé

plus de détails sur: http://blogs.orange-business.com/live-france/2009/09/une-approche-pour-construire-une-structure-de-decoupage-de-projet-efficace.html

Hello,

Here a few principles I use when building or reviewing the level of details of a Work Breakdown Structure (WBS):
1. A task should be named with a unique active word. Example: Design and code a software programme should be split in 2 tasks: one for the design and one for the coding.

2. A task should produce a single deliverable (a documentation, an analysis paper, a software programme…).

3. A task should be the responsibility of a single person.

4. A task should enable an estimate of time and effort with a very high degree of trust

further details at:

http://blogs.orange-business.com/live/2009/09/simple-advice-to-build-efficient-ptoject-work-breakdown-structure.html

Liste de logigiels Project Management Software list

wikipediahttp://en.wikipedia.org/wiki/List_of_project_management_software

Une liste de logiciels en management de projet assez complète qui catégorise les logiciels en fonction de leurs capacités en:

· Gestion de projet

· Outil de collaboration

· Suivi des problèmes

· Gestion de portefeuille de projet

· Gestion des ressources

· Gestion de la documentation

This PM Software list is quite complete and specifies for each tool the categories of needs it can cover:

· Project Management

· Collaboration tool

· Issue tracking

· Project portfolio management

· Resource management

· Document management

http://en.wikipedia.org/wiki/List_of_project_management_software

Une liste de logiciels en management de projet assez complète qui catégorise les logiciels en fonction de leurs capacités en:

· Gestion de projet

· Outil de collaboration

· Suivi des problèmes

· Gestion de portefeuille de projet

· Gestion des ressources

· Gestion de la documentation

This PM Software list is quite complete and specifies for each tool the categories of needs it can cover:

· Project Management

· Collaboration tool

· Issue tracking

· Project portfolio management

· Resource management

· Document management

Processus de validation de document / Document validation process

toolbox

Les chefs de projet ont assez souvent des documents à préparer et à valider avant diffusion. Voici un processus très simple qui permet de structurer son approche.

PMs often have documents to prepare and validate before communication. Here is a very simple process to structure your appraoch.
Processus de validation de document
1. Préparer le document
2. le Revoir avec qui de droit
3. Mettre à jour le document
4. Approuver / Obtenir l’approbation du document
5. le communiquer
Document Validation Process
1. Prepare
2. Review
3. Update
4. Approve
5. Communicate

Scrum: Liste de lectures / Reading List

Scrum: The Better Projects Scrum Reading List

scrum

  • Les bases
  • Lectures avancées
  • Jalons et cérémonies
  • Les Rôles
  • La gestion des exigences
  • Estimer
  • Planifier les releases
  • Test et qualité
  • Erreurs potentielles
  • Amélioration continue
  • Implémenter scrum
  • Encore plus

Posted by Craig Brown