アジャイル開発の勉強メモ
Agile勉強メモ。
アジャイルソフトウェア開発の１２の原則
http://agilemanifesto.org/principles.html
1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによってお客様の競争力を引き上げます。
3.動くソフトウェアを２～３週間から２～３ヶ月というできるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かれなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝える最も効率的で効果的な方法はF2Fで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です
11.最良のアーキテクチャ・要求・設計は自己組織的なチームから生みだれます。
12.チームがもっと効率を高めることできるを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します
この２つの問いへの答えが「YES」なら君はアジャイルだ
Question.1 毎週、価値ある成果を届けられているか？
Question.2 たゆまぬ改善のための努力を惜しまず続けているか？
アジャイル開発手法の起源
１９９０年代のプロセス重視の管理手法のアンチテーゼとして考えだされたソフトウェア開発手法。理論的背景としては、人間の相互作用を重視する、暗黙知を重視する、創発の作用を利用する、などといった人の共同の営みに関心を集める考え方に立脚している。
変化を受け入れるアジャイル開発手法
アジャイル開発手法においては顧客の本当に欲しいものは、事前の計画では分からないという状況を想定している。
変化にも様々な原因があるが、何でも受け入れるのではなく「顧客の本当のニーズに近づくための変化」以外の不確実性（仕様の取り違え、知識不足・経験不足に起因する誤差、開発者の作業効率見積もりの誤差など）は排除することを目指す。
仕様の変更はよりソフトウェアの価値を高めるものとして積極的に実施すべきものと考える。
探索型のプロジェクトに適用可能
１：仕様の変更を吸収して、品質を確保する仕組み（品質面での優位性）
＞テストで品質を確保する。人手による検査を充実させる以外に、自動化テストを初期段階から導入する（テストファーストなど）
＞コードの共同所有のプラクティスにより誰か特定個人がコードを抱え込むがなくなり、チームとしてコードの品質を管理できるようになる
２：創発の仕組みによる創造的ソフトウェア開発の実現（機能面での優位性）
３：必要な機能だけの早期リリースを可能にする段階的リリースの仕組み（期間面での優位性）
事前にアーキテクチャ設計をきちんと行うべき。
従来開発との違いは、必要最低限のコンパクトなアーキテクチャを設計し、ソフトウェアの設計と共にアーキテクチャを成長させる、進化するアーキテクチャの考え方を取り入れる点。
イテレーション～タイムボックス～
時間を区切って終了時間を厳守する方法がある。つまり、終了時間に必ず成果物が出せるようにする。成果物の完成度自体は中途半端であったとしても時間内で出てきた成果物を「是」として次の工程に進む方法。このような方法をタイムボックスと呼ぶ。
最初の検討（スプリント）で納得のいく成果物を出そうとしないことがポイントです
その他メモ
- 開発チームの自律性はアジャイル開発の根幹です
- 自己組織的なチームを創る魔法は「成果責任」と「権限委譲」
- ４つの質問をチームで共有してはどうだろうか？
（１） 自分は何が得意なのか？
（２） 自分はどうやって貢献するつもりか？
（３） 自分が大切に思う価値は何か？
（４） チームメンバは自分にどんな成果を期待していると思うか？
