Scrum Boot Camp 横浜に参加してきた

勉強会 Scrum Agile


(本編終了間際、『ふりかえり』でのKPT作成資料。※なぜ『レッドブル』が置いてあるのかは後述。)

Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した
「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の１つで、
近年アジャイルな開発の手法として日本国内においても急速に採用事例が増えています。

　一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないと
いうケースも良く聞くようになりました。

　そこで今回はこれからScrumを導入して開発を行うことを検討されている方もしくはトレーニングを受けない
(受けさせて貰えない)ままにScrumチームに参加されている方を対象に、Scrumの基礎講習を実施いたします。

　このコースでは講師によるAgileおよびScrumについての解説と、5人程度のチームに分かれてのワークショップを行います。

先月から徐々に足を踏み入れてきた『スクラム』。先月は都合3つのスクラム関連勉強会に参戦していたのですが、今回はそれに続くスクラム関連イベント、そして『Boot Camp』という、現在各所で熱を帯びている実践系イベントに参加してきました。

うわ、つか今気付いたが1週間で3日もイベント参戦してたんだ…しかも全てスクラム関連／スクラム含み(笑)


場所は横浜株式会社アットウェア様 大会議室にて。場所的には横浜駅近く、ちょうど『ハマボウル』が昔あった場所から近いと言う感じでしょうか。勉強会はここまで結構な頻度で参戦してきていますが、何気に横浜開催の勉強会に参戦するのは今回が初めてでした(これまでは全て都内開催の勉強会)。

参加定員が30名と少数なのもあり、募集開始直後に瞬殺(定員達成、即満員)という人気振り。人気振りもさることながら、やはり『Scrumを座学だけでなく、実践でも経験出来る』という点については非常に興味があり(これまでの経験の中ではScrum/Agile経験は無く、興味と書籍資料をかじった程度の知識)、またとても楽しみにしておりました。

本編は10:00〜17:00(昼休憩1時間を挟む)、その後の懇親会(同会場にてそのまま開催)が17:00〜19:00過ぎまで開催という計9時間にも及ぶ長丁場。

長丁場であるにも関わらず、中身の方はダレる事無く全編ぎっしりエッセンスの詰まった『濃ゆい』ものでした。以下セッション毎に分けて個人としての『ふりかえり』(スクラム的な/思い出的な)を行いつつ、内容を振り返っていきたいと思います。

※細かい部分まで記載している場合もあるので、今後こちらのイベントに参加される場合、(実践系イベントのため)読んでしまう事で参加時の新鮮な感動・感情が薄れてしまったり、ネタバレ的な意味合いで面白さが半減してしまうかもしれません。なのでもし以下レポートを読まれる場合はその辺りを踏まえてご覧頂ければと思います。

10:00-10:15 前説

到着は9:45位。皆さん思い思いの場所に着席されていたのですが、開始早々に席替えを実施。

スクラム経験者・初心者、参加者間の偏りを無くすためにシャッフルを行い、程良く参加者間のレベルを等しくして落ち着いた後、グループメンバー間で自己紹介。私が割り振られたグループは『第4グループ』でした。

なお、講師及びファシリテーターは全編通してRyutaro YOSHIBA(TwitterID:@ryuzee)さんが担当。途中その他参加されていたスクラムマスターの方々も要所要所で@ryuzeeさんや参加メンバーの皆さんをサポートされていました。

自己紹介も5分そこそこでスパッと切り上がり、今日行うタスク進捗についての説明。今回は以下のように、付箋とホワイトボードを用いた『タスクかんばん』で今日のスケジュールタスクそのものを管理するという手法で進めていました。写真は中盤から終盤に掛けての状態を撮ったものですが、最初は全て一番左の『TODO』にある状態でした。


  • 企業の置かれた状況
    • ビジネス環境の変化
    • 早い意志決定、具体化が求められる(例)google
    • 変化しない･･･マーケットから見捨てられ、緩やかに組織が死んでいく
    • 顧客自身の変化が求められる
    • IT投資の目的の変化
      • 業務効率化→戦略実現
  • 競争の速度の変化
    • ビジネスモデルの賞味期限が短縮。アメリカ企業は10年サイクル、ヘタしたら1年という短期の場合も。
    • 国内では…
      • mixi：数年前に流行り、facebook台頭でgree/DeNAに差をつけられている。ビジネスモデルが持たない。
  • 変化への対応
    • 事前に綿密にたてた計画を長期間遵守ではなく変化がおこることを前提に頻繁に軌道修正することが必要
  • 納期の確立分布
    • ソフトウェアの納期予測は『確率分布』である
    • ※『この日にりりーす出来そうです』…最もリリース出来る可能性が高い日
  • システムの機能の利用割合
    • 64%の機能は殆ど使われない。
      • 例)携帯の諸機能、MSワード、Excelに於ける諸機能
  • 7つのムダ…トヨタ生産方式におけるムダの分類
    • 作りすぎのムダ…使われない、ビジネス価値を生まない
    • 手待ちのムダ…仕様待ち、ビルド待ち、テスト待ち
    • 運搬のムダ…タスク切り替え
    • 加工のムダ…開発に利用しない報告書、重複した部品
    • 在庫のムダ…過剰なドキュメント
    • 動作のムダ…分散開発による移動時間、ツール不足による手作業
    • 不良を作るムダ…バグの後工程での発覚と手戻り

