Slide 1

Slide 1 text

プロジェクトの成功を支える ZenHub と モブプログラミング 2018.07.11 ランサーズ開発ランチ #6 招待講演 吉田慶章 @kakakakakku

Slide 2

Slide 2 text

カカカカック @kakakakakku - ブロガー 兼 アウトプット芸人 - https://kakakakakku.hatenablog.com

Slide 3

Slide 3 text

最近「リーダー関連」の登壇が多い

Slide 4

Slide 4 text

ZenHub https://www.zenhub.com/

Slide 5

Slide 5 text

ZenHub - GitHub の Issue をラップした「タスク管理ツール」 - Chrome 拡張 or Firefox 拡張 or 専用ウェブページ - $5 user / month - 他の「タスク管理ツール」と比較しても, よくできていて, 大規模でも使える - Trello - Waffle.io - Zube

Slide 6

Slide 6 text

ZenHub 用の リポジトリを用意する ( 実装は複数のリポジトリに 分散するため ) プロジェクトで取り組む MVP ごとに Epic を作る ( 1 プロジェクト : n Epic ) 全てのタスクに Epic と Milestone (スプリント) を設定する ・2018-06-15 (金) ・2018-06-29 (金) ・2018-07-13 (金)

Slide 7

Slide 7 text

Backlogs のタスクは 基本的にメンバーを 割り当てない ( 割り当てると, メンバーごとに 偏りが生まれる ) Doing には 「WIP 制限」を掛ける 各タスクは1-3日で 確実に Closed に できる粒度にする

Slide 8

Slide 8 text

優先「順位」で並べる 優先「度」と言わない Doing に入ったら 絶対に戻らず 右に進むのみ

Slide 9

Slide 9 text

フィルタを活用して 全てのタスクの状況を把握する ( 実際には 50-100 個ある ) ・Labels ・Milestones ・Assignees ・Epics Done は不要で そのまま Closed にする

Slide 10

Slide 10 text

タスクの Close は全員の前でする - デイリースクラムでタスクを Close する - 「全員の前で Close すること」に意味がある - 情報共有のため - 「右に進んだ 」という達成感 - 「Close おめでとう 」と褒め合える空気感 - Fearless Change「小さな成功」 - 「流れの速さ」をデイリースクラムで感じ取る

Slide 11

Slide 11 text

完了の定義 - 全てのタスクで 「完了の定義」を決める - 本当にタスクが完了なのか?の判断軸がブレないようにするため - 作業時間の大幅なブレ, 無駄も減る - 「終わったことになってるけど, 終わってなくない?」 - 全てのタスクに必ず「完了の定義」を含める - 単純に Markdown の List 機能を使えば OK!

Slide 12

Slide 12 text

https://blog.tinect.jp/?p=52516 先週バズった記事も 「タスクの粒度」と「完了の定義」に通ずる

Slide 13

Slide 13 text

モブプログラミング

Slide 14

Slide 14 text

とその前に - 「スウォーミング」 - 「助け合うこと」や「共同作業」のこと - 「1タスク」を「複数のメンバーで」進める文化を作る - もしかして「無理して1人1人にタスクを分割してない?」 - 「リソース効率」ではなく「フロー効率」 - 「タスクをメンバーに」ではなく「メンバーをタスクに」アサインする

Slide 15

Slide 15 text

One day in Kanban land https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

Slide 16

Slide 16 text

One day in Kanban land https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000

Slide 17

Slide 17 text

モブプログラミング - チーム全員で1個の開発に取り組む - モブプログラミングも「スウォーミング」となる - レビュープロセスがなく, その場で「合意」となる意思決定の速さがポイント - スキルセットが異なるメンバーの強みを伝播させる - 実装スキル - 設計スキル - エディタ / ショートカットなどの, テクニック

Slide 18

Slide 18 text

Getting Started with Mob Programming

Slide 19

Slide 19 text

何をモブプログラミングのネタにする? - It should be interesting(楽しそう) - Everyone should be able to contribute(貢献したい) - It should be small, but not too small(小さすぎず,小さく) - It should not have a tight deadline(タイトな期限がないこと) - It should not be overly complex or simple(簡単すぎず,難しすぎず) 僕のチームでは, ゴールが明確な「API 実装 / フロントエンド実装」などをネタにすることが多い さらに「モブリリース」という, 珍しいイベントを開催することもある

Slide 20

Slide 20 text

MDE (Mob Development Environment) - What editor/IDE to use (エディタ) - Keyboard shortcut mappings (ショートカット) - On screen code navigation (エディタに行数を表示する) - 「上!上!4行上!」は禁句で「150行目!」と言う - Version control user account (専用の GitHub アカウント) - Timer (タイマー)

Slide 21

Slide 21 text

MDE (Mob Development Environment) - What editor/IDE to use (エディタ) - Keyboard shortcut mappings (ショートカット) - On screen code navigation (エディタに行数を表示する) - 「上!上!4行上!」は禁句で「150行目!」と言う - Version control user account (専用の GitHub アカウント) - Timer (タイマー) 僕のチームだと, ドライバーは自分の慣れた環境で開発してもらう (HHKB + IntelliJ など)

Slide 22

Slide 22 text

Mob Station - Large Screen TV (巨大なディスプレイ) - Separate smaller screen for mob timer (タイマー用のディスプレイ) - Whiteboard (ホワイトボード) - Comfortable area (快適で広い場所) - Assortment of keyboards (復習の種類のキーボードを接続しておく) - などなど “Manage the noise” と書かれていて, 他のチームに迷惑を掛けない, 独立した場所が良い

Slide 23

Slide 23 text

時間配分 / 人数 - 本書だと「1時間半」から慣らしていくと書いてある - また, 新人がドライバーを担当する場合は「15分」など短くすることも重要 - ダラダラ伸びないように, 決めた時間は厳守する - メンバーは「3-8名」で, ベストは「4名」と書いてある - 「3名」だと, 1人減ると「ペアプログラミング」になってしまうので NG 僕のチームでは「ポモドーロ (25min + 5min)」でモブセッションを回している

Slide 24

Slide 24 text

プランニング (25min) レトロスペクティブ (25min) モブプログラミング (25min) x n - まず git pull から開始する - 実装をする - lint / spec を実行する - 問題なかったら git commit をする - 最後に git push をする - 拍手をする アレンジした今のフロー

Slide 25

Slide 25 text

プルリクエストを見ると メンバー全員のコミットが並ぶ →「達成感」にも繋がる サンプルとして kakakakakku 以外は画像を差し替えている

Slide 26

Slide 26 text

まとめ

Slide 27

Slide 27 text

プロジェクトの成功を支える ZenHub と モブプログラミング