Scrumプロジェクト0010 レトロスペクティブ 15章イテレーションの長さを決める

下記を参考にふりかえりをしてみました。

• リリースまでの期間
  • 著書
    イテレーションは少なくとも4，5回実施する。
  • 現状
    リリースまで１.5ヶ月のプロジェクト。
    イテレーションの期間を2週間とし、3回実施した。
  • 振り返り
    前半と後半でイテレーションの期間を変えることでイテレーションの回数を増やしても良かったかも。
    1.5ヶ月のプロジェクトは短すぎたかも。
• 不確実性の高さ
  • 著書
    不確実性が高くなればなるほど、イテレーションの長さは短くすべき。
  • 現状
    • ベロシティ
      Agileプロジェクトの実績がないため不確実性が非常に高い
    • 技術側面
      使ったことのないWPFを採用するため不確実性が非常に高い
    • フィーチャー
      シンプルなプロダクトであり不確実性は低い
  • 振り返り
    複数の側面で不確実性が高く、イテレーションの期間は短くすべきだったかも。
• フィードバックの得やすさ
  • 著書
    日々フィードバックを得られるか。
    イテレーションレビューは全員が参加し、十分なフィードバックが得られるか。など
  • 現状
    日々フィードバックを得られる。
    イテレーションレビューには全員が参加するが、十分な時間は確保できていない。
  • 振り返り
    フィードバックはイテレーションレビューの場で得るべきだと考えていた。
    イテレーションレビューの目的を明確にし、フィードバックは日々の中で得ればよかったかも。
• 優先順位が安定している期間
  • 著書
    不安定ならば期間は短くするべきである。
  • 現状
    シンプルなプロダクトであり、安定している。
  • 振り返り
    イテレーションの期間は2週間で問題なかっと思う。
• 外部からのフィードバックの必要性
  • 著書
    必要ならば短くするべきである。
  • 現状
    シンプルなプロダクトであり、発注者からの要望もあまりなく、少ない。
  • 振り返り
    イテレーションの期間は2週間で問題なかっと思う。
• イテレーションのオーバーヘッド
  • 著書
    オーバーヘッドがかさむのであれば長めにしてもよい。
  • 現状
    新しいバックログに取り掛かる際に技術調査が発生する可能性が非常に高く、技術調査のオーバーヘッドが多く発生する。
  • 振り返り
    技術調査を前提としたタスクの見積もりを行なっていたので問題なかっと思う。
• 切迫感を感じ始めるまでの時間
  • 著書
    プロジェクトの期日が先になればなるほど、プレッシャーを感じなくなる。
    チームが一定のプレッシャーを感じ続けるようなイテレーションの期間を設定すること。
  • 現状
    プレッシャーを感じていないと見受けられる行動（居眠り・ダラダラしたMTGの）もあった。
  • 振り返り
    プレッシャーを感じていないと見受けられる行動もあったが期間によるものではないと考えている。具体的には下記の事項。
    
    • （主に技術面な）課題を一人で抱え込む
    • 作業待ちが抜けていない
    • 残業癖が抜けていない