ビジネス課題への解決策(アイディア)と、新たな発想(+α)が見つかるIT情報メディア

Menu
  1. TOP
  2. クラウド
  3. アジャイルサムライはスプリント、ユーザストーリー、ベロシティを駆使する

アジャイルサムライはスプリント、ユーザストーリー、ベロシティを駆使する

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 開発の単位はスプリント単位で

 スクラム開発は1週間とか2週間の単位で開発を進めます。これをスプリントと呼んでいます。アジャイル開発では一般にはイテレーション(反復)と呼ぶこともあります。我々は2週間を1つのスプリントとしていますが、 アウトプットはこの単位で作られます。つまり、2週間単位で、計画、設計、プログラミング、テスト、レビューを行います。
 

 レビューでは、実際に動くデモをレビューする事が重要です。この事があるため、アジャイル開発では「機能」とは言わず、「フィーチャー」と呼んでいます。つまり、計画ではどのフィーチャーを実装するかを決定して、レビューではそのフィーチャーが実装できたかどうかを確認します。結果、本番へのデプロイメントをしない場合もあるかもしれませんが、基本、2週間単位で計画を立てているし、またクラウドサービスですので、デプロイメントは出来ます。

 

お客様と開発者の共通言語はユーザストーリーで

 さて、この2週間単位で作るプログラムの粒度ですが、これが結構悩みます。スクラム開発では、フィーチャーをユーザストーリーとして定義し、その単位で開発を行います。もちろん2週間での開発ですので、できる限り粒度は細いほうがいいのですが、あまり細かくするとレビュー(動くデモの確認)が出来なくなります。フィーチャーという言葉を使っているのは見えるデモとして定義した方が良いので、その粒度にユーザストーリーを作りましょうという事だと思います。

 

 もう1つの悩みの種は、プロジェクトの計画時に定義したユーザストーリー(マスターストーリー)が必ず実装されるか?という問題です。いや、実はこの問題が、アジャイル開発とウォーターフォール開発の確執を生んでいる最大の問題です。
 ウォーターフォール開発では、「最初にお客様と約束をしたことは絶対だ!」が基本です。例えばお客様が、途中で「この機能は必要なくなったので、代わりにこの機能を実装してほしい」と言ったとすると、要件変更のプロセスが走ります。時には、全体スケジュールの変更も行われるでしょう。
 しかし、アジャイル開発の場合は、「最初から要件を全て洗い出したとしても、時間とともに変化をするのだから、要求の変更には柔軟に対応すべきである」が基本です。開発者の中には、「そんな事をしたら、お客様は永久に要求をしてきて、プロジェクトは終わらないじゃ無いか」という反応があると思います。いわゆるデスマーチと呼ばれるものです。
つまり、アジャイル開発の場合はお客様との信頼関係が必要です。

 

1. 開発者は要求を柔軟に受け入れる
2. お客様は新しいストーリーを追加する時には、必ず既存のものを削る

 

この様にすれば、お客様は、何でもかんでも要求リストに加えることをしないでしょう。また、技術者にとっては、大きな要求リストはデスマーチ、つまり死のロードを意味する為、要求リストが大きくなってくると、何でもかんでも否定をし始めます。つまり、どうでもいいフィチャーをユーザストーリーとして持ち込まない代わりに、持ち込まれたユーザストーリーは真摯に対応することが重要なんです。

 

