チームで品質を考えるレビュー / team's review for quality

by TAKAKING22

Slide 1

Slide 1 text

チームで品質を考えるレビュー及部敬雄 (@TAKAKING22) Image by Merry Christmas from Pixabay

Slide 2

Slide 2 text

レビューのイメージは？質問

Slide 3

Slide 3 text

Image by Free-Photos from Pixabay

Slide 4

Slide 4 text

必要なことはわかっているけれど… Image by Free-Photos from Pixabay

Slide 5

Slide 5 text

レビューおじさん問題

Slide 6

Slide 6 text

レビューおじさん問題エンジニアとしてスキルアップしていくと、  エンジニアリーダーやテックリードを任されるするとメンバー教育や品質担保の責任が乗ってきて、  例えばレビューをする時間がどんどん増えていくエンジニアリングが好きで頑張ってきたんだけど、  スキルアップするほどコードを書く時間が減る

Slide 7

Slide 7 text

ネガティブなレビューをぶっ壊す！ Photo by Dan Burton on Unsplash

Slide 8

Slide 8 text

いきいきとしたレビュー Image by StartupStockPhotos from Pixabay

Slide 9

Slide 9 text

チームで品質を考えるレビュー及部敬雄 (@TAKAKING22) Image by Merry Christmas from Pixabay

Slide 10

Slide 10 text

@TAKAKING22 制御不能なアジャイルモンスター株式会社デンソーデジタルイノベーション室エンジニア AGILE-MONSTER.COM アジャイルコーチ及部敬雄

Slide 11

Slide 11 text

※書影は現時点のものであり、変更される可能性がありますアジャイル開発とスクラム第2版 2021年4月頃発売予定スクラムガイド2020対応最新の企業事例追加第三章の加筆よろしくお願いします!!

Slide 12

Slide 12 text

JaSST Review‘18 https://speakerdeck.com/takaking22/redefinition-of-review-number-jasst-number-jasstreview

Slide 13

Slide 13 text

TAKAKING22 Sato_ryu ごーた現在3人チーム働き方としてのモブプログラミングチームFA宣言→チーム転職 https://silver-bullet-club.github.io/ SILVER BULLET CLUB

Slide 14

Slide 14 text

チームパタン https://scrapbox.io/silverbulletclub-pattern/

Slide 15

Slide 15 text

お気軽にご相談ください！アジャイルコーチ研修、新卒研修講演、ワークショップチーム開発モブプログラミング支援その他のご相談 https://agile-monster.com/

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

モブプログラミングとはチーム全員で・同じ仕事を .. ・同じ時間に .. ・同じ場所で .. ・同じコンピューターで .. すること

Slide 18

Slide 18 text

モブプログラミングとはチーム全員で・同じ仕事を .. ・同じ時間に .. ・同じ場所で .. ・同じコンピューターで .. すること

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

リモートモブプログラミング環境 )PTUJOH 71/ "848PSLTQBDFT ։ൃϝϯόʔ 7JTVBM4UVEJP$PEF -JWF4IBSF ϓϩμΫτ

Slide 21

Slide 21 text

モブプログラミングとはチーム全員で・同じ仕事を .. ・同じ時間に .. ・同じ空間で .. ・同じ環境で .. することオフライン／オンラインに関わらず同じ空間で技術やツールの進化によって、必ずしも同じマシンでなくとも同じ環境を共有できるようになった

Slide 22

Slide 22 text

同期と分担を繰り返す常に同期している ex. アサイン、設計、キックオフ ex. レビュー、承認、引き継ぎ分担作業モブプログラミング

Slide 23

Slide 23 text

私たちのチームモブ＝チーム仕事の質や状況に応じて、分担作業とモブプロを組み合わせている

Slide 24

Slide 24 text

いつレビューをしているのかモブプログラミングはリアルタイムレビュー常に話す明示的なレビューはしなくなった

Slide 25

Slide 25 text

エクストリーム・プログラミング入門「まえがき」／ケント・ベック著コードレビューがよいのであれば、いつでもコードレビューを行う  （ペアプログラミング）テストがよいのであれば、全員がいつでもテストをして  （単体テスト）、顧客もテストを行う（機能テスト）設計がよいのであれば、設計を全員の日常の仕事の一部にする  （リファクタリング）

