Scrum Gaiyo 2

SQiP Tutorials

Transcript

1. スクラム概要 がい よう
2. 上位下達型の組織 チーム中心の組織
3. 上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に 必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
4. 上位下達型の組織は歴史上の必然 通信手段も教育リソースも限られた中で、 いかに全体を組織として機能させるのか？ 人類はここをずっと追い求めてきた。 世代を超えて、大規模な統治をするために、 人間本来の能力以上に、統治者として のシンボルが必要になった。 権威、武力、教義、秩序、規律、報酬などで コントロールを行った。
5. https://speakerdeck.com/kawaguti/hagechabin はげちゃびん = 技術のわからない 管理者や経営層 「マリー・ アントワネット問題」 と言い換えたい昨今。
6. https://speakerdeck.com/kawaguti/hagechabin
7. https://speakerdeck.com/kawaguti/hagechabin
8. 上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に 必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
9. しかし、もし私が一つの教訓を選ぶとしたら、 他の何よりも多くの組織が失敗していると思うことは、 グループサイズです。リチャード・ハックマンの言葉を 借りれば、チームが5,6,7,8人よりも大きくなり、 10人近くになると、物事が本当に悪くなるという 証拠がたくさんあります。 基本的には、10人、あるいは11人になると、 調整のための雑務に費やす時間が増え、 実際に仕事をする時間が減っていきます。 もう1つは、人間関係の問題が発生することです。 ディナーに行って10人、11人と会話をするのは 不可能に近いですよね。 ロバート・サットン スタンフォード大学経営学部教授
10. スクラムの源流 https://www.infoq.com/presentations/The-Roots-of-Scrum/
11. https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムの源流 • チームプロセス – シリコンバレーの起業家たち • 竹内・野中 – 日本の製造業 • 世界をもっとよい場所に – 内なるビジョン • オブジェクト技術とEasel社のSmallTalkプロダクト • オブジェクト指向アーキテクチャ 設計ツールの専門家、ベンダー、顧客 • 進化生物学と複雑適応系 • プロセスと生産性の研究 • ソフトウェア生産性の研究 • 外科手術チーム(人月の神話, IBM) • 邪悪な問題、正しい解決 • ボーランド Quattro Pro プロジェクト • iRobot -サブサンプション・アーキテクチャ
12. https://agilemanifesto.org/ アジャイルマニフェスト
13. https://agilemanifesto.org/ アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 https://agilemanifesto.org/iso/ja/manifesto.html
14. https://agilemanifesto.org/principles.html アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げま す。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 https://agilemanifesto.org/iso/ja/principles.html
15. https://agilemanifesto.org/principles.html 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 https://agilemanifesto.org/iso/ja/principles.html
16. https://kawaguti.hateblo.jp/entry/20110213/1297531229 私たちはすぐに、 それぞれ推奨しているもの同士が とても似通っているのは偶然ではない、 という結論に至った。 そこには何か根底に流れる共通性があり、 それが何であるかを 見つける必要があると思われた。 なぜなら、日々や分単位のプロジェクトの進め方には、 食い違っている点があり、まだ解消していなかったからだ。 このような食い違いがあるにもかかわらず、 私たちには「私たち以外の人々とは違う」と言える、 とても強い共通性が存在した。
17. スクラム、 リーンは 日本の製造業から 影響を受けている
18. https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長 2002 • 私たちが一番重視するのは、実際に実践し、 行動すること アジャイル原則#1 • わかっていないことはたくさんある。だから 「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に 直面して、もう一度やり直し、2回目の試行で また別の失敗に気づく。そしてもう一度やり 直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの 実践と知識に至る。アジャイル原則#3
19. 竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、 順に次の工程の部署に引き渡される • Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。 https://www.infoq.com/presentations/The-Roots-of-Scrum/
20. コマンド＆コントロールを打ち破る • 旧来の企業では、戦略は中央で作られる • それぞれの現場で、創発的な戦略が自己 組織される • 分散化された認知とアクション • スクラムチームは、 自己組織化を許されなければならない • 自働的 Autonomous • 卓越的 Transcendent • 他家受粉 Cross-fertilization • チームは自らの仕事を選択する • それぞれの個人は自らの仕事を管理する • マネジメントを排除する 竹内野中 https://www.infoq.com/presentations/The-Roots-of-Scrum/
21. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 多様な観点 • 職能横断チーム (クロスファンクショナル) • スクラムチームは(すべての職能を)持つ。 プロダクトの知識、業務分析、UIデザイ ン、ソフトウェアエンジニア、品質保証 • さらに進んだスクラムではもっとステー クホルダーを巻き込む ー 経営陣、顧客、 インストール担当、サポート担当
22. https://www.infoq.com/presentations/The-Roots-of-Scrum/ プリウスプロジェクトチームは 「場」をマネジメントした • リーダーは偶然場を「見つけて」活用す ることができる • リーダーは話し合える空間を提供して 場を作れる • 会議室などの物理的な空間 • コンピュータネットワークなどの電脳空間 • 共通のゴールなどの心理的な空間 • 愛、いたわり、信頼、責任感※ が知識創造 の基礎を作る(自己組織化) • スクラムは、真実、透明性、責任感※ の上 に立つ ※Commitmentは、スクラムガイドでは 確約と訳されています。
23. プロダクト バックログ 顧客が求める機能の 優先順位付きリスト スプリントバックログ スプリント内で完成させる機能 機能をより小さなタスクに分解する 新しい機能 スプリントの 終わりにデモする 毎日15分のミーティン グを行う。 スクラムマスターは３ つの質問をする 1)昨日なにを達成しま したか？ 2)ゴールを満たすため に障害になっているの は？ 3)明日までになにをた 達成しますか？ https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムスプリントサイクル
24. トヨタウェイは 冗長性と失敗を許容する • 生物の進化のような創発的プロセスでは、 失敗が生まれる • 早めに失敗し、頻繁に失敗して、 素早く学習し、急速に進化する • 創発的なソリューションに向けた、 合理的で効果的なアプローチは、 大事故を引き起こす https://www.infoq.com/presentations/The-Roots-of-Scrum/
25. 不確実性が要求する 経験主義的プロセスコントロール • 入力 • 要件 • 技術 • チーム • 制御 • プロセス • 出力 • 漸進的にプロダクトが変化 https://www.infoq.com/presentations/The-Roots-of-Scrum/
26. 世界最初のスクラム – Easel社1993 • ガントチャート禁止 • 役職名禁止 • スクラムマスターを作る • プロダクトオーナーを作る • 自己組織化を生み出すデイリーミーティン グ • スプリントの間は外部からチームを隔離 • スプリントプランニング、スプリントレ ビュー、レトロスペクティブ • どんな技術プラクティスを使う不明だった • 初期のXPの技術プラクティスを使った https://www.infoq.com/presentations/The-Roots-of-Scrum/
27. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 • プロダクトオーナー • プロダクトの機能、リリース日と内容を定義する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に即して機能の優先順位をつける • 30日ごとに機能と優先順位を変更可能 • 仕事の結果を受け入れる/却下する • スクラムマスター • チームが機能し、生産的であるようにする • 役割や職能間で緊密に協力するようにし、障壁を取 り除く • 外部から入る邪魔からチームを守る • プロセスを守られていることを確認する。デイリー スクラム、レビュー、プランニングのミーティング に人々を招く • チーム • 職能横断的な、7±2人のメンバー • スプリントのゴールを選び、成果物の仕様を決める • スプリントのゴールを達成するために、プロジェクトのガ イドラインを守る限り、何でもやる権利がある。 • やり方と結果を自ら決める • プロダクトオーナーに成果をデモする
28. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 プロダクトオーナー • プロダクトの機能、リリース日と内容を定義する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に即して機能の優先順位をつける • 30日ごとに機能と優先順位を変更可能 • 仕事の結果を受け入れる/却下する
29. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 スクラムマスター • チームが機能し、生産的であるようにする • 役割や職能間で緊密に協力するようにし、 障害を取り除く • 外部から入る邪魔からチームを守る • プロセスを守られていることを確認する。 デイリースクラム、レビュー、プランニングの 各ミーティングに人々を招く
30. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 主要な役割(ロール)と責務 チーム (開発者) • 職能横断的な、7±2人のメンバー • スプリントゴールを選び、成果物の仕様を決める • 同ゴールを達成するため、プロジェクトのガイド ラインを守る限り、何でもやる権利がある。 • やり方と結果を自ら決める • プロダクトオーナーに成果をデモする
31. https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムを進化させる Type A, B, Cのスプリント • Type A スプリントで部分的なものしか 作れないかもしれない • Type B 徐々にオーバーラップさせる • Type C すべてを一つのチームで 自分たちのやり方を現地現物で見つめ、 自分たちで進化させていくのがスクラム。 自分で考えるメンバーを作り、守り、鍛えていく。
32. ハイキュー!! 14巻より • 烏野高校の精神的支柱であり、 守備の要(かなめ)である主将の 負傷退場の穴を埋める、 二年生のリーダー。 • スキルも経験も統率力も主将には 遠く及ばない、レギュラーでもない ことを自認しながら、チームのために 尽くした。 • 基本を思い出すこと。練習の通りに やること。全員がベストを尽くすこと。 自分で考えること。 「バタバタしない。 良いジャンプは、良い助走から。」
33. 上位下達型の組織 教育リソースが限られている場合に、 必要なトップ層を中心に教育を行い、 部下の指導を通じてユニバーサル サービスを実現した。ルールを守って 適切に。目標達成と信賞必罰によって コントロール。 チーム中心の組織 実務者によって顧客やユーザーへの サービスが行われている、組織界面に 必要なリソースを集める組織。教育リ ソースが十分に行き渡っている専門家 を現場に。マネジメントは現場を支援 するためにある。
34. https://scrumguides.org/ スクラムの定義のアップデート 『スクラムガイド』 • コミュニティの意見を採り入れて わかりにくい表現をなくしたり、 必須のルールのみを残して、 ベストプラクティスは外し、 ルールブックとして再定義 • 2020年版で主要なワードが大きく 変わったので、認定を受ける方や 最新の動向を確認したい人は 読んでみてください。
35. スクラムマスター プロダクトオーナー 開発者(たち)
36. プロダクトオーナー • プロダクトのビジョンを持ち、育てる。 • ビジョンを達成するためのロードマッ プを考え、提示する。 • 開発チームと協力して、着手可能な仕 様としてプロダクトバックログを作成 する。 • ステークホルダーやエンドユーザーと 話す。 • 予算を確保する。 • ROIが高くなるようプロダクトバック ログの優先順位をつける。
37. • 自己組織化して仕事を進める。 • 全員がプロダクトに貢献する。 • 必要な能力をチーム全体でカバーする。 • プロダクトバックログを理解し、 優先順位に従って出荷判断可能な プロダクトインクリメントを仕上げる。 • プロダクトバックログの各項目に サイズの見積もりをつける。 開発者(たち)
38. スクラムマスター • スクラムのプロセスがうまく機能する ように、あらゆる手を尽くす。 • チームの集中を妨げる妨害を排除する。 • チームの行く手を阻む障害を取り除く。 • チームに改善をそそのかす。 • チームの自己組織化を尊重する。 • プロダクトオーナーが機能していない ときは、指導する。 • 指示しないサーバントリーダー。
39. プランニング スプリント (作業時間) レビュー レトロスペ クティブ スプリント
40. プランニング • プロダクトバックログを理解する。 • バックログ項目はチームが見積もる。 • チームの実力(ベロシティ)からみて、 どこまで行けそうかを測る。 • 行けそうなところまでのバックログアイ テムを完成させるために、チームがどう 動くかを考える。 • よく考えたらダメっぽいなら、もう ちょっと減らす。
41. スプリント (作業時間) • 集中して仕事をする。 • プロダクトバックログの順番通りに 完成させる。 • やり方はチームが考え、自律して進める。 • なるべく多くのバックログアイテムを 出荷判断可能にする。 • どうやると終わるか(完成の定義)は だんだん拡張する。 • 毎日同期し、再計画する = デイリースクラム
42. レビュー • 動くソフトウェアを利害関係者に デモする。 • 利害関係者に意見をもらう。 • できなかったことがあれば報告する。 • 技術的負債について話す。 • ロードマップを俯瞰する。 • マーケットの状況を共有する。 • 追加バックログ項目があれば足す。 • この方向で進めることを合意する。
43. レトロスペ クティブ • なにをやったか話す。 • レビューでどんな意見が 返ってきたか話す。 • 技術的負債について話す。 • よかったことや反省点を話す。 • どうしたらもっとよくなるか話す。 • 困ったことがないか聞く。 • アイデアがあれば出す。
44. ToDo WIP Done プロダクト バックログ スプリント バックログ 障害リスト
45. プロダクト バックログ • 優先順位付けされた機能や対応項目のリスト。 何を提供するか(What)。 • ROIが最も高まるように優先順位付けされ、 開発チームは上から順に届ける。 • 各項目の規模は開発チームが見積もる。 • スプリントで完成した項目の規模の合計が ベロシティ。次も同じくらいいけると考える。 • 開発チームはスプリントごとに、 どうやって実現するか(How)を考え、 スプリントバックログに落とし込む。
46. ToDo WIP Done スプリント バックログ • スプリントごとに、チームが作成し たタスクリスト。 • プロダクトバックログの上位の項目 を優先順位に従って届けるための、 開発チームの作業リスト。 • 完成の定義を守る。 技術的負債を溜めない。解消する。 • チームはタスクに群がって作業し、 アグレッシブに終わらせていく。
47. 障害リスト • チームの進行を妨げる障害をリストにする。 スクラムマスターにとってのバックログ。 • デイリースクラム、レトロスペクティブ などで発見され、まずチームが解決する。 • だれにとってもオープン・正直に。 • 障害は誰のせいでもない。解決できそうな 課題だけを出すような忖度はしない。 • 障害を一歩一歩取り除いていく。 = 改善 • 解決できないときは組織の問題として 助けを求める必要があるかもしれない。
48. アジャイルな見積りと計画づくり スクラム普及の立役者の一人、 マイク・コーンのプランニングに 関する名著。 なぜ時間ではなくポイントで見積も るのか？なぜ私たちは計画に失敗す るのか？プロダクトバックログや、 プランニングポーカーに関して最も 詳しく論じられている。 スクラム ジェフ・サザーランド博士がいかに してスクラムにたどり着いたのか、 詳細に語られた一冊。ジャーナリス ト出身の息子、ＪＪサザーランドが 大きく貢献をしている。ビジネス書 としてスクラムを押さえるために重 要な一冊。野中・竹内論文にどのよ うに出会ったのかも、細かく書かれ ている。 スクラム現場ガイド スクラムアライアンスの初期の マネージングディレクターであ るケン・ルービンの包括的な スクラム解説書。分厚く、詳細 に書かれている。 エッセンシャルスクラム スクラム適用を長年行ってきた ミッチ・レイシーによる 現場で起こる問題に対応する 実戦的なガイドブック。 ScrumMaster the Book 薄い本だが、スクラムマスター の長い道のりを論じている。ま ずチームのコーチングやメンタ リングを行うこと。チーム運営 の罠はどこにあるか。チームを 越えた組織開発の必要性。