<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet title="XSL formatting" type="text/xsl" href="http://agilitateur.azeau.com/feed/rss2/xslt" ?><rss version="2.0"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>L'Agilitateur - Exprimer ses besoins  - Commentaires</title>
  <link>http://agilitateur.azeau.com/</link>
  <atom:link href="http://agilitateur.azeau.com/feed/rss2/comments/65" rel="self" type="application/rss+xml"/>
  <description>Développement logiciel et méthodes agiles</description>
  <language>fr</language>
  <pubDate>Wed, 19 Nov 2008 21:27:58 +0100</pubDate>
  <copyright></copyright>
  <docs>http://blogs.law.harvard.edu/tech/rss</docs>
  <generator>Dotclear</generator>
  
    
    
    <item>
    <title>Exprimer ses besoins - Avangel</title>
    <link>http://agilitateur.azeau.com/post/2006/11/12/Exprimer-ses-besoins#c91</link>
    <guid isPermaLink="false">urn:md5:089686e19bbf0c9485b6e8328924dd99</guid>
    <pubDate>Sun, 19 Nov 2006 12:42:27 +0100</pubDate>
    <dc:creator>Avangel</dc:creator>
    
    <description>Je pense que le modèle métier produit est un document à placer au même rang qu'un diagramme de classes. De cette façon, dès qu'on discute avec les clients des user stories que l'on va réaliser, il y a de fortes chances qu'on le ressorte pour mieux visualiser le process, et qu'on le mette éventuellement à jour.&lt;br /&gt;
&lt;br /&gt;
Je viens de mettre en pratique cette phase de lancement sur notre projet, mais nous avons dû la réaliser en une journée seulement, du fait des créneaux de temps qui nous sont alloués. Le fait de réfléchir aux rôles utilisateurs est une chose, mais ce qui a le plus servi à mon avis est de réfléchir aux intéractions qu'ils ont entre eux. Cela a permis de révéler des User Stories &amp;quot;cachées&amp;quot; dans le métier, auxquelles nous n'aurions probablement pas pensé sans avoir eu ce travail sur les intéractions. Et comme je le pensais, les tâches(buts) déduites de ce diagramme se sont tout naturellement transformées en user stories, le concept est très proche en fait. Il nous a fallu simplement rajouter les user stories purement techniques, qui sont liées à l'implémentation du noyau minimum nécessaire pour s'intéresser aux fonctionnalités utilisateur.</description>
  </item>
      
    
    <item>
    <title>Exprimer ses besoins - oaz</title>
    <link>http://agilitateur.azeau.com/post/2006/11/12/Exprimer-ses-besoins#c89</link>
    <guid isPermaLink="false">urn:md5:92eb485ecb140e2cb51a25d8f81d1f00</guid>
    <pubDate>Wed, 15 Nov 2006 00:14:27 +0100</pubDate>
    <dc:creator>oaz</dc:creator>
    
    <description>Merci pour le lien vers ce document que je ne connaissais pas.&lt;br /&gt;
&lt;br /&gt;
J'ai bien aimé l'approche en 2 dimensions criticité/temps pour déterminer le meilleur contenu possible pour la 1ère version (slide 31). Je reste cependant un peu sur ma faim quant à la mise à jour du modèle métier suite au feedback des itérations. Ce point mériterait à mon avis plus une escription plus détaillée. Mais peut être ce détail vient-il naturellement quand on a effectivement déroulé une phase initiale avec cette méthode ?&lt;br /&gt;
&lt;br /&gt;
En tout cas, la description qui y est faite des histoires utilisateur (peu importe comment on les nomme, 'tâche' ou autre) me conforte dans mes choix de granularité. Un distributeur de billet sert à retirer de l'argent et non pas à saisir un code secret de CB tout comme un bug tracker sert à livrer un produit dont on maîtrise les défauts et non pas à saisir des fiches de bug.</description>
  </item>
      
    
    <item>
    <title>Exprimer ses besoins - Avangel</title>
    <link>http://agilitateur.azeau.com/post/2006/11/12/Exprimer-ses-besoins#c88</link>
    <guid isPermaLink="false">urn:md5:a064095b1d7a50f9a19237a3187f2b6c</guid>
    <pubDate>Mon, 13 Nov 2006 23:07:52 +0100</pubDate>
    <dc:creator>Avangel</dc:creator>
    
    <description>Je suis actuellement des cours en Master 2 (DESS) IHM, où on nous enseignement beaucoup de choses sur les utilisateurs, leur façon de penser, et comment bien comprendre leurs besoins.&lt;br /&gt;
&lt;br /&gt;
Un article très intéressant propose une approche centrée utilisateur pour récolter des besoins sous une forme très proche des User Stories, pour ne pas dire identique. Ca me semble très pertinent et très efficace, ce que je pourrai vous confirmer dans le temps (je vais l'expérimenter sur notre projet de l'année).&lt;br /&gt;
&lt;br /&gt;
Voici le lien : &lt;a href=&quot;http://agilealliancebeta.org/show/1368&quot; rel=&quot;nofollow&quot;&gt;http://agilealliancebeta.or...&lt;/a&gt;</description>
  </item>
    
  
</channel>
</rss>