Slide 26

Slide 26 text

よいプラクティスを習慣化する

Slide 27

Slide 27 text

「する」から「ある」へするあるする、すべきださせる、させられるなんとなく、続いているそうなっている、できている

Slide 28

Slide 28 text

レビューを「する」からチームにレビューが「ある」へ

Slide 29

Slide 29 text

レビュー Image by Free-Photos from Pixabay

Slide 30

Slide 30 text

総合テストよくあるレビュー要件定義基本設計詳細設計実装／単体テスト結合テスト受け入れテスト

Slide 31

Slide 31 text

様々なレビューレビューの種類目的教育レビュー技術トピックを全体に共有し、底上げを図るマネージメントレビューマネジメントに必要な情報を共有し、必要な判断をしてもらうピアレビュー作成物の欠陥と改善の機会を探すプロジェクト終了後レビュー完了したプロジェクトのふりかえりを行い、将来に活かすステータスレビュー関係者で進捗を確認する参考：ピアレビュー／カール・E・ウィーガーズ

Slide 32

Slide 32 text

パーフェクトソフトウェア／ジェラルド・M・ワインバーグ著技術レビューは、「情報を何らかの目的に使えるようにするために、製品に関する情報を収集する」プロセス

Slide 33

Slide 33 text

どうやって自分たちのライフサイクルの中で必要な情報を収集するか Image by athree23 from Pixabay

Slide 34

Slide 34 text

レビューの目的？質問

Slide 35

Slide 35 text

レビューの目的品質向上バグの発見コードの均一化メンバーのスキル教育スキルトランスファー  …

Slide 36

Slide 36 text

レビュー目的の分類 Check Learning Enhance 検査学習強化・品質担保・バグの発見・テスト・（最低限の）  リファクタリング・ナレッジの共有・スキルトランスファー・メンバー教育・文化の醸成・リファクタリング・もっとよく・もっとキレイに・先行投資

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Image by Peter H from Pixabay 品質

Slide 39

Slide 39 text

https://note.com/takaking22/n/ne49e11ce3351?magazine_key=mdc7a6bb0e2b9

Slide 40

Slide 40 text

品質とは誰かにとっての価値であるワインバーグ師匠 Photo by Kira auf der Heide on Unsplash プロダクト開発そのもの！！

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

レガシーコードからの脱却／デイビット・スコット・バーンスタイン著内部品質を作り込んだ結果として、外部品質として定義される特性の実現に近づくことができる。内部品質は結果ではなく  原因であり、良いソフトウェアが備えているべきものだ。

Slide 43

Slide 43 text

外部品質に深く関わることなく内部品質を作り込むことに意味はあるのだろうかその一方で

Slide 44

Slide 44 text

プロダクト外部品質のフィードバックループ内部品質のフィードバックループ開発チームプロダクトチーム

Slide 45

Slide 45 text

内部品質偏向によるリスク作り過ぎを防ぐことができない内部品質の高いゴミを作ってしまう可能性がある

Slide 46

Slide 46 text

外部品質のフィードバックループ内部品質のフィードバックループプロダクトチーム

Slide 47

Slide 47 text

ユーザーテスト（肩越しの視線）実ユーザーがプロダクトを使っているところを見せてもらうこちらの想定通りに問題解決までたどりつけるか問題解決までがスムーズだったか

Slide 48

Slide 48 text

開発者が外部品質に深く関わることユーザーからのフィードバック、ビジネスオーナーの思考、  運用者の関心事がリアルタイムでつかめるようになるその場で作り過ぎを止めることができるシステムの“危険なスメル”を嗅ぎ分けられるようになる

Slide 49

Slide 49 text

危険なスメル（SilverBullet Club Team Pattern）

Slide 50

Slide 50 text

外部品質のフィードバックループ内部品質のフィードバックループプロダクトチームリンクする

Slide 51

Slide 51 text

Image by Karolina Grabowska from Pixabay

Slide 52

Slide 52 text

Less is more 小さなプロダクトが品質をつくるいったん作ってしまうとなかなか捨てられないので、  最初からつくらないで済むのが一番良い外部品質と内部品質の両面から優先順位を判断する

Slide 53

Slide 53 text

捨てる喜び（SilverBullet Club Team Pattern）

Slide 54

Slide 54 text

プロダクトをどうやって小さくするか必要か不要かは内部品質だけでは判断できない外部品質と内部品質の両方の情報を得ることで、  自信と説得力を持ってコードを捨てることができる

Slide 55

Slide 55 text

情報をチームに貯める Photo by Karen Vardazaryan on Unsplash

Slide 56

Slide 56 text

Slide 57

Slide 57 text

レビューおじさん問題

Slide 58

Slide 58 text

レビューおじさん問題属人化の問題情報の偏りによって仕事が偏ってしまうそのままレビューをしていても偏りはなかなか解消しない積極的に偏りを解消しにいく必要がある

Slide 59

Slide 59 text

チームに情報を混ぜる

Slide 60

Slide 60 text

チームに情報を混ぜるレビューレビュー結果の透明化ペアプログラミングモブプログラミング

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

ペアプログラミング／モブプログラミング暗黙知＝形式知にならないもの - コードの組み立て方 - ツールやIDEの使い方のコツ - テストをするときの勘所 - 問題解決の道筋の立て方暗黙知も形式知も共通体験でまとめて伝える

Slide 63

Slide 63 text

チームのベースを揃えることで次のステップへ Photo by Ricardo Gomez Angel on Unsplash

Slide 64

Slide 64 text

レビューのタイミング Photo by Andrew Seaman on Unsplash

Slide 65

Slide 65 text

Re-view 再び見る

Slide 66

Slide 66 text

実際にはFirst-view（初見）であることが多いはじめて見る場合は理解するコストが発生する非同期で他人の思考・仕事を理解することは、  自分たちが考えているよりも難しい実際のレビュー

Slide 67

Slide 67 text

強み弱みリアルタイム  モブプログラミングレビュー Re-view ・常にチームの最善を尽くす  ことができる・結果だけでなくプロセスを  評価することができる・冷静に見ることができる・全体最適を考えてフィード  バックしやすい・その場の熱によって誤った  判断をしてしまう可能性・局所最適に陥る可能性・忖度が生まれやすい  ex. イマイチだけど時間がないから… ・結果のみで読み取れない  部分を知るためには、  コミュニケーションが必要

Slide 68

Slide 68 text

Slide 69

Slide 69 text

私たちのレビュー Check Learning Enhance 検査学習強化 Re:view ・ふりかえり・普段の会話・もっとよくするには

Slide 70

Slide 70 text

レビューの時間軸を考えるリアルタイムレビューとRe:Viewを組み合わせる 0か1かの2択を迫られているわけではないので適応するレビューのタイミング

Slide 71

Slide 71 text

まとめレビューは目的のために必要な情報を収集することである小さくつくるために外部品質と内部品質の両方の情報を得るチームに情報を混ぜていくレビューの時間軸を考える

Slide 72

Slide 72 text

目的のために必要な情報を収集するのがレビュー Image by StartupStockPhotos from Pixabay

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

「する」レビューではなく自分たちの「ある」レビューへ自分たちに必要な情報は何なのか自分たちに適切な方法は何なのか実験を繰り返して自分たちのレビューをつくっていくレビューをもっと自由に

Slide 76

Slide 76 text

内部品質外部品質常にたまにモブプログラミングユーザーテスト Re:view ドッグフーディング私たちのチームのレビュー

Slide 77

Slide 77 text

偏って留まると濁ってしまう Photo by Ice Tea on Unsplash

Slide 78

Slide 78 text

集中することと偏ることは違う集中偏る選択して絞るそこしか見えていない

Slide 79

Slide 79 text

企画、開発、テスト、QA 外部品質、内部品質分担作業、モブプログラミングすべて0or1ではない分けて考えることに偏らない

Slide 80

Slide 80 text

小さくてクロスファンクショナルなチーム常に（頻繁に）行う経験主義いろんなところで聞く話は重要！？

Slide 81

Slide 81 text

レビューをもっと自由にレビューをもっといきいきと