Comments on: Change Management : A Catch-22 http://francoisaubin.com/2007/09/05/change-management-a-catch-22/ Ensure useful and usable solutions Fri, 28 May 2010 15:56:30 +0000 hourly 1 http://wordpress.com/ By: Leading change: the practitioner’s view « User Experience and Cognitive Engineering http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-475 Leading change: the practitioner’s view « User Experience and Cognitive Engineering Thu, 03 Jan 2008 12:57:34 +0000 http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-475 [...] people agreeing on the current situation and the course of actions. In business transformation (change Management), facts are more than data, facts are like an observable situation that can be described and [...] [...] people agreeing on the current situation and the course of actions. In business transformation (change Management), facts are more than data, facts are like an observable situation that can be described and [...]

]]> By: Francois Aubin http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-430 Francois Aubin Mon, 10 Dec 2007 15:35:42 +0000 http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-430 Nous avons expérimenté (œuvré) dans divers contexte de développement : Waterfall, spiral, RUP, agile (AUP et XP) mais pas formellement SCRUM. Nous avons aussi appliqué notre approche à l’optimisation des processus, la conception de produits physiques, l’aménagement physique la conception de systèmes complexes et la formation. En informatique, l’approche agile est la moins mauvaise des approches. A notre avis, aucune des approches informatique ne permet de spécifier les besoins correctement. Souvent, les informaticiens laissent aux analystes d’affaires ou aux clients ce problème. Une méthodologie que ce soit Rational, ou XP, etc. n’adressent qu’en surface les problèmes. L’approches agile par la plus grande rapidité d’essais et erreurs accélèrent le développement. Elle n’adresse pas l’essence du problème qui est l’incertitude des besoins. Elle semble même une réaction (saine) à la bureaucratie engendrée par les Waterfall. A notre avis, le problème est bien plus l’incertitude d’analyse des besoins qu’une question de méthodologie de développement Nous avons démontré au cours de nombreux projets que par une analyse cognitive et de la simulation en avant projet (avant que le budget et le projet de développement) permettent de réduire presque complètement l’incertitude Nous avons expérimenté (œuvré) dans divers contexte de développement : Waterfall, spiral, RUP, agile (AUP et XP) mais pas formellement SCRUM. Nous avons aussi appliqué notre approche à l’optimisation des processus, la conception de produits physiques, l’aménagement physique la conception de systèmes complexes et la formation.

En informatique, l’approche agile est la moins mauvaise des approches. A notre avis, aucune des approches informatique ne permet de spécifier les besoins correctement. Souvent, les informaticiens laissent aux analystes d’affaires ou aux clients ce problème. Une méthodologie que ce soit Rational, ou XP, etc. n’adressent qu’en surface les problèmes.

L’approches agile par la plus grande rapidité d’essais et erreurs accélèrent le développement. Elle n’adresse pas l’essence du problème qui est l’incertitude des besoins. Elle semble même une réaction (saine) à la bureaucratie engendrée par les Waterfall.

A notre avis, le problème est bien plus l’incertitude d’analyse des besoins qu’une question de méthodologie de développement

Nous avons démontré au cours de nombreux projets que par une analyse cognitive et de la simulation en avant projet (avant que le budget et le projet de développement) permettent de réduire presque complètement l’incertitude

]]> By: Jean-Pierre Dufour http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-429 Jean-Pierre Dufour Mon, 10 Dec 2007 14:13:18 +0000 http://francoisaubin.com/2007/09/05/change-management-a-catch-22/#comment-429 Avez-vous déjà expérimenté vos techniques avec des approches de développements de systèmes traditionnels (waterfall) et celles dites Agile (ex: Scrum)? Est-ce que l'une s'est montrée plus appropriée par rappport à l'autre? Avez-vous déjà expérimenté vos techniques avec des approches de développements de systèmes traditionnels (waterfall) et celles dites Agile (ex: Scrum)? Est-ce que l’une s’est montrée plus appropriée par rappport à l’autre?

]]>