このページについて
Scrum Allianceの公認研修である認定スクラムマスター研修に行ってきました。
全3日制。その1日目で得た学びをまとめたものです。
※3日通しての総括編はこちら
※以下は全て個人の理解/感想であり、内容に誤りを含む可能性があります。ご了承ください。
アジェンダ
- スクラムガイドを中心としたグループディスカッション
- いくつかの問いが与えられ、グループ内で回答を作成
- 回答を講師がチェック
- スクラムにおいて重要な（従来開発において陥りがちな）概念の学習
- フィーチャーチームとコンポーネントチーム
- 部分最適と全体最適
- 知識創造
- 経験的と論理的
- プロジェクトとプロダクト
- テクニック的なこと
- TDD（テスト駆動開発）
- ATDD（受け入れ駆動開発）
- リファクタリング
以下、個別のメモです。
チーム作りから学ぶ全体最適
会場は5×6チームの30名
最初は適当に席に座ったが、チームを作り替えることになった
評価観点は以下の４つ
- スクラムの前知識がどの程度あるか（1～10で自己評価）
- 自身の性格が内向的か外交的か（人数バランスが良い方が会議体が良くなる）
- なるべく幅広い職種（開発SE、PM、デザイナ、QAエンジニア 等）
- 同じ会社に所属していないこと
一旦決めて、内向/外向の人数比とスクラム前知識のチーム合計値で微調整した。
この結果、6チームとも内向/外向のバランスや前知識の合計値がほぼ均等になった。
⇒ランダムに座った初期より、ずっと良い組織体に変わった
【学び】
- よりよい組織とするにはどうすればよいか、当事者で話し合うことの重要性
- 部分最適に走らない、全体最適を取るとはどういうことか（という理解）
アジャイルな組織が取るべき「連携」
自分が説明するときにも是非使いたい位、判りやすい動画。日本語の字幕がつけられます。
特に第3走者がバトンを渡すために何をしているかの説明部分が理解しやすいです。
【学び】
- 己が責任範囲や功績に囚われてはならず、チームの成功に向くべきことの重要性を説いている
- そのためには、組織はより簡素に、役割はより曖昧であるべきと説いている
アジャイルな組織に必要な「学習」
- 「知識創造」とは「悩み・学び・造る」という一連のプロセスを指す
- 知らないスキルに挑むことは危険。出来るまでに時間がかかったり、品質不良が起きたりする
- アジャイルな組織は「反復」と「インクリメンタル」を繰り返す
- 「反復」とは同じことを繰り返すこと
- 「インクリメンタル」とは年輪の様にどんどん嵩を増していくこと
- アジャイルはインクリメンタルなイテレーションの反復である
- このために、「学習」が必要なのだ
モブプログラミングのすすめ
- ある（素晴らしい）チームの1日を撮影した動画である
- 動画のポイントは、最初の一時間は技術的な学びを得ることに集中している点だ
- つまり、モブプログラミングが知識創造（悩み・学びの部分）を効果的に解消する手法であることを示している
【その他】
- ペアプログラミングと比べて人数に遊びがある点でも優れている
- 一人が抜けても作業が止まらない
- 何なら「ソロワーク」といって交代で抜けられるルールがある
- 自分の手際を他の人に見られることを恐れるケースがあるが、杞憂なので飛び込んだ方が良い
- おすすめは、間違いに気づいても30秒くらい待ってあげること
ATDD（受け入れ駆動開発）のすすめ
- 従来のユーザストーリでバックログを組む考え方にも課題がある
- 教育的には扱いやすいが、実際の現場では微妙な時がある
- すべて「顧客として～」になったり、コピペになったり・・・
- Gherkinのフォーマットを用いた書き方をすると、そのままUATとして機能する素敵フォーマットになる
- ひとつのストーリー(Feature)に対して複数のシナリオで構成される
- 前提条件（Given）、発動時（When）、結果（Then）の3部で記述する
#Feature: 電子バーテンダーはビールの操作を可能である
Background:
#Given 私達のバーでは５０リットルの樽を使う
#And ３００MLのビールグラスを使う
#Scenario: ゲストはエールを飲みたがっている
#Given バーテンダーは満タンの樽を持っている
#When ゲストがエールををオーダーする
#Then バーテンダーはエールを提供する
#Scenario Outline: バーはエールの在庫を減らす為に管理する
#Given バーは満タンの樽を持っている
#When お客様が <number> 杯のエールを注文する
#Then 樽には <remaining> リットルが残っている
Examples:
| 数 | 残り |
| 1 | 49.7 |
| 3 | 49.1 |
「ユーザに見える価値」と「ユーザに見えない価値」
- 見えるユーザ価値
- 新しいフィーチャー、バグ修正、パフォーマンス改善 など
- 見えないユーザ価値
- テストカバレッジの改善、リファクタリング など
- プロダクトバックログは「見えるユーザ価値」だけを並べることが理想的
- 「見えないユーザ価値」の混入を防ぐには、いかに技術的負債を貯めないかを考える
技術的負債を貯めないために
- ボーイスカウトルール
- 後の人たちに気持ちよく使ってもらおうという精神
- 彼らは自分たちが来た時より綺麗にして帰るルールを敷いている
- ただし、山を全てきれいにするわけではない（周辺を綺麗にする）
- ひとつのバックログにもボーイスカウトルールを適用する
- 例えばログイン機能を開発したら、ログイン機能と周辺のテストコードを修正するし、リファクタリングもする
- たくさん触る機能であれば、沢山の清掃が行われる筈
- こうすることで、大々的な負債は生まれにくくなる筈
「見積もり」の価値
- 大きく二つ
- エンジニア同士の認識があっているか（方や1時間、方や10時間と言っていれば、何か抜け漏れや課題をはらんでいる）
- プロダクトオーナーが大雑把な天気予報レベルの見通しを立てることに使う
コンポーネントチームが抱える課題
- ユーザが本当に欲しいものを提供できているか、最後になるまでわからない
- この結果、道中で多数の「在庫」を抱えていることになる
プロジェクトとプロダクトの違い
- プロジェクト
- 目的、期間、予算が定義されている
- 完了したら新しいプロジェクトが始まる
- プロダクト
- モノを造ることを指す
- プロダクトが存在する限り、バックログには常にアイテムが追加され続けている
プロジェクトのデメリット
- プロジェクトが新しくなる度に体制も新しくなり、キャッチアップコストが発生する
- 契約によって責任範囲が明確になりすぎ、部分最適が発生する（Contract Game）
- アジャイルにおける契約のノウハウはagilecontracts.org参照
ストーリー分割のテクニック
- プロダクトオーナーと議論することで本当のニーズが見えてくる
- 実現可能な切り口で大きな要求のカバレッジを取ることが出来る可能性がある
- CRUDや例外処理、自動/手動などの観点を追加してみる
質疑応答タイム
役割分担や責任を曖昧にした時、個人の評価はどう考えればよいか？
- 個人評価という仕組み自体が部分最適に向いているため、考え方を変えた方が良い。
- 有名な言葉「テーブルの上からお金をどけなさい」
- モチベーション3.0がこの問題へのアプローチについて参考になるらしい
- モチベーションを下げることは難しいが、下げる要因はたくさんある
- 下げる要素を減らした方が良いと思う
フロントエンドに対する自動テストについてオススメありますか
- ツールとしてはJasmineやキューカンバー、TestCafeが挙がった
- ちゃんとDoneの定義に挙げましょう、とのこと
顧客代替として入ったSIerが顧客と揉めないためには
- 形式的な責任問題については、契約を通して回避すること
- 顧客と信頼関係を構築出来るているかがポイント
- そのためには、対話やレビューを通して、顧客の期待値を「細かく」確認すること
モブプログラミング導入のコツはありますか
- ドライバーをきちんとローテーションすることが大切
- ドライバーのスキルによってナビゲーターも伝え方を工夫すること
- 問題に気付いても30秒位見逃してから伝えることもあるそうだ
プロダクトオーナーに権限が足りなくて優先順位が動かせない場合はどうすべきか
- 何としてでも権限を持った人を連れてくる
- 部長⇒事業部長⇒本部長⇒副社長と尋ね歩いて、変えられる人を見つけたそうだ
- そして副社長にPOになってもらったらしい（3日の研修受講も受けてもらい、DailyScrumも毎日出たそうだ）
- もし副社長が現場に来られない場合は、意思決定権を引き渡す様に動くべき、とのこと