[#TiDD]「アジャイルの夢を現実に!」スライド公開 - XP祭り関西2013 - #xpjugkansai
ソフトウェア開発のプロセスはリーダーやマネージャーのものではありません。そのプロセスによって顧客の求めるプロダクトが開発できるだけでなく、そのプロセスを採用した理由を説明できないといけません。もちろん高い生産性が発揮できる様に、メンバーが納得して前向きに取り組めるプロセスでないといけません。
これは、アジャイル開発の導入でも同じです。ブームだから、良いと言われているから、上司が言ったから、というのでは説明にならないですし、プロセスの変更は少なからず負担を伴うので、メンバーも納得しません。
アジャイル開発では優先順位に基づいてイテレーティブに開発されます。ソフトウェアプロセスも同じ様に、具体的な問題の改善策として、繰り返しプラクティスを導入・見直しをされなくてはいけないのです。プロセス改善もまたイテレーティブでなくてはより良いプロセスを実現できないのです。
このようにアジャイル開発を銀の弾丸の様に考えて、それさえ実施すればうまくいくとリーダーが勝手に始めたり、社内への教育も不十分なままにトップダウンに強制する事が大きな間違いである事がわかるでしょう。
21世紀の初めに私たちが見たアジャイルの夢、それを現実のものにしましょう。現実の問題を改善する方法としてプラクティスを導入すれば、チーム内でゴールを共有できますので現状のプロセスを大きく改善する事ができます。それはより良いアジャイル開発の姿であり、アジャイルになりきれないアダプタブルウォーターフォール開発かもしれません。
書籍「チケット駆動開発」では、アジャイルプラクティスの理解を前提に、現状のプロセスをどのように考えるべきであるを書きました。今回の XP祭り関西2013 では、 アジャイル開発に夢を見た人、アジャイル開発をより良くしたい人に向けて 、現状を見極めた上で導入したい具体的なお勧めのプラクティス・代替プラクティスについて説明しました。
1990年代のCMMブームによって、各企業でプロセス改善が行われ、大きな成果を残しました。しかし、その一方で重装備なプロセス標準の強制により、プロジェクトの本当のゴールを考えずに標準に沿う事を目的として開発するようになり、プロセス改善運動は形骸化しました。この過ちを繰り返してはいけません。
より良いソフトウェア開発の未来を築くべく、今回の講演をしました。スライドを公開いたしますので、ぜひご覧ください。
« できる人を観察して勝負する | トップページ | CMMブームふりかえり »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
コメント