現在とりかかっているプロジェクトのリリース作業のためしばらく息もつけない日々でした。それにしてもリリースは何度やってもドキドキ・ワクワクします。素晴らしいメンバーとこの瞬間を共に出来たことに感謝します。
筆者はだいたい家で家族が寝静まってから仕事をすることもしばしばなのですが、今レポートを書き終わり、久々にキッチンで奄美黒糖焼酎の「島のナポレオン」をお湯割りで頂いています。春ですね、沖縄、いきたいですね。
ブログを続けます。
スクラムを採用する理由
スクラムが積極的な管理層を巻き込んでプロジェクトを制御していくことを知らない為に生じる管理者の意見の例を見てみましょう。
「開発チームが機能を減らしたり目標に達するためにコストを増大させたりすることがある」
「どのようにすれば予測すべきことを知り、プロジェクトの悪化を阻止し、制御できるようになるのか」
「どのようにすれば開発チームは怠けたり、組織や顧客の期待を裏切ったりしないのか」
「スクラムチームにプロダクトを納品する責任を持たせたい そのチームが納品できないなら他のチームと契約したい」
「スクラムチームは私に管理権限を与えてくれない」
※管理者:ユーザーや顧客、または開発プロジェクトに資金を出す投資家
定義ソフトウェア開発プロセスの崩壊
~プロジェクトの最初に確実に要求仕様を決定できるという神話は既に崩壊している
・システムのビジョンとすべての要求を定義することから始まる
・プロジェクトの最後の2ヶ月前まで開発されたプロダクトが期待に沿うものなのかどうかがわからない
これまでの手法は、顧客と開発チームのやりとりがほとんどない「壁越しの」システム開発技法といわれています。
プロジェクトマネージャーは計画を持つことによってプロジェクトが制御下にあることを感じ安心します。メンバーは要求された作業を理解してプロジェクトが成功して完了すると感じているが、その計画の基礎となるタスク詳細は不完全です。定義が不完全なので依存関係も不完全、これらの見積もりは作業の割り当てや見積もりを不完全にします。
ほとんどのプロジェクトが高い確率で予測可能だと仮定する場合、PERT図を使い複雑なプロジェクトを制御しようとすると、最善を尽くしていた開発者は、期待されていることに従って行動することに常に失敗し、結局最善を尽くすことをやめてしまいます。
この間違った公式化は、数えきれないほどのプロジェクトのキャンセル「それを元に戻す」ために浪費された多くの努力、コストを産み、適切に管理されたソフトウェア開発の全体的な失敗を導きました。
スクラムはなぜ機能するか
~経験的プロセス制御モデルの採用へ
スクラムは、同一の活動が同一の出力を生成することはほとんどないという見解からはじまります。
・スクラムは、すべてのプロセスは予期できないと考えます。
〜とても複雑で事前に定義することができず、再現できないときは経験的プロセス制御モデルを採用。管理者、顧客、開発チーム間がより密接に協力し、優先順位の高い、小さい要求群を最初に完成します(通常これで 3ヶ月の分量はあります)。
・チームはスプリントの中で新規のビジネス機能を開発します。
・スクラムはすべてをオープンにします。
コミットメントを果たすための生産方法の改善はチームが自主的におこないます。スクラムを使用すると、少なくとも2週間ごとに直接かつ即座に遅延を発見することができます。
スクラムは何が起こっているかを定期的に理解するために活動を定期的に検査し、求められる予測可能な結果を生む活動を経験的に順応させます。
チームは常に臨機応変に対応し、最初にコミットしたもの以上のものをスプリントレビューで実演して管理者を驚かせます。
顧客とのオープンで正直な関係を構築します。
これがスクラムで最も重要な点です。
スクラム・ソフトウェア・デベロップメントとソウル・ミュージック
筆者は、ソフトウェア・デベロップメントはバンド活動に近いと感じています。
ロボットではできない、人間がつくる作品はいつも感動を与えてくれます。
ソフトウェア・デベロップメントもバンドも、間違えても面白い、改善を繰り返し、メンバーのみなさんと一緒に素敵なイノベーションを起こしたいと強く思います。
本日は、筆者の大好きなラモン・ドジャーを紹介します。
70年台ソウル・ミュージック・シーンにおいて多大な功績を残した作曲家にもかかわらず、本人たちのオリジナルアルバムはリリースされず、オリジナルはシングル5枚のみしかリリースされませんでした。中でも一番好きな曲をかけます。
それではまた、皆様良き週末をお迎えください。
Holland Dozier Holland - Why Can't We Be Lovers?