2019/05/23-24 at 株式会社アトラクタ
- 英語 + 翻訳無線機 + 日本人のスクラムトレーナ
- 3-5 年経験の人が 3-4 人、興味があって 1-2 冊本を読んだって人が 15 人程度、全く知らないという人が 15 人程度
- 平均年齢はおそらく 35 くらいだったのではないだろうか
- 5 人テーブル x 8、ワークショップ多め、質疑応答多め
あんまノートとってないので...
->は僕の考え/意見
- スクラムってのは早くてたくさんリリースするものではなくて、why? をたくさん考えることだよ
- output ではなく outcome というフレーズが繰り返された
- delivery より discovery というフレーズも
- 多く早く作ることを重視してはならない、ソフトウェアは課題を解決するために作るので、正しく作らなければならない
- 6-7 割は使われないという報告もあるので、使われるものを作ろう -> 緑本の冒頭にもあるよね
- どかんと作るのではなくて、小さく動くことでまずユーザを得るんだよ
- 同じタイミングで動かない巨大なシステムではなくて、動く小さなシステムを見せることが大事だよ
別に勝ち負け判定はなし、アイスブレイク的な
- WF の良いところは、発注に振り回されない点だ
- WF の良いところは、一度頼んだらあとが楽な点だ
- -> WF は発注に振り回されないっていうけど、あとで変更ができないから念のため巨大に発注する思想なので、むしろスタートから振り回されているのでは
多かったものとか、印象に残ったものとか
- フルスタックメンバーを揃えないとスクラムってできないと思うんですけど
- 講師: そんなのは無理だし、そうではない、チームとしてフルスタックになれば良い
- そんなころころやることを変えたら怒られないのか
- 講師: やることが変わることや、決定があとになることはそんなに怒られない（講師の実体験）
- 講師: ただし、いつ決定するかを不明にしてはいけない、それは怒られる
- リーダーやってるけど、リーダーやっちゃいけないってので回るのか信じられない、命令するのが絶対楽だし、される方もその方が楽なはず
- 休憩時トークなので講師の回答なし
- 私が sm になったとして、devs は外注なんですけど、どうしたら
- 講師: イノベーションを起こすためのプロセスですよ、イノベーション外注してるんですか？
- （僕の感想）作ったものを作り足したり作り直すことを恐れている人が異様に多い
- 一度仕上げたものに修正を入れるなんて！的な
- 今思えば、自動テストの発想がないんだろう
- （僕の感想）同じく、作ったものが軌道修正によってリリースされない場合があることも信じられないという空気
- 講師: とはいえカオスレポートの示す通り、リリース = 使われるではないんだよ
- 講師: 作った物ではなく経験に価値を見出してみよう
- SM と PO って兼任して良いの？
- 講師: だめです、責務が違うので絶対に自分とコンフリクトします
- -> どっかの本でもよく見る話で、これは同意見
- 講師: 本当は「片方が倒れたので」とか、ちゃんとスクラムを理解していて目的に沿ってやれるなら一時的にはあり ただしこの程度の質問をしてくる奴には「だめだ」と返すことにしている
- スクラムやるのに一番良いツールって何ですか？
- 講師: 色々あるけど、個人的にはアナログです ただ例えば遠隔とかもあるので、それ以外は目的に応じて
- 講師: ただしこの程度（課題背景とか添えずに）の質問をしてくる奴には「アナログでできるようになるまでアナログ」と返すことにしている
- デモの時に、PO が正しいかを確認するの？ 何に基づいて？
- 講師: po のチェックは validate, ユーザに価値があるかの検証
- 講師: devs のチェックは velify, 要求通りかの検証
- -> 英単語の意味を考えるとわかりやすい
- うちハードなんですけど、デモとか仮説検証ってどうすれば
- 講師: ソフトが動いていることをテストするソフトを作ってしまうと早いよ
- -> へー（あんま聞いてなかった）
- 講師: DB の準備やアカウントの準備とかはユーザの価値とは関係ないのでスプリントにいれんな
- 講師: スプリント０って呼ぶ派もアライアンスの中にあるけど、僕は嫌い、definition of done とインクリメントがないならばスプリントではないだろ派
- 自分の質問の DDD に続く... ↓
- SM になったら全ての案件においてスクラムをするべきか？
- 講師: もちろん違う、定型作業や繰り返し作業においては WF が良い場合もある
- 通訳すごかった
- 英語で喋れば日本語を吹き込み、こっちが日本語で質問をすればチャンネルを変えて英語を吹き込み
- もう２年くらい何度もやってるので、スクラム詳しいらしいw
- スクラム of スクラムの様なものでやってるけど、チーム間の sp 基準が揃わない
- 講師: 全員で全部の見積もりをやり続けると、にじり寄ってきて大体合うぞ
- リファクタリングやバグ対応の様な直接ユーザに提供する機能（価値）じゃあないものをバックログに載せるべきか
- 講師: リファクタリングの価値は？ -> 高速リリースや高品質 -> 講師: ならユーザに価値がある、載せるってことだ
- 講師: あと、PO に隠れてリファクタをやっていると、進んでいない様に見えたりする弊害があるので、ちゃんと公開してやる
- バグも？
- 講師: バグも、積んで次のスプリント以降でやると良いよ、いつ直すか決めるのも PO だよ
- 非機能要件も？
- -> って質問起票してたんだけど、リファクタリングと同様ですよねって感じ
- インクリメントは = 毎週リリースって意味？
- 講師: デプロイ可能な状態とリリースは別、よくあるのはリリースフラグみたいな新しい機能を公開するかみたいなフラグを PO が変えるパターン
- -> 納得
- DDD はドメイン外を後に決める（作る）し、優れたアーキテクトは決定を後にする（後にできる様にする）という話がある、そういうコンテキストだと毎週デモって成立するの？ definition of done は本番リリースをしなければならないの？
- 講師: デモの目的は「買うやつがいるか」を確認するのがまずあるので、それと照らす
- 講師: 紙芝居もありで、どれだけ変更に耐えられるモデルかをデモしたり、テストシナリオでデモしても良いが、価値の検証と設計の検証はわけると良い
- -> 正直咀嚼しきれなかったので、上のテキストもねじれてるかも...
- 講師: 余談だけど、先にドメイン分析を進めてモデルデモをしてから要求を聞くと、まともな要求になりやすい、いきなり本質的なモデリングのできる要求は出てこない
特に講義とかではなくフリートーク形式（ちゃんとアジェンダはあったけど必要に応じて組み替える）みたいな感じだったので、カテゴライズしづらい
気になったワードだけメモを取ってた手元のノートから復元
- デモは品質ではなくて価値を確認する場
- SM は質問に答えてはいけない
- 講師: あなたたち研修行ったって言ったら戻って絶対質問されるから、答えないで考えさせなさい
- 稼働が高い場合とかは特に求められるけど、コーチングをしなさい
- チームの課題意識と解決力がなくなります
- おわんないのでスプリントを長くしようってよくあるけど、より大きくなるのでより終わらない
- コントロールできなかったのに長くしても解決しない、逆、小さくしなさい
- ベロシティを高くしすぎることに躍起になってはいけない
- 講師: 見てきた感じだと、高いとバックログ作りと管理が雑になったり、必要ないものを作りがちになったりする
- -> oh... tci...
- 講師: あと、20sp でたり 50sp でたりするより、毎回 30sp の方が計画しやすいしデモも受け入れられやすい
- バックログリファインメントはだいたいスプリント期間の１割くらいな
- バックログは価値や機能、スプリントバックログはそれのスプリント分、スプリントバックログからタスクを作る
- -> 絵を見ると割と自明だけど、バックログアイテムとタスクは違うよ、と
- -> つまりうちのバックログってバックログリストみたいなものなんだよなー
- acceptance of criteria: 受け入れ条件、タスクの終わる条件
- -> うちはこれを done の定義って言ってる気がする
- definition of done: 完成の定義、インクリメント単位で存在する
- ちなみに数回前のスクラムガイドで完了の定義から完成の定義に変わった
- 完了だと「いわゆるオワタ」とかのニュアンスを含んでしまうので、やり切ったというニュアンスの完成に変えた
- スクラムガイド見たら
「完成」の定義みたいに強調されてた - -> 知らんかった！
- -> うちって全然スクラムのバージョンアップに追従してないよね
- devs はバックログへのバックログアイテムの追加は末尾にしかできない、並び替えは PO だけが行う
- モバイルはどうなんだろうなー...
- 現場の風景って写真をパラパラと見せてもらった中に、definition of reach というのがあった
- -> 開始の定義とでも言うのかな
- -> 箇条書きで 10 行ほどあって、一瞬見えた感じだと「全員で見積もりをやってること」とか「全員がスプリントをやり切れると思ってること」とかが入ってた
- 完成の定義は本番リリースできる状態のこと
- スプリントのゴールはリリースして解決したいことが何かということ
- po は委員会の様な合議制にしてはならない
- -> 緑本にもあったよーな
- 理解度クイズがあったが、「ドキュメントを書かないことを推奨している y/n」に yes と答えた人が一定数いた
- アジャイルソフトウェア開発宣言は動くものを優先しているだけで、ドキュメントを否定はしていないよ
- -> なんか別の本でも読んだな、これうっかりしやすいので気にしてる
- （どうでも良いことだけど）アジャイル〜〜宣言って英語と日本語で左右逆なんだなー、って
- 左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく の部分な、マジでどうでも良い
- 最後の一言で「銀の弾丸だと思っていたけど、そうでもないし、何より思っていたより大変そう」って言った人がちらほら
- hofstede-insights というサイトが面白かった
- お国柄や趣向とかが確認できるサイト
- Turn the Ship Around! という本が良い
- 潜水艦の艦長のチームビルディングの話？
- 和訳はダサいけどこれ -> 米海軍で屈指の潜水艦艦長による「最強組織」の作り方
- Punished By Rewards
- 人を動かすにはメリットとか経験になるよをアピールしてやってもらうのが良い？の流れで出た本
- 学習性無気力になりやすい（行動しても成果にならないことを学んでしまうこと）のでやめた方が良い（って言った気がする...間違ってたらあれだけど...）
- ちなみに元気な人ほどなる
ど頭にやった
- 20 人くらいでピンポン球を受け渡しなさい
- 全員触ること、ただし同時に複数人で触ってはならない（投げるとかしろ）
- どれくらいできるか見積もって、ふりかえって、というデモンストレーション
詳細はいつかやるかも知れないので割愛w
講師に英語で「いいわよ、あなたたちとっても上手ね。ウォーターフォールが。」って言われて２日間の研修が始まった...
あなたは SM です、対処を考えなさい
これは面白かった
後日: DDD（モデル）とインクリメントについて