第4章 より効果的なアジャイルの始まり : スクラム
読んだことがあるとふと思ったら、それはまとめ(ふりかえり)回で読んでただけだった
あー。なるほど。たしかにふりかえり回だと今後もそういうのありそう。
「三つ子の魂百まで」とはよく言ったもので、物事がどれだけ変化しようと、開発者ってやつは変わらない。
辛辣。。笑
否定できないところがめっちゃおもしろい。というか、エンジニアって別に毎年生まれているから、「最初からこういう開発をするんだよ」っていうジェネラルなソフトウェア工学教育と、現場での積み上げみたいなのがないと一向によくならないんだろうな。
シーケンシャルアプローチは官僚主義でつまずくが、アジャイルアプローチは無秩序でつまずく。
名言すぎる。。。
からの
より効果的なアジャイルのミッションの1つは、アジャイル劇場を防ぐことである。アジャイル劇場とは、チームがアジャイルという化粧でコード&フィックスを覆い隠すことを指す。
名言すぎる。。。
スクラムチームはスプリントの終わりに作業の具体的な成果をデモする
うちのチームでは、デモをすることをSMがすごく嫌って、ユーザー以外も全員ユーザーのつもりでプロダクトを触って感想を言い合う時間にしている。(進捗報告会のような雰囲気を嫌っているらしい)そのため、デモをした経験がなく、デモをしているチームのスプリントレビューの様子は気になる
デモすると相手に触ってもらう時間が減るのと、初めて使った人が使っていくとどうなるかを観測しにくくなると思いつつ、自分らのチームはデモではデモと言いつつ単に使ってもらう時もありました(逆にこちらが見せるだけの時もあるし、見せるのもやるのもある時もある)
https://scrapbox.io/files/628b793684de3b001da0c7e7.png
こんなデータあったのか。やっぱりプロダクトオーナーに悩まされているチーム多いんだなあ。そして、機能横断かつ自己管理できる開発チームの点数が意外と高くて驚いた。
たしかに
似たようなのを見た記憶が最近あるなあと思ったら、p132の大規模開発のやつだった。それに比べれば、健全なプロジェクトに平均的なプロジェクトは、近い。
毎日開催されないデイリースクラム(p44)
デイリーってなんだっけ、と思いつつ、リモートかつ学生で、ほかのやることが多くある中でスクラム開発はできるのか?いや、できない(できていない)そもそも開発自体に取り組んでいる(取り組める)人がいない。かなり通常と異なる例と思いつつ、こういった「行うのが難しい」ケースではどうするのがより良いのだろう?
一般的なスプリントの時間配分
ここのPO版とか、SM版とかがほしいなーって最近思うようになった。とくにPO版。
こういうのを読む一方で、角さんとか関さんとかはScrumちょっとなーっていう感じなのがおもしろい。
マコネルスクラム推しだなーというのが全面的に伝わる章だった。
全般的にシステマチックなのが好きですよね。見積もりにしろ、コードにしろ。
ですよねー 分かります
推奨リーダーシップアクション
検査
■スクラムの実践に関してチームにヒアリングする。スクラムのスコアカードで自分たちを採点してもらう。チームはスクラムをどれくらい効果的に実践しているだろうか。
最近自分はスクラムを実践する場面が少ないので、コーチ先にやってもらうことになるとおもうが、基本は7か6になりそう。
7-8くらいかなあ
6くらいになりそう
■本章で説明したスクラムの失敗モードについてチームの主要なメンバーと話し合い、改善すべき点を洗い出す。
これめっちゃうまくまとまっていて、最初の半年間くらいのスクラムチームはこれを基準に話し合っていくだけでも十分になりそう。
良さそう。うちのチームは改善点を洗い出す時、実際に起きていることをまず洗い出すみたいなのをやっているので、比較的スムーズにできそうな気もする
今僕の知っている限りでも山ほど出てくるが、先述の、「学生だからやることがこれだけではない」を除くようにすると、以下がでてきた
不十分なバックログのリファインメント
ササッとやって終わる感じ
開催されないレトロスペクティブ
授業が終わってからは行っていない
■チームでのスクラムマスターの割り当てについて再検討する。現在のスクラムマスターは、スクラムの失敗モードに関連する規律正しいプラクティスを含め、チームによるスクラムプラクティスの実践にうまく貢献しているだろうか。
うーん、どうなんだろうか。プラクティスの実践に貢献している感じというよりは、全体を広く見通してフローを改善する人、みたいなイメージかな
まだそこまでできていないかなーっていうチームもあれば、比較的そこに注力できているチームもあるなぁ。
どうなんだろうか…(自分がスクラムマスター)1度相談してみようと思う
適応
■チームに対してスクラムを型どおりに実践することを求める。ただし、何か別のことを行う根拠を数字で示せる場合を除く(アジャイルプロセスの変化を数値化する方法については、第19章で詳しく説明する)。
型どおりに実践することを求める、っていうのは個人的にはあまり好きじゃないけど、求めているし実際に型通りに実施している。
スコアカードに表現される部分とか、スクラムガイドにある最低限の部分はやりましょうっていうのはよくわかるのでそうかもなーっていう気持ち。ただし、スクラムガイド2020にあるすべてをスクラムガイド2020の言葉通りにやろうとすると、他のものとの重複があるし、スクラムガイドの定義の方があまりにもゆるいので重複しがちなものの扱いについては、型通りにやっていると言いにくい状況がありそう。(プロダクトゴール、北極星、KGI、OKR、Outcome Delivery、などなど)
19章が気になってくる
■スクラムマスターの能力に問題がある場合は、育成するか更迭する。
更迭w SMの能力に問題があるかないかの判断を正確に行えているかはわからないけど、うちのチームは大丈夫かなあ
なんどか更迭を考えたけど、結局実行できたことがないなー。悪影響がつよいっていうほどの場合には、実質的なSMの人が別にうごきだすっていうのがよくあるからかもしれない。JDがあってロールとして正式?に仕事をするって言うような仕事のしかただと、たしかに更迭しないといけないかもしれない。
以前話した感じだと、更迭を選ばせず育成させるためにわざと極端にしてる意見があったりした気がする