SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

グラス片手にアジャイル開発

グラス片手にアジャイル開発 第5回(前編)
- イテレーション単位のアクティビティ

  • X ポスト
  • このエントリーをはてなブックマークに追加

スプリントのアクティビティ

 では、1つ1つのアクティビティ(活動内容)についてもう少し詳しく見てみましょう。ここからはディーバでの経験を元にアレンジしている部分もあります。

図1 スプリントのアクティビティ
図1 スプリントのアクティビティ

プランニングミーティング

 プランニングミーティングは、「スプリント計画ミーティング」「イテレーションプランニング」などと呼ばれます。通常、スプリントの初日に設定し、2、3時間程度かけて行います。プランニングミーティングは下記のように進めます。

  • ミーティング前
  •  1.タスクを決定する

  • ミーティング時
  •  2.前スプリントのタスク完了を確認する

     3.メンバーの予定作業時間を確認する

     4.スプリントのゴールを共有する

     5.タスクを説明し工数を見積もる

  • ミーティング後
  •  6.タスクを割り当てる

タスクの完了確認

 最初はタスクの終了確認から入ります。前日にレトロスペクションミーティング(後述)を行っていますが、その位置づけは正確には終了「直前」ミーティングです。そこでフィードバックがあったり、まだ追い込み中であったりで、タスク管理上はオープンのままになっているものがあります。そのため、プランニングミーティングでタスク(チケット)の完了確認を行います。これは数分から十数分で行います。

予定作業時間の確認

 次に、各メンバーの予定作業時間を確認します。例えば、有給休暇や外部セミナーなどをあらかじめ作業時間から引く形になります。メンバー間で誰をいつ頼ることができないか共有するための機会でもあります。祝日なども加味すると(暦日で「2週間」を固定する前提の)スプリントでは、実際の作業時間がかなり少なくなる場合があります。ミーティング後のタスク割当のための基礎情報になります。これも数分の作業です。

ゴールの共有

 次に、スプリントのゴールを共有します。ここで目的とするところは、各メンバーがプロジェクトの全体像と、現在自分たちがどこにいるのか、そして、今何を重視しなければいけないのかをしっかりと共有することにあります。各メンバーが主体的に動くことを目指すアジャイル開発では、目的/背景/前提などの共有は非常に大きな役割を持ちます。例えば、「マイルストーン12は、リリース1.1の最後のマイルストーンであり主に品質に注力する。このスプリント34は、マイルストーン12の最初のスプリントであるため、主に操作品質の向上を意図して、画面Xと画面Yとその周辺を改善する」などという情報を共有します。ここも数分から十数分で終わります。

タスクの説明と工数見積もり

 次に、タスクの工数見積もりです。ここはスプリントの中でもっとも重要でかつもっとも難しい作業であると言えます。ここでは「プランニングポーカー」という名の全員参加型の見積もりを行います。プランニングポーカーでは、まず管理者がそれぞれのタスクについてタスク内容を説明します。続いて全員がタスクに対して具体的なイメージを持つまで質疑を行い、最後に全メンバーが、見積もり工数を一斉に提示し中間値を設定します。このときにズレが大きければその認識違いについて話し合い、必要に応じて再度"ポーカー"します。タスクごとに作業を繰り返すため数十分かかります。

 完全に新しいタスクである場合はプランニングポーカーがもっとも好ましいのですが、そうでない場合はいくつかの見積もり方法を併用したりします。もっともその分野に経験豊富なメンバーに聞く、過去にその機能を実装したメンバーに聞く、割り当て予定のメンバーに聞く(次項で述べるように、極力この段階でメンバーにタスクを割り当てておかないことが原則ですが、実際にタスクを処理できるメンバーが決まっている場合もあります)などです。ただ、その場合、プランニングポーカーの副次的効果であるタスク内容の”共有”が疎かになるため、別途説明の機会などを持ちましょう。

※用語1 プランニングポーカー

 「アジャイルな見積もりと計画づくり」における代表的な用語の1つです。各メンバーが0,1,2,3,5,8,13,20,40,100というカードをもち、そのどれかを一斉に提示することから"ポーカー"の名がついています。一斉に提示することで人の意見に左右されなくなります。

 担当者が自ら見積もりすると、見栄を切ったり逆にバッファを載せてしまいがちですが、そうではなく客観的な立場から見ることができ、また、3人よれば文殊の知恵というように、正確性の高い見積もりができるということで有益な方法の一つです。皆がすべてのタスクの概要を理解できることも重要な副次的効果です。

 実際の運用では、時間がかかりがちであること、全員のスキルが一定以上に近くなければいけないことなどから、原則どおりに使いこなすことは容易ではないのかもしれないですが、取り組みがいのあるプラクティスであると思います。

 ここまでがプランニングミーティングの内容です。

タスク割当

 原則としては、プランニングミーティング時点では、メンバーへのタスク割当を行いません。メンバーの予定作業時間と工数見積もりに応じて、管理者(※注1)が、ミーティング後に設定します。

※注1

 ここでは、(ちょっと乱暴ですが)スクラムマスター(現場の管理に責任を持つ人)やプロダクトオーナー(要求の実現に責任を持つ人を管理者として一括りにしています。

 タスク割り当てにおいては、下記のような工夫を行います。

  • 可能な限り役割をローテーションし、1つの機能を複数のメンバーが知るようにする
  • 優先度を明確にし、やや優先度の低いものまで合わせて少し過負荷気味にしバッファとする

次のページ
デイリースクラム

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
グラス片手にアジャイル開発連載記事一覧

もっと読む

この記事の著者

株式会社ディーバ 小林 達(コバヤシ サトシ)

2004年に株式会社ディーバ入社。連結会計システム「DivaSystem」の大規模プロジェクトに参加した後、ビジネスインテリジェンス分野を中心とした複数の製品/受託開発プロジェクトを技術面で主導。オフショア開発でのアジャイル開発経験などを経て、現在はディーバアメリカを含む多国籍メンバーと共に、次世代...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/5565 2010/11/24 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング