hogehoge

アジャイル開発の実際(前編)

コラム, 記事 コメントは受け付けていません。
2月 162009
hugahuga
システム創造事業部
ディレクター
藤原 織衛

fujiwara.JPG
アジャイル開発というとみなさんはどのようなイメージをもたれるでしょうか?
イテレーション開発やペアプログラミングというイメージは広く知られているところかと思いますが、他にもドキュメントが少なそう・・であるとか、一度やってみたいけどどうやっていいのかわからない、そもそも実際の開発にホントに適用できるの?という不安でいっぱいな声も聞こえてきます。
そこで今回は実際にアジャイル開発で行ったプロジェクトをご紹介し、みなさんの一助になれればと思います。
【 実施イベント 】
朝会
毎朝、全員がそろってからスタンドアップミーティングを行います。
マネージャおよびメンバーが報告することは以下です。
・昨日やったこと
・今日やること
・問題点
朝会の主な目的は、メンバーが自分の「やったこと」「やること」を皆に話すことにより、毎日のゴールを明確にすることです。また、メンバー全員が進捗を共有し、問題点があればチームとして解決する意識付けを行うことも重要です。
時間は15分程度です。必要以上に長引かないためにもスタンドアップ形式は有効です。
イテレーション開発
2週間で「動作するもの」をリリースし、お客様に見てもらえるようにします。
2週間の作業内容は計画ゲームで決定します。
計画ゲーム
イテレーション開発の最初の一日目に、「今回のイテレーションでなにを作るか」ということを計画ゲームを行い明確にします。
計画ゲームはお客様を交えて、半日?一日程度ぶっとおしで打ち合わせを行います。
流れとしては以下のような感じです。
・機能の明確化
ホワイトボードに作成予定の機能を書き出していって、お客様と合意をとります。その場でも様々な意見がでて、頻繁に書き直されるため、パソコンで書いていくよりもホワイトボードのほうが有効だったように思います。
(重要なポイントはパソコンを使用してメモ書きします。)
・機能の詳細化
明確になった機能を、詳細なタスクに落としていきます。タスクの見積もりは原則3時間以内とします。
(例えば、○○クラスの△△メソッド作成は1.5時間など。)
ポイントとして見積もり時間は「全力でやったときの時間」を崩さないようにします。
・トリアージ
詳細化の見積もりを進めていくにつれて、明確化した機能が2週間でおさまらない場合があります。そんなときは、ここの部分をこうすれば収まりそうですがどうでしょう?など、お客様と合意できるポイントを話すのが最善だと思います。
・ホワイトボードを写真に取る
ホワイトボードに書いた内容は写真を取って保存しておきます。ですので、ホワイトボードは最終的にはきれいにまとめて書いておくようにします。
タスクかんばん
まず、計画ゲームで決まったタスクをすべて名刺サイズの厚紙(タスクカード)に記入します。
タスクカードには以下の情報を記入します。
・タスクNo
・ストーリーNo
・タスク内容
・作業開始日時
・作業終了日時
・作業者
・予想工数
・実績工数
(作業日時、作業者、実績工数はタスクを実際に消化する人が後で記入します。)
このタスクカードをタスクかんばんと呼ばれるA3くらいのコルクボードにぶらさげておきます。
タスクかんばんは以下の4つの領域に分けられています。
・未着手
・現在作業中
・本日作業予定
・消化済み
朝会では基本的にこのタスクカードを元にその日の作業を決めていきます。
ペアプログラミング
ペアプログラミングと呼んでいますが、プログラミングだけではなく、基本的に作業はすべて
ペアで行う(ペアワーク)こととします。ペアはそれぞれナビゲーターとドライバーという役割
を持ちます。ナビゲーターはドライバーに細かい作業指示を出し、ドライバーは指示通りに
作業を行います。ペアプログラミングの一番の利点は、タスクの作業内容を共有化できると
いうことです。
例えば、作業者の一人が会社を休んでも、もう一人が知っているためある部分を「誰も知ら
ない」ということが起こりにくいです。また、お互いに自然と作業をチェックする仕組みが働く
ため、「ついうっかり」ということがほとんど無くなります。ただし、ペアには現実的に「相性」と
いうものがあるのも事実だと思います。ペアでやってみてそれなりの成果がでていないと感
じた場合はやめたほうがよいかもしれません。
リリース
リリースとはイテレーションの最後に、お客様がアクセス可能なリリース環境にイテレーシ
ョンの成果物をアップロードすることを言います。リリース後、お客様に実際にシステムを
動かしてもらって、想定どおりの仕上がりであるかを確認していただきます。
もし、想定どおりで無い場合はフィードバック表にその旨を記載していただき、対応を後日
相談することになります。
ふりかえり
ふりかえりは文字通り、後ろ(実施したイテレーション)を見てみることです。手法としては
「KPT」を使い、全員で良かったところ(Keep)、悪かったところ(Problem)を挙げていき、最
後に悪かったところの対応策(Try)を話し合います。所要時間は1時間程度とします。
ふりかえりで重要なのは、「問題」対「チーム」の構図を作ることだと思います。例えば、
悪かったところが挙げられたときに特定の個人を責めたりしてしまうと、萎縮してしまい
「悪かったところ」が今後誰からもでてこないということになりかねません。
主な実施イベントを挙げていきましたが、いかがでしたでしょうか?
アジャイル開発ではなくても実施できるものが多数あるかと思います。
次回はプロジェクトで使用したツールについてご紹介します。

当社サイトのご利用について  |  Image: scottchan / FreeDigitalPhotos.net
© 2012 アジャイル開発 | Enterprise Java | 株式会社アットウェア Suffusion theme by Sayontan Sinha