納涼！みんなで持ち寄る『ゾッ！とする話』

第 26 回名古屋アジャイル勉強会

納涼！みんなで持ち寄る『ゾッ！とする話』

2010/08/27

Slide
1 第 26 回名古屋アジャイル勉強会

自己紹介
 H/N ： You&I ( 読み：ユーアンドアイ )
 お仕事： C++ プログラマ
 Web サイト： http://d.hatena.ne.jp/youandi

Slide

アジェンダ
1. 本日のワークショップの趣旨説明
2. KPT( ケプト ) で自己紹介
3. 失敗事例紹介
4. ワークショップ ( ゾッとする話 )
5. ワークショップ ( デスマーチ・デスマッチ )
6. ディスカッションタイム
7. まとめ

Slide

1. 本日のワークショップの趣旨説明 (1/4)

皆さん、宿題やってきましたか・・・？

Slide


皆さん、失敗してますか・・・？

Slide

 今日は、自分や他人の失敗から何か気づきを得る事を主題
とします。
 自分の失敗談を自慢したり、他人の失敗を嘲笑う会ではありま
せん。
 建設的なご意見をお待ちしております！
 でもやっぱりズバッと本音の意見も欲しい所ですよね。
 失敗談の振り返りをして頂く上で、 KPT( ケプト ) を使いま
す。

Slide

 まずは、自分で振り返りをして頂きます。
 次に各自の振り返りを共有します。
 楽しんで下さい。
 でも「楽しかった。」で終わらせないで下さい。
 せっかく参加して頂いたので、何か１つでも気づきを持ち
帰って下さい！

Slide

2. KPT( ケプト ) で自己紹介 (1/3)
 KPT( ケプト ) とは？
 Keep, Problem, Try の頭文字を取ったもの。用紙や何らかの
領域を Keep, Problem, Try の３つの領域に区切り、その３つ
の分類毎に気づき等を書き連ねる。物事に対する振り返り等で
利用する。
 Keep
 良かった事、継続したい事。
 Problem
 問題だった事。
 Try
 試してみたい事。
Slide

Keep Try( 今日の勉強会で学びたい事も！ )

名古屋アジャイル勉強会に継続参加講師役を頑張りたい

C++ プログラマデスマ回避方法を知りたい

毎日日記書いてます C# のお勉強

You&I
Problem

寝不足

資金不足 ( 勉強会に参加しすぎ？ )

プログラミングの書籍を買っても読まない

Slide


それでは、
KPT についてちょっと理解できた所で、
早速 KPT を書いてみましょう。

各テーブル内でひとり約１分間で
自己紹介して下さい！

Slide

3. 失敗事例紹介
失敗事例
医療システムの開発。約 20 名近い人員が客先近くのホテルに宿を取って作業に従事。
プロジェクトの終盤には夜勤体制も行った。
Problem Try
１人あたり１日５件の不具合修正ノルマ。もう少しマクロに ( 全体的に ) プロジェクト状況
→ 皆が目先のノルマに囚われてデグレード頻発。
を見るようにしたい。
夜勤体制になったのは、開発機材が開発人員に対してちょっとした事でキレないようにしたい
少なかった為。４セット程しかなかった。 → チーム内を良い雰囲気に保つ事は大事！
仕様が複雑・膨大過ぎて、全てを把握しきれなかった。ま思った事は腹に溜めないで、ちゃんと言う。
た把握している人もいなかった。
Keep

C++ の案件で new が失敗する事象を垣間見
た。
会議にせよ、設計にせよ、実装にせよ、基本が
大事だなと認識した。

Slide

4. ワークショップ ( ゾッとする話 )
失敗事例
失敗した事例の概略。どんな事をしたのか。規模情報 ( 人数や期間、費用 ) 等。

Problem Try

Keep

Slide

(1/8)

デスマーチ・デスマッチとは・・・、
デスマーチ・オブ・デスマッチを
決める為の戦いである・・・。

デスマーチの勝敗は
ストーリーポイントで決まる・・・。
Slide

(2/8)
 ストーリーポイントとは？
 １つのユーザーストーリー (1 サイクルで実装可能な規模の作
業 ) を実装するのに必要な労力を見積もる手法。
 あるフィーチャー ( 機能 ) を開発する上で関連する労力、それ
を開発する複雑さ、それに付随するリスクをなどをまとめたもの
 具体的にな時間をコミット ( 確約・約束 ) する事なく、難易度を
