アジャイル開発の研修メモ

会社でアジャイル開発の研修を受けさせてもらったのでそのメモ。
メモっただけで理解できていないことなどが多いので、後々調べて理解していく。

研修が終わって一番重要だと感じたのは、アジャイルな開発手法を導入することよりも、
アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則 )」が、チームや経営陣に理解されないと成功しないだろうと感じた。

そこも含めてアジャイルの導入なんだろうけれど。

以下からは研修のメモ書き。


プロジェクト失敗の要因

  • ユーザのインプット不足
  • 不完全な要求事項と仕様
  • 要求事項と仕様の変更
  • 経営者の支援不足

ウォーターフォール型開発の前提

  • 顧客の要求は予め明確になっている
  • 顧客の要求は開発者側に正確に伝わる
  • 顧客の要求は大きく変更されない
  • プロジェクト計画に従えば予定どおり進む
  • 前工程には間違いがない

アジャイル開発とは

  • 反復
  • 漸進的
  • 適応
  • 自律的
  • 多能工
  • 強調

アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発宣言

アジャイル開発の価値観の共有
共通の概念や考え方を広く社会に知らせる

  • プロセスやツールよりも⇨個人と対話を
    • 尊敬の気持ち
    • お互いの信頼感
    • 自由にやり取りする雰囲気
    • 良いコミュニケーション
    • 透明性
    • 目標に対する貢献
  • 包括的なドキュメントよりも⇨動くソフトウェアを
    • 顧客が要求する実行可能な状態のソフトウェア
    • 正しく機能するソフトウェアを一定の間隔で提供
  • 契約交渉よりも⇨顧客との協調を
    • 顧客のプロジェクトチームへの参加
    • 顧客との緊密なコラボレーションの方法や仕組みの導入
  • 計画に従うことよりも⇨変化への対応を
    • 顧客の要求は始めから全てを明確に定義できない
    • 変更があるのは当たり前であるという前提で柔軟に対応

アジャイルマニフェスト 12の原則

アジャイル宣言の背後にある原則

アジャイル開発の特徴

  • 反復・漸進型開発
    • 設計・開発・テストを繰り返し開発
  • ドキュメントより動くソフトウェア
    • 顧客の要求は事前に明確に定義できない
    • 必要なドキュメントは最小限に
    • 顧客との対話を重視しながら要求を明確に
    • 動くソフトウェアのもとで品質管理
  • 顧客との協調
    • プロジェクトの開発時点では、その後の全てを見通すことはできない
    • 反復開始毎に優先的に開発すべき要求を顧客と一緒に決めて実行
    • 顧客のプロジェクトへの参加は必須
  • 変更に柔軟に対応
    • 開発中もビジネス環境が変化して要求自体も変わってくる
    • 変更があるのは当たり前
    • ビジネス価値を上げる要求は歓迎
    • 全ての要求が自由ではない
  • 個人間の相互作用「自己組織的チーム」
    • チーム自身が責任をもって、自律的にプロジェクトを運営
    • 問題意識や目的を共有
    • それぞれの相互作用による知恵の出し合い
    • ひとつの組織としての意思決定
  • ペア・プログラミング
    • 技術の共有
    • 質の高いプログラミング
    • コード全体の問題点とメンバー特性の共通認識
    • ドライバーとナビゲーター
  • テスト駆動開発
    • 最初にテスト項目を決め、動作する必要最低限の実装をまず行う
    • 次にコードを洗練させる
    • XPで多く用いられる

ウォーターフォール型開発との比較

ウォーターフォール アジャイル
成功の指標 計画に合致 変化に対応、正常に動くコード
要求と設計 前もって、大きく 継続的、その都度適切な内容を定義
コーディングとテスト すべての機能を順番にコーディングし、後でテスト コーディングと単体テスト、連続的にリリース
テストと品質保証 計画主体、最後にテスト 並行的、継続的、早期にテスト
管理の文化 命令と管理 リーダーシップ、コラボレーション

アジャイル適用の効果(顧客視点)

  • 早期に導入効果を実現
  • すべての要求が決まらなくても着手可能
  • リスクを早期に軽減
  • 高い投資効果(80:20の法則)
  • Time to Market向上
  • 変化への対応が容易

アジャイル適用の効果(受託企業視点)

  • リスクの早期発見
  • 動くソフトウェアの早期リリース
  • 頻繁な反復による品質向上
  • モチベーション向上と高い生産性
    • 顧客の役に立ったという達成感
    • 自らの責任で計画を立てて実行するためやらされ感がない
  • 開発者の能力向上
  • 残業からの解放
    • 自分たちの開発能力から見て達成可能な計画を自主的に立てる
  • ムダの削減
    • 手戻りがなくなる
    • face to faceのコミュニケーション重視のため、「不要」なドキュメントは作らない
  • 振り返りによる継続的改善

