[PdM/PO] プロダクトの構想フェイズについて(4層の仮説立案→リーンキャンバス→インセプションデッキ→ストーリーマッピング→プロダクトバックログ化)

  • アジャイル開発における、プロダクト像の構想〜タスク化までについての個人的まとめ
  • PO(プロダクトオーナー)PdM(プロダクトマネージャー)は以下の流れで、何を作るか?をまとめていく必要がある
  1. プロダクト像の仮説を立案
    • 抽象度で4層程度に分解して考える
  2. リーンキャンバスを作成
  3. インセプションデッキを作成
    • ex. エレベーターピッチ/やらないことリスト
  4. ユーザーストーリーマッピング
  5. 重み付け(各ストーリーにSMLを定める)
  6. 優先度付け(MoSCoW法や狩野モデルを活用する)
  7. 優先順位付け→プロダクトバックログ
  8. 受入条件の設定
  9. プロダクトバックログアイテムに分割
    • ここでタスク単位になる
  10. DoD(完了の定義)の設定
    • 各アイテムにはDoDが必須
  11. スプリントプランニング~スプリント開始
    • バックログの中からスプリントないで取り組む物を決定する
    • ここで開発が始まる

概要/用語

PO/PdM

  • アジャイル開発においては、以下のロールがプロダクトについての責任を持つ
  1. プロダクトオーナー(PO)

    • プロダクトに関する全ての責任と権限を持つ
    • プロダクトビジョンを確立し、育み、伝達する
    • プロダクトバックログの管理・優先順位に責任を持つ
    • ROIの最大化に責任を持つ
  2. プロダクトマネージャー(PdM)

    • 人によって認識が異なるが、POとスクラムマスターの機能性を合わせた存在と定義されていることが多い
    • スクラム開発においてはPOとスクラムマスターに分解されており、PdMは存在しない。兼任すべきでないと言われている

ユーザーストーリーマッピング

  • ユーザストーリー

    • システムやSWのユーザーにとって価値のある機能を記述したもの
    • ある特定の役割の持ったユーザーから要望された結果を記述し、そのプロセスで何を行いたいのか?その効果(実現価値)も表現する
    • 書式
      1
      「<役割>として<機能>ができる (それは<理由>のためだ)」
  • ユーザーストーリーマッピング

    • ストーリー(ユーザーにとっての価値)を付箋などに書き出し、ユーザーの体験順に時系列で左右に整理、似た機能は上下(基本機能を上、派生的な機能は下)に整理して壁などにマッピングしていく手法
    • 通常ワーク形式で実施する
      • 複数名で3h程度で実施する場を設ける

プロダクトバックログ

  • プロダクトバックログとは?

    • ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリスト
      • 機能開発以外の作業も含まれる
      • バックログへの項目の追加&変更は誰でもいつでも可能
      • POが項目の優先順位付とリストの管理の責任と権限を持つ
      • プロダクトバックログはスクラムチームに限らず、誰でも(ex. ビジネスチーム)参照できる
    • ストーリーを元に作られる
      • 最低限の分解や重み付け、優先順位の定義を経てプロダクトバックログになる
    • バックログ=タスクではない
  • プロダクトバックログアイテム

    • プロダクトバックログを分解してタスク単位にしたもの

リーンキャンバス

リーンキャンバス

  • リーンキャンバス
    1
    リーンスタートアップという著書で有名な起業家のエリック・リースから応用されたビジネスモデルを一枚の図にまとめたフレームワーク
    • ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
    • 目的
      • アイディアに対してビジネス視点からも検討できるようユーザーとビジネスのバランスを考えること
      • ユーザー視点で事業の価値を定義し、価値の構造を可視化することで実現性を検証することが可能になります。

インセプションデッキ

インセプションデッキテンプレート

  • インセプションデッキ

    • プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメント
    • 質問 x 10で構成されている
    • プロジェクト憲章に近い存在でPJ計画書のインプットにもなる
    • 考案者: Robin Gibson (ThoughtWorks社)
    • アジャイルサムライの著者(Jonathan Rasmusson氏)によって広まった
    • プロジェクト計画書ができる時点で盛り込まれていればいいので、初めから全て必須ではない
      • プロダクト像を揃える為の最低限として、エレベーターピッチや、トレードオフスライダーやらないことリストを作っておくと良い
  • エレベータピッチ

    • 以下の書式で[]の中身を書き換えていき、プロダクトを表現する
      エレベーターピッチ
    • リーンキャンバスと同様に、ユーザーストーリーマッピングの前に、プロダクト像の意識合わせに利用する
  • やらないことリスト

    • その名の通り

やらないことリスト


プロダクト像の仮説立案〜タスク化までの流れ

  • ストーリーマッピングの前にプロダクト像を合わせる
  • 1~はワーク内で実施することが多い
  1. 仮説立案
    • プロダクト像を抽象度に応じて階層分けして定義する
  2. リーンキャンパス
  3. インセプションデッキ
  4. ストーリーマッピング
    • ストーリー出し/分類/分割
  5. 重み付け(SMLを話し合う)
  6. 優先度づけ
  7. 優先順位付け
  8. 受入条件設定
  9. バックログアイテムに分割
  10. DoD(完了の定義)の設定

プロダクト像の仮説立案

  • プロダクトのあるべき姿はステークホルダー間で認識齟齬が生まれ易いため、以下のような抽象度で階層分けした仮説を共有することで、アジャイルPJを円滑に進めることができる

抽象度で階層分けしたプロダクト像の仮説

  • 上段が下段のインプットとなる
  • 下段に行くほど抽象度が下がり具体化される
  • Whatばかり話し合っていて、上段のCoreやWhyがずれていることが多い
  • この仮説はアジャイル開発を進めながら何度も見直してブラッシュアップしていく物なので、最初に完璧にする必要はない
    • ステークホルダーでビジョンを共有する

リーンキャンパス

  • 以下の9つの項目を埋め、ステークホルダーと共有する
    • 特にビジネスチームや予算承認者との合意が重要

リーンキャンバス

インセプションデッキ(エレベーターピッチ/やらないことリスト/トレードオフスライダー)

インセプションデッキテンプレート

  • インセプションデッキのテンプレートは以下のURLから入手可能

    • https://cacoo.com/diagrams/nsgCdwRZAHJBXTLy/F96B8
    • インセプションデッキはアジャイル開発におけるPJ憲章やPJ計画書に相当する
    • ストーリーマッピングに入る前に、エレベーターピッチとやらないことリストを作っておくと円滑に進め易い
  • エレベーターピッチ

    • 以下の[]の箇所を埋めて、ステークホルダー間の認識を合わせる
    • [差別化の決定的な特徴]の認識が承認者やビジネスチームとずれていると後で揉めかねない
1
2
3
4
5
6
7
[潜在的なニーズを満たしたり、潜在的な課題を解決したり]したい
[対象顧客]向けの、
[プロダクト名]というプロダクトは、
[プロダクトのカテゴリー]です。
これは、[重要な利点、対価に見合う説得力のある理由]ができ、
[代替え手段の最右翼]とは違って、
[差別化の決定的な特徴]が備わっている
  • やらないことリスト
    • 進める前にやらないことを明確に定めることで、承認者やビジネスチームとの齟齬が生まれにくい

やらないことリスト

  • プロジェクトコミュニティ

    • ステークホルダー全員を明文化
  • トレードオフスライダー(何を諦めるか?)

    • 何を優先するか?メンバとスタンスを揃えられる

トレードオフスライダー

  • その他アクターの認識合わせも実施しておくと良い

ここまででプロダクトの大枠の認識を合わせることで、ストーリーマッピングを円滑に実施可能になる。経験上、ストーリーマッピングは結構な時間がかかるので、こういった前提条件の設定は効果が高い。

ストーリーマッピング

  • マッピングはメンバ間の齟齬を回避するためにワーク形式で行う
  • 難しければ、少なくともPOがマッピングしたものに過不足がないかコメントをもらう

ワークについて

  • 所用時間:3h程度
  • 参加者
    • できうる限り多くのステークホルダーを集めた方が良い
  • ワークの流れ
    • マッピングの前にメンバ間のプロダクト像を整合する
      • ここで、リーンキャンバスやエレベータピッチ、抽象度分けされた仮説を用いる
    • ストーリーマッピング(全部ワーク内でやらなくてもOK)
      • ストーリーを付箋に書き出す
      • 時間軸で物語順に並べる
        • ex. ログイン→認証→…
      • フィチャーとして分類/分割
        • 共通するワードをフィーチャーとして上に付箋を貼る
        • その下に細かいストーリーを並べる
        • 大きすぎるストーリーは分割する
  • 開催形式
    • Localで集まれる場合
      • 複数名でホワイトボードに付箋を貼っていく
    • Remoteで実施する場合
      • Mural, Realtime Boardなどでホワイトボードを代用する
      • BOXなどの同時編集可能な環境があれば、そこのファイルにマッピングする

INVEST

  • ユーザーストーリーはINVEST要素を保持していることが望ましいと言われている
  • INVEST
    • Independent(独立している)
      • 可能な限り他のユーザーストーリーに依存しない
      • 実装、見積もり、テストが容易
    • Negociatiable 交渉可能
    • Valuable 価値がある
    • Estimatable 見積もり可能
    • Small 小さい/適切な大きさ:一つの反復に収まるサイズ
    • Testable:テスト可能
      • ストーリーが完了したかを示すことができる

エピック

  • エピック
    • まだ明確に表現できないものや緊急度の低いもの、NicetoHaveな事柄は大きな塊(エピック)としておいておく
    • 必要に応じてユーザストーリーとして詳細化する
    • 複雑で1つの反復で完了することはできない
    • リリース開始までに1回の反復で完了できる大きさに分割する必要がある

ストーリーの分割

  • 見積もったストーリーがアジャイル開発の一反復に治らない場合にはストーリーの分割を行う。タスクへの分割とは別

分割のガイドライン

  1. データ境界に沿って分割
  2. 操作の境界で分割
  3. 横断的な関心ごとを分離する
  4. パフォーマンス制約をストーリーにする
  5. 優先度に沿ってストーリーを分割する
  6. ストーリーをタスクに分割してはならない

ストーリーとフィーチャーの書き出しが終わったら過不足について議論を行う。その後、各ストーリーの重み付けと優先度付けを実施する。

重みづけ

  • 重み付け
    • 優先順位付の前にSMLで重みづけを行う
      • 重み(ストーリーを達成するまでのコスト)&優先度(ストーリーが産む価値)を先に定めてから順位づけをしないと混乱が生じてしまう
    • Small, Middle, Largeをメンバ間で話し合う

優先度付け

優先度と優先順位は別物

  • 優先度づけ→優先順位付け
    • 優先度
      • 高中低、ABCなど
    • 優先順位
      • 明確な序列
    • 優先順位がつくとバックログになる

優先度付けには様々な手法がある

  • MoSCoW法(各ストーリーに以下のタグを定めていく)
    • Mo: Must Have
      • 絶対必要
      • MVPに必要なフィーチャーはここに含まれる
    • S: Should Have
      • できれば実装すべき
    • Co: Could Have
      • 他への影響がなければ実装できるとよい
    • W: Won’t Have
      • 今回は実装しないが将来に実装するかも

重み付のSMLと頭文字が被って混乱を招くことがあるので注意

  • 可能であればMVPを定義しておくと優先的な機能を可視化しやすい
    • MVP (Minimum Viable Productivity)
      • 実用最低限の製品のこと
      • 使い勝手はともかく最低限の価値を生み出せる状態
    • MVPに含まれる機能は、自ずとMust Haveになる

その他、狩野モデルも有名

  • 狩野モデル(利用者の好みでタグ付)
    • 魅力的(あると魅力的)
    • 一元的(なくても良いがあると差別化できる)
    • 当たり前(あって当たり前)
    • 無関心(どうでもよい)
    • 逆行(あったら困る)

プロダクトバックログの定義(優先順位付け)

  • 先に各ストーリーに設定した重みや優先度を参考に、優先順位をつける

  • ストーリーを優先順位で上から並べる

  • Walking Skelton

    • 実装が短期間で終わる場合は注意深く優先順位付けしなくて良い
  • 判断基準

    • ビジネス価値
      • ex. 同等のビジネス価値を提供可能な場合、開発工数の少ないほうがROIが高いため、つけられる優先順位も高くなる
    • 技術的なリスク
      • 技術的なリスクが高い項目ほど早いスプリントで対処して、リスクを減らすべきである
      • ただ、新設チームの場合は始めにもってこな方が良いケースもある
    • 市場リスク
      • 早く市場に出してフィードバックを得る必要がある物を優先する
      • 他社に先出しされると致命的になる機能など
  • 例えば、MoSCoW法であれば、Must Haveの項目から先に取組み、MVPを完成させる必要がある。

    • 必須の機能が実装されることで、技術的なリスクが序盤で下がり、少なくともプロダクトが動く状態になる
    • その後にビジネス価値に基づいてShouldの項目を片付けていくイメージ
  • ここまでのアウトプット

    • プロダクトバックログ
      • 優先度付されたフィーチャー/ストーリーのリスト

