<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Commentaires sur : Projets sans spécifications détaillées</title>
	<atom:link href="http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/</link>
	<description>Le blog officiel de IP-Tech</description>
	<pubDate>Sun, 05 Feb 2012 06:55:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Par : Amine</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-13151</link>
		<dc:creator>Amine</dc:creator>
		<pubDate>Tue, 14 Sep 2010 14:05:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-13151</guid>
		<description>Dans votre article, vous avez mis en contraste les méthodes de développement  classique (cycle en V, méthode en cascade, etc.) et les méthodes agiles. Les méthodes classiques sont caractérisées par une phase de spécification détaillée dès les phases précoces du développement logiciel. Petite problématique : la réalité est beaucoup plus complexe pour pouvoir tout spécifier et prévoir dès le début et la situation s’aggrave encore lorsque l’équipe technique se penche sur le développement sans une maitrise du domaine fonctionnel et sans être encadrée par un expert fonctionnel. En finit par construire non pas le logiciel demandé par le client mais un logiciel tel qu’il est imaginé par les développeurs logiciel.
Les méthodes modernes, dites agiles, impliquent aussi fort que possible le commanditaire/client dans un processus de développement  itératif et incrémental pour créer une synergie entre l’expert métier et l’expert technique. Cette façon de procéder par itération (de courte durée) permet de construire des prototypes/versions de plus en plus évoluées du système à créer. De cette façon on évite le risque de dérives techniques (les développeurs codent le système tel qu’ils aiment voir au lieu du système que le client aime voir) et aussi aider le client à comprendre ce qu’il veut !!! N’oublions pas que généralement le client n’est pas un expert technique et les dizaines de lignes de spécifications abstraites n'ont pas le pouvoir d’expression d’un logiciel qui tourne devant le client.
Bien sûre il ne s’agit pas de développer dans l’obscurité, les méthodes agiles insistent sur la mise en place d’une architecture logicielle dès le départ, comme précisé dans votre article, flexible et qui s’adapte facilement au changement (dans une certaine mesure bien sûre et n’en pas dans l’absolu).
D’autre part, de mon expérience personnelle relativement courte (3 ans), j’ai remarqué que l’implication du client n’est pas du tout la même dans les différentes phases du projet : le client montre une implication forte et un enthousiasme au début du projet mais malheureusement au fur du temps et l’avancement du projet,  comme si le client se lassait et ce n’est plus la même motivation comme au départ. Faut-il alors réviser les méthodes (agile), qui insistent sur le contact avec le client, pour donner plus  de consigne/d’intérêt à la dimension humaine et les technique de communications  ?</description>
		<content:encoded><![CDATA[<p>Dans votre article, vous avez mis en contraste les méthodes de développement  classique (cycle en V, méthode en cascade, etc.) et les méthodes agiles. Les méthodes classiques sont caractérisées par une phase de spécification détaillée dès les phases précoces du développement logiciel. Petite problématique : la réalité est beaucoup plus complexe pour pouvoir tout spécifier et prévoir dès le début et la situation s’aggrave encore lorsque l’équipe technique se penche sur le développement sans une maitrise du domaine fonctionnel et sans être encadrée par un expert fonctionnel. En finit par construire non pas le logiciel demandé par le client mais un logiciel tel qu’il est imaginé par les développeurs logiciel.<br />
Les méthodes modernes, dites agiles, impliquent aussi fort que possible le commanditaire/client dans un processus de développement  itératif et incrémental pour créer une synergie entre l’expert métier et l’expert technique. Cette façon de procéder par itération (de courte durée) permet de construire des prototypes/versions de plus en plus évoluées du système à créer. De cette façon on évite le risque de dérives techniques (les développeurs codent le système tel qu’ils aiment voir au lieu du système que le client aime voir) et aussi aider le client à comprendre ce qu’il veut !!! N’oublions pas que généralement le client n’est pas un expert technique et les dizaines de lignes de spécifications abstraites n&#8217;ont pas le pouvoir d’expression d’un logiciel qui tourne devant le client.<br />
Bien sûre il ne s’agit pas de développer dans l’obscurité, les méthodes agiles insistent sur la mise en place d’une architecture logicielle dès le départ, comme précisé dans votre article, flexible et qui s’adapte facilement au changement (dans une certaine mesure bien sûre et n’en pas dans l’absolu).<br />
D’autre part, de mon expérience personnelle relativement courte (3 ans), j’ai remarqué que l’implication du client n’est pas du tout la même dans les différentes phases du projet : le client montre une implication forte et un enthousiasme au début du projet mais malheureusement au fur du temps et l’avancement du projet,  comme si le client se lassait et ce n’est plus la même motivation comme au départ. Faut-il alors réviser les méthodes (agile), qui insistent sur le contact avec le client, pour donner plus  de consigne/d’intérêt à la dimension humaine et les technique de communications  ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : FBH (Executive Partner)</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-8902</link>
		<dc:creator>FBH (Executive Partner)</dc:creator>
		<pubDate>Fri, 19 Feb 2010 12:19:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-8902</guid>
		<description>@Adel
Je suis d'accord avec vous, parfois on n'a ni le temps ni les moyens de mettre en place des processus lourd. Donc les méthodes que vous avez citées, sont souvent un bon compromis pour réaliser des livrables de qualités, qui répondent aux besoins des clients sans beaucoup investir dans les spécifications. Bien évidemment, tout cela dépend aussi de la nature du projet, de son contexte et des engagements des différents intervenants.</description>
		<content:encoded><![CDATA[<p>@Adel<br />
Je suis d&#8217;accord avec vous, parfois on n&#8217;a ni le temps ni les moyens de mettre en place des processus lourd. Donc les méthodes que vous avez citées, sont souvent un bon compromis pour réaliser des livrables de qualités, qui répondent aux besoins des clients sans beaucoup investir dans les spécifications. Bien évidemment, tout cela dépend aussi de la nature du projet, de son contexte et des engagements des différents intervenants.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Adel</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-8820</link>
		<dc:creator>Adel</dc:creator>
		<pubDate>Mon, 15 Feb 2010 11:16:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-8820</guid>
		<description>Bonjour,

Dans nos jours, nous pouvons mieux gérer nos projets avec des méthodes qu'on utilise chaque jour. Il s'agit de la méthode Agile avec des scrum et backlogs qui peut vous ider à mettre des objectifs et des priorités.

Merci

 --Adel</description>
		<content:encoded><![CDATA[<p>Bonjour,</p>
<p>Dans nos jours, nous pouvons mieux gérer nos projets avec des méthodes qu&#8217;on utilise chaque jour. Il s&#8217;agit de la méthode Agile avec des scrum et backlogs qui peut vous ider à mettre des objectifs et des priorités.</p>
<p>Merci</p>
<p> &#8211;Adel</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : FBH (Executive Partner)</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-6525</link>
		<dc:creator>FBH (Executive Partner)</dc:creator>
		<pubDate>Fri, 04 Dec 2009 13:42:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-6525</guid>
		<description>Bonjour,

Le rédacteur de cet article est l'un des chefs de projets de IP-Tech.

Honnêtement, on n'a jamais pensé à un générateur automatique de spécifications fonctionnelles. Et je n'ai pas compris ce que vous pourriez mettre en input à un éventuel outil tel que celui que vous recherchez.

Désolé, je ne peux pas aider. Mais si, depuis la rédaction de votre commentaire, vous avez trouvé un outil qui répond à votre besoin (même en parti) n'hésitez pas à partager l'information.</description>
		<content:encoded><![CDATA[<p>Bonjour,</p>
<p>Le rédacteur de cet article est l&#8217;un des chefs de projets de IP-Tech.</p>
<p>Honnêtement, on n&#8217;a jamais pensé à un générateur automatique de spécifications fonctionnelles. Et je n&#8217;ai pas compris ce que vous pourriez mettre en input à un éventuel outil tel que celui que vous recherchez.</p>
<p>Désolé, je ne peux pas aider. Mais si, depuis la rédaction de votre commentaire, vous avez trouvé un outil qui répond à votre besoin (même en parti) n&#8217;hésitez pas à partager l&#8217;information.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : toto</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-6045</link>
		<dc:creator>toto</dc:creator>
		<pubDate>Fri, 13 Nov 2009 14:15:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-6045</guid>
		<description>Merci pour cet article. 

Juste une question , est ce que vous connaissez pas une solution (un soft )qui permet d\'aider à écrire des specs ? 
Je sais que écrire des specs peut être difficilement automatisée, mais on peut au moins décrire les workflows globaux , et les regles métiers, ce qui correspond à 80 % des specs..Je ne sais pas si vous etes d\'accord ?</description>
		<content:encoded><![CDATA[<p>Merci pour cet article. </p>
<p>Juste une question , est ce que vous connaissez pas une solution (un soft )qui permet d\&#8217;aider à écrire des specs ?<br />
Je sais que écrire des specs peut être difficilement automatisée, mais on peut au moins décrire les workflows globaux , et les regles métiers, ce qui correspond à 80 % des specs..Je ne sais pas si vous etes d\&#8217;accord ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : toto</title>
		<link>http://www.iptech-offshore.net/blog/2008/09/12/peut-on-reussir-un-projet-sans-specifications-detaillees/#comment-6042</link>
		<dc:creator>toto</dc:creator>
		<pubDate>Fri, 13 Nov 2009 14:10:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.iptech-offshore.net/blog/?p=24#comment-6042</guid>
		<description>Bonjour,
C'est qui l'auteur de cet artice?
A moins que j'ai pas bien lu , mais je ne trouve nul part le nom de l'auteur.</description>
		<content:encoded><![CDATA[<p>Bonjour,<br />
C&#8217;est qui l&#8217;auteur de cet artice?<br />
A moins que j&#8217;ai pas bien lu , mais je ne trouve nul part le nom de l&#8217;auteur.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