アジャイルのプロセス

スクラムの原点

  • 新製品開発ゲーム
    • 高いパフォーマンス⇨少人数の組織横断的なチーム
    • ラグビースクラムのような自己組織チーム⇨組織の障害要因が取り除かれれば、より高品質なソフトウェアを提供可
  • リーン生産方式
    • リーン:痩せた、贅肉のないの意味
    • 必要な時に必要なものを必要なだけ作り、在庫を寝かせずフル回転させるジャストインタイムのカンバン方式
    • 自ら仕事の結果をチェックし、異常はその場で解決し、次工程に持ち越さない
    • 多能工、目で見て管理、目標を掲げ改善を継続

      スクラムの精神

  • スクラム
    • 反復的な開発アプローチ 動くソフトウェアを順次作り、発展させながら開発を進める
    • タイムボックス:すべての作業や会議は規定された時間内に完了。
    • 目標の共有:目標を共有し、自ら方向性を定め、日々の時間管理をし、改善する
    • 固定したチーム:メンバーは専任。交代せず固定化した体制で臨む。
  • 確約(Commitment):約束したことを確実に実現すること
  • 専念(Focus):確約したことの実現に専念すること
  • 格差ない(Open):たとえ自分に不利なことでも包み隠さないこと
  • 尊敬(Respect):自分と異なる人に敬意を払うこと
  • 勇気(Courage)確約し、隠さず、敬意を払うことに勇気を持つこと
  • スクラムチーム
    • プロダクトオーナー
      • プロダクトの要求事項の定義
      • プロダクトのリリース計画と内容の決定
      • プロダクトの収益性、投資回収性の責任
      • 要求事項の優先順位付け(ビジネス価値・リスク)
      • 作業結果の評価・判断
    • 開発チーム
      • プロダクトの要求事項を反復ごとに納品
      • プロダクトオーナーに品質と納期をコミット
      • 組織横断的チーム活動
      • 自己組織的チーム活動
      • 継続的プロセス改善
    • スクラムマスター
      • 開発チームを自己組織的チームに育成
      • 開発チームの反復活動を支援
      • 開発チームの機能向上、品質向上、生産性向上を支援
      • 開発チームのコラボレーション促進
      • 進捗の阻害要因を除去
      • 開発チームに対して指示・管理は行わない
  • スクラム開発の流れ
    1. リリース計画
    2. プロダクトバックログ (開発対象の動くソフトウェアに関するすべての要求機能が一覧になったもの)
    3. スプリント計画ミーティング
    4. スプリントバックログ (プロダクトバックログを動作するソフトウェアとして実装するために必要な作業のリスト)
    5. デイリースクラム (毎日のミーティング)
    6. スプリント
    7. スプリントレビューミーティング
    8. スプリントレトロスペクティブミーティング
  • リリース計画
    • プロジェクトビジョン
      • 戦略性:ビジネスの価値、差別化要素
      • 目的:システムで実現したいこと
      • プロジェクトスコープ:プロジェクトの全体像
      • 機能・性能:システムにして欲しいこと
    • 要求機能の表現方法
      • ユーザーストーリー
  • プロダクトバックログ
    • 開発要求リスト
    • 優先順位
    • 常時開示
  • スプリント計画ミーティング
    • スプリントゴール どの要求を構築するか
    • スプリントバックログ 選択した項目をタスクに分解
  • スプリントバックログ
    • プロダクトバックログを実装するために必要な作業のリスト
    • 担当するタスクはメンバー自らが選択
  • デイリースクラム
    • 日時の15分程度のミーティング
    • 昨日は何をしたか、今日の予定、今抱えている課題
  • スプリント
    • 最大30日
    • 各スプリントの長さは同一
    • 作業に専念できる環境にすること
      • チーム以外の人は、スプリント中にチームが行っている作業の範囲を変更することはできない
      • チーム以外の人は、スプリントに昨日や技術を追加してはならない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
    • バーンダウンチャート 源氏あの状況をモニターし、どれだけの作業が残っているかを視覚的に分かりやすく表示
  • スプリントレビューミーティング
    • 動くソフトウェアが完了基準を満たしているか
    • プロダクト・オーナーからのフィードバックと受け入れの判断をしてもらう
    • 結果をプロダクトバックログに反映、ソフトウェア全体の完了日を予測
    • プロダクトバックログの内容と優先度の見直し
  • スプリントレトロスペクティブミーティング
    • 振り返り
    • 続けたいことと改善したいことをチーム全員で共有
    • 話題の対象は開発に関わる全てのこと
    • 開発チームが自主運営
    • 自由闊達になんでも話し合える

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

