私はデザイン会社の技術部門で働いています。XP を使用して、部門のソフトウェア開発を管理しています。私は、スクラムについて説明し、クライアントのプロジェクト作業を管理するためのより広い文脈でスクラムが適切かどうかについて簡単なプレゼンテーションを行うよう求められました。
スクラムは、グラフィック デザイナー、情報アーキテクト、コンテンツ エディター、ユーザー エクスペリエンス エンジニア、Web デザイナー、およびソフトウェア開発者を含む部門横断的なチームに適用されます。
スクラムはこの種のチームにどのような利点をもたらすでしょうか?
私の経験に基づくと、スクラムの主な機能は次のとおりです。
そして、これらの機能は次の利点につながります。
利点だけについて話している場合、それらはかなり明白です。
適切な方法論を使用すると、より効果的に作業できます。つまり、プロジェクトの成功率が高くなります。プロジェクトがすでに 100% 成功している場合は、おそらく何も変更する必要はありません。
アジャイルを使用すると、次のことができます。
プロジェクトのスケジュールと状態をより詳細に管理できます (短いイテレーション、速度を計算するための明確で明確な方法など)。
その結果、全体的に高い顧客満足度を達成しています
私の経験では、主な利点は、あなたがスクラムをやっていると上司に言われるようになることと、仕事を終わらせる代わりに毎日の会議に行く時間を無駄にできることです。
...彼らがそれを正しく行っていなかった可能性があります;-)。
あなたが説明したチームには、次の主な利点があります。
何が起こっているのかを可視化し、説明責任を果たします。SHORT デイリー ミーティングでは、何が起こっているか、何が完了し、何が完了していないかをよりよく把握できます。しばらくすると、傾向が見え始めます。見積もりが得意な人、そうでない人、実際には働いていないのに働いていると言っている人などです。いつ完了するかをよりよく把握できます。
自己組織。チーム メンバーは、特定のイテレーションで何をいつ行うかを選択します。人々が慣れていない場合、これには時間がかかりますが、誰が何をするかを誰も指示しないため、最終的にチーム メンバーはより幸せになります。彼らが決めます。
要件の変化に迅速に対応する能力の向上。タイム ボクシング、毎日のステータス チェック、およびユーザーの関与の概念により、フィードバックの収集と優先順位の変更の両方が容易になります。
XP とスクラムの間に大きな違いはありません。すでに XP をお持ちの場合は、おそらく切り替える必要はありません。スクラムオブスクラムのようなスケーラビリティを向上させるために、スクラム固有のプラクティスを採用するかもしれません。XP には、毎日のミーティング、イテレーション、役割分担、ふりかえりなど、他のほとんどすべてのプラクティスが存在します。
実際、そのような分離にメリットがあるかどうかはわかりません。ふりかえり会議で自分の悪いところを判断し、特定の問題に対して任意のプロセスのプラクティスを適用する (または独自のソリューションを作成する) ことをお勧めします。XP とスクラムは、順応性と創造性を高めるのに役立つフレームワークを提供します。従来のプロセスでは、創造的な行動を阻害する一連のルールが提供されます。
あなたのチームとプロジェクトは特別です。開発プロセスを鋭くするために考え、コミュニケーションします。
まず第一に、スクラムは開発ではなくプロジェクト管理の方法論です...XPまたはRUPと組み合わせることができます...
スクラムは、変化するプロジェクトがある場合に適しています...要件が変更された場合、これらの変更に対応する必要があります...スクラムのイテレーションは短く（2〜4週間）、変更に対するより多くの応答が提供されます.. .そして、クライアントは彼の製品の初期リリースを手に入れることができ、あなたは必要なフィードバックをすべて得ることができます...おそらくこれが最初の利点です...
もう 1 つの利点: チームが互いに依存している場合、チームは常に特別に同期して作業します...
私が理解しているように、毎日のスクラムミーティングは、チームが進捗状況とブロックの問題について話し合うためのものです。スクラムマスターが促進します。チームがそうすることを決定した場合、製品の所有者を招待することができますが、会議は上司またはマネージャーに進捗状況を提供することを目的としていません。
私が正しいことを願っています。
私は 2 年間「スクラム」を行ってきましたが、開発プロセスが固定期間 (スプリント) で行われ、何が行われたかを評価できるため、いつでも「現在地」を知る方がはるかに簡単であることが私の経験からわかります。そして、デイリー スクラム (Dmitriy が話していた会議) とバーンダウン チャート (残りの作業の図) がある期間の途中で、チームとマネージャーは、何が既に完了し、チームが何に取り組んでいるのかを常に知ることができます。 .
あなたの場合、スクラムは小さなチームで最もうまく機能するため、大きなスクラムではなく、おそらくいくつかの小さなスクラムが必要になるでしょう。この本には、それに関するいくつかの洞察があります: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
あなたが「スクラム」と言うとき、それがアジャイルを意味しているのか、それとも単に毎日のミーティングを意味しているのかわかりません。毎日の会議の利点は何ですか 3
1 - 抱えている問題をチーム全体に公開する機会があり、思いもよらなかった人からアドバイスを得ることができます。あなたが抱えている問題について助けを求めようとするために、一日中同僚の邪魔をしなければならないよりも効率的です.
2 - グループ チームは、グループ全体が何をしているかをよりよく把握し、自分が直接関与していない開発に影響を与える機会を得ることができます。
3 - 上司を含む全員が、あなたが取り組んでいることや進捗状況を毎日聞いているため、通常、進捗レポートを書く時間が短縮されます。
それがスクラムでの私の経験です
スクラムは方法や練習というより習慣だと思います。アジャイルを行っていることを知らずにスクラムで運用しているチームはたくさんあります。また、自分がアジャイルであると主張し、スクラムの基本原則に従っていないと主張するチームがたくさんある可能性があります。
締め切りが遅くなることはありません:)
チームスピリット 進捗状況の可視性が高い。利害関係者からの頻繁なデモンストレーションと早期のフィードバック 問題が早期に特定される 製品の品質と生産性の向上 顧客満足度の向上