あうとかむ

やったこと。どーでもいいこと。思いついたこと。技術系。読書系。etc.

アジャイルマニフェスト:メモ

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

冒頭

ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている

4つの価値

  • プロセスやツールよりも個人と対話
  • 包括的なドキュメントよりも動くソフトウェア
  • 契約交渉よりも顧客との協調
  • 計画に従うことよりも変化への対応

左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく

12の原則

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

読み解き方

アジャイルソフトウェア開発宣言の読みとき方 (IPA)

アジャイルソフトウェア開発宣言」に対する誤解と真意

  • 「対面コミュニケーション」
    • 個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。
  • 「実働検証」
    • 動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがよりよい成果を生み出す。
  • 「顧客とのWin-Win関係」
    • お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。
  • 「変化を味方に」
    • 顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。

原則01 顧客の満足を求め続ける

  • 基本的な考え方

    • 顧客に(QCDの達成ではなく)ビジネスゴールの達成の観点で満足してもらう
    • ビジネスの成否はビジネスごとに異なります
  • 行動規範

    • ビジネス側の人と開発者は
      • ビジネスゴールについて初期の時点で徹底的に話し合う
      • QCDの達成ではなく、ビジネスゴールの達成を目指す
      • ビジネスゴールに向かっているかどうかを常に確認し、方向がずれていたら素早く修正する
      • ソフトウェアで実現すべき要件を顧客の立場で一緒に考える
      • 顧客が価値を確認しやすい単位に分割し、分割した単位を、素早く継続的に、顧客に提供し続ける

原則02 要求の本質を見抜き、変更を前向きに

  • 基本的な考え方
    • 最初から要求に明確な答えがないことが多く、作るものが不明確な場合があります
    • 開発の後期であっても、要求の本質を見抜き、与えられたコスト・納期・スコープのバランスと要求の優先順位から、変更の受け入れを判断する必要がある
  • 行動規範
    • ビジネス側の人と開発者は
      • 変化を「新しい価値」の発見の機会ととらえる
      • 改善に繋がる要求を生み出すことに努める
      • 価値があるのであれば、積極的に変更を受け入れる
        • ただし顧客に言われるがままに変更を受け入れることはやめる
      • 間違いについてもオープンに議論する
      • よりよいフィードバックを生み出すようなリリースをする

原則03 成果物を2-3週間で、リリースし続ける

  • 基本的な考え方
    • 長い開発期間中に当初顧客が望んでいたゴールが変わり、顧客が本当に欲しかった成果を得られなくなっている可能性がある
    • 成果物を頻繁にリリースすることで、顧客からフィードバックを得ることができ、結果として顧客が本当に欲しいものを作ることができる
    • たとえ後戻りがあったとしても小さくすませることができる
  • 行動規範
    • ビジネス側の人と開発者は
      • 要求は不確実であり変化することが前提であることを共有する
      • 価値に結びつかない中間成果物ではなく、ビジネス観点で評価できるものを提供する
      • 成果物のリリース間隔をビジネスの観点から決める
      • 市場からのフィードバックを共有する

原則04 全員で共通の目標に向かおう

  • 基本的な考え方
    • 不確実性の高いプロジェクトでは、状況が刻々と変化するため、共通の目標が見えないまま進めると、認識の齟齬などが発生する可能性がある
    • 作るソフトウェアの価値やプロジェクトの状況について、常に共通目標に向かってベクトルを合わせながら働く
      • ビジネスの価値を最大化するため
  • 行動規範
    • ビジネス側の人と開発者は
      • 一緒の場所で働けない場合は、工夫して、方向性を共有する
      • 一緒にビジネスを成功に導くという共通目標を日々確認する
      • 全員で双方向のコミュニケーションが図れるようにする
        • 要求の出しっぱなしはやめる
        • フィードバックをもらうために、頻繁にリリースをする
      • 全員が共通認識を持つために、必要最低限のドキュメントを書く

原則05 人の意欲は信頼から

  • 基本的な考え方
    • 意欲のある前向きな人々を集めて、彼らが働きやすい環境を整えることが求められる
  • 行動規範
    • 顧客の価値創造のために、自らが考え、自らの行動と判断に責任を持つ
    • 自分の作業だけでなく、顧客の価値創造のために何ができるかを考える
    • 積極的にデモを行い、顧客からのフィードバックを受ける
    • お互いが協調し、集中して作業できる環境を作る

原則06 コミュニケーションは直接対話で

  • 基本的な考え方
    • 伝えたい情報や開発者間で伝え合う情報の中には、仕様とは異なり、目的、希望、夢、心配ごとなど、正確に表現できないものもある
      • そのような情報は、言葉では伝わりにくかったり、伝える際に齟齬や誤解を起こしやすかったりする
  • 行動規範
    • 決まった仕様を伝えるだけのような一方通行はやめる。
    • 他の役割の人と話すことで自分の範囲を広げ、これまで気づいていなかったことにも気付けるようにする
    • 何か気になることがあったら、直接会話をする
    • しぐさや表情から、言葉にならない本心(心配ごと、違和感)を感じ取りる

原則07 進捗も品質も現物で

  • 基本的な考え方
    • 進捗状況を正確に把握するためには、動くソフトウェアを確認することが、最も信用できるやり方
      • 求められている価値をどれだけ実現できているか
    • この場合の動くソフトウェアは、計画通りに進んでいるかということではなく、市場にリリースできる程度の品質を満たしている必要がある
  • 行動規範
    • 動くソフトウェアを早いタイミングで見せられるように、小さな単位でモノを作る計画を立てる
    • 顧客の期待に合っているか判断する
    • 受入基準をビジネス側の人と開発者で作る
    • 動くソフトウェアに求められる必要な品質が担保されているべき
    • 開発中の仕掛りを極力少なくする
    • 実物に対する受入基準の合格/不合格で測る
    • 実物を触って進捗を測る

原則08 一定のペースでプロジェクトにリズムを

  • 基本的な考え方
    • ゴールを目指して過負荷なパフォーマンスを求められることがある。

      • 無理をした状態では創意工夫をしたり、改善をしたりという意欲が起きない。
      • また、無理をして一時的に生産性を上げたとしても、その無理が祟ってその後の生産性が落ち、結果的にトータルパフォーマンスは低下してしまいます。
    • 開発者の生産性を最大限に引き出し、価値あるものを提供し続けるためには、

      • 開発者だけでなく、ビジネス側の人も心身ともにベストな状態を保ち、
      • 無理のない一定のペースを維持することが重要。
  • 行動規範
    • 定期的に繰り返す「リズム」を大切にする。
    • 一定のペースを保つために、生産性を見える化し、適切に計画を見直しする
      • 持続可能なペースは、開発者ごとに異なる
    • コミュニケーションを密にし、お互いの考えを共有して助け合う
      • 無理が生じている箇所(ボトルネック)を見つけ、助け合って改善する

原則09 よい技術、よい設計、よい品質の追求

  • 基本的な考え方

    • 新しいビジネスを支えるソフトウェアは、状況に応じて、いつでも素早く変更できることが求められる
      • 優れた技術力に支えられた、優れた設計になっている必要がある
      • よい品質には、高い保守性が欠かせない
    • 設計やソースコードの可読性などについて、技術的な問題が蓄積されると、ソフトウェアの保守性が低下し、素早く変更できない状態に陥る
      • 市場の変化への対応が遅くなり、ビジネスを成長させる際の大きな阻害要因となってしまう
    • よりよい技術を追い求め、効果的にその技術を活用することで、素早く、品質よく、変化に対応し続けることができ
    • 技術力を磨き、プロダクトへの適用技術と設計に対して、常に注意を払うことが重要
  • 行動規範

    • 常に最新の技術を学び、効果的な技術はプロダクトへ適用する
    • ソースコードの状態を目視やツールで常に診断し、常に変更して高い可読性を維持する
      • 可読性を高めると、多くの場合、コードの行数は減ります。
    • 自動化されたテストを作成して常に実行し、問題をすぐに発見する
    • 全員上記の行動に価値があることを認める。

原則10 ムダ=価値を生まない、を探してヤメる

  • 基本的な考え方

    • 顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、そのムダを減らすためにたゆまぬ努力をする。
    • ムダの中には、組織にとって現在必要なものも含まれるので、見逃しがち。
    • これまでの常識や慣習にとらわれず、新鮮な目で現状を直視する
    • 日々の作業の中からムダを見つけ、削減することは、身軽になり機敏性を高めるだけでなく、コスト削減と生産性向上にも貢献する
  • 行動規範

    • 顧客の要求を鵜呑みにせず、「その要求は本当に必要ですか?」と聞く
      • 顧客にとって本当に必要か分からない機能を、先に作るのは「つくりすぎのムダ」
    • ムダについて、真剣に話し合いましょう
      • 例えば、ある作業を100倍して、その価値も100倍になっているか考えてみる
    • 顧客に価値をもたらさない会議や報告をなくす
      • 進捗会議は短く、報告資料はシンプルに

原則11 よいモノはよいチームから

  • 基本的な考え方
    • 最良のアーキテクチャ・要求・設計は、最良のチーム(=自律型のチーム)から生み出される
      • 自律型のチームとは
        • メンバー一人ひとりが自らの行動、作業に責任を持つとともに、
        • お互いの連携により、チームとしての成果を最大限に発揮することができる
優秀なメンバーが集まったチームだとしても、お互いに連携や協調がなければ、
チームの能力は、個々のメンバーの能力の和でしかありません。あるいは、個々の
作業が重複していたり、相反する作業をしていたりすれば、チームとしての成果に
悪影響を与えます。
一方自律型のチームでは、メンバー一人ひとりが常に改善の意識を持ち、お互
いの能力を高めながら共通の目的や目標に対しての取り組みが継続されます。
そこには相乗効果が生まれ、チームとしてメンバー個々の能力以上の成果を発
揮することが可能になります。その結果、自律型のチームから、ベストな成果が生
み出されることになるのです。
  • 行動規範
    • チーム
      • プロジェクトの達成すべき目的や目標と、それを支える規律・ルールを共有する
      • 自分たちで規律・ルールを決める。
    • メンバー
      • 自ら率先して作業の改善や課題の解決に取り組む。
      • 自分の不得意な作業、領域についてもチャレンジして取り組む。
      • お互いの作業状況をオープンにし、共有する
      • 困っているメンバーがいたら、助け合う

原則12 自分たちのやり方を毎週、調整する

  • 基本的な考え方

    • “ふりかえり”
      • プロジェクトの進行中に定期的に、短い時間で行うこと
      • よいやり方はどんどんよくなり、もし、失敗したとしても(うまくいかなかったとしても)影響を最小限に留めることができる
      • プロジェクトにとって有用ではあるが言いにくいことを言えるようになる
  • 行動規範

    • だらだら続けることはやめる。
    • “ふりかえり” のルールはチーム全体で決める。
    • チームで問題に立ち向かう。
      • 個人の責任を追及してはいけない。
    • 必要に応じて周りに協力をあおいで解決する。
    • 挙がった課題をすべて解決しなくても気にしないようにする。
      • 失敗は許容する。すぐ改善すればよい。

おわりに

  • 変化とスピードが要求されるこれからのビジネスに対応するためには

    • 変化とスピードがプロセスにあらかじめ組み込まれているアジャイルソフトウェア開発にシフトしていく必要がある
  • アジャイルソフトウェア開発へのシフトの阻害要因の一つとして、

    • アジャイルソフトウェア開発宣言」および「アジャイル宣言の背後にある原則」が、日本においては十分に伝わっていないことがあげられる
    • 伝わっていたとしても正しく伝わっていないケースが少なからず見受けられます。
  • 価値を追い求めるために、

    • 常に考え続け、体現し続けていく姿勢こそが、アジャイルソフトウェア開発に一番大事なマインドセット
    • その姿勢を維持し続けるためには、自分たちに合った方法を常に試していく必要がある
    • その失敗の中からより最善の策を見出し、その時に一番よい方法を見つけ出していきましょう。
    • 失敗を、効率よく成功の糧
      • よいと思ったらまずやってみて、うまくいかなければ短いサイクルで「改善」を繰り返していけばよい、という考え方
    • アジャイルソフトウェア開発とは「改善」をたくさん試せる手法

スクラムガイド 2020:メモ

スクラムガイド 2020/11 を改めて読んでみる。

