ソフトウェア開発現場での集合知

  • 0
    いいね
  • 0
    コメント

    ソフトウェア開発現場で使われている


    集合知を活用した見積もり手法を紹介


    正解よりも合意形成を重視する一例として


    プランニング・ポーカー


    アジャイルソフトウェア開発で使われている工数見積もり手法の一つ


    紙のカードを使って、1~2週に一度実施されるカジュアルな手法


    James Grenningが考案


    Mike Cohn「アジャイルな見積もりと計画づくり」で有名に


    広域デルファイ法が元になっている。


    やり方


    1.プロジェクトを小さな作業単位に分割する。


    例) twitterっぽいサイトをつくる

    • ログインしてツイート一覧が見れる
    • つぶやき投稿できる
    • 検索できる
    • リツイートできる

    2. 基準となる作業を選ぶ


    (「例: 検索ページをつくるのに5かかると仮定する」)


    3. 開発チームのメンバーは、それぞれフィボナッチ数(1,2,3,5,8,13) の書かれた札をもつ。


    4. 1で分解した作業をひとつ選び、メンバーに内容を説明


    5. 合図で、基準の作業にくらべてどれくらいの量かを考えて札を出す。


    6. もし出した数字がばらばらの場合、お互い判断した理由を話し合う


    7. 全員の札がある程度収束するまで繰り返す。


    1. プロジェクトを小さな作業単位に分割する。
    2. 基準となる作業を選ぶ
    3. 開発チームのメンバーは、それぞれフィボナッチ数(1,2,3,5,8,13) の書かれた札をもつ。
    4. 1で分解した作業をひとつ選び、メンバーに内容を説明
    5. 合図で、基準の作業にくらべてどれくらいの量かを考えて札を出す。
    6. もし出した数字がばらばらの場合、お互い判断した理由を話し合う
    7. 全員の札がある程度収束するまで繰り返す。

    集合知なのか?


    エンジニア向け導入説明時に、


    群衆の叡智の説明について説明がなされる。


    例)


    『アジャイル・サムライ』 で


    ジェームズ・スロウィッキー「みんなの意見は案外正しい」


    雄牛の重量宛てが紹介されている


    元のデルファイ法や予測市場との比較


    予測結果の精度を重視


    プランニング・ポーカー


    見積もりの差の理由を議論することで、情報共有を目指す


    予測主体の独立性は重視されない


    取引回数


    1作業についき、数回の取引(投票と市場の中間)


    1週間から2週間に1回(1~2時間程度)開催される。


    かなり日常的に使用される


    他の手法との共通点


    参加者の多様性が重要だと説明される


    専門家だけでなく、実際に作業する人が見積もる


    参考資料

    http://kawaguti.hateblo.jp/entry/20120218/1329524230