見積もる事を目的としている。
 アジャイルな見積もり手法では、規模を見積もり、期間を導出
する。ストーリーポイントは規模を表すもの。
 ストーリーポイント間の相対値が重要。

Slide

(3/8)
 ストーリーポイントの利点
 職能横断的な作業の進め方を促進
→ チームを専任作業ではなく多能工化する
 純粋な大きさを表すので見積もり結果が長持ちする
→ 基準にしたストーリーとの大きさの比較で見積もるので、基準に変更が
ない場合には他のストーリーにも変更はない
 早く見積もる事が出来る
→ 単純な大きさの比較で見積もるので簡単
 担当者による相違の影響を受けない
→ チーム全員で見積もるので誰が担当するかによって大きさに変化はな
い

Slide

(4/8)
 ストーリーポイントの欠点
 顧客に説明しづらい
 導入しづらい
 見積もりの注意点
 人は規模の大きさが 10 倍を超える場合にはうまく見積もれない

Slide

(5/8)
 ストーリーポイントによる見積もりを実施するには
 チーム内で見積もりを行う際には、プランニングポーカーを使
います。
 各自が 10 枚のカードを持ち、基準となるストーリーとの対比で
自分がこれと思ったカードを 1 枚選び、せーの！等のタイミング
で一斉に出します。
 出したカードの一番高い人と一番低い人との差が大きい場
合、何故そのポイントのカードを出したのか話し合いを行い、調
整を行います。
 調整後に再度、同じ事を繰り返し行い、ポイントがほぼ揃うまで
やります。但し全員揃える必要はなく、ある程度の所で妥協しま
しょう。
Slide

(6/8)
 ストーリーポイントによる見積もりの練習
 話を聞いているだけでは分かりませんね。
 よろしいならば練習だ。
 各種ボールの大きさで練習です。
 ゴルフボール
 ピンポン球
 硬式の野球ボール
 ソフトボール
 ラグビーボール
 バスケットボール

Slide

(7/8)
失敗事例
医療システムの開発。約 20 名近い人員が客先近くのホテルに宿を取って作業に従事。
プロジェクトの終盤には夜勤体制も行った。
Problem Try
１人あたり１日５件の不具合修正ノルマ。もう少しマクロに ( 全体的に ) プロジェクト状況
→ 皆が目先のノルマに囚われてデグレード頻発。
を見るようにしたい。
夜勤体制になったのは、開発機材が開発人員に対してちょっとした事でキレないようにしたい
少なかった為。４セット程しかなかった。 → チーム内を良い雰囲気に保つ事は大事！
仕様が複雑・膨大過ぎて、全てを把握しきれなかった。ま思った事は腹に溜めないで、ちゃんと言う。
た把握している人もいなかった。
Keep

C++ の案件で new が失敗する事象を垣間見
た。
会議にせよ、設計にせよ、実装にせよ、基本が
大事だなと認識した。

Slide

(8/8)
 各テーブルで、プランニングポーカーを用いたストーリーポ
イントによる見積もりで、私の事例を基準にデスマーチ・オ
ブ・デスマーチを決定して下さい。
 デスマーチ・オブ・デスマーチが決まったら、テーブル毎に以
下のまとめを行って頂き、発表する為の準備をして下さい。
 デスマーチ・オブ・デスマーチのストーリーポイントは何ポイント
か？
 何に重き ( ゾッと指数、不幸指数等 ) を置いて判断を行ったの
か？
 デスマーチ・オブ・デスマーチの事例について、予防・回避策は
何かあるか？
Slide

6. ディスカッションタイム

失敗の事例や
その予防・回避方法について
皆さんで語り合いましょう！

Slide

7. まとめ
 KPT( ケプト ) で振り返り
 とりあえずやってみましょう！
 ストーリーポイントによる見積もり
 規模を見積もり、期間を導出する。
 チーム全員で見積もる。
 基準を決める。 ( ストーリー、着目点 )
 手早く簡単に。

Slide

納涼！みんなで持ち寄る『ゾッ！とする話』

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to 納涼！みんなで持ち寄る『ゾッ！とする話』

Similar to 納涼！みんなで持ち寄る『ゾッ！とする話』 (20)

Recently uploaded

Recently uploaded (8)

納涼！みんなで持ち寄る『ゾッ！とする話』