Pages

2014年3月29日土曜日

スクラムを採用する3つの理由 / Holland Dozier Holland

こんにちは、@wd0214です。

現在とりかかっているプロジェクトのリリース作業のためしばらく息もつけない日々でした。それにしてもリリースは何度やってもドキドキ・ワクワクします。素晴らしいメンバーとこの瞬間を共に出来たことに感謝します。

筆者はだいたい家で家族が寝静まってから仕事をすることもしばしばなのですが、今レポートを書き終わり、久々にキッチンで奄美黒糖焼酎の「島のナポレオン」をお湯割りで頂いています。春ですね、沖縄、いきたいですね。

ブログを続けます。

スクラムを採用する理由


スクラムが積極的な管理層を巻き込んでプロジェクトを制御していくことを知らない為に生じる管理者の意見の例を見てみましょう。

「開発チームが機能を減らしたり目標に達するためにコストを増大させたりすることがある」

「どのようにすれば予測すべきことを知り、プロジェクトの悪化を阻止し、制御できるようになるのか」

「どのようにすれば開発チームは怠けたり、組織や顧客の期待を裏切ったりしないのか」

「スクラムチームにプロダクトを納品する責任を持たせたい そのチームが納品できないなら他のチームと契約したい」

「スクラムチームは私に管理権限を与えてくれない」

 ※管理者:ユーザーや顧客、または開発プロジェクトに資金を出す投資家


定義ソフトウェア開発プロセスの崩壊

~プロジェクトの最初に確実に要求仕様を決定できるという神話は既に崩壊している


従来の技法を見てみましょう。

・システムのビジョンとすべての要求を定義することから始まる

・プロジェクトの最後の2ヶ月前まで開発されたプロダクトが期待に沿うものなのかどうかがわからない

これまでの手法は、顧客と開発チームのやりとりがほとんどない「壁越しの」システム開発技法といわれています。

プロジェクトマネージャーは計画を持つことによってプロジェクトが制御下にあることを感じ安心します。メンバーは要求された作業を理解してプロジェクトが成功して完了すると感じているが、その計画の基礎となるタスク詳細は不完全です。定義が不完全なので依存関係も不完全、これらの見積もりは作業の割り当てや見積もりを不完全にします。

ほとんどのプロジェクトが高い確率で予測可能だと仮定する場合、PERT図を使い複雑なプロジェクトを制御しようとすると、最善を尽くしていた開発者は、期待されていることに従って行動することに常に失敗し、結局最善を尽くすことをやめてしまいます。

この間違った公式化は、数えきれないほどのプロジェクトのキャンセル「それを元に戻す」ために浪費された多くの努力、コストを産み、適切に管理されたソフトウェア開発の全体的な失敗を導きました。

スクラムはなぜ機能するか
~経験的プロセス制御モデルの採用へ


スクラムは、同一の活動が同一の出力を生成することはほとんどないという見解からはじまります。

・スクラムは、すべてのプロセスは予期できないと考えます。
〜とても複雑で事前に定義することができず、再現できないときは経験的プロセス制御モデルを採用。管理者、顧客、開発チーム間がより密接に協力し、優先順位の高い、小さい要求群を最初に完成します(通常これで 3ヶ月の分量はあります)。

・チームはスプリントの中で新規のビジネス機能を開発します。

・スクラムはすべてをオープンにします。

コミットメントを果たすための生産方法の改善はチームが自主的におこないます。スクラムを使用すると、少なくとも2週間ごとに直接かつ即座に遅延を発見することができます。

スクラムは何が起こっているかを定期的に理解するために活動を定期的に検査し、求められる予測可能な結果を生む活動を経験的に順応させます。

チームは常に臨機応変に対応し、最初にコミットしたもの以上のものをスプリントレビューで実演して管理者を驚かせます。

顧客とのオープンで正直な関係を構築します。
これがスクラムで最も重要な点です。


スクラム・ソフトウェア・デベロップメントとソウル・ミュージック



筆者は、ソフトウェア・デベロップメントはバンド活動に近いと感じています。
ロボットではできない、人間がつくる作品はいつも感動を与えてくれます。
ソフトウェア・デベロップメントもバンドも、間違えても面白い、改善を繰り返し、メンバーのみなさんと一緒に素敵なイノベーションを起こしたいと強く思います。

本日は、筆者の大好きなラモン・ドジャーを紹介します。
70年台ソウル・ミュージック・シーンにおいて多大な功績を残した作曲家にもかかわらず、本人たちのオリジナルアルバムはリリースされず、オリジナルはシングル5枚のみしかリリースされませんでした。中でも一番好きな曲をかけます。

それではまた、皆様良き週末をお迎えください。




Holland Dozier Holland - Why Can't We Be Lovers?


2014年3月9日日曜日

デイリースクラムミーティング / 君が僕を知ってる

こんにちは、@wd0214です。

今回はアジャイル開発で最もポピュラーなメソッドであるスクラムを紹介することを試みます。スクラムの概論は数あるサイトにて見つけることができると思います、このサイトでは、何回かに分けて実技から入っていきましょう。

まずはどのチームでもすぐに導入できるデイリースクラムミーティングを紹介します。


忌野清志郎/君が僕を知ってる






