「アジャイルソフトウェア開発の奥義」の読書メモです。

時々、個人の見解入りです。

アジャイルアライアンス宣言

プロセスやツールよりも、人と人同士の交流を重視する。

開発環境を整えるよりも、開発チームを形成することの方がずっと重要である

同意。開発チームがあれば、開発環境も整えられていきそうです。

包括的なドキュメントよりも、動作するソフトウェアを重視する。

システム全体を見渡すことができるような資料は必要だと思います。

仕様書となると、システムの変更に合わせて保守していく必要があるので難しそうです。

システム改修する -> 関連する資料修正する の資料に関しては、なくても良いものかもしれません。

資料 -> システム改修 に属する資料であれば、必要なものと言えそうです。

契約上の交渉よりも、顧客との協調を重視する。

成功の鍵は、顧客との密接な協調関係を築いたことと、コストや納期をがちがちに決めるような契約書ではなく、相互の協調関係について取り決めた契約書を用意したことにある。

システムの開発であれば、契約前、つまりシステムの開発前に全てを決め切ることは出来ないと思うので、この方針にした方が円滑に進みそうだと思います。

計画に従うことよりも、変化に対応することを重視する。

変更があることは頭に入れておく必要があり、計画と変化を天秤にかけた時、変化の方を優先せよという意味だと捉えました。

変化を優先するとは、ある目的、ゴールに向かって、変化を受け入れることだと思います。

原則

アジャイルアライアンス宣言で掲げている4つの価値を実現するために、以下の12の原則が導き出されました。

最優先事項は顧客を満足させることであり、価値あるソフトウェアを早い段階から継続的に届けることでこれを実現する

物事の判断ポイントになるので、プロジェクトを進めていく上での土台になると思います。

要求変更を歓迎し、たとえ開発過程の後半であってもそれを受け入れる。アジャイルプロセスは、変化に対応をすることで顧客の競争上の優位性を確保する。

これはよく分からないです。

実働可能なソフトウェアの納品を頻繁に行う。できるだけ短い時間で納品することを旨とし、数週間から数ヶ月間隔で納品する。

同意。

顧客と開発者はプロジェクト全般を通じて日々ともに働かなければならない。

現実的に可能なのかわかりませんが、理想だとは思います。

自社サービスだったら、現実的だと思います。

やる気のある開発者をプロジェクトの中心に据え、彼らが必要とする環境とサポートを与え、信頼して仕事の完遂を任せる。

同意。

開発チームで情報を伝達する最も効果的な方法は、直接話し合うことである。

基本的には同意。関わっている人数が多いときは、チャットなどで話しに参加していない人も見られるようにしておく必要があると思います。

実動するソフトウェアこそが進捗状況の尺度である。

同意。

持続できるペースで開発する。そうすれば、スポンサーも開発者もユーザーもずっと一定のペースを確保できる。

同意。しかし、予測していないことは、どこかのタイミングで起こりがちなので、前倒しで進めておきたいという思いもあります。

高度な技術と優れた設計への配慮は、アジャイル性を高める。

開発スピードを保つ鍵は「品質である」

本の中では、あとで書き直すという考えは持たない方が良いという意味合いでした。

シンプルさが肝心 ー やらなくていいことはしない。

このやらないことを決めるというのは難しいのですが、リソースの制約がある以上、意識したいところです。

最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。

プロジェクトにコミットするという意味だと捉えました。

（どんな仕事にも言えそうですが）

チームは定期的にプロジェクトを見直し、より効果的な方法を考え、対応方法の変更や調整を行う。

改善策を考え続けろという意味だと捉えました。