アート・オブ・アジャイル デベロップメント 社内読書会＃２

２章　アジャイルになる方法

４つの価値

• コミュニケーション (プロセスやツールより人と人との交流を重視)
• シンプルさ (包括的なドキュメントよりも動作するソフトフェアを重視)
• フィードバック (契約上の交渉よりも顧客との協調を重視)
• 勇気 (計画に従うことよりも変化に適応することを重視)

１２の原則（プラクティス）

?顧客の満足度を最優先
?いつでも要件の変更を受け入れる
?動くソフトウェアの納品を頻繁に行う
?顧客と開発者が日々ともに働く
?リーダーをサポートし、信頼する
?直接話し合って情報交換する
?実働するソフトウェアが進捗状況の尺度
?持続できるペースを保つ
?高度な技術と優れた設計
?やらなくていいことはしない
?自己管理能力のあるチーム
?定期的にプロジェクトを見直し調整する

所感

らしいです、としか現状では言えないですが・・・

ひとつわかることはリリースを数週間単位で頻繁に行うことによって機能追加や仕様変更に迅速に対応できるのは実感としてあります。
現在自分が参加しているプロジェクトはおよそ２週間でイテレーションを区切って開発を行っています。
画面や機能単位で随時追加していくので仕様の変更があっても影響範囲が小さいことが多いです。
ペアプロなどを行うことによって常に誰かにレビューしてもらえる環境でコミュニケーションも取りやすく、まだよくわかってないですが"アジャイル"な環境・チームで開発を行えていると思います。12のプラクティス全てを遵守しているわけではないですが・・・

他部署の方に話を聞いたところ、社内でアジャイルな開発を行っているチームはごく一部らしいです。
「素敵な開発手法なんだよね？でも浸透しないのは何か壁があるから？」ということを気にしながら今後も読み進めていきます。