プロダクトバックログを起点として、スプリント計画や詳細なタスクへの落とし込みを行っていく


プラダクトバックログアイテムの定義

  • プロダクトバックログを細分化するとタスクになる
    • プロダクトバックログアイテム(項目)=タスク
    • これらのアイテムにはDoD(完了の定義)を定める必要がある
    • バックログごとに表を作るイメージ
      • カラムはバックログ、バックログアイテム、各アイテムのDoD(完了の定義)

完了の定義:DoD(Difention of Done)を追加

  • DoD(Difention of Done):完了の定義

    • アウトプット
      • ex. 関連する設計ドキュメントがある
    • 状態
      ex. 2名以上がレビュー、テスト実行済み
  • DoDを定めなければ進捗の実態の測定や品質管理が難しくなる

ここまでで、プロダクト像の定義〜タスク化が完了


2レベルプランニング

アジャイル開発は適当に進めていいわけではなく、2段階で計画を立てて、順次見直しながら進めていく

  • リリース計画
    • ユーザにコミットするリリースの時期
  • スプリント計画
    • 対象スプリント期間内に行うべきことの計画

リリース計画の立案

まずは全体の進め方を検討する

  1. SPの長さを決める
    • スクラム開発なら2w程度
    • 通常のアジャイル開発では4~8w程度
  2. ユーザーストーリー。エピックの規模を見積もる
    エピックは見積もり可能な大きさに分割する
  3. ユーザーストーリー、エピックに優先順位をつける
  4. 1反復で消化できるポイントなど(ベロシティ)を見積もる(例:一反復=15ポイント)
    • 立ち上げ段階の予測はとても難しいので厳し目に見積もる
    • 一度スプリントを回せば、前回はこの程度消化できたので…という測量が可能になり精度が上がっていく。段々精度が上がっていくものという認識でOK
  5. 反復にユーザーストーリー、エピックを配置する
    • スプリントの期間と、ベロシティが定まった箱の中にどのストーリーを詰めていくか?考えるイメージ
  • プロダクトオーナーは、ROIを最大化するにはどうすべきか?を常に考えて、責任を持つ必要がある

価値とシステムにおけるリスクの二軸のマトリクスで分類する

スプリントプランニング

次にスプリントごとの計画をする

  • バックログの中から次のスプリントで取り組む物を選択する

    • ここでやっと開発を始めることができる
    • 以降のスプリントサイクルについては別記事に記載
  • 2部構成で実施する

    • パート1
      • 開発チームはPOと一緒に次のスプリントでどのような機能を実装するか
      • SPで対象とするバックログの選定
      • ストーリーの確認
    • パート2
      • 開発チームがその機能をどのようにプロダクトに追加するかを決定する
        • ストーリーの作成
  • スプリントバックログ

    • タスクボード To Do/Doing/Done を使う
      • ここでGitのカンバンなどを用いる
    • ここでの単位はプロダクトバックログアイテム(タスク)
  • 三角測量 プランニングポーカー

    • 見積もるための基準となるストーリーやタスクを1つ決める、
      比較しながら見積もっていく手法
    • 相対的見積もり
    • 異なる数字を出した場合は、最も大きい数字を出した人と、小さい数字を出した人で根拠を説明しあう

参考

関連記事

その他

アジャイル開発におけるプロジェクトマネジメントについて

アジャイル開発の概要と各フェーズについて学んだことのメモ

1. アジャイルプロジェクトマネジメントの概要

アジャイルPMとは

  • PJのスケジュールを複数のサイクルで分割する

    • “イテレーション” or “スプリント”と呼ぶ
  • 成功するアジャイルプロジェクトの特徴

    • スプリントが4~12w
    • 文章よりもコミュニケーションに重点を置く
    • 業務部門と技術部門が同じ場所にあるか、緊密に連携できる環境にある
    • 全面的に支持するスポンサーがいる
    • ニーズの変化を先読みして取り入れる
  • アジャイルPJに必要な条件

    • 最終段階までのビジョンをもつ
    • 常識とされているPJのライフサイクルに従う
    • 要件を理解している
    • スケジュールが共有・管理されている
    • 専任のチームが作業に専念できる
    • 緊密なコミュニケーション
  • フェイズ

    • 初回のみ実施
      • 構想
    • 以下を複数サイクル繰り返す
      • 思索
      • 探索
      • 適応
    • 最後のみ実施
      • 終結

アジャイルライフサイクルの概要

  • 構想フェイズ(一度だけ実施)

    • これから開発するものを顧客と決める
    • チームに必要な人材を定義
    • 価値観と規範を定義
    • Output
      • スコープ
      • 目標
      • 関係者
    • チームのコラボレーションツール
      • 業務時間やミーティングなども含めて決定する
      • 相談方法なども
  • 思索フェイズ

    • フィーチャー単位の提供計画
      • スプリントごとに1 or 複数完成させる
      • フィーチャーとは機能 or 成果
    • 見積もり
    • リスク
    • Output
      • スプリントの要件とフィーチャーの一覧を作成
      • 各フィーチャー毎に以下を見積もる
        • 作業量見積もり
        • リスク見積もり
  • 探索フェイズ

    • 毎日のスタンドアッププミーティング
    • 内部でフィーチャーをレビュー
      • 業務担当チーム&技術担当チームの話合いや
        テスト結果に基づいて行う

フィーチャーが完成したらイテレーションの終わりに振り返りを行う
これが適応フェイズの目的

  • 適応フェイズ

    • 顧客によるフィーチャーの最終レビュー
    • チームによる振り返りのミーティング&記録
      • こうして得られた教訓を次にスプリントの計画に生かす
  • 終結フェイズ

    • 成果物が完成していること
    • 学んだ教訓を記録していることを確認

  • アジャイル開発を適当に実施すると、探索フェイズのみに集中して、他のフェイズの時間をろくに確保できなくなってしまうパターンが多いと感じる
    • メンバーへの必要性の周知 & スケジュールの確保が必要

