nDiki : スクラム

2016年12月20日 (火)

第9回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会9回目。今日は第9章 プロダクトオーナー。

自分がプロダクトオーナーをしていることもあり発表担当をしました。

受け入れ条件の定義と検証

受け入れ条件が満たされていることを確認することがプロダクトオーナーの主な責任の1つにあげられています。これはスプリントレビューで行うのかなと勘違いしていたのですが、プロダクトオーナーによる受け入れ条件の検証はスプリントレビューまで待たずにスプリント実施のときに行うとあり、ここは学びになりました。スプリントレビューでデモが許されているのは完成した機能だけとのことです。

ただ CSM によるとプロダクトオーナーが忙しくスプリントレビューのタイミングになっているところも多いらしいです。

誰がプロダクトオーナーになるべきか

ネットサービス開発は商用開発にあたるので「顧客の声を代弁する社員(プロダクトマネージャーなど)がなる」に相当しますね。

その他の役割と組み合わせ

プロダクトオーナーとスクラムマスターを兼任するのはよくないという点については、それぞれ違う行動指針で動くものだからと CSM がいっていました。確かに。

プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。

プロダクトオーナーチーム

チーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。

プロダクトオーナー? プロダクトマネージャー?

勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。

勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。 CSM は(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。なるほど。

スポンサード リンク
[ 12月20日全て ]

2017年1月10日 (火)

第10回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会10回目。今日は第10章 スクラムマスター

「私は 問題を解決するためにいるわけではない。あなた方が問題を解決できるようにここにいるのだ」

チームに作業を依頼したり、仕事のやり方を指示したりすることもできない。スクラムマスターには仕事を完成させる責任はない。

スクラムマスターコーチのように振る舞いプロセスのリーダーとして支援する役割の人です。

スクラムマスターの存在はスクラムのかなり大きな特徴といえる要素だと思っています。スクラム以外の開発プロセスで同様にコーチ的な役割の人は定義されているのでしょうか。そんな特筆すべきスクラムマスターですが、期待よりかはちょっとあっさりな説明だった感じはします。

誰がスクラムマスターになる?

スクラムマスターの経験豊かな人がいる場合は別として、多くの場合は今いる人の中の誰かになってもらうことになるのでしょう。その場合は

  • ビジネスドメインの専門家の必要はないが技術的知識を理解していること
  • コーチとして質問力がある・辛抱強いこと

が良い条件のようです。

人が少ない場合はどうでしょうか。その場合は複数のチームのスクラムマスターを兼任する形が良く、そうでなければ(有能な人であれば)開発チームメンバがスクラムマスタを兼任するのが良いとのことでした。前の章でも書かれている通りスクラムマスターとプロダクトオーナーの兼任はやめた方が良いとmもあらためて述べられていました。

スクラムマスターはとても1章で全てを語れるものではない奥が深いものなのでしょうね。もし担当することになったら沢山学ぶべきことがありそうです。

[ 1月10日全て ]

2017年1月17日 (火)

第11回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会11回目。今日は第11章 開発チーム。

ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。

開発チームのスキル

開発チームは設計・開発・統合・テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。

このために

マネージャーは、今いる人たちでT型スキルのチームを作るべきである。

マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。

と書かれています。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。ただこの方法だと浅く広く学習は進むと思うのですが、 T 型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。

「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。

開発チームの構成

チーム構成の話では小さいチームの方が

としています。一方

  • チームのもつスキル
  • 議論の多様性
  • 学習

などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では

一般的には5〜9人のチームが最適とされている。

ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。

と述べられていました。そういう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。

掛け持ち

掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。

複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する

3つ以上のプロジェクトの仕事を同時に行うのは経済的ではない

とありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。そういった状況が発生するのは

多くの組織では、同時に開始するプロジェクトが多すぎる

ということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。

チームの寿命

長寿のチームはできたてのグループよりも生産性が高い

については完全同意。今までもチーム殺しをしないように意識はしてきました。特にスクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。

[ 1月17日全て ]

2017年1月22日 (日)

WIP を下げるために GTDプロジェクトリストからバックログを分ける

スクラムソフトウェア開発をしていて仕掛り(WIP)を減らすことのメリットを体感しています。そして考えてみるとプライベートを含め個人でやる事がどんどん増えてしまっている理由の一つに WIP が多すぎるのではと思えてきました。

GTD では次の行動を決めてリストに放り込み、あとはその時の状況で実行可能なものを選んでやっていきます。局所的には一番効率が良いように見えるのですが、気をつけないと WIP なプロジェクトがどんどん増えてしまいがちで、自分の場合、気がつくとあまり何もできていないなという状態になってしまいます。

Someday/Maybe リストが GTD にはあるので、すぐにやらないものはそこに入れておくという方法もあります。しかしこのリストはかなりぼんやりしたものも混ざっているので「既に ready だけれど WIP を上げないためにまだやらないプロジェクト」を一緒に入れておくのはかなり気持ち悪い。

ということでプロジェクトリストについて「(狭義のやっている/やる)プロジェクトリスト」と「バックログリスト」の2つに分けてみることにしました。タスク管理ツール Remember The Milk でバックログリストの方のタスクは拾わないようにスマートリストを修正。毎朝軽く眺めてバックログリストから今日仕掛ってもいいものをプロジェクトリストに移すようにします。

今日やり始めてみたところ前よりは集中して取り組めて捗りました。いいかも。

[ 1月22日全て ]

2017年1月24日 (火)

第12回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。

今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。

複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。

ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。

フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。

ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。

本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。

スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。

リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。

[ 1月24日全て ]

2017年1月25日 (水)

プロダクトバックログを分割詳細化した時にエピックを「残り」で残す

スクラムプロダクトバックログリファインメントの時に、上位のプロダクトバックログスプリントで完成させられるように分割詳細化していきます。

 |-- 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
[ 1月25日全て ]

2017年1月27日 (金)

「権限の7つのレベル」の訳語

Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。

  1. Tell
  2. Sell
  3. Consult
  4. Agree
  5. Advise
  6. Inquire
  7. Delegate

権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。

訳語は人によっていろいろあるようです。

1. harakachi 氏・NuWorks合同会社の場合

http://qiita.com/harakachi/items/d75461402815d76b12c5

http://nuworks.jp/ja/2016/12/09/deligationpoker/

  1. 命令する(私が彼らに決定を伝える)
  2. 説得する(私が彼らに売り込む)
  3. 相談する(彼らに相談し私が決める)
  4. 同意する(私と彼らが合意して決める)
  5. 助言する(私は助言するが彼らが決める)
  6. 尋ねる(彼らが決めた後で私が尋ねる)
  7. 委任する(私は彼らに完全に委ねる)

2. Ryuzee.com の場合

http://www.ryuzee.com/contents/blog/3669

  1. 指示する: 管理者として意思決定を行う
  2. 売り込む: 意思決定についての人々を納得させる
  3. 相談する: 決定する前に、チームからの意見を得る
  4. 同意する: チームと一緒に決定を下す 
  5. アドバイスする: チームによる意思決定に影響を及ぼす
  6. 問い合わせる: チームの決定後のフィードバックを求める
  7. 移譲する: 特に影響を及ぼさずチームに任せる

3. エッセンシャル スクラムの場合

今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。

  1. 通知
  2. 説得
  3. 相談
  4. 合意
  5. 助言
  6. 確認
  7. 移譲

しっくりきそうなもの

好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。

  1. 指示する
  2. 説得する
  3. 相談する
  4. 合意する
  5. 助言する
  6. 確認する
  7. 移譲する

こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。

[ 1月27日全て ]

2017年1月30日 (月)

これからしばらくは「プロセスではなくプロダクト」

去年の秋から何チームとかスクラムチームとして開発をするようになったこともあって「プロセス」に意識を割く割合が多い日がここしばらく続いていました。

ちょっと形になってきてプロセスの方の検査と適応はまわるようになってきたので、2月から、といわずこれからしばらくはよりプロダクトの方に意識を向けていくことにします。

今日のさえずり: デリゲーションポーカーも良さそうですがインディアンポーカーも良いものです

2017年01月30日

[ 1月30日全て ]

2017年1月31日 (火)

第13回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

  • チームを編成する
  • チームを育てる
  • 環境を合わせてなじませる
  • 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

[ 1月31日全て ]

2017年2月7日 (火)

第14回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

  • 事前にきちんと計画を作れると思うな
  • 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

[ 2月7日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 1.034649s / load averages: 0.97, 1.96, 2.16
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker