「Raccoon Tech Connect #5 |スクラム開発の工夫」に参加してきました

実行可能な計画

スプリントバックログ

  • 実行可能な計画
  • 見積もりどおりの工数でうまくいくことは少ない
    • ならすとだいたいスプリント内でちょうどいい
  • 見積もりブレる時
    • 前倒した時
      • 着手前に実行可能になっているもの
    • 伸びた時
  • 料理のレシピのような状態になっているといい

期限厳守のスクラム開発現場での経験談

  • 山下さん(ラクーンホールディングス)

SIerでのスクラム開発

  • 品質と期限の両立
    • 出来る人に一極集中
  • 全員が互いをフォローすうりょうな開発現場にしたい
  • 文法でやってることの独り言を描いてもらう
  • 全体像や進捗が分からない
    • TDD的にやることりすと作ってから開発
  • 情報共有不足/属人化
    • 何でも書けるwikiにメモ残すように

Web開発チームを育てるスクラムの透明性

  • 平尾さん(ラクーンホールディングス)

透明性

  • 透明性が確保されてると
    • 無知の知を得やすい
    • 助け舟を出しやすい
    • 進捗を検査しやすい
  • 公開
    • リードタイムの見える化
    • チケットテンプレートの統一

オフショア開発でもスクラムがしたい

  • 菅原政行さん(Faber Company)

オフショア

  • ベトナムで開発曽々木が先にあった
  • 日本7人ベトナム26人
  • 最初はエンジニア2人
  • 納期は絶対という文化があった
    • 遅れそうな時に柔軟に対応していくように変えていった
  • スプリントレビューで実装視点の説明がせれていた
    • ユーザーストーリーの共有が不十分?
    • ミーティングへの同席など
  • 透明性
    • 開発組織が何してるか外から分からない
    • まずはスクラムというものを社内に知ってもらうところから
    • slackが開発とそれ以外で分かれてたので集約
  • 対話

PJ終盤でインセプションデッキを作ったハナシ

  • 保田さん(ラクーンホールディングス)

インセプションデッキ

  • リリース1ヶ月前に1ヶ月以上遅れてることに気づく
    • 情報共有ができてなかった
  • やばいにおい
    • 言った言わないになる
    • 話が噛み合ってない
    • たらればの空中戦が増える
  • インセプションデッキ作った
    • PJの方向性や期待値を再確認
    • 現実が見えてきてそれに向き合う合意ができた
    • やるやらの判断基準ができた