2016/1/18 Regional SCRUM GATHERING® Tokyo 2016 に参加しました（一日目）

1/18,19の二日間にわたって開催された Regional SCRUM GATHERING® Tokyo 2016に参加してきました。

まずは、天気予報通りといえばその通りなのですが、おかげで新宿にたどり着いた時には午前中のセッションが終わっている（＝基調講演聞き逃した！！！）という波乱の一日目の感想です。

togetterはこちら

NexusとLeSSの概要説明、比較

最近話題の大規模Scrumフレームワークの中から
Scrumの父Ken Schwaber氏の「Nexus」と認定スクラムマスター研修の講師でお馴染みのBas Vodde氏の「LeSS」の概要とその差分についての解説のセッションでした。

資料はそのうち上がると思うので、内容はそっちを見ていただくとして、資料が公開されました
聞いてみた個人的な感想としてはNexusは依存関係の最小化にこだわったり、イベントに関しても代表者でやるイベントとチームでやるイベントをかっちり分けている印象があり、シンプルさにこだわっている感じを受けました。
一方LeSSは、通常のScrumの延長線上でありながら、大規模ゆえのチーム感の調整・協調作業ができるように最大公約数的なゆるいルールを提案している感じを受けました。

個人的な好みとしては、製薬が少なそうなLeSSの方が適用しやすい印象を受けました。

生き延びよう！強い組織になろう！ - 迷わず行けよ 行けばわかるさ

Scrumを導入して一旦うまく行ったものの、
そのままの勢いで周囲を巻き込もうとしたら煙たがられてしまった話とその後それをどうカイゼンしたかというお話。

おそらくスライドはそのうち公開されるんではないかと思います。

Scrumとかうまく行きだすと、なんかいい気になって「善意の押し売り」＋「正論で殴る」のコンボみたいな状況になって孤立してしまい、うまく行かなくなるような雰囲気を感じました。
その結果、メンバーが萎縮してしまって本当の問題が表面に現れなくなってしまっていたのかなと感じました。

ただ、体調を崩したタイミングで自分自身でふりかえりを行ったことを天気に、イケイケで勧める感じから、みんなの話を聞くスタンスに変わったことにより状況が良くなったと
やはり対話することが大切だなと、あと仲間がいると心強いなぁと感じました。

僕らのおれおれメトリクス / We metrics in our own way!

スライドはこちら僕らのおれおれメトリクス / We Metrics Our Own Way!

とあるチームに対して、どのようなメトリクスを取得し、
それをどのようにつかってチームに考えてカイゼンしてもらったかというお話。

メトリクスにはお金に関わるKPIに関するメトリクスと、チームの健康状態を測るHealthcheckのメトリクスがあり。
何かとおろそかにされがちなHealthcheckのメトリクスも大事だよということを再認識しました。

よいメトリクス＝NARRATE

NARRATEの中でも、何かと値で絶対的な評価をしがちですが、絶対値ではなく値の「傾向を見る」というところと、
「チームが見たいと思うメトリクス」という点がメトリクスを取る上での心がけとして重要に思えました。

スクラムとメトリクスとテストを活用するチームの事例

スライドはこちらScrum,Test,Metrics #sgt2016

1
2
3
4
私は最高のチームの一員であるだろうか？
最高のスクラムをできているのか？
最高の開発をできているのか？
つまり、最高のスクラム、最高の開発とは何で あるのか？を常に問い続けるチームになる必要 がある。

この一節にしびれました。
具体的なメトリクスの例は、結構過激なのもあるので、このまま全てチームに適用できないかもしれませんが、
常にすべての前提を（もっとカイゼンできないか）疑う姿勢は脱帽でした。

Technology-Driven Development

昔のスライドはこちらTechnology-Driven Development: Using Automation and Development Techniques to Grow an Agile Culture
きっと最新版も公開されるはず。

テストやデプロイ、要求の確認にツールを導入したら目に見えて効率が上がったというおはなし。
Agile2014で海外登壇＆発表されたセッションの日本語番ということで、技術要素などは若干古いらしいですが、
改善点を見つけるための計測とそれを改善し続ける取り組み、そして実際成果が出ているところは非常にすごいです。

社内でアジャイルアジャイル言ってる人が多いが、プロセスばっかりで、テクニカルな要素が全くおろそかだったことに対するアンチテーゼとしてのTechnicalDrivenという表現をしているという反骨精神的なものもアツくさすがアジャイル会のプロレス伝道師というところでした、

以下、殴り書きメモ

NexusとLeSSの概要説明、比較

Nexus

Nexus のイベント

  • プランニング

    • Scrumとほとんど同じ
    • 最初に代表者 -> 次にチーム
    • チームごとにスプリントプランニングするが、場所は一緒のところで、不明点はその都度他チームに確認する

  • デイリースクラム

    • 全体 -> チームごと

  • スプリントレビュー

    • 全チーム合同でやる
    • 全部できないかもしれない -> うまくやってね（としか書いていない）

  • レトロスペクティブ

    • 依存関係をとくていして最小化するということが繰り返し語られている

  • リファインメント

    • 1チームに割り振れる単位まで分割する

    • 依存関係を洗い出す

成果物

  • PBL

    • 全体で一つ
    • レディ
      -> 依存関係が排除されているか最小化されている -> チーム単位でPBIを完成させられないと行けない

  • Nexus PBL

    • 次のスプリントで行う分のバックログ

    統合

  • 作成物の透明性

    • 技術的負債

  • 完成の定義

    • Nexus完成の定義

    QA

    • PBL おすすめツールは
      → 数チームならアナログ

    → 全体はJira チームごとではアナログでやってます

Less

  • Less 2-8 チーム向け それ以上は Less Huge

  • LeSS Huge

  • LeSS Rules 2016/1 が最新

構造

  • 大規模なんでマネージャーいるよね

    • Undone Work
      → わざわざUndoneとかいらなくない？
      → 実際こうなってしまうので、（しかたなく？）定義している

特徴

基本的には1チームのScrumと同じ

協調と統合

  • マルチチームのミーティングなどを定義している

LeSS での役割

PO

  • 優先順位付けはかならず一人で演る
  • 明確化はユーザー・顧客・チームでやる

SM

  • プロダクト全体を意識するように働きかける→ チームないで凝り固まらないように
  • 3チームまでは兼務OK

チーム

  • フィーチャーチーム

イベント

  • 全体的なイベントが追加された

初期のプロダクトバックログリファインメント

  • 完成の定義
  • ビジョン

スプリント

スプリントプランニング

  • Nexusと同じ
    1部
    全体
2部

各チーム

マルチチームスプリントプランニング
→ 複数チームが分担を話し合いながらプランニングする

デイリースクラム

  • Scrum of Scrum
    → 週に3回程度

プロダクトバックログリファインメント

全体的な
  • クロスチームで見積もる
マルチチーム
  • 関連するチームが集まってやる（全員or関係者）
チーム
  • チームで完結することは

スプリントレビュー

  • スプリントレビューバザール
    • 複数のエリアがある大きな部屋で実施

レトロスペクティブ

  • すべてのチームを妨げているのは、全体の問題リスト？に上げる

全体のレトロスペクティブ

*

作成物

PBL

Scrumと同じ

インクリメント

Scrumと同じ
ただし、統合されていること

DoD

  • チームごとに拡張することはOK

未完了作業

  • リスク・遅延を引き起こす可能性のあるものに対してチームで議論する

まとめ

ガイドとルールのセットになっている

代表者の参加するイベント → チームのイベントの2段構え

協調と統合

Nexus と LeSS の比較

Nexus

役割、作成物 イベントルールは普遍
シンプル10ページ

LeSS

オフショアとかのコツが書いてある
全部やれとは言ってない

デイリースクラム

Nexus

依存関係の最小化！にこだわってる
ソフトウェア以外にも適用しにくい

LeSS

フィーチャーチーム
マネージャーに言及している

生き延びよう！強い組織になろう！ - 迷わず行けよ 行けばわかるさ

前回までのあらすじ

  • 上司と世界観と共有
    → 話を聞いてくれる、一緒にセミナーに出てくれる

鬼っ子

→ アジャイルがうまく行っているアピールが強すぎた
→ WF XS Agile の発生!！

結果

  • チームが見ざる言わざる聞かざる
  • 形だけのスクラム
    →ざんねんスクラム化

病気になった！

→ 一人レトロスペクティブす@病室

