サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
www.servantworks.co.jp
Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213 Professional Scrum Product Owner™ 認定研修(試験付き) (2024年3月28日
Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213
ワークグループとチームの主な違い 上の表のようにワークグループとチームの違いを定めたとしましょう。私はよく「同じ景色を見ているか」でどちらなのかがわかると述べてきました。また、どちらが優れているとか二項対立を促したいわけではありません。ただし、この2つの違いを各自、各"グループ"、各組織で認識しておくことは大切だと捉えています。なぜならば、「このチームは、...」、「チームなのだから...」、「チームワークで乗り切ろう」などのように言葉として『チーム』と言うことは多いと思いますが、それが同調圧力となってしまい、無理を強いることになっている現場をよく見てきたからです。 ここで続編として述べておきたいのは、チームは育つということです。あるいはチームは育てていかなければならないと言うべきでしょうか。チームをどう育てるのかというと、仲の良さとかが挙げられがちだと思いますが、ここは踏ん張りどころで定
解説 このホワイトペーパー(ガイド)「アジャイルのカタ」は、「Agile Kata」の日本語翻訳版です。翻訳は長沢智治が担当させていただき、7名の翻訳レビューを経て、agilekata.orgならびに、agilekata.proに提供し、公開されました。 このドキュメントでは、アジャイルを実践し定着化するための中核となる「カタ」を提唱しています。アジャイル宣言やその12の原則、スクラムやカンバンといったフレームワーク、アジャイルプラクティスや、アジャイルリーダーシップ、アジャイルコーチングは、一つ一つとっても共感でき、またある種の理想でもあります。しかしながら、従来の習慣や成功体験により、アジャイルを良いものだと認めつつも、従来の考え方ややり方、制約に引きずられ、本来のアジャイルを実践できない現場を多くみてきました。「アジャイルのカタ」は、『トヨタのカタ』で解くほぐされた「改善のカタ」を中
チームで受講することで、クイックにスタートできる研修メニューをご用意しています。チームの立ち上げ時期や、学び直し、認識合わせとしてご活用ください。
はじめに この記事は、【徹底解説】シリーズの一環です。Daniel Russo氏と共著したスクラムチームに関する学術論文の非技術バージョンになります。Daniel氏は、オールボー大学の教授で、経験的ソフトウェア工学を専門としています。私は、組織心理学者であり、調査開発と統計が好きなスクラムの実践者です。なお、私たちの論文は、現在、学術的なピアレビューを受けています。 スクラムチームの効果性 どうすれば、スクラムチームをより効果的にすることができるでしょうか。書籍、ポッドキャスト、ブログ記事、オンラインで見つける資料のほとんどは、この質問に関係しています。「スケーリングフレームワークは、効果性に対してどのような影響を与えるだろうか」、「スプリントゴールはどうだろうか」、「どうすればチームがもっとオーナーシップを持てるようになるのか」、「スクラムマスターやアジャイルコーチが、演習やワークショッ
講演資料 #RSGT2023 での講演資料です。再演のご依頼などお気軽にご連絡ください。 簡単解説 軽く補足をしておきますが、今回本編では「カンバン」という言葉も文字列も使っていません。これはあくまでスクラムでのスプリント活動とアウトカムへの貢献が主だからですが、愚直にカンバンのプラクティスを実践するというのが良いというわけでないという暗示的なものでもあります。What/How→Who/Whyになり、柔軟性がないままにカンバンのプラクティスを採用すればいいというわけではないからです。また、カンバンガイドにある用語と言葉を変えている点については、カンバンガイドにて、用語は現場に合わせて使えばよく、コンセンサスがとれていればよいという旨が書かれており、現場が一番わかりやすい言葉を用いているため、セッションでも現場の言葉を用いました(極端な例: WIP制限→トランキーロ)。 補足記事
各位 Scrum.orgにて公開されている「Scrum Guide Companion for Leaders」を代表の長沢智治が共訳にて日本語翻訳し、日本語翻訳版『リーダーのための「スクラムガイド」手引き』として、Scrum.orgに提供し、公開されましたので、お知らせいたします。 また、同タイミングにて、「ビジネスアジリティのための投資戦略」も同様に日本語翻訳版が公開されました。 リーダーのための「スクラムガイド」手引き スクラムガイドは、複雑な問題に対応するフレームワークのルールとして浸透していますが、リーダーシップの役目を担うステークホルダーの一人としてどのように支援し、役目を果たすのかは、キャッチアップが難しい面があります。そこで、「Scrum Guide Companion for Leaders」では、文字通りスクラムガイドをリーダー層の理解促進と、スクラムチームの支援を的確
はじめに スクラムは、プロダクトをつくるための戦術的なフレームワークですが、事前につくる価値のあるものが何かを確かにする必要があります。しかし、プロダクトのディスカバリーフェーズが成功したとしても、プロダクトバックログが適切な作業に適していなければ、適切な方法で適切なものをつくるのに苦労することがあります(ガベージイン、ガベージアウト)。以下、この記事では、スクラムチームの成功を阻んでいるプロダクトバックログのリファインメントのプロセスを含んだ27のよくあるアンチパターンを示します。 『スクラムガイド』によるプロダクトバックログ まず、プロダクトバックログの目的について、最新のガイドを見てみましょう。 プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。 1 スプリント内でスクラムチームが完成で
はじめに DXやアジャイル人材の育成に熱心になっている現場が増えてきています。弊社へのお問い合わせも人材育成と学び直しが多くなっています。しかしながら、人材が育っていく環境づくり(=環境育成)には、そんなに思慮もコストもかけていないことが多いことが気になっていました。人材を育成することはとても大切ですが、果たして人材は一人ひとりへの教育の機会を提供すればよいものでしょうか?私たちは、人材が育つ環境に着目をしてきました。 環境なくして人材は育たないという仮説 どんなに個人に対して研修の機会を増やしても、期待通りには人材が育たないことがあります。また、代表して誰かが研修に参加したところで、その体験会を現場で開催したとしても、研修で得たことを十分に伝達することはとても難しいです。 人材を育てるには研修などの育成機会は重要ですが、それ以上に重要なのは、日々どう過ごしているか、それがどのように業務に
スクラムについて スクラムについては、『スクラムガイド』を読んで、理解して、チームで読み合わせして、そして、実践してみているかと思います。もちろん、『SCRUM BOOT CAMP THE BOOK』などの書籍も読んで参考にしたり、『More Effective Agile』を読んで、リーダーとして抑えておくべきことを確認したりもしているかもしれません。 スクラムについては、ガイドが公開され、更新され続けていること、書籍をはじめとした有益な情報に比較的容易にアクセスできることがとても助かります。また、Scrum Alliance, Scrum.org などの研修や認定、その他のスクラムやアジャイルの研修も充実しています(※弊社も研修を実施しています)。 知識と理解をどう確認しているか みなさんはスクラムの知識や理解をどのように確認しているでしょうか。まず大事にしていただきたいのは、チームで
はじめに 正直に言うと、組織内で唯一のスクラムマスターであることは楽しいことではありません!組織の中で自分が唯一のアジャイル担当であると気づくたびに、とても孤独を感じていました。既にその役割を経験していたとしてもそうなのです。だからこそ、周りのサポートがなければ、独りでこの変化を起こそうと試みてもすぐに圧倒されてしまうのです。 それゆえ、スクラムマスターや他のアジャイルのプロフェッショナルのチームがいる組織で働くことは、よりやりがいのある経験になると感じました。そして、この経験は自分たちのプラクティスコミュニティ (CoP, Communities of Practice) を共に編成することで、さらに素晴らしいものになりました。 プラクティスコミュニティ (CoP) とは CoPとは、関心のある人たちが集まる倶楽部のようなものだと考えてください。しかし、単なる関心のある人ではなく、特定の
DX の動機付けとしては、「外部の変化速度より内部の変化速度が上回らないと衰退につながるので、そうならないように検査と適応していく。そのためにデジタルのチカラを活用していくことが不可欠である。ただし、なんでもデジタルにしたら良いと言うわけでもない。というあたりにあると思っています。 現状と実状を知る 今回は、業務フローとIT化、そこからの知見ででてくる業務フローの改善と真に価値のあるIT化を順に図解してみていきます。 大事な体験 体験といってもここで言い表せないくらいのボリュームとなります。そこでここでは、体験を以下のようにわかりやすくしてみたいと思います。 中間成果より成果に価値をおく さまざまな業務やビジネスにおいて中間成果が多く存在しています。そしてそこには多くの関係者がかかわっているわけです。組織における価値と言い換えてもいいかもしれませんが、それよりも大切にしておきたいのは最終的
スクラムチーム スクラムチームには明確な3つの責任で構成されています。 スクラムマスター プロダクトオーナー 開発者 スクラムチームが過度の対立や信頼の欠如に悩んでいるとき、その原因は、それぞれの責任を明確にしていないことであることがよくあります。プロダクトオーナーは、最善の意図を持っていたとしても、次のスプリントに集中しすぎ、全体像を見ることを欠いてしまうことがあります。スクラムマスターは、チームを過度に保護するようになり、開発者は、喜んでもらいたいために、より多くの作業を引き受けることになり、スプリントゴールを危うくしてしまうのです。 明確な責任の欠如を示す指標 チームにおける明確な責任の欠如は、以下ような示す指標として表れます。 プロダクトオーナーが、プロダクトゴールを作成しない、もしくはプロダクトゴールを伝えない プロダクトバックログには、次のスプリントに向けた十分な作業の「準備(
はじめに 2020年12月に、Johannes Schartau と Christiaan Verwijs と私で、『Zombie Scrum Survival Guide』(ゾンビスクラムサバイバルガイド)を出版しました。スクラムが、ゾンビスクラムになってしまいがちな理由を読者に理解してもらい、実践的で地に足のついた手助けを提供するために書き記したのです。ゾンビスクラムは、簡単な実験で解決できるものではりません。組織に深く浸透しているほど、解決にはより多くの労力が必要となります。そこで、書籍が発売されてからのおよそ半年後に、本書に書かれている実験を実践することで、わたしたちのコミュニティがどのように進歩しているかを確認したいと思いました。経験したゾンビスクラムとの闘いの成功例とは?そこで何が起こったのか?ゾンビスクラムはどのようなもので、どのようにしたら状況を改善することができたのか?を
依存関係は知識のギャップ Michael James 氏によると、ソフトウェア開発のようなナレッジワーク(知識労働)における依存関係は、物理法則ではなく、知識(ナレッジ)のギャップによって引き起こされるといいます。 確かに、「靴下を履いてから靴を履く」ということは、ナレッジワークには当てはまりません。例えば、第1章の内容を知っていれば、第2章から書籍を書き始めることもできます。知識の創造は、物理的な依存関係ではなく、知識を発見し、創造する能力によってのみ制約されています。 要求が曖昧でプロダクトオーナーが不在の場合、スキーマの変更をするためにデータベース管理者からの指導が必要な場合、開発環境が提供されてからでないと開発を開始できない場合、他のチームによる API の変更が完了してからでないと作業を続行できない場合、変更審査委員会が先に変更を承認する必要がありプロダクトバックログアイテム(P
はじめに スクラムチームは、常にプロダクトバックログリファインメントを行っています。スプリントレビュー中でも、デイリースクラムの後でも、スプリントプランニング中でも、そして、開発の一環としても行われています。スクラムチームは、今後の作業についての話し合いを行い、共通理解を得るのです。この話し合いには、以下のようなものが含まれます。 作業から得られる成果物の明確化 完成したときに個別のピースが価値を持つような作業への分割 スクラムチームと組織のゴールが最善に達成できるようにするためのプロダクトバックログにある作業の並び替え プロダクト必要な新たな作業の追加、冗長な作業の削除 作業にある依存関係の解消 作業の規模と価値の見積もり 作業における前提条件を理解 つまり、そのプロダクトバックログにおいて、プロダクトバックログアイテム(以下、PBI)として表現されている将来の作業のすべてです。Barr
TL;DR: スクラムの確約(コミットメント) 新しい『スクラムガイド』(※訳注: 2020年11月に公開されたバージョン)は、規範的なものではなく、より包括的なものになっています。また、以前のバージョンでは、スクラムの確約(コミットメント)に伴うスプリントゴールと完成の定義が宙に浮いているようなになっていましたが、これらの要素をより良い形で含めることで、未解決の問題を解決しています。 以前のバージョンにとっては、この包括的な部分がとてもうまく機能しますが、最新バージョンに関しては、靴べらが必要です。 パターンを早く見つけるために「Scrum Guide 2020 Reordered 」も読んでください。 スクラムガイド 2020 何よりも、新しい『スクラムガイド』では、多くの提案を削除して、規範的ではないものになっています。例えば、「デイリースクラムでの(3つの)質問」、「レトロスペクテ
次のページ
このページを最初にブックマークしてみませんか?
『サーバントワークス株式会社 | アジャイル支援とトレーニング』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く