nDiki : 勉強会

2016年11月8日 (火)

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

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

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

原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。

イテレーティブとインクリメンタルの話のところでは

スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。

とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。

「3.3 予見と適応」では

コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。

アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。

WIP にまつわる話

作業者の手持ちではなく、作業の手持ちに注目せよ

は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。

「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。

勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。

スポンサード リンク
[ 11月8日全て ]

2016年11月15日 (火)

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

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

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

4.2 タイムボックス化

「締めくくりの促進」のところで

スプリント最終日を厳格なデッドラインにすると、チームは期日どおりに仕事やり遂げようと熱心に働くようになる。

とあるのですが、ここはまだまだできていない感じです。終わらなかったら次で的な空気がまだあるのでここはメリハリをつけていけるといいなと思っています。

4.4 普遍のスプリント期間

チームが今のスプリント期間で仕事を完了できないということは、スプリントの期間を長くする理由にならない。(中略) それはスクラムチームが機能不全になりかかっている兆候であり、改善する機会なのだ。

単純に駄目だったと思うだけでなく、改善につなげていくというのが大事ということですね。

またスプリント期間を固定することについて「一定したリズム」になることを利点にあげているのを読みなるほどなと思いました。リズムがあると考える負担が減り習慣化しやすくなる気がします。

5.5 ゴールを変えない

基本ゴールは変更しない方が良いのですが現実にはそうも言っていられない状況も発生します。本書ではそこについては「実利的であるべし」として状況によって柔軟にとしています。

プロダクトオーナーがスプリントゴールを変更する必要性について、経済的な観点でざっくばらんにチームと議論できているものであれば、たいていのチームはその必要性について納得してくれるので、やる気も高まっていたようだ。

やはりチームで取り組むことなので信頼関係が常に大切だと肝に銘じることにします。

[ 11月15日全て ]

2016年11月22日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会5回目。今日は第5章 要件とユーザーストーリー。

「5.3 改良し続ける」では要件の詳細化について書かれています。

いつかやるかもしれない(やらないかもしれない)要件よりも、すぐに取りかかろうとしている要件のほうが小さくて詳細化されている。必要になったときにジャストインタイムで、詳細化されていない大きな要件を小さくて詳細化された要件の集まりにするのだ。

必要な範囲で要件の詳細度を上げていくということを明確にしているのがスクラムらしいですね。ただ直近取りかかるものばかり意識していると、破棄する要件は減るかもしれないですが作ったものを捨てる(か、そうでなくても変更しなければならなくなる)こともありえるので、そのあたりの絶妙なさじ加減が必要でしょう。

このあたりが「5.5 詳細化レベル」での「ユーザーストーリーの抽象化階層」の話でフォローされている感じです。

ユーザーストーリーの作り方としては「5.9 ストーリーの収集」で「ストーリーマッピング」というテクニックが説明されています。

抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解する、というものだ。

ストーリーを時系列と優先順位の2軸で作っていくというやり方でなかなか良さそうでした。ひとまとまりのサービス/機能を作る時は試してみたいです。

[ 11月22日全て ]

2016年11月29日 (火)

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

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

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

プロダクトバックログは、優先順位の高いものほど詳細度を上げて分割していく一方で優先度の低いものはざっくりとで良いというのがポイント。現実的で良いなと思います。2回から3回分程度のストーリーを準備完了状態で抱えておくのが経験的に良いとのことでした。

一方プロダクトバックログはリストなのでこの分解ツリーが見える化されていません。このあたりがちょっと扱いにくいなと感じることはあります。アウトライナーのような形でツリーで整理しつつ、その中でプロダクトバックログアイテムとなるところのみビューとして抽出して順序付けるものがあるといいのになと思うことはあります。

グルーミング(プロダクトバックログリファインメント)については

プロダクトバックログのグルーミングは、プロダクトオーナー主導で行う共同作業だ。

と書かれていてこれは「おっと」と感じたました。関係者でのグルーミングはおざなりにしていたなと。ここは PO の責任範囲だとあらためて把握。なおグルーミングはいつ行ってもいいとありました。

開発チームは、各スプリントの作業時間の最大1割程度までをグルーミング用に確保すべきだ。

とあり結構たっぷりだよなと思うわけですが、考えてみるといわゆるウォーターフォール開発でも初期の工程に時間をかけているわけですし、特別多い割合でも無いのかなと。

複数チームでプロダクトバックログをどうするかについては、1つのプロダクトバックログからビューでチーム別のプロダクトバックログを用意するのが良いとありました。理想的には確かにそうだと思いますが、そこまでやるとすると結構ヘビー級のツールが必要になって気がしてそちらの学習・運用コストが馬鹿にならないのではという印象を受けました。

何事もできるだけシンプルにしていきたいですね。

[ 11月29日全て ]

2016年12月6日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント。

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

今日のさえずり: 昨日エア縄跳びをしたのでふくらはぎがやや筋肉痛

2016年12月06日

[ 12月6日全て ]

2016年12月13日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

[ 12月13日全て ]

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月24日 (火)

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

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

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

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

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

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

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

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

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

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

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

[ 1月24日全て ]

About Me

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

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

follow us in feedly

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

月別インデックス
Process Time: 0.056459s / load averages: 0.27, 0.41, 0.52
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker