kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

スクラムマスター研修受けてきた

取り急ぎまとめ。

  • 昨日・今日の2日でスクラムマスター研修を受けてきた
  • 目的はスクラムを導入しているがイマイチうまく言っていない現在のチームの改善、人にスクラムを教わることでよりよいプロセスにできるのではないかという期待
  • 基本的に自分のキャリアのためであること、会社を説得することが面倒であること、そもそも会社が出してくれそうにないこと、また取得後数ヶ月で転職するとさすがに申し訳ないこと(今のところ具体的な転職予定はないが、申し訳無さで転職の選択肢が取りづらくなることを嫌って)私費で行った
    • 税込みで計216,000円也
  • 結論から言うと非常に良かった
    • 一番良かったのはたぶん30~50回行われた参加者とガビィ、原田氏とのQ&Aで、スクラムガイドや一般的なスクラム本で語られないところ、語られても深くは掘り下げれらないところを細かく、背景を交えつつ聞けたところ
  • 参加者のやる気も非常に高かった。AWSの公式講習を受けたことがあるが(こちらも1回2~3日、20万円ぐらいかかる)、ずっと参加者のやる気は低かった
    • 実際に体を動かしたりポスターを作るなどよりアクティブなアクションが多かったのがよかった理由の1つ
  • 参加者の背景も多様で面白かった。組み込み系企業のいわゆるテックリードのように、新しい手法・技術を指導する立場にある人、会社の資格取得推奨制度をきっかけに来ている人(AWSの資格コンプリーター!)、技術コンサルをされている社長さんで、コンサル先でスクラムを指導できるように来た人など
    • 女性の参加者は全体の1/6~1/5ぐらいに見えた(6人チームに平均1人いた感じ)。比較的ソフトウェアエンジニアリングの世界より女性比率が多いように感じたが、講師が女性であるため参加しやすかったのかも
    • 年齢層も幅広く20代から40代までいた
  • たくさん勘違いや心得違いも見つかった。ごく単純な誤解から、背景を理解せず字面だけを読んだ結果真意を理解していないケースまで
  • 基本的に引きこもり・出不精なので、1日目はすごく緊張した。同じチームでやった2日目になるとだいぶお互いの人柄の理解が進んで話がしやすくなった
  • 1日目も2日目も無茶苦茶疲れた。頭いっぱいでへとへとになって自宅に返った感じ。自分は参加者の中では比較的長くスクラム(あるいはスクラムのようなもの)をしていたほうで、キーワードだけは比較的知っている方だったのにそれほど負荷が高かったので、よりスクラムに親しんでいない人はもっと大変だったかも

以下取ったメモから順不同で書き出す

  • 絵を沢山書こう
  • リファクタリングはストーリー(タスク消化)の一部。タスクと分離しない。恒常的なリファクタリングの時間をタスク見積もりに含める。恒常的にリファクタリングをする
  • 大規模チームでも編成できる。車のファームウェアのチームなどは数百人単位
  • walking skeleton
  • リモートスクラムを最初からやるのは難しい。合宿あるいはonboardingで最初しばらく一緒に仕事をすると成功しやすい
  • output ではなく outcome(機能数より具体的な成果)
  • chaos reportによると80%の機能はほとんど使われていない
  • チームがこなれてくるとスクラムマスターはお互いのタスクを交換して苦手なタスクをやらせる
    • 一時的にベロシティが下がることを許容する。しかしその後よりチームは強くなる
  • 弁当が美味い
  • スクラムマスターはポストイットが基本、jiraなどのツールを最初から使うとツールに踊らされる
  • スクラムマスターはあくまでコーチ的。開発メンバーに指示をせず、解決策も直接提示しない
  • 不要だと判断された機能はきちんと削除する
  • スクラムは経験主義をバックグラウンドとしている
    • 経験主義については個人の経験に基づいての判断ではないことに注意。ここはもうちょっと読んで理解したほうがよいかも
  • CIは重要。完成の定義をストーリーごとにクリアするにはCIで自動化しないと現実的ではない
    • 一方でCIに関するタスクをそのままPBIにしないこと
  • アーキテクチャの改善やサーバ・環境の用意、ホワイトボード・付箋・部屋・PCの用意などはスクラムで規定されていない。それらはスプリント0として扱うような方式もあるが、原田さんはあまり推奨していない。あくまでスクラム開始前に用意しておくこと。
  • 未完了は再見積もりをしてバックログに戻す(つまり未完了になったタスクのベロシティは行ってしまうと失われることになる)
  • スクラムマスターはドミナントにならないよう、必要であれば会議を意図的に欠席したりincognitoしたりする
  • 特に初心者のスクラムマスターは開発メンバーと兼任するべきではない
    • 最初のX日(1週間だっけ?)はチームを観察する、よく観察する
  • やる気のないメンバー、スクラムに反対するメンバーなどに対する手法は基本的にスクラムは規定しない
    • それらはスクラムの外側で対処するべき問題だが、やる気のないメンバーはスプリントごとのデモで自身を取り戻させることができるかもしれない
    • プロダクトオーナーが協力的でない場合は、開発メンバーはビーチに繰り出す
      • 不要な機能を作ることはむしろ害悪。削除に追加でコストがかかる
      • プロダクトオーナーがPBを持ってくる来る時に備えてビーチに繰り出し英気を養うのが開発チームの最善
    • スクラムの反対するメンバー(デイリースクラムに参加しない、など)はチームから一時的に取り除くなどの対処を取る
  • 上にも関係するが、あくまでスクラムはプロダクトマネージメントのフレームワークであり、開発で発生する問題や意思決定すべてに関する回答リスト・規定ではない
  • プロジェクトマネージメントではなくプロダクトマネージメント
  • トヨタの片山さんいわく、イテレーション(繰り返し)ではなく改善のサイクル
  • スクラムマスターとしてはチームに干渉しすぎない。自分たちで問題を発見させ、答えを聞かれたら5 whyメソッドを使って自身に考えてもらう
  • 見積もりがあんまり大変なので、最初はS, M, L, XLの4つ程度に分ける
    • それぞれSP3, 5, 8, 13に割り当てる うまくいくチームがある程度パフォーマンスを出すまで3ヶ月(原田さんのいうある程度のパフォーマンスってどのレベルのイメージだろう?)
  • 2,3ヶ月ごとに2,3名入れ替わるようなチームは安定度が足りない
  • 完成の定義はすべてのPBIに適用される汎用的なもの。acceptance criteriaはPBIごとのもの
  • Goalはステークホルダーからわかることが重要
  • CXOがスクラムに不安を感じている場合は、とりあえずミニマムで試してみることが重要
    • 一方でスクラムが成果を出すまで一定の期間が必要なので、スプリントごとのデモでステークホルダーや開発メンバー自身に手応えを掴んでもらわないと続けにくそう。
  • 優秀なスクラムマスターは日本人的シーンで場が凍っても待つ。いくらでも待つ
    • たぶんそこで待たないとメンバーは責任感を持たず、自主的に動かないからだと思う
  • 報酬制度を個々人でやるのは危険

講義中のメモ

iot企業ハードウェアチームとの連携 絵をたくさん書く

先行しているプロダクト、リファクタリングが必要。 プロダクト要求を進められない。

手分けしやすい、スケールしやすい、 なんでわけるの? PM以内の大丈夫? 大規模チーム? スケールスクラム 早めに手に入る。 要求分析 今は発注側がしんどい スクラムのメインフィールドはイノベーション イノベーションは外注できない

walking skeleton

scrum of scrum

遠隔地は最初からは難しい、一度一緒に飯を食べて、しばらく仕事をすると、リモートにしても成功しやすい。

outputではなくoutcome chaos report

機能数より成果 最初からチームで機能横断的である必要はない、レビューを繰り返すとフルスタックチームになる。

旧来のチーム、前職のようなチームではどうする? スクラム部署を小さく作り始める。デンソーの例

スクラムマスターはいつかけしかける、自分の苦手なタスクをする。

挨拶、ボールゲームで推測の難しさ、 スクラムイベント、うまい弁当、アジャイル宣言

リスクに対するテクニック、ウォーキングスケルトン 細かく作る。 シンプルなケースを作る。 80%の人を救うケースを作る、それがウォーキングスケルトン。

そもそもの問題が見えてない、マネージャーがこない?部屋がコンフリクト?

プロダクトバックログ、あまり長過ぎると管理が大変。 せいぜい100個が上限 でもの重要性

リファインメントはスプリントの10% 2週間でクソみたいなものを出すのは大事。 工数感を共有できるから。

スクラムマスターはポストイットでマスターする。

経験主義は科学分野から

POの最大の価値はプロダクトバックログ

リファクタリングをプロダクトバックログに入れろ、普段のタスクでリファクタリングしろ

機能は削除しろ。

デザイナーのためのCIを回して、積極的に参加してもらう。 チームに参加してもらう。 CIがキモ

セキュリティアーキテクチャ設計書に連絡先を書いてこちらです、にしておく

SIヤーではお客様はプロダクトオーナーではない。プロダクトオーナーは社内で建てる。 お客様はステークホルダーに過ぎない。

featureフラグでdoneにする。 デプロイは開発が任意。

プロダクトバックログには誰でも突っ込める。 優先順位を入れ替えられるのはPOだけ。

二日目

未完了は再見積もりしてバックログに戻す

デイリースクラムはマスターに報告しがちなので、マスターは隠れるなど メールが来る、登録する、日本語と英語がある、50問か30問かわからない、4択、制限時間は1時間、二回受けて2回とも落ちた人は居ない。72%で合格

ドラッカーもdone is better than doing

特に初心者のスクラムマスターは開発メンバーとも兼任するべきでない。 プロダクトバックログはvalidate 開発チームはバックログ通りに作っていることを保証するべき イテレーション、繰り返しではなく改善のサイクル、トヨタの片山さん曰く

優秀なスクラムマスターは待つ。気まずくても待つ。

スクラムマスターとしてチームに干渉し過ぎない。責任をチームに持たせるため、自ら解決させる。

    でも、そうするとスクラムマスターはやることなくない?

プロダクトオーナーが休み、病気は代理を立てる。

ビーチに行っていい?

どこまでやるんだっけ、はプロダクトオーナーと相談

3,5,8,13をSMLXLに割り当てる

high priorityかつXLは潰す。

環境構築のような機能に直結しないタスクはどうなる?

スクラムはプロジェクトマネジメントの手法ではなくプロダクトマネジメントの手法

上手く立ち上がる3/2のチームがある程度パフォーマンスが出るまで3ヶ月ぐらい。 二、三ヶ月ごとに2,3名入れ替えるのは安定度が足りない。

product ownerはend targetを決める。

今、definition of doneは完了の定義ではなく完成の定義という訳語にして曖昧さをなくした。

完成の定義は、汎用的なもの。 acceptance criteria はPBIごとのもの。

サーバの用意やインスタンスの用意はスプリント外で事前に用意する。

Goalはstake holderからわかることが重要

リファインメントはミーティングを短くする

CXOの不安を解消するため、試してみる。

試作品でもwalking skeletonを作る。 ソフトウェアでハードウェアがきちんと動いていることをテストするようにすれば、すごく高速に設計できる。 あとシミュレータをガチガチに作る。 スプリントを回すため、

何がやりたいと聞く。 報酬制度は個々人でやるのは危険

5 whyはガビーもやるテクニック

これはと思ったら、病院へ