スクラム勉強メモ

第1回

プロジェクト掛け持ちのチームメンバ

スイッチングコストがかかることの共通認識が必要。(0.5+0.5の仕事はできない)

スクラムマスターが指示を出す

指示が出したいならPO側の人間になるべき。
開発リーダーとして開発チームにいるべきでは?
そもそもSMの仕事を分かっているか?
スクラムマスターという名前がよくない。
レトロスペクティブで、各メンバーがあげたプロブレムに対してのTryをどんどんスクラムマスターが決めていってしまう。
スクラムマスター当番制。

POとあまり連絡が取れない

チーム内にPO代理を立てた。
POが参加してくれなくなることがある。
POもSMも「役割」なんだから、ダメなら辞める、変える。
「自分が機能すればうまくいく」ことに気づいてもらう。

「偉い」とは?

その人の発言を重要視しないといけない、ということ?
肩書?
年齢?

お勧めコミュニケーションツール

Slack チャンネル乱立問題あり

アジャイルやりたい

課題は何か?が必要。

第2回

スクラムのイベント

プランニングが時間通りに終わらない

2H予定に対して4Hかかってしまう。
かかるのは仕方がない。「かかっていること」を認識していることが重要。
プランニングを負担に感じるのがよくない。
制限時間で切るものあり。終わらなければ「それが俺たちの現状じゃん」って受け入れる。
「ふわっとした状態で初めてしまう」よりも、きっちりタスク定義やりきってから開始するほうがまだいい。
どこで苦労するか、だけの問題。

10人を超えると、他の人が何をやっているのか分からなくなる。

デイリースクラムが進捗報告だけで終わる

「問題になっていること」を何故伝えなければいけないかを理解する必要がある。
ひねり出せ。
問題がないなら、「こういう課題がありましたが、こう解決しました」でもいいからいうようにする。
「自分の中で解決できているからいいや」ではダメ。
デイリースクラムで、課題が出なかった時、昨日帰った時間を一緒に発表するようにしてた事例。それが遅い時間だと「？」みたいな。
進捗確認の場ではなく課題発見の場である。
進捗報告なくてもいいくらい。
SMに話している人がいる。開発チームに向かってしゃべる(共有する)場である。
形骸化したらつまらない。何か楽しくする工夫。
今日の技術トピック
進捗報告はRedMineとか「ツール見といて」でいいじゃん。

スプリントレビューの準備が大変

その準備が必要な作業なんだったらタスクにしておけ。
開発チームのゴールのイメージが、デモを行える状態になっていないのでは?（機能を実装すればOKみたいに）

レトロスペクティブで同じ問題が何度もあがる

何度も同じ問題が上がり、誰も解決しようとしない。
タイトルは同じでも、中身が変わっている可能性はないか?問題のポイントが変わっているとか、問題の深堀のレベルが変わっていないとか。
Actionに落ちてないことは多い。なんでもいいからActionに落とす。やってみたら、得るものがあるはずで、同じトピックでも議論の進展があるのかも。
プランニングは終わるまでやるのに、レトロスペクティブは終わるまでやらないのはなぜか?
そのトピックだけを深堀する1～2時間を作るとか。
そのチームでは解決できない問題であるという可能性。
レトロスペクティブのマンネリ化。→場所を変える。ネタを変える。匿名性にする。
「アジャイルレトロスペクティブズ」https://www.amazon.co.jp//dp/4274066983
Problemにあげた切り
KPTからYWT
Problemに対して「〇〇をがんばる」というTryにしてしまうと、またProblemになってしまう。
問題が振り返りまで持ち越されている段階でNG。SM仕事しろ事例。

その他のイベントってない?

お茶会
お菓子タイム
余裕がないと改善は行えない
ランチバックログ

第3回

コミットしたPBIを完成できないことが多い

できないことが続いて、それが普通になってしまってはいけない。
ビジネス側との信頼関係に問題が生じる。
「守れることをやる」
「期待にこたえたい」という思いがあるのはわかる。
良かれと思って頑張りすぎてしまうと、その場はいいかもしれないが、以降で正しい見積もりができなくなってしまう。
「開発側が仕事してない」「ただ遅延してるだけじゃん」って思われちゃう。

PBIの優先順位がつけられない

どれも最重要になってしまう。
それって優先順位がついてないと同じ事。それでも順位付けしてください。
具体性があるかどうかを順位(着手順)の判断材料にする。
開発のしやすさの観点で開発チームに意見聞くとか。
優先順位に納得ができない場合は?POとすり合わせ。
比較基準が決まっていない。AとBはコスト観点で比較して、BとCではデリバー観点で比較したりして。
そこの基準作りをちゃんと考えるべきではないのか。決まれば自動的に優先度判断できる。

タスクの割り込みが頻繁に発生

主にバグ
割り込み頻度、ボリュームを定量化して計画までもっていく
割り込みタスクの割合を可視化。(別の色のチケットで管理)それをPOや発生元と共有する。
「バグ」「他部署」「自己発見した作っていなかったタスク」
知らない間に割り込みをやっている(割り込みに気づいていない)のがまずい。

改善策が多すぎて消化できない

少しでもできてるならいいじゃん。ゼロなのは問題。
1回で済むものと、継続的にやらないといけないもの。区別してやる。
個数を制限して入れ替え制。
テンションが上がる改善策か、やってもテンション上がらない改善策か。
改善策と問題の解決は別の問題では?
暫定策と恒久策のバランス。
ものによってはプロダクトバックログに入れる。
全く改善策が浮かばないものは?
自分たちが解決できないものは、「制約条件」として扱うべきでは?