Architect's Log

I'm a Cloud Architect. I'm highly motivated to reduce toils with driving DevOps.

エンタープライズアジャイル勉強会 2018年10月セミナーに参加しました

エンタープライズアジャイル勉強会 2018年10月セミナーに参加したので、メモを共有します。

エンタープライズアジャイル勉強会

www.slideshare.net

エンタープライズアジャイルでチームが超えるべきこと

グロースエクスパートナーズ株式会社鈴木雄介様のセッションでした。

スコープを管理する

ウォーターフォール

  • S-QCD

アジャイル

  • QCD→S
    • アジャイルではチームとリズムが先にある
      • チームサイズとリリースサイクルが決まればコストとスケジュールは確定してしまう
      • その中で実施できるスコープを決定する
    • チームの固定:効率的だから
      • 繰り返すことが前提のため調達コストが省かれる
        • 人の学習能力と依存 > 適切な要因の調達
      • 日付の固定:リズムが安定するから
        • 次のリリース日があることでスコープ調整がしやすい
          • イテレーション後には次のリリースが来る
    • ゆるやかに変更することは許容される
  • 従来型
    • 常に全体
  • アジャイル
    • 概要と部分

スコープを管理する

  • いかにして部分のスコープを確定するか?
    • 機能そのものよりも使われ方
      • 使い方を基準にして部分が成立することを保証する
      • 部分で価値があること
        • 例:マスタ登録できるだけでは意味がない。ユーザーは商品を閲覧したい
  • リーンキャンバス
    • 誰にとって価値があるサービスなのか
  • インセプションデッキ
  • エレベーターピッチ
  • カスタマージャーニー
  • サービスブループリント
    • いわゆる業務フロー
  • ユーザーストーリー
    • <ロール>が<機能>を行う。なぜなら<ビジネス価値>をしたいから
  • プロジェクトを立ち上げる稟議書との戦い
  • MVP(実用最小限の製品)
    • どうやって部分を積み重ねるかが肝
    • 全部、大事なんです。
      • 優先順位が決められず要件が決まった機能から作ってしまう
  • ウォーターフォールはPMに依存する。アジャイルはその部分をプロセスに移譲