アジャイル開発ってよく聞くけどなんやねん、ということで本書を手に取ってみました。
アジャイルが出てきた背景として、、過去にソフトウェア工学が発展する中で包括的なドキュメントや計画が重視され、人がおざなりなる傾向があったことを理解できました。
過去に自分が経験したことですが、時間をかけて業務の補助ツールを作成したのですが、「これじゃない」感があり満足した成果が得られないことがありました。こういう「価値がない」状態を二度と発生しないために何ができるのか。
アジャイルの目的
アジャイルの目的は「価値」の最大化です。
価値を定義しなさい、価値を。
ソフトウェアの開発を委託する顧客は、「このソフトウェア/システムがあれば業務効率が上がって収益が上がるはずだ」など、そのソフトウェア/システムに対して費用を払って得られる利益を期待しています。その期待が顧客にとってのソフトウェアの価値になります。
ソフトウェア/システムによって得られる効果・成果のことですね。
「アジャイルソフトウェア開発」とは
ある特定の開発手法を指すものではなく、ソフトウェアの価値を最大限に高めるために、エンジニア、マネージャ、顧客も含めて取り組むべき「考え方」や「姿勢」です。
もちろん、いろいろな手法や手順が本書で紹介されているのですが、それはアジャイルソフトウェア開発を実現する手段であって、アジャイルソフトウェア開発というのはあくまで「考え方」や「姿勢」ということみたいです。
その他、気になった部分だけ列挙します。
- こたつモデル
- プロジェクト内に、時間の長さが一定のタイムボックスというもので細分化する
- タイムボックスの長さは、プロジェクトの長さを10-12ぐらいで分けるのが最適らしい
- タイムボックスの長さが固定なのは、作業効率(ベロシティ)を把握するため
- タイムボックスごとに「ふりかえり」を行う
- プロジェクトを、ストーリーとして捉える
- 最後のタイムボックス終了までにストーリーを完結させる。
- YAGNI ※特段アジャイルに限ったことではないと思いますが
- プロジェクトだって、ソフトウェアと同じく、INPUT -> 処理 -> OUTPUT という流れになっている
- ソフトウェアカンバン
- やるべき項目を「タスク」として細分化するが、その細分化の大きさは「半日から2日」
- タスクを「Done」にする条件(Doneの定義)をチーム内で決める
- Redmineによるチケット駆動開発(TiDD)
- テスト駆動開発(TDD)では「予定通り失敗する感覚」が大事
実践が肝ですが、それが課題です。
0 件のコメント:
コメントを投稿