2. 各フェイズの詳細

構想フェーズ

PJの基礎を作る段階

  • 構想フェーズ終了時のOutput

    • プロジェクト憲章を作成。以下を記載
      • スコープ(PJの範囲)
        • プロダクトのビジョン(最終プロダクトの概要)を記載
          • ターゲットの顧客
          • 主なメリット
      • 全体的な目標
        • PJの目的
      • プロジェクトの関係者
        • PJのスポンサーとマネージャーの責任を明記
        • PMに権限を与え、レベルを定義する
    • コラボレーションツール
      • セットアップ~動作確認まで
      • ツールは使いやすいことが重要。
      • 最初は少数の単純なツールから始め、必要に応じて他のツールを追加していくのがよい
      • どれだけ高度なツールを選ぶかはPJの規模や関係者の人数、共同作業の量を考慮して決める
    • チームの規範
      • 構想フェイズでは全員が共同で プロジェクト全体の設計に取り組む。
        その際に物理的な作業場所など チームの共同作業の進め方について 規範を作成することが重要
      • 規範の例
        • 他の人の意見に積極的に耳を傾ける
        • 人ではなく問題を非難する
        • まず理解しようと努める
        • 現在のスプリントとフィーチャー(プロダクトバックログ)だけに焦点を合わせる
        • 問題を見つけた場合は指摘し 解決策を提案する。
        • 毎日のミーティングに積極的に参加し、 集中する。
        • 他の人と対立した場合は 解決するよう努力し、 解決できなかった場合は 双方が上層部に助けを求める。
        • メールは顔が見えない コミュニケーション手段なので 問題解決には使用しない。
        • ミーティング中にメールなどに 返信しない。 当座の問題に専念する。
        • 互いを尊重する。 プロジェクトを最優先に考える。
        • 他のメンバーの役割と責任を理解し、 お互いを尊重する。
  • チームの規模感

    • チームは 15 人以下が適切。 16 人以上のチームも可能ですが その場合は 15 人以内の サブチームに分ける。
      • 大規模なチームではメンバー間や 開発するフィーチャー間の調整が 難しくなるリスクがある。
  • アジャイルプロジェクトのリスク

    • ほとんどは以下に起因する。このような状況は避ける
      • フィーチャーの開発スケジュールが きつすぎること
      • 最終決断を下す権限を メンバーがもっていないこと

プロジェクト憲章を策定し、コラボレーションツールを準備し、リスクを抑えたチーム編成を決めたら、次は最初のイテレーションの思索フェーズに着手する


  • PJ憲章やチームの規範はGitのWikiに載せると良さそう

思索フェーズ

  • 最終目的

    • 業務部門と技術部門が各イテレーションで開発するフィーチャーを決定すること
  • 2回目以降のイテレーションの場合は 前回完成できなかった フィーチャーの見直しも行う

  • 業務部門と以下を検討する

    • 新規のフィーチャー
    • 未処理リストにあるフィーチャー
    • 前回のイテレーションで完成しなかったフィーチャー
      • 未処理リストに追加される
  • フィーチャー

    • 要件と似ているが、特定のビジネスニーズに絞ったもの
    • 顧客にとって重要な小さな業務を”行為”と”結果”という形で表したもので、事業目標の達成を可能とするもの

流れ

  1. フィーチャーの洗い出し

    • カードや付箋で書いて集めるか、コラボレーションツールを使用する
  2. 論理的に分類

  3. 優先順位付け

    • 業務部門が技術部門の助言を受けながら優先度付けを行う
    • この時、業務部門の関係者は既存のフィーチャーについて尋ねたり、追加したりする
    • 追加のフィーチャーに関する話し合い重要な部分
      • ほとんどの場合は一部のフィーチャーを 将来のプロジェクトに 持ち越す必要がでる。
      • 予算も時間も限りがあるため、以下ができたら準備完了フィーチャーリストを確認して 優先順位をつけ、
        業務部門とスポンサーが同意したら 準備完了
      • フィーチャーリスト
        • イテレーションの開始時に見直し、最新の状態にする必要がある
  4. 作業量の見積もり

    • 初回のイテレーションでは、全フィーチャーの見積もりを出す
      • チームや業務部門の担当者と協力し、 正確な見積もりを出すようにします。
  5. イテレーション、マイルストーン、リリース計画を作成

    • 以下を決定
      • 開発する全フィーチャー
      • 完成日
      • 業務部門に フィーチャーを実装する日
  • 思索にかける時間
    • 初回のイテレーションでは時間がかかる
    • 2回目以降はあまり時間をかけない
      • 例えば8週間のイテレーションの場合、思索フェーズは5日程度

探索フェーズ(プロダクトの制作段階)

  • 毎日のスタンドアップミーティングは 全フェーズで行うが 探索フェーズでは最も重要な役割を果たす

    • 15分程度。長くても30m以内
    • 各チームメンバが前日の成果、当日の予定、作業を進めるために必要なサポートについて情報を共有する
    • ”課題を解決する場では無い”
      • 課題は記録し、ミーティング後に対処して、翌日全員に報告する
      • 文書にする必要は無いが、学んだ教訓は課題登録簿に記録
  • PMの責務

    • オブザーバとしての役割を果たす
      • 立ち会うだけで進行はチームにまかせる
    • 未解決の課題が無いか確認する
    • 障害となるものが無いか確認する
    • 時間と共にリスクが提言していることを確認する
    • 関係者に状況を伝える
  • マネージャーの役割

    • 組織上の障壁に対処する
    • スプリントで開発しているフィーチャーの進捗管理をする
      • 完成したフィーチャー派ミーティングで伝え、提示する
      • 予定より遅れているフィーチャーがある場合は その原因を究明
        できるだけ、早期に修正し 教訓を反映できるように記録
  • 一般のPJと同様に課題登録簿を管理していく必要がある

    • 重要なのは課題を迅速に解決すること
    • 未解決の加太が増えている場合は門外があるので変更を検討する必要がある
    • チームがプロダクトの開発に追われて 時間がなくなることがよくある。
      • 時間管理とスプリントのスケジュール管理は 非常に重要。
  • 以下のどちらかで探索フェイズを終了する

    • スプリントで予定していた フィーチャーが完成
    • フェーズ期間が経過

このどちらかの条件に沿って 探索フェーズを終了することが重要

  • 探索フェーズの期間が7週間あって その間にフィーチャーが完成しなかった場合
    • スケジュール通りにフェーズを停止して 適応フェーズに進む
    • 適応フェーズでは学んだ教訓を記録して 適用する
      • 教訓の変化をメンバー全員に周知し 関係者とともに要望の確認や 調整を行う
        これが探索フェーズに続く 適応フェーズの目的

  • 課題管理はgitのissueとカンバンで運用すればOK

適応フェーズと終結フェーズ

スプリント最後のプロセス

  • 適応フェーズ

    • チームで以下の作業を行う
      • 成果を確認
      • 計画と比較する
      • 良かった点と悪かった点を話う
      • 変更の合意を取る
      • 前回の適応フェーズの教訓と付き合わせ 同じ傾向が見られないか確認
    • 顧客と以下を確認する
      • プロダクトを顧客と一緒に確認
      • 目標通りに機能することを確認
      • 業務への効果を検証
        • 顧客の業務の変更があった場合は 開発したフィーチャーの有効性が 十分かどうか確認
        • またそのフィーチャーが業務に期待通りの 効果をもたらすかどうかも検証。
  • 各適応フェーズで学んだことを話し合い、 フィードバックを共有することは とても重要

    • 問題解決の為のブレインストーミングを行う
  • フィードバックを元に多数の修正や変更を加える

    • フィーチャーの追加・削除
    • 見積もりの変更
    • 未処理リストのフィーチャーの優先度の変更
    • スタンドアップミーティングの議題を変更
    • 人員体制を変更
    • リスク登録簿を変更
  • 今後のスプリントに影響する変更については、理由と共にメンバに周知する

  • PMの役割

    • 功績を称える
    • 次期スプリントに向けてチームの士気を高める
    • 長期の場合はメンバを一時的にスプリントから外す
  • 終結フェイズ

    • マネージャの役割
      • ベンダーとの間で支払いが済んでいることを確認
      • 財務情報を確認
      • 人員を他のプロジェクトや業務に割り当てる
      • プロジェクト全体の成果を伝える
      • 開発したフィーチャーが業務で効果を上げているか監視する
    • アジャイルの経験が少ない場合は、学んだ教訓を整理する

ポイント

  • スプリント=イテレーション
    • 通常は4~12週間をかけて行う
  • アジャイルライフサイクル:5つのフェーズ
    • 構想、思索、探索、適応、終結

3. 構想:プロジェクトの選択と計画


アジャイルPJを選択する

  • アジャイルが適しているPJ

    • 質の高いプロダクトを短期間で納品するが、一括納品する必要が無い場合
    • 進捗に応じて要件が変わる可能性がある場合
    • メンバーが主体的ンい子決定できる場合
    • プロダクトを分割納品しても業務上の価値を提供できると思われる場合
  • アジャイルに適しているPJの特徴

    • 要件が変化する
    • PJをスプリントに細分化できる
  • アジャイルに適さないPJの特徴

    • スプリントの単位で進める必要が無い
    • PJが別の手法で成功した実績がある
    • 全てのフィーチャーを一度に納める必要がある

イテレーションで進めることだけがアジャイルではない

アジャイルと非アジャイルを組み合わせる方法もある

プロジェクトのスコープを決定する

  • 構想フェイズ

    • 以下を作成
      • 顧客が求める最終プロダクトのビジョン
      • PJのプロダクト憲章
    • 次にプロダクトデータシート(PDS)を作る
  • PDS(プロダクトデータシート)概要

    • 計画書
    • プロジェクトの概要をまとめたもの
    • PJの詳細なスコープを記載したPDSはPJのコミュニケーションツールとしても活用可能
    • 一般に初回のスプリント前の構想フェーズで作成
    • 1~3P程度で完結にまとめる
      • PJ憲章から抜粋したPJの説明とスコープの概要
      • PJの目標
  • PDS(プロダクトデータシート)詳細

    • PJの説明
      • PJ憲章から抜粋したPJの説明とスコープの概要
    • PJの目標
    • スケジュール
    • コストの見積もり
    • 制約
      • 環境
      • 安全
      • 経済
      • 技術
        • 準拠すべき技術企画
      • 政治的
      • PJのスケジュール
        • 完了日
      • チームまたは開発するプロダクト
        • 特定の期間しか参加できないメンバ
    • 優先順位
      • 以下の中で優先順位をつける
        • スコープ
        • 人員
        • 品質
        • スケジュール
        • その他の資源

スプリント計画を策定する

  • イテレーション(=スプリント)は基本4~12週間

    • 思索/探索/適応が含まれる
  • 各スプリントの前後を、思索/適応フェイズに1週間ずつ割り当てる

    • 始めの思索フェイズは数日多く見積もる
  • スプリンと計画を立てるには全フィーチャーの一覧と規模の見積もりが必要

  • フィーチャーの分類基準

    • 業務部門における優先順位
    • 対応可能な技術者
    • 利用可能な資源
    • 事業分野
  • フィーチャーの規模の見積もりは大まかでよい

    • ex. 大: 80h 中: 40h 小:20h
    • 見積もりは思索フェイズごとに行う
  • この後に期間を決める

    • “スプリントの規模が決まったらそれを変えない”
  • 潤沢な資源と人員がいる場合

    • “もっとも優先度の高いフィーチャーから取り組む”
  • “期間を短くして焦点を絞る”

  • スプリント計画例 (6ヵ月の場合)

    • 構想フェイズ: 1ヵ月
    • 残りの5ヵ月を複数スプリントに分割
      • スプリントの期間を決める
      • 各スプリントの前後を、思索/適応フェイズに1週間ずつ割り当てる
        • 残りは5週間となる
        • 5週間でどこまで進める考える
      • 各スプリントの残りの期間を探索フェイズに当てる
      • 探索フェイズの中で消化可能なフィーチャーを見積もりと優先度に応じて割り当てる
  • 各フィーチャーの規模の推定をせずになんとなく進めてしまうPJが多い

リスクを管理する

  • スプリントごとにリスクを管理

  • アジャイルが初めての場合は始めの数回のスプリントの難易度を下げる

    • 2回目以降で難易度を上げていく
    • 特に技術力が必要なPJ等

”フィーチャーの難易度を上げすぎない”

  • ”アジャイルに慣れる時間をチームに与える”

    • 慣れていない場合は難しいフィーチャーを後ろに
    • 経験豊富なチームであれば難しいフィーチャーから取り組む
      • PJ全体の見通しがたつ
  • 各スプリントの数を調整する

    • “初期段階のスプリントのフィーチャーを減らす”
  • 業務部門特有のリスクに注意

  • 最適な実装順を決める

  • 業務への影響を考える

ポイント

  • アジャイル手法によるプロジェクト管理が適しているタイプ

    • 短期間で納品する必要があるが、一括納品する必要がないプロジェクト
  • プロジェクトデータシート(PDS)でプロジェクトのスコープを決める作業

    • マイルストーンを含む詳細なタイムライン設定
    • コストの見積もり
  • スプリントの期間と各スプリントで開発するフィーチャーの数を決めること

    • スプリント計画
  • リスクを低減する方法の1つ

    • チームの生産性が十分に上がるまで、最初の数回のスプリントで開発するフィーチャーの数を少なくすること

4. 思索:アジャイルプロジェクトの進め方


要件を特定する

  • 要件の収集

    • 開発チームより先にビジネス
    • 新しいフィーチャーを定義する
  • 要件特定の技法

    • ユースケースの活用
    • パフォーマンス要件カード
  • ユースケースの活用

    • 特定の目標を達成するシステム、 またはプロセスとアクターの関係を 図で表す。
    • アクター
      • 人、会社や組織、 部門、コンピュータープログラム、 コンピューターシステムなど。 判断を下せる実態を示す
    • 要件の範囲を表すボックス
      • アクターがシステムを使ってできること書く
      • ボックスの外にシステムと相互に作用する 様々なアクターを示し、ボックスと繋げる
    • ユースケースは IT プロジェクトや IT 以外のプロジェクトで 要件を文書化する際に使用できる
    • ユースケースにより 関係者は要件が機能となり ビジネスニーズを満たす要素を 想像しやすくなる
  • パフォーマンス要件カード

    • 機能カードと似ているが、このカードには 複数の機能に適用される要件を示す
    • 各要件には固有の ID、 内容を示す簡単な名称、 またはタイトルが必要
    • 困難度
      • 業務部門がその他の要件や 機能と比較して 優先順位を決定する際に役立つ
      • 複雑度(低・中・高)
    • 最後の受け入れテストの項目
      • プロダクトの開発後に 要件が実現したかどうかを 検証する方法を示します。

要件の文書化はどのようなプロジェクトでも重要。アジャイルプロジェクトでは 要件が継続的に増加する。 ビジネスアナリストが中核的チームに 先立って取り組みを進めると 各スプリントの始動時に機能や要件に関する 最新情報が得られる。

スタンドアップミーティングを計画・実施する

  • 毎日のスタンドアップミーティング

    • 重要な情報の共有
    • 所要時間は15分
    • 立ったまま行うことで頭がさえ、楽観的でアクティブな状態を維持できる
    • 業務部門と技術部門のチームメンバー全員と プロジェクトマネージャー、 別名スクラムマスターが 出席
  • PMの役割

    • 会議の進行役は努めない
    • チームのステータスを様々な順序で提示させる
    • タイムキーパを割り当てる/ローテーションする
      • 一人30s~1m
      • 慣れたら不要
  • スタンドアップミーティングでは

    • 問題を解決しない
      • 最も難しい
    • 必要なメンバーに限定
    • 一貫性が重要
      • 同じ時間
  • PMが観察する項目

    • チームメンバーが協力し合っているか
    • リスクが表面化しているか?
    • 解決を支援できる一般的な問題があるか?
    • 問題のリストに含まれる項目が増加しているか?
    • アジャイルプロセスに難しさを感じているチームメンバーはいるか?
  • 前向きな雰囲気で終わらせる

    • 成功体験を共有する
    • 進捗を示す
    • 前向きな姿勢を維持
  • 毎日合っている場合は空けてもOK

  • 週に1回のペースで

    • 他の関係者を参加させる
    • 最後に5分感、質問の時間を設ける

計画を管理・調整する

  • アジャイル手法にうとい人の誤解

    • アジャイルプロジェクトには制御の仕組みがない
  • スコープは未処理リストで管理する

    • フィーチャーの完了と新しいフィーチャーの追加によって範囲をコントロールする方式
    • 業務部門と技術部門が協力し、 継続的に優先順位を見直し、 次のスプリントで実装する機能を 判断する
    • 未処理リストへのこのような変更は 一般的に行われるが 現行スプリントのスコープは 常に固定することを忘れてはならない
    • 機能リストは合意したら その後は変更してはならない
    • ベロシティ
      • スプリントで完了している 平均的な機能の数
      • これは以前のスプリントを 調べることで算出可能
      • チームの資源=ベロシティ
      • 低下している場合
        • 原因を取り除く
      • 下方修正する場合
        • 今後のスプリントで対処するフィーチャー数を減らす
      • 利点
        • 生産速度の把握によって制御を可能にすること
        • 状況に応じてリリース計画や資源を調整できる
  • ベロシティを使うと生産率を把握できる

  • バーンダウンチャート

    • これから完了する作業を表すコミュニケーションツール
    • 機能の生産が 予定より進んでいるか遅れているか そして全機能がいつ完了するかを 明確に示す。この情報を使用して進捗を継続的に監視し 必要に応じて調整して 生産性を最大限に高めることが重要。
  • バックログチャート

    • 機能数(フィーチャー)と完了までの予想期間を表すもの
    • X軸
      • PJのタイムライン
    • Y軸
      • PJ or スプリントで未完了の作業
    • 開始点では残りの作業は全作業ということになる
    • 進み具合を予定と比べて見る
      • これに応じて各スプリントで
        • 完了する機能を調整する
        • 時間やコストを増やす
        • 生産能力に合わせて機能の計画を見直す といったことが可能になる

アジャイルプロジェクトは、これらの シンプルな制御テクニックを使用すれば うまく管理できる


ポイント

  • 要件を特定するために、中核的チームよりも1つか2つ先のスプリントに取り組む人
    • ビジネスアナリスト
  • スタンドアップミーティングにかける理想的な時間
    • 15m
  • スタンドアップミーティングの特徴
    • 参加者が立って行う
    • リモートの場合はどうすべきか?
  • 平均的なスプリントでチームが開発する機能数のこと
    • ベロシティ

5. 探索:開発・制作プロセスを管理する


開発業務を干渉せずに管理する

  • マネージャーの役割
    • チームを リードすることではなく 観察して相談に乗ること
      • 従来のPMとの違い
    • コーチングで導く
    • 障害を明確にする
    • スタンドアップミーティングではしっかり耳を傾ける
    • フォローアップを行う
      • ミーティングの後にフォローする
  • リソース
    • 情報(顧客、既存のシステム、作業の繁忙期など)
    • ツール(プラットフォーム、試験期間、専用ソフトウェアなど)
    • 専門家との関係(業界の専門家、設計者など)
    • トレーニング(経営方針、カスタマーサービスなど)
  • チームによる手動が必要な場面
    • フィーチャーに優先順位を付ける
    • タスクの見積もりを行う

マネージャーはこれらの主導権をチームにゆだね、必要な時だけサポートする

  • チームの自主性を助ける重要な方法の一つ

    • チームの決定を支援する
  • 決定が順当に行われるようにする

    • 失敗から学ぶ
  • よくある問題を回避するためにすべきこと

    • 顧客は開発チームと日常的に共同作業を行い、効果的な協力を実現しているか?
    • 顧客が主要なチームメンバとコミュニケーションがとれていないほど多忙ではないか?
    • 上層部が反復型のアプローチに困惑し、 必要な機能を完了できるのか 心配していないか?
      • 上層部の不安については 最初の数回のスプリントでコミュニケーションを時間をかけることで軽減可能
  • リズムに合わせる

    • 生産性の高いチームは一定の周期で 作業を進める
    • スプリントの期間が6週間の場合、プロダクト機能を開発する2~5週目の間に作業が集中することがある
    • マネージャーがストレス要因に注意し、 各自の作業負荷を 効果的に管理できているか確認する
    • 次のスプリントに備えることができるように 作業が少ない週も設ける

探索フェーズではプロダクトマネージャーはタスクマスターではない。各チームメンバーの効率を 最大限にするためにできることを全て行い、主体的で生産性の高いチームとなるようにサポートする。

効果的なコラボレーションを実現する

  • スプリントを成功させるには効果的な協力が不可欠

  • PDCAサイクルはコラボレーションの促進に有効なテクニック

    • Plan
      • 作業が発生するとメンバは通常二人一組で簡単な作業計画を立てる
    • Do/Check
      • 一人が作業を実行して完了後に、もう一人が検証して評価する
      • GitのIssue運用のイメージ
    • Adjust
      • 結果が期待と異なる場合はすぐに改善意取り掛かる
  • コロケーションを実施できない場合

    • アジャイル手法は各チームが 同じ場所で作業することが前提ですが 現実では難しいことも多い
    • 中核的チームメンバーが 同じ場所で作業できない場合は コラボレーションのためのツールや技法を 追加で用意する必要がある
      • Slack, Teams, Git等のイメージ
    • その他例
      • Sharepoint
      • ビデオ会議
    • 少なくとも1回は 実際に顔をあわせるようにする
      • PJの開始時が良い。最初のスプリントを 一緒にやることも効果的。
  • 探索フェーズではマネージャーはチームの規範が確立していて 意思決定の方法について、合意が得られていることを確認する。 全員の意見が一致しなかった場合の枠組みや 手法を決めておくとよい。

  • 決定が全員一致ではない場合のフレームワーク

    • アイデアの共有を奨励
    • 責任をもって率直な意見を述べる
    • アイデアにしっかり耳を傾ける
    • 過半数の賛成で決定とする
      • 話し合いが 堂々巡りになるのを防ぐ
    • 決定の根拠が理解されなければならない
    • 反対する人の支援が必要
    • 拒否権を持たない
      • チームの決定は覆さない
  • 全員一致が理想だが、討論の時間には制限を設ける

    • 全員一致を目指すことに同意したとしても 議論の時間に制限を設けて 適切なタイミングで 結論を出すようにする

普段からPDCAや有効なコミュニケーションツールを使用し チームの規範で意思決定の方法について合意を得ておく必要がある。これらをGitのWiki等に載せていくイメージ

問題とリスクを管理する

  • 問題が表面化したときにするべきことについてチームを教育する
  • 互いに信頼を気づくっことが重要
  • 健全な対立をする
    • 問題を批判する
      • 人を批判するのではない。よく言われていること
    • 対立に真正面から取り組む
    • 事実を提示する
    • 賛否両方のシナリオを示す
  • 決定を行う必要がある場合

    • 明確にする
    • 根拠を示す
    • 視線を要請する
  • 優れた作業環境

    • コロケーションが不可欠
    • 静かな場所が用意されている
    • 仕切られた場所が用意されている
    • ヘッドフォンの使用が許可されている
  • 物事を戦略的に見ることが必要

    • チームにリスクの譲歩を提供し続けることで、メンバー自身がリスクを低減する能力があることを再認識できる
  • 問題およびリスク管理

    • 関係性が重要
    • 意思のぞ通
    • 明確なガイドラインを示す
    • 解決の為のツール

6. 適応と終結:納品前に微調整する

スプリントで学んだ教訓を確認する

  • 正しい質問をすることが重要

    • 批判的な観点からPJを確認する
  • 適応フェーズを待たずにフィードバックを得る

    • メンバーが感じた問題点をいつでもメモできる場所をチームルーム内に設けておく
      • 前後関係が分かるよう詳細に
      • 解決方法は分からなくても構わない。フィードバックを書き留めるだけ
        • GitのIssueやWikiを利用する?
      • 中規模の機能の完了に 予定より時間がかかっている
      • 毎日のミーティングに 15 分以上かかっている
      • 常に新しい機能が必要になるので 終わりが見えない
    • こうすることでスプリントの最後に振り返りをする際に議論の材料となる情報がたくさん集まる。通常はスプリント中に作成したリストを基に 振り返りに参加したメンバーから 他の問題点を引き出す
  • 教訓を得られるフィードバックを優先する

    • 問題点をすべて確認したら、プロジェクトへの影響に基づいて フィードバックの優先順位を決める。それぞれの対処方法を判断し、優先順位が高いものに 重点を置く。
  • 優先順位をつけるための技法

      • 項目が30とする。振り返りの参加者に10票ずつ与え、PJにとって最も重要だと思う項目に投票してもらう
  • 問題の根本的な原因を特定する

    • いいアイデアを集める
      • アイデアが湧いてくるようにする
      • 創造性を持つことを奨励する
      • できればチームメンバー外の人にファシリテーションを任せ、マネージャーもメンバとして参加する
  • 5本指の投票

    • 提案された解決策に対する賛成度合いを指の数で表す
      • 5 満足している
      • 4 まあまあ満足している
      • 3 普通
      • 2 懸念がある
      • 1 重大な懸念がある 
    • 1, 2を投票したメンバーに懸念していることを確認
    • 全員が3以上に投票するまで解決策を練り直す

どのような決断に達したとしても プロジェクトに関するすべての変更点を 中核チームと広範囲の関係者に伝え全員が 新たな方向性を確実に理解するようにする

ビジネスの優先事項の変化に対応する

アジャイルでは変化するビジネスニーズに対応することが重要

  • ビジネスに対応する際に考慮すべきこと

    • 機能の優先順位設定の影響については業務部門に助言しておく必要がある
      • 同種の機能を一スプリントで実装する場合と複数スプリントに分解して実施する場合で工数が変わるため、再見積もりする必要がある
    • PMはこの影響を顧客に伝える必要がある。通常はコストや資源に影響する
  • 必須のフィーチャーが存在する場合がある

    • 先に作る必要がある機能など
  • ビジネスの優先順位の変更により フィーチャーが再開発されることがある

  • フィーチャーの再構築

    • 通常起こりうるが、計画が必要
      • アジャイルではよくあることなので 計画に織り込んでおく。
    • 新しい順序があれば確認する
    • 正確な見積もりを可能にする
      • 初回スプリントで リリース計画を作成する際に 後続のスプリントの見積もりを 正確にするために その分野の専門家が 提案された機能の順序を確認し、 設計と再開発の影響を 判断する必要がある。 適切に計画して見通すことで業務部門は 機能の優先順位を管理し、 プロジェクトチームは助言をして 各スプリントで変更を適用するというアジャイルの基本原則を維持できる

PJを終結する

  • 終結フェーズはPJ全体で学んだ教訓を理解し、文書化することから始める

    • アジャイルの標語ではこれを振り返りと呼ぶ
  • 振り返り

    • PJ(またはスプリント)の教訓を記載した文書を作成すること

終結フェーズでは他の関係者を招待してもOK
振り返りが完了したら終結処理に入る

  • 終結フェーズを開始する場合

    • 全フィーチャーが実装済み
    • 時間が残っていない
    • 資金が残っていない
  • PJを終結する場合んお検討事項

    • バックログリストを見直す
    • 残りのフィーチャーの重要性を判断する
    • 新しいフィーチャーが必要かどうかを考える
    • 新しいPJが必要か考える
  • 優先度の低いフィーチャーを段階的に実施するように変える

  • 成り行きを見る は有効なアプローチ

  • 業務部門にバックログリストを提供する

  • チームイベントは重要

    • 終結を実施する
    • PJが終了したことを知らせる
    • 成果を評価する
    • メリットと問題点について話しあう
  • マネージャーと協力してチームメンバーの次の任務を決める

    • PMはメンバーを通常の業務に戻すか、他のPJに移す
  • PJ終結の「人間的側面」

    • 感情的になる可能性がある
    • 注意散漫になる場合がある
    • 全体的な有効性に重点を置く
    • 改善点について検討する

7. アジャイルのヒントとコツ

トラブルの兆候を見極める

アジャイルプロジェクトでもトラブルが起きることはある

  • トラブルの兆候

    • 残っているフィーチャー
    • スノープラウィング
      • スプリント終了時にフィーチャーを次へ持ち越さない
      • 通常最初の2つのスプリントの終了時に実際の生産性に合わせて 見積もりを修正する。 ただし修正が繰り返し行われる場合は すぐにミーティングを行って 原因を話し合い、 適切に対処することが必要
    • 優先度の低いフィーチャーの開発
    • 不適切なフィーチャー
    • 修正が必要なフィーチャー
  • 問題の根本的な原因

    • 適切な質問をしなかった
    • 何を開発しているかを顧客が理解していない
    • ビジネスニーズを正確に把握していない
  • 根本的な原因への対応

    • プロダクトレビューを行う
    • プロダクトバックログを修正する
  • その他のトラブルの兆候

    • チームの出席率の問題
      • 欠席しtアメンバーに個別に連絡する
    • PJバッファを使い切っている
      • 最適なツールは問題ログ
        • 問題発生の日付と説明、 その原因を記録
        • これで問題の規模と回数を確認し、 バッファをいつどのように使っているかを 把握する
    • PMとチームのどちらが「解決者」になるか
      • 成功するアジャイルチームには自己統治が大事

管理手法の調整

  • アジャイル手法を初めて使用する場合

    • 経営陣の不安を予期する
    • 経営陣にとって重要なことに重点を置く
    • 経営陣の考えを誘導する
  • 経営陣の一般的な優先事項

    • ビジネスの問題を解決する
    • 統率力を維持する
    • チームの指揮を高める
  • 顧客満足

    • 顧客の積極的な参加を求める
  • 顧客の役割

    • プロダクトのバックログを定義する
    • 優先するフィーチャーを決める
  • 統制の維持

    • 協力関係を管理する
    • 重要な管理手段を理解する
    • 従来の報告手段が役に立つ場合もある
  • スコープの管理

    • プロダクトのデモで得られた顧客のフィードバックを活用する
  • 時間の管理

    • MS Project等でマイルストーンのガントチャートを作るのもいい
    • スプリントごとのフィーチャー、 プロジェクト全体のスプリント間の 依存関係を示し 定期的に内容を更新して 経営陣に見せることができる
  • コスト管理

    • 固定予算を示す
      • 信用を得るには アジャイルプロジェクトに チームのメンバーだけが使用できる 固定予算があることを示す。 従来のプロジェクトでよく使われる 実コストと予算の関係性を示した S 字曲線ではなく、 顧客と開発チームの両者が フィーチャーごとのコストと ビジネスにもたらす実益を 比較できるものを用意しする。
    • フィーチャー毎のコストと、ビジネスにもたらす実益を比較する
      • フィーチャーの納品時には 予算残額を査定し 承認された資金を使いきる
  • チームの士気を 高める要素
    • 適切な技能
    • コントロールの分担
    • 迅速に成果を出す
    • 成功を繰り返す

その他

  • 手法以上にチームのコミュニケーションに重点を置く

  • 経営陣に進捗を報告する

  • メンバ全員に各自の役割とチームのミッションを理解させるのが重要

  • 一貫した強いリーダーシップを示すのが成功のカギ

  • スノープラウィング

    • プロジェクトマネージャーが完了した作業をチェックし、計画と相違ないことを確認する作業

関連記事

@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×