ブログ

ryuzeeによるブログ記事。不定期更新

チームがアジャイルかどうかをセルフアセスメントする42の質問

みなさんこんにちは。@ryuzeeです。

How Agile Are You? (Take This 42 Point Test)が良い記事なので抜粋・意訳にてご紹介します。 ちなみにチームが「アジャイル」か?というより、チームが「スクラム」か?といった方が良いと思われるので、その点は留意してください。

  • チームに決定権限が与えられている
  • チームは、自己組織化されていて、目標を設定して達成することを管理(者)任せにしない
  • チームは成果物の提供に対してコミットし、責任を持つ。そしてチームがゴールに到達するために、あらゆるタスクに協力する
  • チームはプロダクトオーナーが誰であるかを知っている
  • それぞれのスプリント/イテレーションには明確なゴールが設定されている
  • テスターを含む全てのチームメンバーは、要件を抽出するワークショップに参加する
  • 要求事項の文書は十分にそろっている。そしてフィーチャーを実装できるレベルまで協力して詳細化する
  • テストケースが要求事項やユーザーストーリーごとに事前に用意されている
  • ビジネス上の価値によって優先順位付けされたプロダクトバックログやフィーチャーリストがある
  • プロダクトバックログに、チームによって作成された見積りが載っている
  • チームは自分たちのベロシティを知っている
  • ベロシティは各スプリント/イテレーションにどれだけのストーリーを含められるかの指標に使われる
  • スプリント/イテレーションは4週間またはそれ以下に区切られている
  • スプリントの予算はどれだけのプロダクトバックログ、フィーチャーをそのスプリント/イテレーションに含めることができるかを決定するために計算される
  • スプリント/イテレーションは、チームで合意している終了日に終了する
  • スプリントバックログ内の全てのタスクは1日以下のタスクに細分化される
  • 要求事項は、ユーザーストーリーとして記述されており、カードに書かれている
  • チームはポイントを使って見積る。そのポイントはプロダクトバックログ/フィーチャーリスト内の各項目の相対的なサイズを示している
  • チームは、日々の進捗をトラッキングするためにバーンダウンチャートを利用する
  • ソフトウェアは各スプリント/イテレーションごとにテストされており動作する
  • チームは、スプリント/イテレーションの間、(周りから)混乱させられない
  • 変化はスプリント/イテレーションのあいだ、ずっと統合される
  • 自動化されたユニットテストが適切に実装されている
  • 自動ビルドと自動リグレッションテストがある
  • 予想よりうまくいった場合に、スプリント/イテレーションに含める追加タスクを決めている
  • プロダクトオーナーは、各スプリントに積極的に関わる
  • 全てのコードの変更は元に戻すことができ、またいつでもリリース可能である
  • テストはライフサイクルに統合されており、最初のフィーチャーのリリース時からテストをしている
  • 進捗を妨げる障害は、ホワイトボードに記録されて、ただちに解決する
  • 誰かが終わった!といったら、それは出荷可能(リリース可能)ということだ
  • チームは日々の進捗や問題を、分かりやすく見える化するためにホワイトボードを利用する
  • スプリント/イテレーションのゴールはホワイトボード上にはっきり書いてある
  • すべてのユーザーストーリーとタスクはそのスプリント/イテレーションの期間中はホワイトボード上に表示されている
  • たとえスクラムマスターが不在でもデイリースクラムは毎日同じ時間に実施しているか?
  • デイリースクラムは標準の3つのスクラムの質問(昨日何やった?今日なにやる?困っていることは?)に答えるようになっていて15分以内に終了しているか
  • スプリント/イテレーションの終了後に、製品のデモとスプリントレビューを実施している
  • テスターを含む全チームメンバーが、スプリント/イテレーションレビューに出席している
  • スプリント/イテレーションレビューにステークホルダー(顧客)が出席している
  • 各スプリント/イテレーションの終了後にふりかえりを実施している
  • 各スプリントのふりかえりでキーメトリクスのレビューと捕捉をしている
  • テスターを含む全チームメンバーが、スプリントのふりかえり会に出席している
  • スプリントのふりかえりで出たアクションが、次のスプリント/イテレーションで、前向きな影響を持っているか

原文は以下の通りです。

  • The team is empowered to make decisions.
  • The team is self-organising and does not rely on management to set and meet its goals.
  • The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
  • The team knows who the product owner is.
  • Each sprint/iteration has a clear goal.
  • All team members, including testers, are included in requirements workshops.
  • Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
  • Test cases are written up-front with the requirements/user story.
  • There is a product backlog/feature list prioritised by business value.
  • The product backlog has estimates created by the team.
  • The team knows what their velocity is.
  • Velocity is used to gauge how many user stories should be included in each sprint/iteration.
  • Sprints/iterations are timeboxed to four weeks or less.
  • Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
  • The sprint/iteration ends on the agreed end date.
  • All tasks on the sprint backlog are broken down to a size that is less than one day.
  • Requirements are expressed as user stories and written on a card.
  • The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
  • The team generates burndown charts to track progress daily.
  • Software is tested and working at the end of each sprint/iteration.
  • The team is not disrupted during the sprint/iteration.
  • Changes are integrated throughout the sprint/iteration.
  • Automated unit testing is implemented where appropriate.
  • There is an automated build and regression test.
  • Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
  • The Product Owner is actively involved throughout each sprint.
  • All code changes are reversible and it is possible to make a release at any time.
  • Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
  • Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
  • When someone says ‘done’, they mean DONE! (ie shippable).
  • The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
  • The sprint/iteration goal(s) is clearly visible on the board.
  • All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
  • Daily scrums happen at the same time every day ? even if the scrum master isn’t present.
  • The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
  • There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
  • All team members, including testers and Product Owner, are included in the sprint/iteration review.
  • The sprint/iteration review is attended by executive stakeholders.
  • There is a sprint retrospective at the end of each sprint/iteration.
  • Key metrics are reviewed and captured during each sprint retrospective.
  • All team members, including testers, are included in the sprint retrospective meeting.
  • Actions from the sprint retrospective have a positive impact on the next sprint/iteration.

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック