March 2021
Beginner to intermediate
288 pages
5h 8m
Japanese
| エリック・ナイバーグ | ![]() |
スクラムチームは同じ場所で働かなければいけないとか、同じ会社の人でなければいけないと言う人は多い。だが、そんなことはない。スクラムは複雑な問題を解決するためにある。複数の会社のメンバーが分散したチームに所属して働くと、問題はさらに複雑になる。だからこそスクラムの出番だ。
Scrum.org(https://scrum.org)の新しいウェブサイトを開発するのに、複数の場所から知識と才能を集める必要があった。使いたい技術を持った外部業者を探すだけでは足りず、一緒にスクラムをやれるパートナーを求めていた。当たり前の話だ。
スクラムのルールだけでなく、少しだけ仕事の条件に注意を払うだけで、いろいろやりやすくなった。
外部業者と契約条件の交渉をしているとき、最初から18か月のプロジェクトへのロックインを求められるのは嫌だった。プロジェクトが進むにつれて、学習して進化したいからだ。しかし、契約についてのある程度の保証が欲しいという外部業者の言い分も理解した。合意点を見出すのは難しくなかった。4週間前(1〜2スプリント)前までに通知すれば、契約の延長やキャンセルができるオプションを付けて、複数スプリントをまとめて契約することにしたのだ。
私たちのスクラムチームは、機能横断的なだけでなく、組織横断的だった。Scrum.orgからプロダクトオーナー、外部業者からスクラムマスター、開発チームは両方から参加してチームができた。開発者が両方から参加することで、Scrum.orgのウェブサイトを長期にわたってメンテナンスするのに必要な知識とスキルを移転するのに役立ったし、外部業者のエンジニアが既存のシステムを理解するのにも役立った。 ...
Read now
Unlock full access