10:15-11:00 Agile基礎講習

ここでWORKSHOP #01『日々の業務の中で、ムダと思えるものを1つ選び、それに対する解決策を考え、10分後に発表』を開催。

各グループ共に議論を重ねるものの、10分の時間制限内では間に合わないところも多く(自分らのグループもそうでした)、結果としてプラス5分程度の延長。

ここで@ryuzeeさんがワークショップをふりかえり。

  • アジャイルで重要なのは、『タイムボックス(動かせない時間の箱・時間枠)』という概念である。
  • タイムボックスで限られた時間の中で最大限の効果を発揮する・結果を出すという事が一番大事。
  • その点で言えば、多くのグループが発注者(お題発表者である@Ryuzeeさん)の注文を守れていなかった。
  • (今回のお題に関して)極論を言えば、中身に興味はなく『10分後に誰かが発表』をしてくれればそれで良かった。
  • 私達プレイヤー(チーム/参加者)としては、まず最初にゴールを発注元に確認するべきであった(ゴールに関する情報の擦り合わせ不足)。

初っ端のワークショップでエンジンが掛かりきっていなかった部分も有り、また若干の意地悪っ気を働かせていた節が@Ryuzeeさんの方にもあったようなので(笑)こういう形のふりかえりとなったのですが、なるほど！と思わされた部分のあったワークショップでした。なお、意地悪っ気のあるワークショップは午前中までで、午後はとても優しく、親身になって質問に答えて頂けるセッションとなっていました(笑)


ワークショップ１つめの後は、アジャイル基礎講習セッション。


  • 4つの基本概念
    • プロセスやツールよりも個人と対話
    • 包括的なドキュメントよりも動くソフトウェア
    • 契約交渉よりも顧客との協調
    • 計画に従うことよりも変化への対応
  • Agile開発の原則
  • 最大限、顧客を満足させる
  • 要求変更を受け容れる
  • やる気のある人でチームを組む
  • みんなで顔を合わせて情報伝達
  • 進捗は動くソフトウェアで
  • ユーザは一定のペースを保つ
  • 優れた技術・良い設計に目を配る
  • 単純性(やらなくて良い事はやらない)
  • 自己最適化
  • チームに最も効果的な方法を選択
クレド

リッツ・カールトンはお客様への心のこもったおもてなしと快適さを提供することをもっとも大切な使命とこころえています。

私たちは、お客様に心あたたまる、くつろいだそして洗練された雰囲気を常にお楽しみいただくために
最高のパーソナル・サービスと施設を提供することをお約束します。

リッツ・カールトンでお客様が経験されるもの、それは感覚を満たすここちよさ、満ち足りた幸福感
そしてお客様が言葉にされない願望やニーズをも先読みしておこたえするサービスの心です。
我が信条

我々の第一の責任は、我々の製品およびサービスを使用してくれる医師、看護師、患者、
そして母親、父親をはじめとする、すべての顧客に対するものであると確信する。
顧客一人一人のニーズに応えるにあたり、我々の行なうすべての活動は質的に高い水準のものでなければならない。
適正な価格を維持するため、我々は常に製品原価を引き下げる努力をしなければならない。
顧客からの注文には、迅速、かつ正確に応えなければならない。
我々の取引先には、適正な利益をあげる機会を提供しなければならない。
  • 意識すべきは『価値』！我々はIT技術を使った顧客サービス業である。
  • 顧客に何を提供するのか？どんな価値をもたらすのか？
  • Agileとは(@ryuzeeさんの考える定義)
    • 顧客の価値を実現するツール
    • メンバーの幸せを実現するツール
    • 会社の利益を上げるツール
    • ※技術や方法論に目的が行ってしまうのは良くない傾向。
  • Agileの様々な手法
    • Scrum/XP/Lean辺りを覚えておけばOK。
  • Agileとウォーターフォール(※以下WF)の違い
    • [WF]最初に立てた計画を正しい、とする手法→『長編映画』：[Agile]例えるなら『連続ドラマ(しかも韓国の)』(※読者のハガキで急に展開が変わるような)
    • [WF]要求事項からリリース時間を逆算：[Agile]リリース時間を決めて、構築出来る機能を決める
  • WFの問題点
    • プロジェクトの終盤まで何の価値も実現出来ない
    • 最後の最後まで問題発見が遅れてしまう
    • 計画依存
    • プロジェクトマネージャ力量依存(パワープレイヤーなら上手く行くけど…)
  • WFのメリット
    • 計画が正しくて変更されない保証があるなら、Agileよりもやりやすい。
    • 分担が明確で、要員確保がしやすい。
    • 外注しやすい。
  • Agileの特徴
    • ビジネス価値を基準
    • 優先順位を付ける(※優先『度』では無い。注意！)
    • 小さい単位でリリース
    • 全て完了させて次へ
    • 依存性の排除
    • ムダを省く
  • Scrum/Leanのメリット
    • 他機能へのインパクトの極小化
    • 全体進捗が明確である
    • ムダな作業が行われにくい
    • 進捗管理は『0か1か』だけである。
      • WFのような、進捗『0% - 50% - 90% - 90ウン%...』みたいな曖昧なものではない！
        • 『何となく終わっていない…』のが溜まっていく
        • 多くのものに手を付けすぎない方が良い。『各個撃破』の方が良い。
        • 『doing』が多いのは良くない。
  • AgileとWFの違い
    • [WF]計画適合：[Agile]変化への対応
    • [WF]コマンドコントロール：[Agile]リーダーシップ・協業的
    • [WF]大きく前払い：[Agile]継続的・発現的
    • [WF]大きくドーン！：[Agile]UnitTestを積み上げて少しずつ
    • などなど。
    • 計画作りの頻度と計画の粒度が違う。
    • Agileはリスクマネジメント(お客様側の視点から見ると、特に顕著)
      • リスク：
        • 必要なものが必要な時に出来上がるか
        • ムダコストが発生する可能性
        • 不確実なものを大きく予測してそれに従い行動
        • 結合試験辺りで発生しうる『ビッグバン・リスク』("結合試験なのに結合出来てない")

11:00-12:00 Scrum基礎講習


  • Scrum普及状況
    • Agile手法の利用経験：[海外]69%が利用 [日本]良いとこ1割程度？
    • 導入主導層：[海外]経営、上級管理職 [日本]開発、より現場に近い層から
    • 導入動機：マーケットへの投入時間の短縮、変化への対応が強い。
    • 導入効果：優先順位の変更にも対応可能に、プロジェクト可視化に成功、
    • 等々。多くの組織で何らかの改善が見られる。薦める際には『海外でもこういう数字が出ていますよ』が効果的。
  • 採用状況：大多数がScrumを採用している。
    • Scrum単体：58%
    • Scrum＋XP：17%
スクラムが開発手法として登場したのは1993年、Jeff Sutherland、John Scumniotales、Jeff McKenna がラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築したのが最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。
スクラム的手法を以前から開発プロジェクトで使っていた企業として、富士ゼロックス、キヤノン、本田技研工業、日本電気、セイコーエプソン、ブラザー工業、3M、ゼロックス、ヒューレット・パッカードなどがある。これらのプロジェクトについては、一橋大学の野中郁次郎と竹内弘高が Harvard Business Review 誌に "The New New Product Development Game" として発表している（1986年1-2月）。逆に言えば、この論文がスクラムという用語の元となった。
  • Scrumを100語で説明
    • ビジネス価値を早期に顧客に提供
    • 動作するソフトウェアを速やかに・繰り返し確認
    • 優先順位(優先度ではない)
    • チームでやり方を決める

『自己組織化』というキーワードが出て来たところで、ここでWORKSHOP #02『自己組織化ゲーム』が行われました。

代表で10名程前に集まり、自己組織化を体感するゲームを実践。(『第23回すくすくスクラム 〜Scrum の概要〜』でも行われた、輪になってやる例の『アレ』でした。)

ここでの意図としては、『ゴールが分かったらみんなで動ける』というアジャイルが本来目指す姿。PM主導のコマンドコントロールでは時間が掛かる(10分と予想)ものを、自己組織化したチームによるスピードアップで効率化(1分しか掛からなかった)出来た事を体験出来たワークショップでした。

ちなみに、これはやはり説明が中々に難しいワークショップでして、実演指導をされたスクラムマスターのQooh0 (Qooh0)さんも説明に少々苦戦されていました。(^_^;)その場でスライドを作るというような宿題を課すやり取りがスクラムマスター間でなされていたので(笑)、いずれまたこのワークショップが行われる際には改善がみられるのでは、と思います♪(^o^ )

  • オペレーションプロセスの変化
    • [コマンドコントロール]→[自律化・自己組織化]
    • コマンドコンロトール
      • 上司の命令従っていれば良い
      • 人が育たない
      • 優秀な人は居なくなる
    • アジャイル自己組織化
      • 責任は負う
      • 上司は後方支援、ファシリテータ役
      • 上司はチームを信じる
  • Scrumの骨組み ※括弧内略称は個人的に命名。必ずしも世間一般的な用語…でもないのかしら？
    • (1).3つのロール
      • プロダクトオーナー(PO)
      • スクラムマスター(SM)
      • チーム
    • (2).4つのミーティング
      • スプリント計画
      • スプリントレビュー
      • スプリントのふりかえり
      • デイリースクラム
    • (3).3つの道具
  • Scrumの利用例
    • Microsoft, Google, IBM, Yahoo等様々な有名企業が採用。国内でもGREE等
    • WEBサイトの開発等が、最もスイートスポットな(利用に適した)場面。
  • ロールの話
    • プロダクトオーナー(PO)
    • スクラムマスター(SM)
      • スクラムプロセスの番人
      • 外部干渉からチームを守る
      • プロジェクトマネージメントの代表
      • Scrumの価値、プラクティス実現に責任を持つ
      • 障害事項を取り除く(PC性能が遅い、等…)
      • チームが十分に生産的である事を保証する
      • プロダクトオーナー、スクラムマスターは通常チームに一人ずつ。
    • チーム
      • 5〜9人、機能横断的(1人が何でも出来る)
      • メンバーはフルタイムプロジェクト参加が原則
      • チームは自己組織化されている
      • メンバー交代はスプリントとスプリントの間のみ
      • 特定分野のスペシャリスト(例:DBチューニング、デザイナ等)は掛け持ちOK。
      • 肩書きは無し。
  • マルチタスクの無駄
    • 脳にとっては良くない。生産性は低い。
    • マルチタスクが無駄である事は、科学的に証明もされている。
    • プロジェクト兼任もやはりムダ。ストレスの原因にもなる。
    • どうしても必要ならタイムボックス化して対応。(日付/曜日で分ける、午前/午後で分ける等)
  • チームのルールに伴う責任
    • 全てのAgileなプロセスはチームへの権限委譲とチーム内での文化及び規範の確立を必要とする。
    • デイリースクラムに出席する
      • 参加出来ない場合：罰ゲームなど(皆の前で歌う、おやつ神社へ寄付等)が効果的
    • 完了定義に従って作業を行う
    • チームメンバーを助ける
    • チームメンバーを育てる
  • コミットメントとは何か？
    • チームが『全力で選択したストーリーをDoneにしようとする』こと→"コミット"。
    • チームの責任であり、個人の責任ではない。
    • 見積もりはコミットメントではない。あくまで予測。
    • 複数スプリント経過後、ベロシティに基づいて見積もりをチームで合意する事は可能。
  • Doneの定義

Scrum基礎講習も終盤を迎え、ここでQ&Aタイム。

  • [Q].Scrumが社風的に難しい場合はどのような対応を？
    • [A].兼任した場合、タイムボックス化して対応することが有効。スイッチングコストが掛かってしまう。
      • タイムボックス化すれば生産性は高くなるだけど、(端から見てると)生産性が低いように見えてしまう(忙しくしてるように見えないから？)
      • この辺りの問題に関しては、結局のところ上司の勉強不足である部分が大きい。(面と向かっては言えないけど)
  • [Q].POが丸投げしてきた場合は？
    • [A].『POが価値を決められないのなら、サーフィンにでも行ってくるよ』(と、海外のとある人は回答していた)
    • こういう場合はSMがPOを教育する必要がある。

等々その場で2〜3、かなり細かく回答して頂けていました。あと質問内容は忘れたけど『小規模Scrumで出来ない人は、大規模Scrumでやってもダメ』というお言葉も。

12:00-13:00 昼休憩

実際には20分押しだったため、12:20〜13:20の昼休憩。自分が居た第4グループを含め計8人で近くのお店でお食事しました。
私は残り7人については完全初対面な方々ばかりでしたが、午前中のセッションについての話、仕事とスクラム/アジャイルに絡めての話など、様々なテーマでお話する事が出来ました。

…と、ここで当エントリ冒頭のKPTマップwith『レッドブル』の写真についてちょっとした小話を。

個人的には『レッドブル』好きである事はこれまでにもブログで度々言及してきましたが、この日も参加前に(長丁場を見越して)3本購入し、イベントに参戦していました。んで、午前中のイベントにて、その他第4グループメンバーの方々とレッドブルについてのトークになり、偶々昼食帰りに通り過ぎたコンビニで『レッドブル』が売っていたため、半ばノリで皆さん購入された…という流れに。

午前中は第4グループでしたが、この時を境に『チームレッドブル』に生まれ変わり、1グループだけ何か妙な雰囲気の机上となっておりました(笑)

この光景を見て、数々のスクラムマスターであると同時にRedBull Masterでもある@ryuzeeさんもこの光景を楽しんでおられ、後ほど写真にも撮って頂けました。個人的な好みがイベントにちょっとしたアクセントを付けられたようでちょっぴり嬉しいやら恥ずかしいやらでした。(^_^;)

13:00-14:00 プロダクトバックログ演習

昼休憩後のセッションは『演習』メイン。とその前に今回のScrum Boot Camp実施についてご参加されていた(@ryuzeeさん以外の)スクラムマスター/スタッフの皆様方の御紹介。セッションやワークショップの合間、または懇親会の場でも非常に気さくな雰囲気で、タメになるお話を皆様方から伺う事が出来ました。ありがとうございました！

※TwitterTLその他から一覧に纏めてみましたが、この情報で合っていますでしょうか？もし間違いなどあれば御指摘頂けるとありがたいです。(^.^;)

  • プロダクトバックログ(PBL)とは
    • 要求事項の一覧
    • プロジェクト中に求められる全成果の一覧。
    • プロダクトオーナーによって優先順位付けされる。
    • 全項目が詳細である必要は無い。
    • ユーザストーリーの書き方
<役割>として<機能や性能>が出来ること。それは<ビジネス価値>のためだ。
  • PBL分割の方向
    • 技術的レイヤー単位で分割をしない。
    • 動作する機能単位で分割をする。
  • ユーザストーリーの『INVEST』
    • Independent
      • 互いに独立していること
      • 依存関係・前後関係排除(これらが高いと見積もりが難しくなる)
    • Negotiable
      • 交渉可能
      • 会話のための道具
      • 一度決めたことが絶対ではない
    • Valuable
    • Estimable
      • 見積もり可能(が出来る位のストーリーの粒度)
    • Sized Right(Small)
      • 適切な大きさ
      • 十分にストーリーが分割されていること
    • Testable
      • テスト可能
      • 受け入れテストを記述出来る

ユーザーストーリーの話の後で、3つめのワークショップWORKSHOP #03『プロダクトバックログをみんなで作る』を実施。

『会社の中で使う飲み会管理システムを作る』というお題で、制限時間内にプロダクトバックログを10個以上挙げ、それらに優先順位を付ける。というものでした。その他幾つかの条件(発注元の希望)が提示された後に開始となりました。

グループ内で作成したPBLはこんな感じ。画面上から優先順位が高く、下に行くにつれて優先順位が低くなる…という感じです。

作成して行く過程で、『どうしてもこれがないと始まらない、という項目が出来てしまうのがこれは良いのだろうか？』という問題に直面したのですが、スクラムマスターの方に聞いてみたところ『流れが出来るのはある程度仕方のないこと。最低限は許容し、あとは判断基準に応じて』といった答えを頂きました。

また、優先順位決めについては多分に感覚的な部分があったのですが、実際の業務や現場では上記『INVEST』で定められた基準が各種存在すると思われるので、それらも有効に・適切に使って判断を下していくのだ、というお話も聞けました。


ワークショップの後はQ&Aタイム。

  • [Q].ストーリーを考えるにあたり、用語集的なものは必要？
    • [A].場合によって。必要なら作りましょう。
      • ロールや単語のイメージを揃える必要はある。特に"ユーザ"なんて単語は一番ヤバいかも。
      • 作る・イメージを共有するにあたって、『会話する』という事が重要。議論にこそ価値がある。
  • [Q].TOP5位は決められるんだけど、後は大体便利機能的なものばかり。こういうときも全部に優先順位は付けるの？
    • [A].振らないor適当に割り振ってしまっても構わない。単純比較で良いのでは？

また、『優先順位は常に見直しましょう』『実装前提・実装ベースのストーリーになるような話はやめたほうが良い』などのアドバイスもありました。


そして引き続き講義。次の内容は『見積もり』について。

  • Scrumの見積もりは相対見積もりで行う。
  • 見積もりはあるポイントを起点にして行えば、簡単・シンプルになる。
  • 見積もりの際のポイントは、何の意味もない概念的なもの。

プランニングポーカーの説明後は、4つめのワークショップWORKSHOP #04『プランニングポーカー演習』。

先程作ったプロダクトバックログの各項目に対し、独自の手法・ルールでポイントを見積もっていきます。行った手順については以下の通り。(注：この手順は今回セッション独自のもので、必ずしもこれが全てではありません。案件でもチームでも異なりますし、チーム内で決められたルールに基づくものになります)

  • チーム全員(オーナー・チーム)で行う。
  • 準備
    • PBL項目の中で一番小さいと思えるものに1ポイント設定
    • それの5倍位はありそうなPBL項目に5ポイントを設定
  • 実施
    • 残ストーリーを、基準とした2つのストーリー(1ポイント・5ポイント付与したやつ)を元に1ストーリーずつ見積もっていく
    • 項目に対して、想定する見積もりポイントのカード(今回用意されたカードは1,2,3,5,8,13の6種類。これも場合に拠って変わる)を一斉に出す
    • チーム内の数字がバラつく場合、最大値と最小値と出した人が『なぜそれを選択したか』をチーム全員に説明。その上で再度ポーカー実施
    • 隣接する2値に収束した場合は、大きい値を選択(例:議論の結果、2と3の二択結果となった→"3"をその項目に対応)

見積もり時の風景はこちら。現在見積もり中のタスクに関してはレッドブル缶を置いて分かりやすくしています(笑)なお、プランニングポーカーのカードについては1セットのみ本物を利用、残りのセットはトランプで代用していました。

最初自分ではポイントの割り振り方に大きな勘違いをしていたのですが、実践して行く過程で認識修正。必ずしも13ポイント(今回のカードで最大)を割り振る訳では無く、基準となる2ポイント(1,5)を割り振ったものに対して、どの程度の規模なのか。それに該当するポイントの1枚(自らの考え)を提示する、という感じですね。

最大値or最小値を出した人は『なぜそのポイントを出したのか』をコメントしなければならないため、自分の考え・見積もりもより熱の入った真剣なものになります。この辺のやり取りを通して、グループ内の他の方の考えが分かったり、『そう言われれば…』と考えを改めたりする事が出来ました。

一見するとゲームをやってるようにしか見えませんが、これは『やってて楽しい』(ゲーム的な意味ではなく)ですし、何より真剣に項目に対して意見を交換しあい、議論が出来るので効果が高いな〜、と感心。

ちなみにこのワークショップ後の質疑応答、要点コメントは以下。

  • ポイントが大きすぎると、見積もりが不確実になる。
    • 大きくなればなるほど、数字の差に意味は無くなってくる。
  • 大きくなった場合、ストーリーを分割すると良い。
  • 正しく分けるとテストがしやすくなる。
  • 見積もりが大き過ぎた場合の決めはチームで行う。
  • ストーリー分割時、明確に書き直せるなら(そしてそれがチームの理解を得られるのなら)書き直した方が良い。

会話の中で、『アーキテクチャジャンプ』『スプリント0』というキーワードも出て来ました。

14:00-15:00 スプリント計画演習

  • スプリント計画会議…スプリントとは？
    • 最大限4週間までのタイムボックス
      • @ryuzeeさん的には2weeksがオススメ。
    • 一度決めたスプリントの長さは決して変わらない(変えちゃダメ！)。期間固定である事に意味がある。
    • スプリントの中断はPOのみ可能。
  • スプリントバックログ
    • タスクは理想時間単位で、チームで見積もる。
    • チームの平均的なスキルの人で見積もる
    • タスクがデカ過ぎると見積もれない
    • 就業時間の60%位しか使えない
    • プロダクトオーナーがSBLについて分かっている必要は無い。


こちらのテーマについてもワークショップWORKSHOP #05『スプリントバックログ演習』を実施。

  • 優先順位の高いバックログ項目を3つ選択。
  • 選択した項目いついて、タスクの洗い出しと時間の見積もりを行う。
  • 時間幅は0.5h〜8.0hの間。

…こちらのワークショップについては、自分らのグループは前提条件の見極め、分割の際の判定基準等の認識違いによって結局1つも完成させる事が出来ず仕舞いでした。(1つ目のタスク分割で難航)

分割に際してより実装的な面に着目してしまい、その実装面を考慮するには環境面の前提条件を洗い出しておかなきゃいけないんじゃないか？とか(この辺りは『アーキテクチャジャンプ』というテーマや『スプリント0』と呼ばれるフェーズで消化・対応すべき箇所という事が判明)、DBのテーブル定義も全テーブルやらなきゃ行けないの？→いやいや、この場合は対象テーブルだけで良いんだよ、とか、設計書を書くタスク、設計するタスクはどうするの？とか…一番考え方の切替を必要とされ、その切替が一番出来てなかったな〜と実感させれらたセッションでした。

自分もここまで非アジャイルな現場で経験を積んできたため、どうしても考えをシフトさせる事が出来ず難儀。『いっぱいやればすぐ慣れる』とアドバイス頂いたのですが、この部分に関しては本腰で取り組めるような状況が無いとなかなか苦心するだろうなぁ…とは思いました。

15:00-16:00 Scrumのその他のトピック

