目次 Nexusの概要... 2 Nexusガイドの目的... 2 Nexusの目的... 2 Nexusの背景... 2 Nexusフレームワーク... 3 Nexusのプロセスの流れ... 4 Nexus... 5 Nexusの役割... 5 Nexus 統合チーム... 5 Nexus 統合チ

Size: px

Start display at page:

Download "目次 Nexusの概要... 2 Nexusガイドの目的... 2 Nexusの目的... 2 Nexusの背景... 2 Nexusフレームワーク... 3 Nexusのプロセスの流れ... 4 Nexus... 5 Nexusの役割... 5 Nexus 統合チーム... 5 Nexus 統合チ"

みいかちとく
5 years ago
Views:

1 Nexus ガイド Nexus を使用した大規模スクラムの公式ガイド : ゲームのルール January 2018 Developed and sustained by Ken Schwaber and Scrum.org [ 日本語版 ] Japanese

2 目次 Nexusの概要... 2 Nexusガイドの目的... 2 Nexusの目的... 2 Nexusの背景... 2 Nexusフレームワーク... 3 Nexusのプロセスの流れ... 4 Nexus... 5 Nexusの役割... 5 Nexus 統合チーム... 5 Nexus 統合チームのプロダクトオーナー... 6 Nexus 統合チームのスクラムマスター... 6 Nexus 統合チームのメンバー... 6 Nexusのイベント... 7 リファインメント... 7 Nexusスプリントプランニング... 7 Nexusスプリントゴール... 8 Nexusデイリースクラム... 8 Nexusスプリントレビュー... 8 Nexusスプリントレトロスペクティブ... 9 Nexusの作成物プロダクトバックログ Nexusスプリントバックログ統合インクリメント作成物の透明性完成の定義最後に謝辞翻訳年から2018 年にかけてのNexusガイドの変更点 Page 1

3 Nexus の概要 Nexus ガイドの目的 Nexusは大規模なプロダクトやソフトウェアのデリバリーを発展および維持するためのフレームワークであるその構成要素としてスクラムを使用している本ガイドでは Nexus の定義を説明する Nexusの定義には Nexusの役割イベント作成物とそれらをまとめるルールが含まれる Nexusは Ken Schwaber と Scrum.org が開発したものである Nexusガイドはその開発者たちが執筆提供する Nexus の目的 Nexus( 名詞 ): 人々やモノの関係性やつながり Nexusは役割イベント作成物と約 3~9のスクラムチームの作業を組み合わせてまとめるルールで構成されたフレームワークである複数のスクラムチームはゴールを達成する統合インクリメントを構築するために 1つのプロダクトバックログに取り組んでいる Nexus の背景ソフトウェアのデリバリーは複雑であり開発作業を統合して動作するソフトウェアを生み出すには多くの作成物やアクティビティが必要になる完成された成果を生み出すにはこれらをうまく調整しなければいけない作業をうまく整理して並び替え依存関係を解消して成果の準備を整えなければいけない多くの開発者たちはスクラムフレームワークを使用してチームで協力しながら動作するソフトウェアのインクリメントを開発デリバリーしているだが複数のスクラムチームが1つのプロダクトバックログや1つのコードベースで作業しているとしばしば困難が生じてしまうたとえばお互いに影響を及ぼすような作業をするときに開発者たちが同じ場所にいない場合どのようにしてコミュニケーションをとればいいのだろうか? 開発者が異なるチームに所属している場合どのように作業を統合してどのように統合インクリメントをテストすればいいのだろうか?2つのスクラムチームの作業を1つのインクリメントに統合したときにこうした課題が発生するスクラムチームが3つ以上になるとさらに事態は複雑になる複数のチームが協力して少なくともスプリントごとに完全で完成したインクリメントを作成しようとするとそれぞれの作業に多くの依存関係が生まれるこうした依存関係は以下に挙げたものと関係している Page 2