「ミーティングなんて言ってるようじゃダメなんだよ。普通に集まってさ、普通にワイワイ言ってることが大事だと思うんだよな、俺は。そういうことじゃない? 夫婦とかもさ。友達とかも。」


デイリースクラムミーティングとは



15分の日次ミーティング(朝会)、全員が3つの質問に答えます。

1.前回のスクラム以降何を行ったか


2.次回のスクラムまでの間何をするか


3.作業をする上で何が障害となっているか


報告はお互いの顔を見ながら行います。

全体で15分程度、チーム全員が参加し、一人ずつ報告し全員が聞き、チームを妨害している要因を洗い出し、すべてを見える化し、スクラム開発が機能するようにします。


デイリースクラム後のフォローアップミーティング



3つの質問だけでは状況がつかめず議論が必要な場合、 フォローアップミーティングを開催します。

「スクラムの後でこの問題について話をしたい、関心がある方は残ってほしい」

必ずデイリースクラムの後に行います。


アジャイルのすべてのメソッドについてとても大事なことは、例えばこのデイリースクラムミーティングを開催するかどうかについても、「チームが自分達自身で決める」ということです。


スクラムマスターの役割



・スクラムマスターはミーティングを適切に進めます。

・スクラムマスターはミーティングの場所と時間を設定します。

・チームメンバーは時間通りに行動します。

・スクラムマスターはメ ンバーが出席しているかどうかに関わらず、予定の時刻にミーティングを開始します。

・遅刻したメンバーはスクラムマスターにすぐに1ドルを支払います。

・優秀なスクラムマスターはミーティングが始まる前に椅子を机の周りに並べておきます。

スクラムマスターは、チームが自分達自身で問題を解決できることを支援します。


デイリースクラムでの障害の識別、判断



スクラムマスターはその障害を記録し、取り除く責任があります。

デイリースクラムミーティングでのチームの報告例:

「サーバー、ネットワークが遅い、落ちる」
「管理者に他の作業を頼まれてしまった」
「どのようにして先に進んだらよいかわからない」
「設計上の判断が下せない」

効率よく作業を行う妨げが何かをチームメンバーが見極めたらスクラムマスターは障害をホワイトボードに書き留めます。

スクラムマスターが障害を理解できない場合、 ミーティング後に発言した人と会って学習します。

未解決の障害がホワイトボードに溢れてきたら、それは 上位組織がチームをサポートしていないことを示します。この場合、スクラムマスターはスプリントをキャンセルする強力な切り札をきることができますが、その前に管理者のサポートの欠如がもたらす結果について慎重にかつ熱心に議論する必要が有ります。

コミットメントを達成する為の判断をチームが下せない場合、スクラムマスターはなるべくその場で判断を下します。

その場で判断を下せない場合、スクラムマスターはミーティング後1時間以内に判断を下し全員に周知します。


デイリースクラムミーティングの規則について12のこと



1.チームメンバーの数に関わらず、15分のタイムボックスで行われる。

2.毎日同じ時間かつ同じ場所で行う。日次スクラムは一日の始まりに行うのが最適である。こうすると、チームメンバーは職場に到着するとまず前日に行った作業とその日に行う作業を考えるようになる。

3.チームメンバーは全員出席する必要が有る。何らかの理由で参加できない場合は電話で報告するか、別のメンバーに自分の状況を報告させるような形で参加する必要が有る。

4.チームメンバーは時間通りに行動しなければならない。スクラムマスターはメンバーが出席しているかどうかに関わらず、予定の時刻にミーティングを開始する。遅刻したメン バーはスクラムマスターにすぐに1ドルを支払う。

5.各チームメンバーは3つの質問にだけ答える。 このプロジェクトに対して、前回の日次スクラム以降何をしたか、このプロジェクトに対して、今から次の日次スクラムまでに何を行う予定か、作業を出来るだけ効率的に行うことを妨げていることはあるか。

6.チームメンバーはこれらの質問以外の、懸案、設計、問題の議論、ゴシップなどの議論へ外れてはいけない。スクラムマスターは責任を持って、各人の報告をテキパキと進める。

7.日次スクラムの間は一度に一人だけが話すことが出来る。その一人とは、自分の状況を報告している人である。他の人はその報告を聞き、別の会話をしてはならない。

8.あるチームメンバーが他のチームメンバーに関心がある報告を行ったり、他のチームのサポートを必要としたりするときは、日次スクラムの後に集まって、関心のあるメンバー間ですぐに調整を行うことが出来る。

9.「ニワトリ」は会話や観察や拒否反応など、日次スクラムにおいて自分の存在を目立たせるようなことを行うことは出来ない。

10.ミーティングに参加している「ニワトリ」が多すぎる場合、スクラムマスターはミーティングを順序よく集中的に進行する為に、出席者を制限できる。

11.「ニワトリ」は、ミーティングの後で報告内容を確認したり、アドバイスや指示を行ったりする為にチームメンバーと話すことは出来ない。

12.上記の規則に従うことが出来ない「ブタ」や「ニワトリ」は、ミーティングから退席させられる(ニワトリ)か、チームから外される(ブタ)


スクラムが機能するのは、頻繁なインスペクションと適応に対してすべてのことが目に見えるようになる場合だけ。スプリントの間はチームの邪魔をしない。スクラムマスターは意味のある精度で、すべてのことを可視化します。

物事を解決する第一歩は、明らかにすることです。


次回に続きます。