粕谷大輔のレビュー一覧
-
Posted by ブクログ
以前、スクラム開発を採用していたプロジェクトチームの規模（人数）が大きくなってきたとき、Scrum@Scale導入の話が上がってきました。その時に本書を購入。
Scrum@Scaleがどういうものかという説明は当然として、実際の導入事例が紹介されているので、Scrum@Scale導入時にとても参考になりそう。
前提としてスクラム開発のことを知っておく必要がありますが、第2章に「スクラムのおさらい」として簡潔にまとめられているので、問題はないと思います。スクラム開発を知っている人にとっても、この「おさらい」はチートシート的に役に立つのではないかと思います。
要所要所で図があったり、要点が箇条書きで簡潔にまとめられているところがあるなど、個人的にはかなり理想に近いテキストで、非常にわかりやすい内容だと感じました。 -
-
-
Posted by ブクログ
大規模スクラムの中でも、特にScrum@Scaleに主眼を置いた一冊。
その他の手法にも触れつつ、どういった部分に主眼を置いているのか、異なるのかといった部分が紹介されていてよかった。
著者が実際に組織に導入した例などにも触れつつ、構成する各コンポーネントの働きや協働する内容が説明されており、実際の現場に当てはめてイメージがしやすかった。
フラクタルな構造を維持するうえで、完全に官僚的な構造を排除することは難しく、必要最小限の官僚機構を導入するというのは納得感がある。
複数のチームが連動するスクラムチームの中に身を置いている中で感じていた課題を自分の中で整理するうえで、非常にいい本だった。 -
-
-
Posted by ブクログ
わかばちゃんと学ぶサーバー監視
わかばちゃんと学ぶシリーズの書籍です。
サーバー監視の入門書として読みました。
【本書で学べること・考えること】
- 監視とは？
- 監視の必要性
- 監視のトレンド（クラウド対応）
- 監視のあるある問題と対策
- 監視ツールの代表例
- 監視ツール「Mackerel」の使用例
- オブザーバビリティとは？
- オブザーバビリティの成熟度
読んでみての感想です。
内容は非常にわかりやすいです。
監視の目的、必要性、あるある問題と対策で、監視の概要を知ることができます。
また、監視のクラウド対応や監視ツールなどのトレンドを知ることもできます。
オブザーバビリティの項目では、オブザーバビリティの概要、成熟度の指標を知ることができます。
ビジネススキルがある程度あれば、監視のビジネス上での重要度も理解できると思います。
実際のツールについては、「Mackerel」の使用方法についてのみ書かれているので、使わない方は、コラム以外は読み飛ばしても良いかもしれません。
個人的には、監視の入門書としては良い本だと思いました。 -
-
Posted by ブクログ
LeSS：プロダクトバックログは一つ、プロダクトオーナーも1人。スプリントバックログはチームの数だけ必要。
Scrum@Scale：開発現場のHowの部分を担うスクラムマスターサイクル＋Whatの部分を担うプロダクトオーナーサイクル
スクラムマスターサイクルは、開発チームが複数で連携するためのやり方を定義しています。プロダクトオーナーサイクルは、複数の開発チームが連携するために、それぞれのチームに所属するプロダクトオーナーたちの仕事のやり方を定義しています。
Scrum@Scaleの主な特徴は、普通のスクラムを「拡張」している点にあります。ただし、拡張することによって複数のチームによる相互のコミュニケーションが必要になるため、チーム間のコミュニケーションに関するルールを設けています。なぜなら、チームの数や関わる人数が増えて規模が大きくなるほどコミュニケーションの複雑さは増し、やがてそれは手に負えなくなってしまうからです。
…Scrum@Scaleとは、通常の単一スクラムチームの活動にチーム間の連携のしくみを追加したもの、と言い換えることができます。
▫️スクラムオブスクラムマスターの役割
・SoSとして開催するイベント全般の開催支援・ファシリテート
・SoSとして以下に関する話し合いが確実に行われるようにする
・SoS全体として仕事の妨害になるもの（障害物）の共有や除去
・SoS全体としてのプロセスの改善
・チーム横断的な依存関係の調整
・チーフプロダクトオーナーと緊密に連携し、SoSとして統合されたインクリメントを届けることに責任を持つ
・SoSそのものの継続的な改善に責任を持つ
各チームのプロダクトオーナーは、SoSやSoSoSといった構造でひと塊りになったチームどうしの結び付きの単位で、プロダクトオーナーどうしのチームを組みます。図4.13のようなイメージです。このチームで、組織全体で一貫性を持ったプロダクトバックログを作ります。そしてチームごとにプロダクトバックログをブレークダウンして供給します。そうすることで、チームが個別のプロダクトバックログを持ちながら、組織全体においても方針がバラバラにならず、一貫した方向性を示し続けることができます。このようなプロダクトオーナーによるチームを「メタスクラム」と呼びます。
メタスクラムは、プロダクトに関する方向性を決定する場となります。したがって複数の方針決定者が横並びで決定権を持った状態で活動することはあまり好ましい状態ではありません。意見が割れた場合などに、最終的な決定権を持った人が必要です。このメタスクラムには、チーフプロダクトオーナーという最終的な意思決定者を置きます。これは、専任でも、各チームのプロダクトオーナーの誰か1人が兼務してもかまいません。
スクラムマスターサイクルとプロダクトオーナーサイクルの最初の交差点は「チームプロセス」です。スクラムガイドが定義しているスクラムの活動を軸に、Scrum@Scaleとしての組織構造を定義しています。ここからいったんスクラムマスターサイクルと、プロダクトオーナーサイクルの活動は分岐します。
プロダクトオーナーサイクルでは、組織全体の一貫性を維持し、スケールされたすべての組織が足並みをそろえるために「戦略的ビジョン」を策定し、維持します。
次に、その「戦略的ビジョン」に基づいて作成したプロダクトバックログの優先順位付けを行います(「バックログの優先順位付け」)。
プロダクトバックログは、決められた優先順位に従って整え、必要に応 じて各チーム単位に分割します(「バックログの分割とリファインメント」)。
プロダクトバックログの準備が整えば、それをいつリリースするのか「リ リースプランニング」を行います。
これらの活動を「EMS」が中心となって繰り返します。
スクラムマスターサイクルでは、日々の開発をしながらプロセスの「継続 的改善と障害の除去」を行います。
スケール化された組織では、複数チームが連携して作業にあたることと なるため、「チーム横断の調整」も欠かせません。
やがて開発したプロダクトを「デリバリ」します。
これらの活動は「EAT」が中心となって繰り返します。
活動が分岐していたプロダクトオーナーサイクルとスクラムマスターサ イクルは、プロダクトをデリバリし、そのフィードバックを得る段階で再 び合流します。ここで、それぞれの活動の次のスプリントに必要な重要な 手がかりを得ます(「プロダクトリリースとフィードバック」)。
これらのフィードバックを正しく解釈するために「メトリクスと透明性」 が重要な要素となります。
これらの両輪の活動を繰り返しながら「プロダクトインクリメント」を生み出します。
これが、Scrum@Scaleの全貌です。
▫️12のコンポーネント
・スクラムマスターサイクル
・EAT
・継続的改善と障害の除去
・チーム横断の調整
・デリバリ
・プロダクトオーナーサイクル
・EMS
・戦略的ビジョン
・バックログの優先順位付け
・バックログの分割とリファインメント
・リリースプランニング
・両サイクル共通
・チームプロセス
・メトリクスと透明性
・プロダクトリリースとフィードバック
▫️企業変革の「８つのアクセラレータ」
・危機感を醸成する
・変革を推進するチームを築く
・戦略的ビジョンを作る
・ビジョンを伝え、熱意のあるメンバーが参加する
・障害を取り除き、成果をあげる
・短期な成功を生み出す
・変化を促進する
・変化を根付かせる