4 1. 要求 : 要求のスコープが重なる可能性があるあるいは実装方法が影響しあうこともあるプロダクトバックログの並び替えやプロダクトバックログアイテムを選択するときにこのようなことを考慮する必要がある 2. ドメイン知識 : チームにいる人たちはさまざまなビジネスやコンピュータシステムの知識を持っている作業に必要な知識が持てるようにこうした知識をすべてのスクラムチームに適切に行き渡らせスプリント中にチーム間で割り込みが発生しないようにする 3. ソフトウェアやテストの作成物 : 要求はソフトウェアで具現化されている / されることになる要求チームメンバーの知識ソフトウェアの作成物を同じスクラムチームに対応付ければある程度はチーム間の依存関係を軽減できるスクラムを使っているソフトウェアのデリバリーが大規模になった場合要求ドメイン知識ソフトウェアコードの作成物の依存関係は開発チームの組織化を推進するものでなければいけないそれが可能ならば生産性は最適化されるだろう Nexus フレームワーク Nexusは複数のスクラムチームが協力して統合インクリメントを作るためのプロセスフレームワークである Nexusはスクラムやその構成要素とうまく調和しておりすでにスクラムを経験した人たちには馴染みのあるものとなるだろうスクラムとNexusの違いはスクラムチーム間の依存関係や相互作用に注意を払っており少なくとも1つの完成した統合インクリメントをスプリントごとにデリバリーするところにある大規模スクラムのためのNexus フレームワーク Page 3

5 図に示したように Nexusは以下の要素で構成されている役割 : 新しい役割であるNexus 統合チームは最高の成果が生み出されるように Nexu sの適用とスクラムの運用の調整コーチ監督を担当する Nexus 統合チームはプロダクトオーナースクラムマスター Nexus 統合チームメンバーで構成されている作成物 : すべてのスクラムチームが共通した1つのプロダクトバックログを使用するプロダクトバックログアイテムがリファインメントされ準備完了の状態になればスプリントのなかでどのチームが担当するのかが共有されるようになる新しい作成物であるNexusスプリントバックログはスプリントにおける透明性の確保を支援するすべてのスクラムチームはそれぞれのスプリントバックログを保持しているイベント : 通常のスクラムイベントを強化するために新しいイベントを追加補助 ( スプリントレビューでは ) 置換する手を加えたことにより Nexus 全体と各スクラムチームの両方の取り組みに役立つ Nexus のプロセスの流れ Nexus は複数のクロスファンクショナルなスクラムチームで構成されているスクラムチームは協力して少なくともスプリントの終了までにリリース判断可能な統合インクリメントをデリバリーする依存関係があるためチームが最も適切なメンバーを自己組織化的に選択してから特定の作業を行うこともあるプロダクトバックログのリファインメント : プロダクトバックログは依存関係を特定してそれらを排除あるいは最小化できるようにうまく分割する必要があるプロダクトバックログアイテムはリファインメントによって薄くスライスされた機能となるそれらを担当するチームはできるだけ早く決定すべきである Nexus スプリントプランニング : それぞれのスクラムチームの適切な代表者が集まりリファインメントしたプロダクトバックログの議論やレビューをする代表者は自分たちのチームのプロダクトバックログアイテムを選択するそれからそれぞれのスクラムチームで必要に応じて他のチームと情報交換しながら自分たちのスプリントの計画を立てる成果物となるのは包括的な Nexus スプリントゴールにあわせた複数のスプリントゴールそれぞれのスクラムチームのスプリントバックログ 1 つの Nexu s スプリントバックログである Nexus スプリントバックログによってすべてのスクラムチームが選択したプロダクトバックログアイテムとそれらの依存関係が明らかになる開発作業 : 統合の完了をテストできるようにすべてのチームが共通の環境に頻繁に統合する Nexus デイリースクラム : それぞれの開発チームの適切な代表者が毎日集まり統合の問題が発生していないかを確認する問題があればスクラムチームのデイリースク Page 4

6 ラムにその情報が伝えられるスクラムチームはデイリースクラムにおいて Nexusデイリースクラムで発生した統合の問題を解決できるようにその日の計画を立てる Nexusスプリントレビュー :Nexusスプリントレビューはスプリントの終了時に開催され Nexusがスプリントで構築した統合インクリメントのフィードバックを提供するものであるすべてのスクラムチームがステークホルダーと一緒に集まり統合インクリメントをレビューしてもらうこのときにプロダクトバックログの調整が行われることもある Nexusスプリントレトロスペクティブ : それぞれのスクラムチームの適切な代表者が集まり共通の課題を特定するその後スクラムチームが個別のスプリントレトロスペクティブを開催するチームの適切な代表者が再び集まり共通の課題の必要なアクションについて議論することでボトムアップの情報を提供する Nexus Nexus の役割イベント作成物はスクラムガイド ( に書かれているスクラムの役割イベント作成物の目的や意図を継承している Nexus の役割 Nexusは Nexus 統合チームと約 3~9のスクラムチームで構成される Nexus 統合チーム Nexus 統合チームには (Nexusの共同作業による) 統合インクリメントを完成させる最終的な責任がある統合インクリメントは少なくともスプリントごとに作成されなければいけないスクラムチームにはリリース判断可能な完成したソフトウェアのインクリメントを開発する実行責任があるスクラムチームのメンバーの役割はスクラムガイドで規定されている Nexus 統合チームは以下の構成であるプロダクトオーナースクラムマスター 1 人以上のNexus 統合チームメンバー Nexus 統合チームのメンバーは Nexusに含まれるスクラムチームのメンバーでもあるただしその場合もNexus 統合チームの作業を優先しなければいけない Nexus 統合チームのメンバーであることはスクラムチームのメンバーであることよりも優先されるこれにより多くのチームに影響する問題を解決する作業が優先されるようになる Page 5

7 Nexus 統合チームの構成は Nexusのニーズに応じて時間とともに変化する可能性がある Nexus 統合チームの共通のアクティビティには依存関係やチーム間の問題に対する認識を高めることやコーチングコンサルティングが含まれるまたプロダクトバックログの作業を行うこともあるスクラムチームは Nexusに含まれる統合の問題に取り組んでいる Nexus 統合チームは N exusの統合のフォーカルポイントを提供する統合にはチーム間の技術的 / 非技術的な制約を解消することも含まれるこうした制約は統合インクリメントを絶えずデリバリーするというNexusの能力を妨害する可能性がある Nexus 統合チームは制約を解消するために Nexusにあるボトムアップの情報を使うべきである Nexus 統合チームのプロダクトオーナー Nexusは 1つのプロダクトバックログで作業するスクラムフレームワークで説明しているように 1つのプロダクトバックログにはその内容の最終決定権を持つ1 人のプロダクトオーナーが割り当てられるプロダクトオーナーには Nexusの複数のスクラムチームによって統合されたプロダクトや作業の価値を最大化する実行責任があるプロダクトオーナーは Nexus 統合チームのメンバーであるプロダクトオーナーは Nexusで作成する統合インクリメントの価値を最大化するためにプロダクトバックログの管理に最終的な責任を持つそのやり方は組織 Nexus スクラムチーム個人によって大きく異なる Nexus 統合チームのスクラムマスター Nexus 統合チームのスクラムマスターは Nexusフレームワークが理解され実施されることに対する実行責任を持つ Nexus 統合チームのスクラムマスターは同じNexusに含まれる1 つ以上のスクラムチームのスクラムマスターになることもある Nexus 統合チームのメンバー Nexus 統合チームはツールプラクティス一般的なシステムエンジニアリングの利用に精通したプロフェッショナルたちで構成される Nexus 統合チームのメンバーは依存関係を検出するためにこれらのプラクティスやツールがNexusのすべてのスクラムチームで確実に理解実施されるようにするまた完成の定義に向けてすべての作成物を頻繁に統合する Nexus 統合チームのメンバーには Nexusのスクラムチームがこれらのプラクティスやツールを獲得実施学習できるようにコーチングや指導を行う実行責任があるまた Nexus 統合チームは品質の高い統合インクリメントを開発するために組織で求められる開発インフラアーキテクチャ標準についてスクラムチームをコーチする主要な実行責任が満たされたなら Nexus 統合チームのメンバーは 1つ以上のスクラムチームの開発チームメンバーとして作業することができる Page 6

8 Nexus のイベント Nexusのイベントの期間はスクラムガイドの対応するイベントの長さによって決まる Ne xusのイベントは対応するスクラムイベントに追加されたタイムボックスであるリファインメント大規模なプロダクトバックログのリファインメントには2つの目的があるどのチームがどのプロダクトバックログアイテムを提供するかをスクラムチーム全体が予測することでチーム間の依存関係を特定するのに役立つこの透過性によりチームは依存関係を監視しながら最小限に抑えることができる Nexusによるプロダクトバックログアイテムの細分化は過度な衝突を起こすことなく単一のスクラムチームが作業できるようにプロダクトバックログアイテムが十分に独立するまで継続するリファインメントの回数頻度時間出席者はプロダクトバックログの本質的な依存関係によって決まるプロダクトバックログアイテムは非常に大きく曖昧な要求からスクラムチームが1つのスプリントでデリバリーできる実行可能な作業までさまざまなレベルの分解を経由するリファインメントは必要に応じてスプリントの期間中も継続する Nexusスプリントプランニングでプロダクトバックログアイテムを選択できるように各スクラムチームがプロダクトバックログのリファインメントを継続する Nexusスプリントプランニング Nexusスプリントプランニングの目的は Nexusのスクラムチームが1つのスプリントで行うすべての活動を調整することであるプロダクトオーナーはドメイン知識を提供し選択や優先順位の付け方を指導する Nexusスプリントプランニングの前にプロダクトバックログを適切にリファインメントして依存関係を特定して削除または最小化しておく必要がある Nexusスプリントプランニングではリファインメントのイベントで作られた作業の順番をそれぞれのスクラムチームの適切な代表者が確認調整するコミュニケーションの問題を最小化するためにスクラムチームのすべてのメンバーが参加すべきである NexusスプリントプランニングではプロダクトオーナーがNexusスプリントゴールについて説明する Nexusスプリントゴールはそのスプリントでスクラムチームが達成する目的を説明したものである Nexusのすべての作業が理解できたらスクラムチームはそれぞれのスプリントプランニングを実施する Nexusでは新しく発見した依存関係を他のスクラムチームと共有できる Nexusスプリントプランニングはそれぞれのスクラムチームがスプリントプランニングを終了したときに完了する Page 7

9 Nexusスプリントプランニングでは新しい依存関係が明らかになることがあるそれらは透明化して最小化すべきであるまた複数のチームをまたがる作業の順番を調整することもあるプロダクトバックログを適切にリファインメントしておけば Nexusスプリントプランニングで新しく依存関係が見つかることは少ないだろうスプリントで選択されたすべてのプロダクトバックログアイテムとそれらの依存関係は Nexusスプリントバックログで透明化するべきである Nexusスプリントゴール Nexusスプリントゴールはそのスプリントの目的である Nexusに含まれるスクラムチームのすべての作業とスプリントゴールの総和である Nexusスプリントレビューでは Nexusスプリントゴールを達成するために開発が Done になった機能のデモを行うそこでステークホルダーからフィードバックを受け取る Nexusデイリースクラム Nexusデイリースクラムはそれぞれの開発チームの適切な代表者が集まり統合インクリメントの現在の状態を検査し統合の問題を特定しチーム同士の依存関係や影響を新たに発見するためのイベントである Nexusデイリースクラムでは参加者は統合インクリメントの衝突に焦点をしぼり以下のことを議論すべきである昨日の作業はうまく統合されたか? うまく統合されていなければそれはなぜか? 新たに特定された依存関係や影響は何か? Nexusのチーム間で共有が必要な情報は何か? 開発チームはNexusデイリースクラムを使い Nexusスプリントゴールに対する進捗を検査する Nexusデイリースクラムでは Nexusに含まれるスクラムチームの作業の現時点での理解をNexusスプリントバックログに反映する必要があるスクラムチームは Nexusデイリースクラムで特定された課題や作業を引き取りそれぞれのデイリースクラムで計画する Nexusスプリントレビュー Nexusスプリントレビューはスプリントの最後に開かれそのスプリントでNexusが構築した統合インクリメントに対するフィードバックを提供し必要であればプロダクトバックログを適応するものである Nexusスプリントレビューはスクラムチームのスプリントレビューを置き換えるものであるなぜならステークホルダーから統合インクリメント全体に対するフィードバックを得ることが重要になるからだ完了した作業のすべてを詳細に見せることは不可能かもしれな Page 8

10 いステークホルダーからのフィードバックを最大化するにはそれなりのテクニックが必要である Nexusスプリントレビューの結果は修正されたプロダクトバックログになる Nexusスプリントレトロスペクティブ Nexusスプリントレトロスペクティブは Nexusが検査と適応に焦点をしぼり継続的改善のために今後のスプリントの改善策を練るための公式な機会である Nexusスプリントレトロスペクティブは Nexusスプリントレビューの後次のNexusスプリントプランニングの前に開催する Nexusスプリントレトロスペクティブは以下の3つのパートで構成される 1. 最初のパートは Nexusの適切な代表者たちが集まり 1つ以上のチームに影響がある問題を特定する機会であるこの目的は共通の問題をすべてのスクラムチームに明らかにすることである 2. 2 番目のパートはスクラムチームが開催するそれぞれのスプリントレトロスペクティブであるこれはスクラムフレームワークで説明されているものである議論のインプットとして Nexusスプリントレトロスペクティブの最初のパートで挙がった問題を利用できるスクラムチームのスプリントレトロスペクティブではこれらの問題に取り組むアクションを生み出すべきである 3. 最後の3 番目のパートはスクラムチームの適切な代表者が再び集まり特定されたアクションをどのように透明化して追跡するかに合意する機会であるこれにより N exus 全体が適応できるようになるスケールには機能不全が伴うためすべてのレトロスペクティブでは以下の議題を扱うべきである完成していないものはあるか?Nexusは技術負債を作り出していないか? 作成物 ( 特にコード ) は頻繁に ( できれば毎日 ) 統合されているか? 未解決の依存関係が蓄積されない程度にソフトウェアは頻繁にビルドテストデプロイされているか? 上記の問いに対して必要ならば以下のことを議論するなぜこのようなことが起きたのか? どのように技術負債を解消するのか? どのように再発防止するのか? Page 9

11 Nexus の作成物作成物は透明性や検査と適応に必要な機会を提供する作業および価値を示したものである透明性および検査と適応についてはスクラムガイドに記述されているプロダクトバックログ Nexusとそこに含まれるすべてのスクラムチームに対してプロダクトバックログはただ1つだけ存在するプロダクトオーナーにはプロダクトバックログの内容可用性順番の最終的な責任がある大規模の場合依存関係を検出して最小化できるレベルまでプロダクトバックログを理解しなければいけないそのためにプロダクトバックログアイテムを薄くスライスされた (thinly sliced) 機能と呼ばれる粒度まで分解することが多いスクラムチームによって選択可能になったときにプロダクトバックログアイテムはNexusスプリントプランニングに向けて準備完了(Ready) になったと見なされるこのとき他のスクラムチームに対する依存関係は排除または最小化されそのスクラムチームだけでプロダクトバックログアイテムを完成できなければいけない Nexusスプリントバックログ Nexusスプリントバックログはそれぞれのスクラムチームのスプリントバックログにあるプロダクトバックログアイテムをまとめたものであるこれはスプリントにおける依存関係や作業の流れを強調するために使用する Nexusスプリントバックログは少なくとも毎日 ( 多くの場合 Nexusデイリースクラムで ) 更新する統合インクリメント統合インクリメントとは Nexusにおいて完了した統合された作業すべての現在の総和である統合インクリメントは利用可能でリリース判断可能なものでなければいけないつまり完成の定義を満たしていなければいけない統合インクリメントは Nexusスプリントレビューで検査する作成物の透明性構成要素であるスクラムと同様に Nexus も透明性にもとづいている Nexus 統合チームは Nexus のスクラムチームや組織と一緒にすべての作成物において透明性が確保され統合インクリメントの統合状態が幅広く理解されるように作業する Nexus の作成物の状態にもとづいた意思決定は作成物の透明性のレベルによってその効果が決まる不完全あるいは部分的な情報では意思決定も不正確で間違ったものになるこうした意思決定の影響は Nexus の規模に応じて大きくなっていく技術的負債が Nexus にとって許容できなくなる前に依存関係を発見して解消できるようにソフトウェアを構築しな Page 10

12 ければいけない透明性が確保されていなければリスクが最小化され価値が最大化されるように Nexusを効果的に導くことは不可能である完成の定義 Nexus 統合チームは完成の定義に実行責任を持つ完成の定義はスプリントで開発される統合インクリメントに適用されるものである Nexusのすべてのスクラムチームは完成の定義を忠実に守らなければいけないインクリメントは統合されており利用可能でありプロダクトオーナーによってリリース判断可能となったときに完成と見なされるスクラムチームはチームにおいて独自の完成の定義を適用することも可能だがインクリメントの完成の定義よりも緩い基準を適用してはいけない最後に Nexus は無料であり本ガイドで提供されるものであるスクラムフレームワークと同様に Nexus の役割作成物イベントルールは不変である Nexus の一部だけを導入することも可能だがそれは Nexus ではない謝辞 Nexus および Scaled Professional Scrum は Ken Schwaber David Dame Richard Hundhausen Patricia Kong Rob Maher Steve Porter Christina Schwaber Gunther Verheyen が共同で開発したものである翻訳本ガイドは上記の謝辞にある開発者たちによって提供された英語バージョンを日本語に翻訳したものである日本語訳は角征典と守田憲司が担当した Page 11

13 2015 年から2018 年にかけてのNexusガイドの変更点 1. Nexusガイドの説明を大規模スクラム開発の外骨格から Nexusを使用した大規模スクラムの公式ガイド : ゲームのルールへ変更した 2. Nexusを人々やモノの関係性やつながりと定義した 3. Nexusのプロセスの流れでは個々のメンバーではなくチームに焦点を当てるような言語に変更した > Nexusは複数のクロスファンクショナルなスクラムチームで構成されているスクラムチームは協力して少なくともスプリントの終了までにリリース判断可能な統合インクリメントをデリバリーする依存関係があるためチームが最も適切なメンバーを自己組織化的に選択してから特定の作業を行うこともある 4. Nexus 統合チームの役割を明確化した a. Nexus 統合チームは Nexusのスクラムチームのメンバーで構成されることが多いこの構成は Nexusの個々のスクラムチームからボトムアップで情報を収集することをサポートする b. Nexus 統合チームは統合作業を行なうものではない統合作業は個々のスクラムチームが行う c. Nexus 統合チームがNexusに含まれるスクラムチームのひとつであるという混乱の原因となっていたので Nexus 統合チームがスクラムチームであるという定義を削除した 5. Nexusのイベントのリファインメントを Nexusスプリントプランニングの直前に移動した a. リファインメントを2つのパートに分けないようにした見える化ではなく透明性や透明化の言葉を使うようにした b. リファインメントからミーティングを削除し単にリファインメントとした c. リファインメントは必要に応じてスプリント全体で継続的に行うことを強調した 6. Nexusゴールは Nexusスプリントプランニングの入力または出力として指定されていないため変化する可能性があるむしろNexusスプリントプランニングでプロダクトオーナーが説明するゴールであるなお同じ場所にいる必要性についての言葉を削除した Page 12

14 a. Nexusゴールは Nexusスプリントゴールに変更したスクラムフレームワークとの整合性を保つために新しい作成物の一覧から外した b. 目次から削除した 7. Nexusデイリースクラムはチームの依存関係に加えてチーム同士の影響を見る機会とした a. Nexusデイリースクラムは Nexusスプリントバックログを調整する唯一の機会ではないこれは Nexusスプリントバックログを調整して作業やチーム間の依存関係の理解を反映するためにチームが一緒に集まる最短の時間である b. Nexusデイリースクラムは Nexusの開発チームがNexusスプリントゴールの進捗状況を検査する機会である 8. Nexusスプリントレビューはショーアンドテルの機会ではない ( スクラムにおいても違う ) 必要に応じてプロダクトバックログを適応する機会を示す言葉を追加したまた Nexusスプリントレビューのフィードバックの必要性について Nexusのプロセスの流れで触れた 9. Nexusスプリントレトロスペクティブは Nexusが自身について検査と適応をしながら次のスプリントのために改善計画を作成する公式の機会であるという説明を追加した a. スクラムガイドのアップデートに合わせて NexusスプリントレトロスペクティブもNexusの継続的改善のために存在するものとした 10. 統合インクリメントは統合作業現在の状況を示すものとした 11. 完成の定義では統合インクリメントが統合されている必要があることを明示した 12. 作成物の透明性からソフトウェアを開発するときには技術的負債が許容不可能になる前に依存関係を検出および解消しなければいけない許容不可能な技術的負債かどうかは結合するときにはじめてわかるただしすべての依存関係が解消されたかどうかは不明のままだという文を削除し技術的負債がNexusにとって許容できなくなる前に依存関係を発見して解消できるようにソフトウェアを構築しなければいけないを追加した 13. ソフトウェアのプラクティスに関する段落を削除した重要かつ関連性は高いもののこのトピックについては価値を追加できるように精査する必要がある 14. クリエイティブコモンズを追加した Page 13

スクラムと監査についての一考システム監査人協会近畿支部近藤博則

スクラムと監査についての一考システム監査人協会近畿支部近藤博則スクラムと監査についての一考システム監査人協会近畿支部近藤博則自己紹介近藤博則 ( こんどうひろのり ) 昭和 54 年 11 月 4 日生まれ平成 27 年システム監査技術者試験合格関西支部報告 2 本支部メルマガ巻頭言寄稿など支部活動に参加アンケートスクラムを知っていますか? スクラムを使ったとがありますか? スクラムを監査した事がありますか? スクラムが生まれた背景ビジネスの不果実性の増大