LeSS Study LeSS本読書会 第3回
第2回に引き続き、恵比寿 Redhatさんでの開催でした。 第2章の残りが対象でしたが、今回も途中の議論が盛り上がり完走できませんでした。
Q: 設計ワークショップはいつやるのか?
A: 必要なときにやる、いつやってもよい。
設計ワークショップは第2章の実際のLeSS開発事例で紹介されていた取り組みで、複数チームが関係する開発・修正がスプリントで生じた場合、事前に設計スプリントや設計ストーリーをやることなく、スプリント計画前後で関係するメンバーが集まり短期間で設計を済ませるという取り組みです。本の例ではスプリントプランニング2の後になっていましたが、設計ワークショップによって依存ストーリーやタスクの見落としなど気がつくこともあるので前にやっても良いよという話をしました。
Q: LeSSをどうやり始めたら良いのか? 導入手順は明確に規定されているのか?
A: 特に規定されていない。やりながら学ぶ。
SAFeの開発経験がある方からの質問でした。SAFeは導入手順が細かく規定されており、その通りに従っていけば悩むことがないそうです。とはいえ手順が多くて導入コーチ無しには始められない気もするのですが…
LeSSでは導入規定は特に規定されていません。ただおすすめの導入タイミングはチームメンバが増えてしまったことで2チームに分割する必要が生じた時です。他のスケーリングフレームワークよりもオーバーヘッドになる役割やセレモニーが少なく、スクラムを自然とスケールさせられます。
いきなり大規模に始めるのではなく、まずはうまくスクラムが回せる1チームを作ってからスケールさせるのが定石と何人かの方がおっしゃっていました。
Q : LeSSはうまく行くのか?
A: うまく行くよ！
「LeSSが使えると思って勉強会をやっているのか、使えるかわからないから勉強会をやっているのかどっちか」という質問でした。 実際にLeSS経験があるのは私一人だったようですが、「うまく行くよと」お答えしました。
Q: プロダクトオーナーにいつ成果物を見せるのか? スプリントレビューまで待つ?
A: いつでも、できたらなるべく早く見せる。
スクラムでやりがちな間違いとして、チームが完了させたストーリー・アイテムをスプリントレビューまでプロダクトオーナーに見せないというものがあります。できたものは早く見せた方がフィードバックがもらえるのでどんどん見せましょう。
アンチパターンとしてスプリントレビューで初めて見せると、スプリントレビューが細かな進捗確認の場や、成果物の出来栄えチェックの場になりがちです。
Q: チームは「コードでコミュニケーションをとる」と短くかかれれているが、込められている意味が大きい。
質問ではなく感想ですが、LeSSでは全チームが全コンポーネントを触り、頻繁に統合することで互いの開発が関連することを早期に検知します。コードがコンフリクトしたり、テストが通らなくなったり、設計に食い違いが生じたりなど。問題が生じたら相手の席まで歩いていき、話し合いを行います。
頻繁に統合を行うにはブランチを切らず、マスターで開発をする癖をつける必要があります。ワントランク開発 - tuneの日記で紹介した内容ですが、多くの開発では「最高のプルリクエスト」を追い求めがちです。
Q: コンフリクトしないの?
A: 特に問題になることはない。
作業に支障をきたすほどコンフリクトするのであれば実装や設計がまずい。 テストを回し終えないと次のコミットができないルールがあるのならば、テスト時間が長いなど別の問題を抱えている可能性もある。
コンフリクトしないように事前の設計やタスク分割を頑張るのではなく、細かくマスターに修正を入れ込んでいくやり方を習得したり、テストの実行時間を短くしたりして、根本的な解決を目指す。
Q: オーバーオールレトロスペクティブとは?
A: プロダクト開発全体の課題を考える場である。
チームごとの振り返りの後に行われる、複数チーム横断でプロダクト開発全体の問題を議論する場である。
私が勘違いしていたのは
- チームの振り返りの共有会では無い。
- チームの問題のエスカレーションの場では無い。
の2点です。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
