AGILE-MONSTER.COM

チームで品質を考えるレビュー

team's review for quality

チームレビュー品質
SpeakerDeck で見る →

概要

2021年1月22日（金）JaSST Hokuriku 21にて。

スライドの内容

  1. チームで品質を考えるレビュー 及部敬雄 (@TAKAKING22) Image by Merry Christmas from Pixabay
  2. レビューのイメージは？ 質問
  3. Image by Free-Photos from Pixabay
  4. 必要なことはわかっているけれど… Image by Free-Photos from Pixabay
  5. レビューおじさん問題
  6. レビューおじさん問題 エンジニアとしてスキルアップしていくと、
 エンジニアリーダーやテックリードを任される するとメンバー教育や品質担保の責任が乗ってきて、
 例えばレビューをする時間がどんどん増えていく エンジニアリングが好きで頑張ってきたんだけど、
 スキルアップするほどコードを書く時間が減る
  7. ネガティブなレビューをぶっ壊す！ Photo by Dan Burton on Unsplash
  8. いきいきとしたレビュー Image by StartupStockPhotos from Pixabay
  9. チームで品質を考えるレビュー 及部敬雄 (@TAKAKING22) Image by Merry Christmas from Pixabay
  10. @TAKAKING22 制御不能なアジャイルモンスター 株式会社デンソー デジタルイノベーション室 エンジニア AGILE-MONSTER.COM アジャイルコーチ 及部敬雄
  11. ※書影は現時点のものであり、変更される可能性があります アジャイル開発とスクラム第2版 2021年4月頃発売予定 スクラムガイド2020対応 最新の企業事例追加 第三章の加筆 よろしくお願いします!!
  12. JaSST Review‘18 https://speakerdeck.com/takaking22/redefinition-of-review-number-jasst-number-jasstreview
  13. TAKAKING22 Sato_ryu ごーた 現在3人チーム 働き方としてのモブプログラミング チームFA宣言→チーム転職 https://silver-bullet-club.github.io/ SILVER BULLET CLUB
  14. チームパタン https://scrapbox.io/silverbulletclub-pattern/
  15. お気軽にご相談ください！ アジャイルコーチ 研修、新卒研修 講演、ワークショップ チーム開発 モブプログラミング支援 その他のご相談 https://agile-monster.com/
  16. モブプログラミングとは チーム全員で ・同じ仕事を .. ・同じ時間に .. ・同じ場所で .. ・同じコンピューターで ..
  17. モブプログラミングとは チーム全員で ・同じ仕事を .. ・同じ時間に .. ・同じ場所で .. ・同じコンピューターで ..
  18. モブプログラミングとは チーム全員で ・同じ仕事を .. ・同じ時間に .. ・同じ空間で .. ・同じ環境で ..
  19. 同期と分担を繰り返す 常に同期している ex. アサイン、設計、キックオフ ex. レビュー、承認、引き継ぎ 分担作業 モブプログラミング
  20. 私たちのチーム モブ＝チーム 仕事の質や状況に応じて、 分担作業とモブプロを組み合わせている
  21. いつレビューをしているのか モブプログラミングはリアルタイムレビュー 常に話す 明示的なレビューはしなくなった
  22. エクストリーム・プログラミング入門「まえがき」／ケント・ベック著 コードレビューがよいのであれば、いつでもコードレビューを行う
 （ペアプログラミング） テストがよいのであれば、全員がいつでもテストをして
 （単体テスト）、顧客もテストを行う（機能テスト） 設計がよいのであれば、設計を全員の日常の仕事の一部にする
 （リファクタリング）
  23. よいプラクティスを習慣化する
  24. 「する」から「ある」へ する ある する、すべきだ させる、させられる なんとなく、続いている そうなっている、できている
  25. レビューを「する」から チームにレビューが「ある」へ
  26. 総合テスト よくあるレビュー 要件定義 基本設計 詳細設計 実装／単体テスト 結合テスト 受け入れテスト
  27. 様々なレビュー レビューの種類 目的 教育レビュー 技術トピックを全体に共有し、底上げを図る マネージメントレビュー マネジメントに必要な情報を共有し、必要な判断をしてもらう ピアレビュー 作成物の欠陥と改善の機会を探す プロジェクト終了後レビュー
  28. パーフェクトソフトウェア／ジェラルド・M・ワインバーグ著 技術レビューは、「情報を何らかの目的に使えるようにする ために、製品に関する情報を収集する」プロセス
  29. どうやって自分たちのライフサイクルの中で 必要な情報を収集するか Image by athree23 from Pixabay
  30. レビューの目的？ 質問
  31. レビューの目的 品質向上 バグの発見 コードの均一化 メンバーのスキル教育 スキルトランスファー
 …
  32. レビュー目的の分類 Check Learning Enhance 検査 学習 強化 ・品質担保 ・バグの発見 ・テスト
  33. レビュー目的の分類 Check Learning Enhance 検査 学習 強化 ・品質担保 ・バグの発見 ・テスト
  34. 品質とは誰かにとっての価値である ワインバーグ師匠 Photo by Kira auf der Heide on Unsplash
  35. レガシーコードからの脱却／デイビット・スコット・バーンスタイン著 内部品質を作り込んだ結果として、外部品質として定義される 特性の実現に近づくことができる。内部品質は結果ではなく
 原因であり、良いソフトウェアが備えているべきものだ。
  36. 外部品質に深く関わることなく 内部品質を作り込むことに意味はあるのだろうか その一方で
  37. プロダクト 外部品質の フィードバックループ 内部品質の フィードバックループ 開発チーム プロダクトチーム
  38. 内部品質偏向によるリスク 作り過ぎを防ぐことができない 内部品質の高いゴミを作ってしまう可能性がある
  39. 外部品質の フィードバックループ 内部品質の フィードバックループ プロダクト チーム
  40. ユーザーテスト（肩越しの視線） 実ユーザーがプロダクトを使っているところを見せてもらう こちらの想定通りに問題解決までたどりつけるか 問題解決までがスムーズだったか
  41. 開発者が外部品質に深く関わること ユーザーからのフィードバック、ビジネスオーナーの思考、
 運用者の関心事がリアルタイムでつかめるようになる その場で作り過ぎを止めることができる システムの“危険なスメル”を嗅ぎ分けられるようになる
  42. 危険なスメル（SilverBullet Club Team Pattern）
  43. 外部品質の フィードバックループ 内部品質の フィードバックループ プロダクト チーム リンクする
  44. Image by Karolina Grabowska from Pixabay
  45. Less is more 小さなプロダクトが品質をつくる いったん作ってしまうとなかなか捨てられないので、
 最初からつくらないで済むのが一番良い 外部品質と内部品質の両面から優先順位を判断する
  46. 捨てる喜び（SilverBullet Club Team Pattern）
  47. プロダクトをどうやって小さくするか 必要か不要かは内部品質だけでは判断できない 外部品質と内部品質の両方の情報を得ることで、
 自信と説得力を持ってコードを捨てることができる
  48. 情報をチームに貯める Photo by Karen Vardazaryan on Unsplash
  49. レビュー目的の分類 Check Learning Enhance 検査 学習 強化 ・品質担保 ・バグの発見 ・テスト
  50. レビューおじさん問題
  51. レビューおじさん問題 属人化の問題 情報の偏りによって仕事が偏ってしまう そのままレビューをしていても偏りはなかなか解消しない 積極的に偏りを解消しにいく必要がある
  52. チームに情報を混ぜる
  53. チームに情報を混ぜるレビュー レビュー結果の透明化 ペアプログラミング モブプログラミング
  54. ペアプログラミング／モブプログラミング 暗黙知＝形式知にならないもの - コードの組み立て方 - ツールやIDEの使い方のコツ - テストをするときの勘所 - 問題解決の道筋の立て方
  55. チームのベースを揃えることで次のステップへ Photo by Ricardo Gomez Angel on Unsplash
  56. レビューのタイミング Photo by Andrew Seaman on Unsplash
  57. 実際にはFirst-view（初見）であることが多い はじめて見る場合は理解するコストが発生する 非同期で他人の思考・仕事を理解することは、
 自分たちが考えているよりも難しい 実際のレビュー
  58. 強み 弱み リアルタイム
 モブプログラミング レビュー Re-view ・常にチームの最善を尽くす
 ことができる ・結果だけでなくプロセスを
 評価することができる
  59. 強み 弱み リアルタイム
 モブプログラミング レビュー Re-view ・常にチームの最善を尽くす
 ことができる ・結果だけでなくプロセスを
 評価することができる
  60. 私たちのレビュー Check Learning Enhance 検査 学習 強化 Re:view ・ふりかえり ・普段の会話
  61. レビューの時間軸を考える リアルタイムレビューとRe:Viewを組み合わせる 0か1かの2択を迫られているわけではないので適応する レビューのタイミング
  62. まとめ レビューは目的のために必要な情報を収集することである 小さくつくるために外部品質と内部品質の両方の情報を得る チームに情報を混ぜていく レビューの時間軸を考える
  63. 目的のために必要な情報を収集するのがレビュー Image by StartupStockPhotos from Pixabay
  64. 「する」レビューではなく自分たちの「ある」レビューへ 自分たちに必要な情報は何なのか 自分たちに適切な方法は何なのか 実験を繰り返して自分たちのレビューをつくっていく レビューをもっと自由に
  65. 内部品質 外部品質 常に たまに モブプログラミング ユーザーテスト Re:view ドッグフーディング 私たちのチームのレビュー
  66. 偏って留まると濁ってしまう Photo by Ice Tea on Unsplash
  67. 集中することと偏ることは違う 集中 偏る 選択して絞る そこしか見えていない
  68. 企画、開発、テスト、QA 外部品質、内部品質 分担作業、モブプログラミング すべて0or1ではない 分けて考えることに偏らない
  69. 小さくてクロスファンクショナルなチーム 常に（頻繁に）行う 経験主義 いろんなところで聞く話は重要！？
  70. レビューをもっと自由に レビューをもっといきいきと

サイト内を検索