社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。
今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。
複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。
ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。
フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。
ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。
本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。
スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。
リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。
スクラムのプロダクトバックログリファインメントの時に、上位のプロダクトバックログはスプリントで完成させられるように分割詳細化していきます。
|-- P1 (分割詳細化済み) | |-- P1-1 | |-- P1-2 | `-- P1-3 |-- P2 (一部分割詳細化済み) | |-- P2-1 | |-- P2-2 | ... `-- P3 (未分割詳細化)
ツリーになるのだけれどどうするのが良いかなあという話になりました。大きな視点だと分割元もわかるようにしておきたいし、途中までしか分割されていないものはまだ残りがあることを忘れないようにしたい。
分割し残りがあるものは「残り」としてフラットにしてしまえばいいんじゃないということになりました。「残りプロダクトバックログアイテム」を作ればフラットなリストにしても漏れないよねと。
|-- P1-1 |-- P1-2 |-- P1-3 |-- P2-1 |-- P2-2 |-- P2-残り `-- P3
Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。
権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。
訳語は人によっていろいろあるようです。
http://qiita.com/harakachi/items/d75461402815d76b12c5
http://nuworks.jp/ja/2016/12/09/deligationpoker/
http://www.ryuzee.com/contents/blog/3669
今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。
好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。
こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。
去年の秋から何チームとかスクラムチームとして開発をするようになったこともあって「プロセス」に意識を割く割合が多い日がここしばらく続いていました。
ちょっと形になってきてプロセスの方の検査と適応はまわるようになってきたので、2月から、といわずこれからしばらくはよりプロダクトの方に意識を向けていくことにします。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。
スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。
ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。
マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。
チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。
本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。
チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。
後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。
今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について
「原則なしに上辺だけプラクティスを実行してても意味ないよ」
と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。
事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。
プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。
ということで継続的にプランニングし直していくことが大切なのだなと。
14.4 プランニングの選択肢は、最終責任時点まで変更可能にする
についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも
重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。
14.7 早めにリリース、頻繁にリリース
については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。
この章でも
この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。
と言った上で
もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。
としていました。
昨年秋から開発グループを3チームに分け、それぞれのプロダクトバックログを用意してスクラムで開発をしていました。数カ月経ちだんだんとスクラムチームとしての形ができ、また課題も見えてきたこのタイミングで3つのプロダクトバックログを1つにまとめてみることにしました。
月曜日に CSM からプロダクトバックログを1つにまとめるとう提案を受けたので、勢いでその日に1つにマージしちゃいました。3つのチームで取り組んでいることについて優先順位をつけるのはガッツが必要ですね。それぞれのチームとしては最優先のものを取り組んでいるものに対して優先順位をつけるのですから。
ツールとしては Google スプレッドシートでプロダクトバックログを作っていたので、そのまま Google スプレッド上で1つにまとめ、そのかわりにフィルタを使ってチーム別のビューも用意しました。
一昨日に1つにまとめたあと、昨日と今日と各チームのプロダクトバックログリファインメントを実施。他のチームのにあったプロダクトバックログアイテムについての興味の持ち方はチームそれぞれ。じっと概要をまず聞くチームだったり、積極的に内容を聞いてくるチームなど個性がありました。
3本のプロダクトバックログを1本にまとめることで、同時に進める開発の数を減らすべきだなということがおのずと見えてきました。今後は全チームを通してみんなで優先順位の高いものからやっていけるようにしていきたいなと思っています。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の15回目。今日は第15章 さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。
この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。
勉強会では自分たちの事業でのプロダクトは何か(例えば mixi は1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。
それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。
スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。
このあたりは続く章で説明があるのかもしれません。
今年は「人工知能とは」「機械学習とは」を繰り返し聞きました。
グーグル株式会社 佐藤一憲(@kazunori_279)氏
わかりやすくわくわくする発表でした。簡単に出来ちゃうと感じさせるトークでしたが、製品に適用していくには泥臭いトライアンドエラーとリリース後の保守が待っているのだなあというのも想像しながら聞いてました。
ハードウェアの話を聞いていると、もはや超大手の手のひらの上で学習させていくしかないのかなーと感じさせられちゃいます。
株式会社ジャストシステム 宮崎哲哉(@miya2tetsu)氏 大島教雄氏 岡美香氏
自社製品の訴求セッション。デブサミじゃなくてもという感じではありました。
ソニーデジタルネットワークアプリケーションズ株式会社 吉田万里子氏
エンジニアとしての思いと親としての思いを叶えるためにラズパイで遊んでみるという話。子供の成長についていろいろ考えていらっしゃって素敵だなと感じました。
後半にだんだん技術的に具体的な話にきちんともっていく構成も上手いなと。
グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏
準備完了なプロダクトバックログアイテムを準備完了にしていくためのサイクルやタスクをどうするかなと思っていたので参考になるかもしれないなと思いました。複雑になるので今のチームの状態でやるべきかは見極める必要がありそうですけれど。
日本マイクロソフト株式会社 千代田まどか(@chomado)氏
一つ前のセッションを見終えてからいったらもう満席でした。
TickleCode 代表 小林由憲(@yoshiii514)氏 関西Javaエンジニアの会 阪田浩一(@jyukutyo)氏
勉強会の話。
「運営に関わろう、なければ作ろう」
なりたい人に近づくといいよという話と、貢献しなよという話。
株式会社インターネットイニシアティブ 穴吹健一氏
最後は IIJ のセキュリティビジネスの話に落ち着いて終了。さすが IIJ 的な内容のトークはあまり無かったです。
株式会社ワークスアプリケーションズ 井上誠一郎氏 株式会社ノーチラス・テクノロジーズ 神林飛志 株式会社セゾン情報システムズ 小野和俊氏
お互いにレスペクト感があるなかでの軽快な対談を楽しみました。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の16回目。今日は第16章 ポートフォリオプランニング。
これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。
ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。
本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。
今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。ライフサイクル収益には利益以外にも社員満足度・顧客満足度・従業員満足度(離職率と採用コスト・回復コスト)なども考えれれる」といったことを CSPO 研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。
本書によるとポートフォリオバックログに入れる際は
コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。
とのこと。
ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。
と言い切ってます。迷ったら不採用という考えについて Joel on Software の採用面接ゲリラガイドを思い出しました。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。