LeSS Study LeSS本読書会 第5回
LeSS Study LeSS本読書会 第4回
第4回に引き続き、恵比寿 Redhatさんでの開催でした。 第4章「顧客価値による組織化」を読みましたが、話が脱線して盛り上がる回で途中で終了しました。
Q : 「フレームワークを先に作りたがるエンジニア」は何故ダメとされているのか?
A: 毎スプリント顧客価値を提供するように開発するのがスクラムのやり方だとして、初期のスプリントは開発の足回りに時間を取られることが少なくありません。スプリント0で準備することもありますが、それを指した記述に感じました。私が感じている課題は、はじめにシステムの上から下まで、一通り触って作ってみることで、課題を早く出すことに価値があるのだと考えました。フレームワークをミルフィーユのように用意していると、どこかのレイヤーに課題があるときに気がつくのが遅れてしまいます。
Q : チームの大半は顧客中心のフィーチャーチーム とはどういうこと?
A: 「チームメンバーの大半はフィーチャーチームのためのメンバ」という意味ではなく、「複数あるチームの大半はフィーチャーチームで構成され、そうでないチームが少しある」という意味だととりました。リリースまでに必要な作業だがフィーチャーチームができないもろもろ(テスト、リリース判定、マニュアル作成、などなど)をとり扱う「Undoneチーム」を書籍のあとで触れているのでこのことではないかと思います。
Q : 「同一ロケーションのチーム」は時代遅れでは? リモートで効率的に働くやりかたもあるはず。
この日一番盛り上がった脱線話でした。
A1: F2F派の意見です。顔を合わせて仕事をする以上に効率の良いやり方はないのではないか? リモートワークを許容するにしても、まずは顔を合わせて自分たちが出せる最高パフォーマンスを確認し、リモートを取り入れても効率が落ちないようにするべき。そもそもチームの全員が通勤時間0秒だとしたら、それでもリモートで働くことを選ぶのか?
A2: リモート派の意見です。同一環境(全員リモート)を同一ロケーションと呼べば問題ないのでは。チームの一部がリモートだと情報格差やタバコ部屋の議論のような問題が起きてしまうが、全員リモートで環境を揃える努力をするならば、チャットなどのやり取りで議論過程が残る利点もリモートにはある。
Q : チームを長生きさせられている組織はある?
A: ずっとは難しいというのが参加者の感想でした。チームがプロダクトに紐づき、そのプロダクトが長生きするとチームも長生きする傾向があるようです。
Q : フィーチャーチームの欠点「乱雑なコード/設計につながる」
A: MVP(Minimum Viable Product)だからスピードを重視して乱雑なコードを書いたり、設計に手を抜いたり、テストを省略したりというのはやりがち。
避ける方法として下記が挙がりました。
- 重要な機能(システムの背骨)から作ることで、全体で重要なことを最初によく考える。
- Doneの定義をきちんと用意する。
- MVPであっても使い捨てでなくMVPなりのアーキテクチャを考える。
Q : フィーチャーチームの改善目標は誰が決める?
A: チームが決める。ボトムアップだけでは組織課題に対処できないのでトップ・マネジメントを巻き込むイメージ。
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者: 榎本明仁,木村卓央,高江洲睦,荒瀬中人,水野正隆,守田憲司
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