対立構造を作っていた要因

チームが困っているポイントが変わっていた

どうやるか→どうしたらうまくいくか

→ コミュニティから力を借りた(2名)

再始動

  • そっとチームに関与

一人でなんとかしようとしていた愚かさ

→ 先人はみんなで、チームでやれって言ってる

人生は短い

ジェフ・サザーランド

無駄なことでなく、有意義なことに人生を使おう

僕らのおれおれメトリクス / We metrics in our own way!

http://www.slideshare.net/yattom/we-metrics-our-own-way

見積もりに自信がないチーム
→バーンダウンしない

Tシャツ見積もりを使っていた
→うまくいかない

  • 変えた
    Spring1-3 Tシャツ 1wスプリント
    Sprint5- ポイント 2wスプリント

  • うまく行った
    見積もり通りに行った

  • なんでうまく行ったの？

    分析

    バックログアイテムを分析

    同じポイントでも5倍くらいの時間見積もりの差があった
    →見積もりが上手にできるようになったわけではない
    →3,5 と 8,13 で時間に差がない → うまくなってない
    →問題か？
    →別に問題ではない
    →カイゼンはできているのでOK

オーバーワークしてない？

スプリントの予実を見る（見積もり時間と実績時間）

スプリントの進捗

  • 発生したタスクと、終わったタスクをプロットしたグラフ
  • バグ、テストの分量も追加でプロット

Sprint8

  • ビジネス的な要望でやってほしいことがあった！
  • オーバーコミットでも完成出来た

傾向を見た

Sprint7まで 見積もり＞実績
Sprint8 見積もり<実績

Sprint11,13 SprintDondeできなかった
→ 見積もり＜実績

ダメな時の傾向

  • 最後にまとめてテストをして、バグがばっと出た！！！ Sprint8,Sprint11
  • 追加のタスクが多い！ Sprint13

メトリクスの使い方

→ ヘルスチェック

  • こんなの出てます、このパターンやばくない？ とSMが言う
    → チームが考えてアクションをする

メトリクス

KPI

  • お金に関わるのでみんなが奇にする

    HealthCheck

  • お金にかかわらないので、みんな疎かにしがち
  • 傾向を見なければいけない

Scrum Master

→ OK！ じゃあやってみよう！

Agile Metrics in action

良いメトリクス

  • 自然に計測できる
    →メトリクスのためにプロセスをかえない
  • 自動化
    →手間は減らそう
  • 意味がある
  • 安定している
    →傾向を見ないといけないので
  • チームに沿っている
    →チームに合わせたメトリクス、チームが必要としている
  • タイミング
    → チームが使いたいタイミングで見れるようにする
  • 見たい！
    →チームが見たいと思うものを

NARRATE! 物語！

スクラムとメトリクスとテストを活用するチームの事例

保守で4年目のプロジェクト

→ 2014まではうまくやれてなかった
→残業多い、再計画が不正確すぎる

カイゼン
1w Sprint
Scrum event is on time as possible
multi functional
‥

→ すべての活動を見えるようにする

大切にしているポリシー

→最高の開発、最高のスクラムとはなんであるかを常に問い続ける
→そのためすべての活動を疑う
→スクラムイベントも疑う
→なぜ必要なのか！

メトリクス
→予実はチームメンバーが自主的に15分単位で入れている
→レビューの品質も定量化されている

テスト

→アジャイルでテストをやるのだから、テストが別チームとか、バックログにテストとかあったらリリースできないよね？

  • Specification By Example
  • 探索的テスト

  • レビュー
    → などの高効率テストを行う

  • 誰のようきゅうを表現したテストであるかと徹底する
    → なんとなくは許さない

スプリントレビュー

  • レビューを行う人は持ち回り
    →チームのことなんだからわかるよね？

→ 全くわからない という人をなくす
→ わかってないと見積もれない！→コミットできない
→ サポートがあればできるの前に説明できるという状態があるだろう → せめてそこまでは持っていく スプリントレビューの場でそこまで持っていく

メトリクス

  • メトリクス取っていなかった→自信過剰だった

  • 不満からメトリクスを取るようになった
    → できるチーム
    → 頼まれごと多い
    → 自分の仕事できない！！！！
    → 割り込み作業をメトリクス化
    → 40%
    → 割り込み作業のおねがいテンプレ化
    → 10%になった
    → メトリクス重要！！！となった。

