InfoQ ホームページ Scrum に関するすべてのコンテンツ
-
マネージャ 2.0: スクラムでのマネージャの役割
スクラムは3つの役割しか定義しない。それはプロダクトオーナとスクラムマスタとチームだ。ここにはマネージャは存在しない。Pete Deemer氏はスクラムを適用したときにマネージャが受ける影響や、マネージャの役割をどのように再定義するのがいいのか(職務内容記述書のサンプルを含む)、マネージャをスクラムマスタに任命することなどを考察する。
-
アジャイルの限界
非伝統的な環境でアジャイルを実践しようとする試みが直面する問題は、アジャイルの原則が適用できないことでも、フィードバックのサイクルが始めからうまくいかないことでもない。アジャイルのスイート・スポットの外では、アジャイルの技術を適用するにはさらなる障壁があり、コストがかかること。これが、彼らが直面した問題だ。これらの障害物はアジャイル自体の適用を妨げるものではないが、アジャイル適用のコストを引き上げる。
-
マルチタスクで仕事は遅くなる
個人がマルチタスクで仕事をした場合、非効率で遅くなることは今ではよく知られている。アジャイル/スクラムチームであれば、実行しなければならないプロジェクトの数が鍵となる。アジャイルはチームは一度に一つのチームに従事するべきで、そうでなければ破たんする、と示している。Roger Browns氏はなぜこのようなことが起こるのか、掘り下げて解説している。
-
仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?
Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏が、バックログに関する彼らの意見とアジャイルチームを成功させるために必要な事を語った。
-
-
短いイテレーションの事例
Valtech Technologies社のアジャイルコーチであるDave Nicolette氏は、短いイテレーションは長いものよりも良いのかという質問に、取り組んでいる。Dave氏は、短いイテレーションは、変更に対しより素早く対応し、より多く問題を発見し、修正する機会があることをデモしている。また、短いイテレーションがバーンアウトや他の問題を招きかねない懸念材料について��対処している。
-
-
事例研究：Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
-
アジリティのためにコンポーネントチームより機能チームを選ぶ
Craig Larman氏とBas Vodde氏は、どのように、そし��、なぜ機能チームがうまくいくのかを説明し、この主要な組織の変化が価値あるものであることを主張します。
-
改善、成功と失敗: 中国でのスクラム導入
InfoQ Chinaは中国でスクラム（Scrum）がどのように導入されているかに関する調査を行いました。私たちはこの記事のために5つの事例をピックアップしました。これらの事例は、異なるさまざまな会社によるもので、異なるプロセスが利用され、異なる結果が生じたものです。
-
チームがキュービクルと引き換えにコミュニケーションスキルを得る手助けをせよ
アジャイルの「自己組織化チーム」のパラダイムでは、チームのメンバに新しいスキルが要求されます。この記事では、発展しつつあるチームの自己組織化を壊さずに、新たなスキルを伝えるためのいくつかの戦略を提案します。そして、新しいスキルを身につけるのに役立つ資料のありかを提示しています。
-
高い生産性を生み出すソフトウェア開発の秘伝
何について学ぶのか？お互いのこと、テクノロジ、ドメイン、顧客など、すべてについてである。速く学習するチームは成功する。チームのパフォーマンスを妨げる目に見えない「学習ボトルネック」について詳しく知りたいのなら続けて読んでほしい。