読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

第5回TFSUGに参加しました

agile tfs

4月13日 第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ #tfsug(東京都) に参加しました。Evernoteのメモを貼り付けておきますので、参考になれば幸いです。書いたらまずいとかおかしい部分がありましたら教えてください。 @SHIBAO800 さんの後半は流れが速すぎてメモが取れなかったので、認定スクラムマスターからみっちり教育を受けて出直しますね。。


4/13 (金) 19:00-20:45
日本マイクロソフト品川本社

TFS de アジャイルを書いたわけ

@libaty さん

  • 開発支援のお仕事
  • とある開発案件
  • Scrum
  • 1スプリント2週間、1リリース4スプリントで計画
  • プラクティス(検討中含む)
  • TFSを運用
    • Visual Studio Scrum 1.0テンプレートを使用している。後から出てきたテンプレートなので、一部だけ日本語化されている。
    • プロセステンプレートをカスタマイズしている。
      • タスクの2点見積もり
      • 実績入力(振り返り用)
  • チームをまとめる
    • チーム vs 問題
    • 感情の共有が実は効果的だったり(怒り)
    • 目的の共有
      • なぜプロジェクトをやるのか?
      • なぜアジャイルなのか?
      • なにをもって成功なのか?
      • このチームが結束している理由をみんなで考える
    • 事前にアジャイル支援チームの勉強会を受けた。
      • なぜやるのか?
      • スモールでとにかくやってみろ(あきらめるな)
  • 現場で直面してること
    • Feature or Function? 要求?仕様?
    • タスクの粒度
    • ドキュメントのレベル
    • タイムボックスの魔の手
      • 会議:エンドレス延長とか後から蒸し返すとか。決まらない。
      • 作業:時間の切迫感が強い。
    • 「とりあえずやってみる」は無計画ではない。
      • 例えば打合せは、議題、進行、ネタ集めを済ませてから開催すべき。
      • 頭では分かっていても難しい。
    • 正直しんどい
    • お菓子は大事!
    • ハイプカーブ
    • チームメンバーのスキル差が顕在化してきた
  • アジャイルで議論は活発になる。自然に意見が出るようになる。
  • 考えることをやめたらアジャイルじゃない by @kaorun55
  • 続きは6/9(土) Community Open Day 2012で!

アジャイル開発から継続的デリバリーへ

@SHIBAO800 さん

  • IPA/SECの発表
  • とある社内システム案件
    • ユーザ部門の責任者として案件に着手。
    • 開発部門はインドにオフショア。アジャイルなにそれおいし(ry
  • しかし、流れないウォーターフォールに直面する。
  • PMとして改革に乗り出す。
    • Scrumベースにプロセスを整備
    • インド開発拠点の自治化
    • アジャイルっておいしい
    • 現場はモチベーションアップ
    • プロダクトオーナーとスクラムマスターを兼任してしまった(アンチパターン
  • リリース後、エンハンス開発が始まる。終わらない開発。
  • 現場を見直してみると
    • 自動化されていないテスト
    • 統一されていない環境、Excel地獄
  • 立て直し
    • ゴールを共有する。
      • 自己組織化
      • 共感
      • 人は性善説、組織は性悪説
      • 毎週半日のワークショップを開催した。チームを引き込む。
    • 対立構図を解消する
      • コンテキストや問題 vs チーム
      • Agile Buffet
        • 自分達の現場でどんなプラクティスを適用するか考える。
    • 小さな成功体験をつかむ
      • 開発環境→テスト環境→Scrum環境
        • 開発環境はVM
        • Test Manager+TFSでテスト
        • ブランチ運用
      • 日本でやってみる、そしてインドへ
      • 各スプリントで一つ取り入れる
    • 制約と非制約
      • 既存資産を抱えたプロジェクトで、単体テスト or 受け入れテストのどちらを先に自動化していくか?
        • 受け入れテストの自動化から着手。
        • エンハンスする部分は必ず単体テストを書く。
      • リスクベースドテスト
        • 各フィーチャにビジネス価値を付ける。
        • ビジネス価値のリスクが高い部分から優先して自動化する。
    • ツールとアナログの組合せ
      • アナログは直感的、チームの外から見える。
      • 一方で、アナログで気づかないことにツールで気づける。
      • デスマの見える化。まわりから状況を見えるようして改善につなげる。
    • ユーザーストーリーマッピング
    • プロダクトバックログはTFSで
    • プランニングポーカー
    • スプリントバックログ
    • モニタリング
    • バーンダウンチャート
      • 印刷して貼っておく
    • デモレビュー
    • 振り返り
  • 継続的デリバリーヘ
    • アメリカの調査ではアジャイルの開発期間は2週間が多い。一方で、リリース間隔は1ヶ月以上・・・
    • リリースの悪夢
    • ビジネス駆動のリリース
    • ユーザと開発のフィードバック
      • ユーザにとってソフトウェアの価値は?
    • リスクの低減
      • 誰も使わないソフトウェア
      • ビッグバンリリース
    • 継続的デリバリーの流れ
    • すべてを構成管理下に置く。
      • 開発環境クラウド
      • 必ず自動化されたデプロイを通じてデプロイする。
      • クライアントAPのデプロイ自動化はTerminal Service RemoteAppを利用した。
    • カナリヤリリース
      • ユーザ自身も何か欲しいか気づいていない。誰からも使われない無駄なものができる。
      • イノベーター、アーリーアダプタに先行リリースしてフィードバックを得る
      • Minimum Valuable Product
      • 通常エンハンスと新フィーチャーでアプローチを変える
        • 通常エンハンス:受け入れテストを通過したら本番にリリースする。
        • 新フィーチャー:受け入れテストを通過したらCanary環境にリリース。コアユーザによるテストを経てリリースする。
  • 大事なのはチームメンバーが自律的に動けること。
  • ゴールを共有する。