スクラムの定義

  • スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワーク
1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する
4. 繰り返す
  • スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている
  • スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするもの
  • スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になる

スクラムの理論

  • スクラムは「経験主義」と「リーン思考」に基づいている。

    • 経験主義では、知識は経験から生まれ、意思決定は観察に基づく
    • リーン思考では、ムダを省き、本質に集中する。
  • スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ(反復的)でインクリメンタル(漸進的)なアプローチを採用している

  • スクラムを構成するのは、

    • 作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。
    • また、必要に応じてそうしたスキルを共有または習得できる人たちである。
  • スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。(スプリント)

    • これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。

透明性

  • スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている
    • 透明性の低い作成物は、価値を低下させ、リスクを高める意思決定につながる可能性がある。
    • 透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。

検査

  • スクラムでは、検査を支援するために、5 つのイベントでリズムを提供している。
    • 検査によって適応が可能になる。適応のない検査は意味がないとされる。

適応

  • 関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる。
  • スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。

スクラムの価値基準

  • スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
    • 確約(Commitment)
      • ゴールを達成し、お互いにサポートすることを確約する。
    • 集中(Focus)
      • ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。
    • 公開(Openness)
      • 作業や課題を公開する。
    • 尊敬(Respect)
      • お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される。
    • 勇気(Courage
      • 正しいことをする勇気や困難な問題に取り組む勇気を持つ。

スクラムチーム

  • 機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。
  • 自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する
  • 敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさ
  • ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。

開発者

  • 開発者は常に次の結果に責任を持つ
    • スプリントの計画(スプリントバックログ)を作成する。
    • 完成の定義を忠実に守ることにより品質を作り込む。
    • スプリントゴールに向けて毎日計画を適応させる。
    • 専門家としてお互いに責任を持つ。

プロダクトオーナー

  • プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。
    • プロダクトゴールを策定し、明示的に伝える。
    • プロダクトバックログアイテムを作成し、明確に伝える。
    • プロダクトバックログアイテムを並び替える。
    • プロダクトバックログに透明性があり、見える化され、理解されるようにする。

スクラムマスター

スクラムイベント

スプリント

  • スプリントゴールの達成を危険にさらすような変更はしない。
  • 品質を低下させない。
  • プロダクトバックログを必要に応じてリファインメントする。
  • 学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。

スプリントプランニング

  • スプリントの起点
    • トピック 1:このスプリントはなぜ価値があるのか?
      • プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案
      • そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する
    • トピック 2:このスプリントで何ができるのか?
      • 開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるよ
    • トピック 3:選択した作業をどのように成し遂げるのか?
      • 完成の定義を満たすインクリメントを作成するために必要な作業を計画

デイリースクラム

  • 計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させる
  • デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる
    • これは集中を生み出し、自己管理を促進する
  • コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
  • スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日を通じて頻繁に話し合う

スプリントレビュー

  • スプリントの成果を検査し、今後の適応を決定すること
  • スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビュー

スプリントレトロスペクティブ

  • 品質と効果を高める方法を計画すること
  • 個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する

スクラムの作成物

  • スクラムの作成物は、作業や価値を表している。
    • プロダクトバックログのためのプロダクトゴール
    • スプリントバックログのためのスプリントゴール
    • インクリメントのための完成の定義

プロダクトバックログ

  • プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧

確約(コミットメント):プロダクトゴール

  • プロダクトの将来の状態を表している
    • スクラムチームの計画のターゲット
    • プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か(what)」を定義するもの

確約(コミットメント):スプリントゴール

  • スプリントバックログ
    • スプリントゴール(なぜ)、
    • スプリント向けに選択されたいくつかのプロダクトバックログアイテム(何を)
    • およびインクリメントを届けるための実行可能な計画(どのように)で構成
  • スプリントの唯一の目的

確約(コミットメント):完成の定義

  • インクリメントをまとめたものをスプリントレビューで提示する
  • 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない
  • プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である

  • 作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性が生み出される。

  • プロダクトバックログアイテムが完成の定義を満たしていない場合
    • リリースすることはできない。
    • ましてやスプリントレビューで提示することもできない。
      • そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。