開発の生産性はベロシティポイント

 前回のブログ「スクラム開発でバッファを最小限に」では、私は「人日」で説明しましたが、スクラム開発では、「ベロシティポイント」を使います。アジャイルサムライと言う著書では、絶対的なメジャーメントよりも、相対的なメジャーメントがいいとされています。ベロシティポイントにすると、ユーザストーリーの難易度を示すことが出来ます。人日や人月に慣れている開発者にはわかりにくいでしょう。結局は、人日や人月に変換するのでは?というご指摘はごもっともですが、「このユーザストーリーは何人日で出来ますか?」「はい、2人日です。」「それでは、今週の金曜日にできるのですね。」「いいえ、次のスプリントの終了は2週間後の水曜日なので、再来週の水曜日までお待ちください」と話しがややこしくなります。人日はある意味絶対メージャーと解釈することもできるため、この様なことが起きます。開発者が言ってる「人日」を正しく翻訳すると、「1日7.5時間を全てプロジェクトに使えるとして、開発終了には1日かかります」ということですが、お客様の「人日」は「スタートして次の日には終わってる」ということになります。解釈が異なります。開発者の「2人日」は、「2フル・スタンダード・ワーキングデイ・ポイント(フル=時間を100%プロジェクトに使える/スタンダード=残業時間は予定には入れない/ワーキング デイ=もちろん土日祝は予定には入れない)」と解釈しましょう。

 

 「人日」で答える代わりに、「このユーザストーリーは2ポイントです。」「そうですか、このスプリントはあと何ポイントこなすことが出来ますか?」「はい、あと2ポイントこなせます。」そうすれば、「他に優先順位の高いストーリーがない限り、再来週の水曜日には終了できますね」「はい、問題ありません」となります。「こんなにうまくいくのかよ」と疑問を持たれている方は、是非スクラム開発を経験してみてください。

 

 
 さて、前々回のブログで、「スクラム開発でペースを作れ!」を紹介しました。そうそう、5キロを何分で走れるかですね。5キロを20分でしか走れない人に、監督が「15分で走れ!」と言ったらどうなるでしょうか?まさに、デスマーチが始まります。同じ様に、1スプリントを15ポイントしかこなせないチームに20ポイントのユーザストーリーを課すとどうなりますか?デスマーチが始まります。じゃ、1スプリントをどれだけで走れるか?が課題となります。幾つかのスプリントをこなしていくと、15ポイントしかこなせないと思ってたチームが、18ポイントこなせると気づくかもしれません。こんな時は、チームのペースが上がったと喜びましょう。スクラム開発チームの生産性が何かの効果でよくなったと考えられます。技術者が新しいテクノロジーに慣れてきたのかもしれません。または、お客様の業務を理解し始めて、ユーザストーリーを詳細の仕様に落とし込むことがうまくいき、手戻りがなくなってきたとも考えられます。
 但し、間違っても、残業をし無理してベロシティポイントを上げようとしないでください。もちろんバッファを使い切った時にやむなく残業をする場合はあるかと思いますが、無理してベロシティをあげようとすると、チームのペースが崩れます。ベロシティポイントをあげるのは仕組みを変えたり、知恵絞ったり、経験を積んだりしながらあげていってください。

 

チームワークを大切にしよう

 ウォータフォール型の開発では、WBSのそれぞれのタスクに担当者が書き込まれます。つまり、ある担当者はそのタスクが終わると、次のタスクを実行するわけですが、次のタスクのまでスケジュールに余裕がある場合はどうするでしょうか?自分のタスクは早めに終わって、次のタスクまで時間がある人は、別の仕事をするか、他のタスクの準備をするか、つまり開発者の自由に使うかもしれません。これが前回のブログ「スクラム開発でバッファを最小限に」で話しました「バッファ」の使い方になります。ウォータフォール開発では、自分で作ってあったバッファは自分で勝手に消化されてしまう可能性があります。 

 

 アジャイルな開発ではチームでストーリーをこなしていくため、1つのタスクが終わると、バックログから優先順位の高い新たなタスクを取り出して実装を始めます。この場合、バッファを活用してどんどんと開発を進めることができ、バッファはどんどん貯まっていくことになります。チームのためにバッファを貯めた人は評価してあげましょう。

 

 むむむ、この話を聞いて、察しのいい方はこう思ったのではないでしょうか?「優秀な技術者であるほど、損する仕組みが、スクラム開発なのですか?」どんどん、ストーリーをこなしていく技術者はどんどんバッファを貯めていくが、ストーリーが全く進まずに、停滞して、他の人に迷惑をかけ続ける技術者はバッファをどんどん食いつぶしていく。スクラム開発では、スプリント毎にアウトプットを出すために、チームワークが必要です。ベロシティポイントもチームでどれくらいのベロシティとなるのか?が重要となります。つまり、チームで少し経験が浅い開発者を教育して、ベロシティが上がれば、チームのベロシティは確実に上がります。
 このように考えれば、ベロシティは絶対的なメジャーメントよりも、相対的なメジャーメントとし、スプリント毎にポイントをトレースして、チームのベロシティがどのように変化しているのかを見ることも必要です。絶対に、チーム毎にベロシティを競わせることをしないでください。そのようにすると、残業時間が増えて、新たなデスマーチが始まるかもしれません。
メールマガジンの登録はこちらから
メルマガ登録 お問い合わせ