[RSGT2017 レポート] Growing Agile Practice

こんにちは、すずしゅんです。この度、2017/01/12-13開催の Regional Scrum Gathering Tokyo 2017 に参加してきました!!こちらの記事ではセッションの様子をお伝えします。

• Regional Scrum Gathering Tokyo 2017

セッション情報

• 講演: Rachel Davies氏
• 時間: 2017/01/12 13:30 - 13:50
• Theme: チームの学びと成長 Learn And Grow By Team

セッション内容

はじめに

• UNRULYという会社で10年間XPでチームを運営している
• 今回はSCRUM/XPを経験してきたから見地からアジャイルプラクティスを成長させる方法について話します

ウォーターフォールの問題

• 問題は遅く感じること
• ソフトウェアの品質がわかるのが最後

XP/SCRUM

• 大きな分析も無い、テストもない
• ただし小さな分析やテストを行い配布を行っている
• Agileプラクティスの一つ
• それぞれ進化しているので、プラクティスは変わってきている
• XPとSCRUMの境界はなくなってきている

レトロスペクティブ

• うまくいっている、ハッピーであるかどうかを時間軸を皆で書き込む
  • X軸は時間, Y軸が気分とする
• チームダイアリーボードを行っている
  • 毎日の日報をそれぞれがボードに付箋に書き出していく
  • 振り返りのときの備忘録になる
• ファシリテータは入れ替えていく

ユーザーストーリーカード

• 有名になった“xxxとしてxxxをしたい、それはxxxという価値を生む”記載方法は今は行っていない
• カードに書くべきことは、今ではタイトルとストーリーポイントのみ
• 詳細なことはTrelloに記載している

今行っている技法

1. ペアプログラング
   • 2人のプログラマで1つのコードを書く、1日毎に交代する
   • 品質にフォーカスした技法であり、速度にフォーカスしていない技法
   • プログラマ全員がユーザストーリに関わることができる
   • あらかじめペアプロを嫌がる人は採用しない方法もある
2. モブプログラミング
   • ペアプロの発展系、3人以上で行う
   • 10-15分でドライバをローテーションする
   • 作業の重要性と複数人に関わるかどうかか判断し、モブプログラミングと、ペアプログラミングどちらかを判断する
3. レーン毎にオーナーが居る（開発者
   • 進捗ではなくプロダクトリサーチのためMTGを昼前に行っている
   • 話したい事があれば話す（5分程度）
   • 音声記録をして録音して、NYのビジネス側などのステークホルダーへ
   • 録音すると短く終わる
4. 本番リリース
   • Grafana使ってるAlertが上がれば表示される
   • Chaos Monekey
   • Feature Toggles
   • 小さい単位でリリースする
   • Live環境でのコントロールができる

アジャイルプラクティスの共有

• どんな形で良いプラクティスを普及させる事ができるか？
• アイデアをカンファレンスの場で共有する
• 色んなイベントに参加する
• うまくいった、いってない事に耳を傾ける、話す
• 業界のプラクティスを帰る事ができる
• インスピレーションを受けたら実行する
• 効果が出るまで時間がかかるとは思う

QA

• 日本のコミュニティについてどう？
  • 熱意のある人達もいる
• アナログ/デジタル多様なツールを見せてもらったらどんな基準で選ぶ？
  • ロケーションや時間帯
    • 場所が離れてるならデジタル
  • デジタルツールの方が共有しやすい
• マルチプロダクトバックログについて聞きたい
  • リサーチが済んでないものにに対して見積りをしてしまう
  • なので、チームメンバー間でリサーチを分散する
  • 現場の人間がリサーチをしてビジネスを理解する
  • ステークホルダーにリサーチを伝える
    • 価値が無かったらそのリサーチは止めなければならん
  • 4チームの計画MTG
• 開発者が行ったリサーチはどんなもの？
  • 2つの責任を負ってる
    • リアルタイムxxx
    • ダッシュボード（UI）
      • UXエンジニアと協業してワイヤーを
  • 開発者のリサーチ
    • ライブラリ選定とかは好き
    • の前にユーザー(ビジネス)の理解をしてもらいたい
• サービス業界のプラクティスについて、開発者がストーリーを作るのは素晴らしい
• MOCK(MOB?)プログラミングに興味がある、見積りはどうする？
  • 作業量は変わらない
  • ペアでもMOBでも
  • 4つのスプリントの平均をとっている
    • 時間を測ってはいない
    • マネジメントにどう説得するか
    • 信頼されていれば何をしようと問題ない
    • スクリーンを買うコストが一番問題かな
  • 皆で行うので、ストーリーA ストーリーBと流れが 非常にスムーズ
• チームメンバーに関する質問、採用時にペアプログラミング好きな人をとって、フルスペクトラムな人じゃないと成功しない？
  • 他の会社でうまく行くかどうかは、なんとも言えない
  • 開発者が同じ場所、時間にいる事これが大事
  • MOBで皆でストーリーじゃなくて1人はCSとかハイブリッドで行うアプローチも有ると思う
• レイチェルさんは開発者ですが、プログラミングしたことない人もいますが、どうしたらよい？
  • TOYOTAがあるよね、その辺のプラクティスも取り入れる必要がある
  • プログラミングの現場を見てもらうとよいのでは？
    • 何を経験して何が痛みかを経験する事が出来る

すずしゅんはこう思った

レイチェル氏も、現場のチームに合わせてプラクティスを改変していることが当たり前だけど記憶に残りました。既存のやりかたに囚われず、現場とビジネスが連携して目標達成したり、楽しく仕事をしたりできるような支援を行っていこう、と思いを新たにしました。