アート・オブ・アジャイル デベロップメント 社内読書会＃１
アート・オブ・アジャイル デベロップメント社内勉強会を今日から始めました。
日々、要約をまとめていこうと思います。
わかりやすくするために自分の言葉に直しているため、間違っている点があれば指摘していただけると嬉しいです。
１章
なぜアジャイルなのか？
- アジャイル開発を行うと生産性が上がったという統計がある。
- ただし生産性を上げるためにアジャイル開発を導入するのではない。(※むしろ下がることもある)
- 導入するかどうかの決め手は「アジャイル開発がプロジェクトに成功をもたらすかどうか」
成功を理解する
古典的定義
成功した：納期通りに予算内で仕様通りに全ての機能を実装した
苦戦した：予算や納期をオーバーしたりしたがとにかく完成した
失敗した：開発の途中でプロジェクトが中止になった
しかし、以下のケースも事実としてある。
- 一銭も儲からなくてもプロジェクトが成功することがある。
- たくさんの収益をもたらしてもプロジェクトが苦戦することがある。
納期より大事なもの
成功には種類がある。
- 組織的な成功（組織に価値をもたらすこと）
- 技術的な成功（保守性の高いコードを書くこと、など）
- 個人的な成功（やりがい・コーディングが楽しい、など）
プロジェクトの成功を考える上で上の３つの成功すべてが重要。
所感
現在の僕はアルゴリズムを考えるのが楽しい、プログラムが動くのが楽しいといった「個人的な成功」しかほとんど意識できていません。「技術的な成功」については最近考え始めました。デザインパターンやリファクタリングについて勉強中でこれが実践できればといったところです。
「組織的な成功」を開発者が意識しなければいけないのかについては疑問を持ちました。
「組織的に成功はしないけど頑張って！！」と言ってSEが仕事をプログラマに振ることは考えられないからです。
多くの開発は長い時間をかけると思うので、時代が変わって開発中のシステムが役に立たないことがわかれば組織的に失敗する前にプロジェクトを中止にすることが出来ます。組織的に成功することを重視するなら、それを判断する役割の人がプログラマとは別に開発チームの中に必要だと思いますがどうなのでしょうか。。。
次回も楽しみです。
