InfoQ ホームページ Scrum に関するすべてのコンテンツ
-
/articles/kenji-modeling-agile/ja/smallimage/logo.jpg)
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
もはやアジャイルソフトウェア開発手法はソフトウェア開発の主流になりました。動くコードは一番重要なチーム成果物として扱われることになりました。それにしても、あいかわらずモデリングは必要です。平鍋健児氏はこのアジャイル時代におけるモデリングの適切なモデリングと重要な役割について探求します。この記事では、システム”全体像”の理解共有が不可欠であるマルチチーム開発のスケーリングにフォーカスを当てました。
-
/articles/self-organizing-organizations/ja/smallimage/logo.jpg)
本当に自己組織化したチーム
この会社は、個人個人の自由意志によって組織化されています。みんながゴールを達成するために、協力することを自由に選んでいます。実際に自己組織化した会社を経営していなくても、自己組織化した会社について知りたいと思っている人たちのために、この記事は書かれています。
-
アジャイルにおけるビジネスアナリスト像
2010年8月に、BABOKのアジャイル拡張（Agile Extention)のドラフト版が公開された。アジャイルにおけるビジネスアナリストがリエゾン（橋渡し役）として有効に機能するには、動作するソフトウェアを実現する開発チームへ継続的に寄り添い、貢献しなければならない。そのため、アジャイルでのビジネスアナリストは、資料作成や分析の技術だけでなく、ソフトウェアの実現に関わる技能を備えることが必要となるだろう。これは逆に、開発チー���がビジネスアナリシススキルを備えるべきだということも、また示唆している。
-
/articles/technical-debt-levison/ja/smallimage/technicaldebt.jpg)
技術的負債、マネージャの視点
Developers often talk about Technical Debt saying its slowing your projects down. What are they really saying? What measures can you take to reduce it before it cripples your projects?
-
/articles/scrum-management-deemer/ja/smallimage/scrum.jpg)
マネージャ 2.0: スクラムでのマネージャの役割
スクラムは3つの役割しか定義しない。それはプロダクトオーナとスクラムマスタとチームだ。ここにはマネージャは存在しない。Pete Deemer氏はスクラムを適用したときにマネージャが受ける影響や、マネージャの役割をどのように再定義するのがいいのか(職務内容記述書のサンプルを含む)、マネージャをスクラムマスタに任命することなどを考察する。
-
/articles/limits-of-agile/ja/smallimage/image_agile_border.jpg)
アジャイルの限界
非伝統的な環境でアジャイルを実践しようとする試みが直面する問題は、アジャイルの原則が適用できないことでも、フィードバックのサイクルが始めからうまくいかな���ことでもない。アジャイルのスイート・スポットの外では、アジャイルの技術を適用するにはさらなる障壁があり、コストがかかること。これが、彼らが直面した問題だ。これらの障害物はアジャイル自体の適用を妨げるものではないが、アジャイル適用のコストを引き上げる。
-
/articles/multitasking-problems/ja/smallimage/JugglingBalls - small.jpg)
マルチタスクで仕事は遅くなる
個人がマルチタスクで仕事をした場合、非効率で遅くなることは今ではよく知られている。アジャイル/スクラムチームであれば、実行しなければならないプロジェクトの数が鍵となる。アジャイルはチームは一度に一つのチームに従事するべきで、そうでなければ破たんする、と示している。Roger Browns氏はなぜこのようなことが起こるのか、掘り下げて解説している。
-
/articles/backlog-panel/ja/smallimage/backlog.jpg)
仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?
Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。
-
/articles/backlog-not-waste/ja/smallimage/image_agile_plant.jpg)
-
/articles/short-iterations-argument/ja/smallimage/calendar.JPG)
短いイテレーションの事例
Valtech Technologies社のアジャイルコーチであるDave Nicolette氏は、短いイテレーションは長いものよりも良いのかという質問に、取り組んでいる。Dave氏は、短いイテレーションは、変更に対しより素早く対応し、より多く問題を発見し、修正する機会があることをデモしている。また、短いイテレーションがバーンアウトや他の問題を招きかねない懸念材料についても対処している。
-
/articles/agile-product-owner/ja/smallimage/image_medal.jpg)
-
/articles/dutch-railway-scrum/ja/smallimage/DutchTrain2.jpg)
事例研究：Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。