エンタープライズアジャイルとは

  • アメリカを中心に海外ではビジネス、ITの分野で広く普及している
  • 2001年のアジャイル宣言
  • 変化するビジネスニーズへ、より迅速、的確に対応
  • ITを通じてお客様のビジネス価値向上

普及への仮題

ハイブリッド開発

  • ハイブリッド開発の例
  • アジャイル開発に向くプロジェクト
    • 要求が事前に定めにくいプロジェクト
    • 革新的、実験的、経験がない分野のプロジェクト
    • 顧客が積極的に参加出来るプロジェクト
    • スキルが高く、高いモチベーションと専門性を持ったチームが編成できるプロジェクト
    • 日々チーム内及び顧客との緊密なコラボレーションができるプロジェクト
  • ウォーターフォール型開発に向くITプロジェクト
    • 事前に要求がほぼ確定できるプロジェクト
      • 基幹系業務、感情系業務
    • 厳格な変更管理が要求されるプロジェクト
    • 広範囲のドキュメントが要求されるプロジェクト
    • 法律や規則へのコンプライアンスが要求されるプロジェクト
    • 主要な役割に未経験者を割り当てしないといけないプロジェクト
      • 人材不足なプロジェクトってこと?
    • 顧客やエンドユーザのプロジェクト参画が制限されるプロエクト
    • 分散開発環境のプロジェクト
      • 複数のベンダーが関わるとか?

アジャイル開発のメリット

  • 顧客側
    • 頻繁な反復レビューにより、プロジェクトの進捗状況がわかるため安心感がある
      • 顧客がシステム開発に理解があれば良いけれど、そうじゃない場合は発注したんだからあとはちゃんと作ってになりそう
    • 反復レビューとフィードバックによって価値のあるシステムとなり、満足度が向上する
    • 開発の終盤まで要求仕様が検討できる
  • 開発側のメリット
    • 頻繁な反復レビューによって、リスクを早期に検知できる
    • 頻繁な反復テストによって、品質が向上する
    • 仕様追加があっても柔軟に予算と納期に対応出来る
      • 予算増えるの?納期変えられるの?どうやって?
    • 開発に投入するマンパワーの平坦化

チーム発展

  • チームとは
    • 共通の目的、達成すべき目標、そのためのアプローチを共有し、連帯責任を果たせる補完的なスキルを備えた人の集合体。
  • チーム発展段階モデル
    1. 成長期
    2. 動乱期
    3. 安定期
    4. 遂行期 自己組織的チームになる
  • 自己組織的チーム
    • お互いの信頼
    • 共通の目標を一緒に協力して達成する
    • 自由裁量権あるいは権限移譲されたチーム
    • チーム自ら意思決定する
    • チームは計画実行をコミットする
    • 情報はオープンで共有かされている
    • 建設的な反対意見は歓迎される
    • メンバーの役割は明確である
    • メンバーは高いモチベーションを持っている
    • マネージャーはチームをコントロールするのでなく支援する
    • プロセスは継続的に改善がなされる
    • 対話を重視する
    • お互いが助け合う
    • お互いが学び合う

アジャイルとリーダーシップ

  • アジャイルを成功に導くリーダーシップ
    • 感情の知性(EQ Emotional Intelligence Quotient)
      • 感情の状況を理解し、それをうまくコントロールする能力
      • 人の言動や行動は、その時々の感情の状態に大きく影響される
      • 良い人間関係
      • EQは適切な訓練によって高められる
      • 自分の今の感情の状態を認識し、それをコントロール
      • 相手の今の感情の状態を認識する
    • コミュニケーション
      • 個人との対話を
      • 顧客との協議を
      • 動くソフトウェアを
    • 共同作業とチームワーク
      • チームワークの善し悪しが開発業務の成否を左右する
    • ビジョン
      • プロジェクトが進むゴールを明確に示す
      • ゴールの共有
    • ファシリテーション
    • 他者の成長
    • コンフリクトマネジメント
      • 効果的なコンフリクトは必要、コンフリクトを有効活用する
    • 柔軟性
      • 変化へ柔軟に対応
  • 指示管理型リーダーシップとコラボレーション型リーダーシップ
    • モチベーション
      • 指示管理型:大きな権力を持ちたい
      • コラボレーション型:他者の役に立ちたい
    • マインドセット
      • 指示管理型:競争を勝ち抜き自分が賞賛される
      • コラボレーション型:強調とWIN/WINを重視
    • 影響力
      • 指示管理型:自分の権力を行使して畏怖させて動かす
      • コラボレーション型:信頼関係を気づき、自律性を重視、説得して動かす
    • コミュニケーションスタイル
      • 指示管理型:他者に対して命令、指示することを重視
      • コラボレーション型:他者の話を傾聴することを重視。
    • 業務遂行能力
      • 指示管理型:自分自身の能力向上で得られた自信をベースに他者に指示する
      • コラボレーション型:他者の育成、ともに学習することにより能力向上
    • 成長についての考え方
      • 指示管理型:しゃない制度等を利用することで自分の地位を上げ、成長していく
      • コラボレーション型:他者のやる気を大切に考え、個人と組織の成長の協調を考える
    • 責任についての考え方
      • 指示管理型:責任とは、失敗した時にその人を罰するためにある
      • コラボレーション型:責任を明確にすることで、失敗からも学ぶ
  • サーバント・リーダーシップとは
    • リーダーシップのスタイル
    • 5つの柱、11の特徴
      1. 奉仕の精神
        • 奉仕
          • 使命感:使命感を持って下から支える
          • 導き:共通のゴールに向かい導き、組織と人を動かす
      2. 対人関係力
        • 傾聴
          • 最後まで話を聴く
          • 相手の方を向いて聴く
          • 相槌を打つ
          • 黙ってもせかさない
          • 体全体で聴く(顔の表情、しぐさまで含めて)
          • 相手の発するシグナルをきちんと受け止める
          • 相手の言葉の奥底に潜む本筋と感情を理解する
          • 相手から自分の話を聴いてもらえるという姿勢
          • 的確な質問で、相手の意図を引き出す
        • 共感
          • 他人の感情、軽々ん、問題を理解する。あるいは共有する能力
          • 期待値を理解する
          • イメージ力を強化する
          • 共鳴しあえる共通の価値観の見い出し
          • 相手が欲している、困っていることを理解するため相手との架け橋を作る
          • 感じたことを相手に伝える優しさを持つ
          • 相手は共感してほしい、共感したいと思っている。自分の感情も相手に伝えてみる。
        • 気づき
          • 自分自身、組織、スタッフすべてに気を配る
          • メンバーに対する気づき
          • プロジェクトに関する気づき
          • 自分自身に対する気づき
          • 何が問題で何をすべきか
          • 刻々と変化する女うっ今日にたえず敏感になる
          • 自分自身の能力や限界を理解し、他人の意見に耳を傾け自己開発に努める
        • 癒し
          • 相手にかけているもの、木津ついていることを見つけ出し助言を与える
          • かけている部分を見つけたら、すぐに誘いの手を差し伸べる
          • ねぎらいと感謝の気持ちで接する
          • かけていることを悪と捉えない
      3. ビジョン
        • 概念化
          • 目指すゴールの絵を描く
          • 達成可能な大きな目標を立て、具体的な手順を列挙する
          • メンバーには結果責任を負わせながらも、目標達成ん向け自ら模範を示し、導く
        • 先見力・予見力
          • 目的地までどうやって行くかを示す力
          • 通常ルートと何かが起こった時のルートを予見する
          • リーダーは、行き方を常に見直しながら、何が起きるか察知して適切な判断を適宜下す
          • 洞察力を付ける
            • 直感的に判断する力
      4. モチベーション
        • スチュワードシップ
          • 大切なものを任せても信頼できると思われるような行動
          • 権力・理屈などに依存せず黙々と自分の役割の遂行に浸る
          • その人の背中を見て人々が自然と付いてくるような行動・姿勢
          • 組織の大きなゴールに応えるためには自己犠牲も厭わない
        • 説得
          • あることを相手に説明し、納得してもらい、相手に行動を自発的に起こしてもらう
          • 権限に依存することなく、服従を強要しない
          • 納得してもらい、共通のコンセンサスを確立する
          • 説き伏せるのではなく、自発的にゴール・ミッションを納得してもらう
          • 相手の言うことに耳を傾けながら、自分自身の意見も主張し相手にわかってもらうの力が必要
      5. 成長
        • 人々の成長へのコミット
          • メンバー一人一人に目をかけ、人間的にもキャリア的にも成長することをコミット
            • 定期的な面談、現場研修への積極的な参加、グループディスカッションを実施
            • メンバーの成長意欲を満たし、サポートする
          • 自分勝手な選り好みはしない
          • リーダーの役割はメンバーがゴールを達成するのを助けること
          • メンバーのパーソナルスキル、プロフェッショナルスキルの開発
          • 効果的なフィードバックを行い、さらなる成長のためのニーズを見つけ出す
          • 開発チームの一人一人の少しづつの成長がチームの成長になり大きなパワーになっていく
        • コミュニティづくり
          • 情報、計画、資源を共有しながら共同作業をする
          • 友好的、協力的雰囲気を作り出す
          • 自らが尊敬、助け合い、強調の模範となる
          • 積極的、情熱的なコミットメントを喚起し、チームを一体感ある集団にする
          • 顕密な人間関係を作り上げることに時間をかける
          • まずは、開発チームというコミュニティを念頭に置く