レビュー

  • レビュアー

    • 指摘内容を狩野モデルで素敵品質指摘が多い人はダメレビュアーとか

  • レビュイー

    • 情報共有が多すぎる人は理解が浅いとか

計画内作業と計画外作業

アドリブ

→いいアドリブと悪いアドリブ

無関心品質が0であること

新しいTryをした時に注意力を

→音楽を聞くというTryに対してどうだったか
→音楽に載ってると視野が狭くなる
→得意な作業は早くなる
→不得意な作業、注意が必要な作業はいけてない

わかったこと

  • 自分が納得したものを取り入れる
  • 活動に対してできるだけ早くフィードバックを上げるとどんどん良くなる、よくなりたいという気持ちになる。

スプリントレトロスペクティブをレトロスペクティブしていますか？

→なかなか解決できない問題がどういうふうに変化しているかを計測する

Technology-Driven Development

TDDからインスパイアされて作った言葉

TecDDの3つの目的

  • 業務効率化
  • 教育
  • コラボレーション

TecDDの経緯

  • アジャイルをやりたいけど助けてくれない？
  • Androidのプロダクトのチーム

問題点

  • アジャイルやりたいって言うけど経験者がいない
  • 業務の殆どが手作業で
  • チームメンバーが若くて業務経験が浅かった

大変だなぁだが、たぎるぜ！
→何やっても効果がある！！

具体的な話

CI/CD

  • 手作業でパフォーマンスが低い
  • 要求が曖昧で、チームが混乱している

→地ならしをしたい！！！

CI/CD以前

  • 変更要求に対する回帰テストに週 13.5時間 かかっていた
    → 週の1/3以上がこれに！！

自分のマシンでCI/CD

  • 一時間ごとにビルド
  • 毎日端末にデプロイ
    →実機でデモ＆進捗確認
    →進捗がわかる＆フィードバックが早くなる！
    → 13.5h -> 15min へ
    → 自動化にかかった時間 = 2w

TDD

なぜ？
→アンドロイドわからないから、勉強したかった
→みんなAndoroid知らない
→テストを使ってわからないところを明らかにしたかった

before TDD

  • 1 アクティビティ追加に時間がかかる

  • Android JUnit
    → テストしづらい、テストが遅い
    → mockito, roborectricを導入

After mockito, roborectric

→コンポーネント単位でテストできる様になった
→ 5日→1日になった

BDD

  • Feature creep 要求の爆発！！
  • ユースケースレベルのバグとデグレは検知できない
  • ドメインの知識が必要になった

Feature creep

  • 企画側からのやれやれ圧力に対抗する必要が出てきた

デザイナーが話す
→開発チームがBDDのSpec形式で確認
→開発＆確認
→コラボレーションが可能に

After BDD

  • Bugs -67%
  • 変更要求 -70%
  • デグレ -60%

新しく出てきた問題（内密に）

  • スコープの変更ができないという問題
    →このスコープではどうやってもできない
    →アナリストに直訴
    →アナリスト：NO 全部やって

なんでか？

  • 社風として、一回企画を通したものは死んでもやりなさい！
    → なんとかならないかと一ヶ月調整
    → 失敗
    → 偉い人に直談判
    → OK

  • TecDDとか言ってきましたが、必ずしもそれだけが解決方法ではない。

    • なんでもいいから問題が解決できればいい

Feature

  • Adroidエミュレータ遅いよね？Genimotionいいらしいよ
    →メンバーからの提案は積極的に取り入れるようにした。

  • TecDDは開発者のものではなくて、アナリストやエグゼクティブを巻き込むように活動をした。
    →プロダクトの全体像を見ながらすすめる必要がある
    →スクラムであるならばプロダクトオーナーがそれを示す必要がある。

結論

  • passionate member
  • 現場主義

Agile2016

  • アトランタでやります
  • ぜひ参加してみたらいかがでしょうか？

#＃ 質問

Technology とあえていったのは？

→ 当時Scrum偏重で、技術を疎かにしがちだったので、そこへのアンチテーゼ

ツール入れればOK?

→ No. ツールを使って、失敗して、そこから学んで進んでもらう