セッションやらワーキングショップやら、特に大きな区切りは1回あった位なのでここの区切りが正しいかどうか微妙…(^^;)

バーンダウンチャート
デイリースクラム
  • 毎日やる。
  • 15分 タイムボックス厳守！
  • 立ってやる事！(座ると時間が延びる)
  • コミュニケーションの改善
  • 無駄なミーティングの防止
  • 迅速な意志決定
  • 問題解決の場ではない
  • 特定メンバーへの報告でもない
  • 全員が3つの質問に答える(@ryuzeeさん曰く『デイリースクラム5分前には考えておいてね』とすると効果的)
    • 昨日やったこと
    • 今日やること
    • 困っていること
  • 1人2分、7人でも15分。
  • [Q].毎日やる必要無くない？
    • [A].No, 毎日やります
  • [Q].メールでも良い？
    • [A].No, 会って話すことが重要
      • 会って話すことでプレッシャー/タスク完了についてプレッシャーを掛ける
      • メールなんて結局読まない
  • 朝やるのが基本だが、場合・都合によっては夕方やるところも
    • 朝の場合は始業後30分後位がちょうど良いかも
スプリントレビュー
  • チームがスプリント中に完了した事を発表
  • 完了しなかったことも発表
  • 通常スプリントにて定めたストーリーのデモを行う
  • 準備に時間を掛けすぎないこと！(パワポとかで)
  • スクラムマスター/プロダクトオーナー/チーム全員で参加
  • 誰でも招待可能
  • 結果に満足したか？を確認
  • 次にどうするかを考える資料となる
  • 大事なのは『ちゃんと出来ているか』。
ふりかえり
ふりかえりによる改善
  • プロセス改善の場
  • 個人攻撃はしない
  • 個人評価に結びつけない
  • 特定メンバーの喋りすぎはNG
  • Tryは本当に出来ている？追跡重要
  • 同じProblemが毎回出ていないか？
  • 全部の問題に、一度に手を付けないこと。
  • 出来る事から、改善する態度が大事。
会議体のまとめ

メトリクス
プロジェクトバーンダウン
  • 未完了のストーリーのスプリントをスプリント毎にプロットする
  • どんな指標データが取得出来るかはチームの成熟度による
  • 数値を個人評価用として使わない事！
    • 抜け駆け、秘密主義の原因に。
  • 前提・環境が異なるので他チームと数値を単純比較しない事。
その他：ドキュメントについて
  • 全く書かない訳ではない。
  • 必要な時期に、必要なものを書く。
  • 完了の定義にドキュメントを含める。
  • 終盤に揃っていれば良い。
  • 自動化出来るものは自動化する。
  • 文書承認主義組織の場合は、組織自体を改革する必要がある。
その他：スプリント0
  • プロダクトのゴールや価値の明確化を行う。
  • プロダクトバックログの作成
  • おおよそのリリースプランニング
  • ロールの明確化
  • チームに対するスクラムのトレーニング実施
  • スプリントの長さを決める
  • 『Done』の定義を決める
  • 開発言語・大きい意味でのアーキテクチャ選定
  • 技術的スパイク(技術検証)の実施
  • 開発環境の作成
  • チームのルールを決める
  • チームの部屋を作る
その他：妨害事項リスト
  • プロジェクトを進める上で妨害となっている項目のリスト
  • 解決の優先順位をつける。※スクラムマスターが管理
  • スクラムマスターは優先順位の高いものからチーム内外と交渉して解決。
  • 物理的に不可能なものは含めない
  • 多くし過ぎない
その他：アナログの有効性
  • 壁に貼って常に目の届くところに掲げておくのは効果的。
  • 『アナログでやっても上手くいかない人はデジタルでやっても上手くいかない』
  • 何の着手を許すか(WIP)に制限を掛ける
  • アナログツール(付箋・模造紙等)とISMSとの兼ね合い…社内に確認を取る。場合によっては個別対応可能だったりする
    • (例)付箋・模造紙の場合、帰宅時にはがす/カバーをかけておく/施錠可能な部屋を設けてセキュリティを強化 など。
その他：XPとScrumの融合
その他：失敗するスクラム
その他：大きなプロジェクトへの導入
その他：品質の話
  • WFモデルの課題として
    • 作ったソフトウェアが顧客ビジネスのニーズにマッチしているかどうかを確認出来るのは、受け入れ試験の時期になってしまう。
    • モノの品質確定は終盤にずれ込んでしまう
  • アジャイルでの品質の作りこみ
    • Scrumでは出荷可能な製品の積み上げをスプリント毎に提供しているので対応可能。
その他：テストの4象限
  • Agileにおいては、テスト自動化は必須(Scrumではフレームワークの定義のみで触れられていないが)。
  • 自動化しないと後が大変。
  • 自動化しないと、規模に応じてテスト工数の占める割合が増加していく(＝価値への投資が減少)
その他：質疑応答等
  • [Q].スクラムチームを組む時、どうやってメンバーを選ぶか？
    • [A].技術でよりも、性格で選ぶかも(@ryuzeeさんの場合)
      • コミュニケーション力重要：会議で喋れる/時間通り来る/人のアドバイスを聞く
  • [Q].極端にチームメンバーが変わってしまうケースはどうやって対応？
    • [A].スプリント期間を短くして対応(従来は2週間→1週間に短縮)
      • 基本的に、Scrumは実測駆動。
  • タスクの分割
    • 荒い設計→細かくする際はチームで設計活動を行う。そのため、チーム皆でスプリントバックログ作成等を行う。
  • アナログのメリット
    • 常に見ながらやる(やれる)点は大きい。見えると色んなことが出来る。
  • [Q].アジャイルの品質と会社の標準(の差)をどうやって定めるか？
    • [A].自分の会社の基準と、顧客の基準は必ずしも関係性は無い。
      • お客様のビジネス価値を満たすかどうかで決める。

16:00-17:00 ふりかえり

Scrum Boot Camp最後のワークショップはWORKSHOP #06『今日のふりかえり』を実施。

今回のScrum Boot Campに触発されたのか、皆さんTryの項目が多く出てきてましたね。あとはタスク分割のワークショップで手こずった所が

レッドブル缶をあの位置に置いたのは、個人的に『ただ単にスペースが空いてたから』だったのですが、振り返り終了後に各グループの(ふりかえり)結果を各自閲覧してた際にどなたかが『そこ(Keep＝今後も続けること)に置くんだ…』と呟かれていたのを聞いて、思わずニヤリとさせられてしまいました。(^_^*)

まったく意図してなかったのですが、これも偶然なのか。もちろん、レッドブルはこれからも続けていきますよ！( ｀・ω・´)


懇親会開催前、場所作りの時間を利用してお知らせなど。

2011/06/24(金) スクラム道バースト開催！


このイベントにも参戦します。観客としてですが、どのようなセッションが展開されるのか楽しみです！

2011年07月、『The Agile Samurai』発売！

こちらのエントリで募集されていた件の書籍ですね。

原書はこちら。

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)


非常に興味深い内容です。発売されたらぜひ読んでみたいと思います。

17:00-19:00過ぎ 懇親会


若干本編が押してたので実際の開始は17:00を過ぎてからでしたが、同じ場所でそのまま懇親会の流れへ。
こちらの懇親会でも、色々な方から興味深い話を聞くことが出来ました！2時間あっという間でしたね。


本編セッションのみならず、質疑応答や懇親会の場でも非常に為になるお話やフレーズを聞かせて頂いた@ryuzeeさん。

会場提供をして頂き、懇親会の席では『開発では全てペアプロやってる』というお話をして頂いた@tw_takubonさん。
(つかそんな現場、超羨まし過ぎる…)

認定スクラムマスター及び研修制度について丁寧に教えて頂いた@miholovesqさん。


同じ第4グループ改め『チームレッドブル』でご一緒させて頂いたチームの皆さん。
(@frerudevさん/@gantawitterさん/@cointoss1973さん/@dproject21さん)

その他、イベント・懇親会でお話出来た皆さん、今回はありがとうございました！


是非次回も参加したい…ところなのですが、@ryuzeeさんにお話を伺ったところ、次回に関しては『講師を変えて・同じ形態で』という事らしいです。恐らく近々参加募集もなされる事と思いますが、その際にもその旨(今回参加された方はご遠慮を…)が記載されるのではないでしょうか。残念ではありますが、この体験は皆さん是非ともして頂きたいと思いますので、興味を持たれている方は是非とも参加を検討されてみてはいかがでしょうか。自分としても次に参加出来るチャンスをうかがいつつ、その他のスクラム/アジャイル関連イベントにも顔を出して行こうと思います。



そして、次回以降も開催されるであろう『Scrum Boot Camp』に参加が決まった際、『興味があるけどAgile/Scrumの実施経験・一部適用経験が無い』といった方は事前に予習・勉強等をしておく事を強くお勧めします！ 計6〜7時間にも及ぶセッション＋ワークショップ、その中身も非常に濃いものなので、全部を一度に消化・振り返りを行うのは正直厳しいのではないか、と思います。（自分もほぼそのような立場で参加しましたが、結局この振り返りエントリを書くのに丸一日費やしてしまいました…(^o^;)）

幸い、スクラム/アジャイルに関しては無料でPDF資料が提供されています。まずはこの辺りの資料を読むことから始めてみるのも良いと思います。