16

私の会社は最近スクラムを使い始めました。2回のスプリントを行いました。私たちはまだ学習中ですが、開発プロセスのいくつかの問題を明らかにして修正しました。ですから、一般的にはそれは私たちにとって良いことだと思います。

福音書記者、皮肉屋、そしてその間のすべての人からのスクラムに関するインターネットの思索の多くを読んで、3つの一般的でやや矛盾したテーマが私に際立っていました：

  1. スクラムのプロセスが十分に厳密に実行されていないため、スクラムの実装は失敗します。
  2. 組織がスクラムを独自の環境/文化/慣行に適応させていないため、スクラムの実装は失敗します。
  3. スクラムのプロセスは重要ではありません。アジャイルマニフェストの値のみが重要です。

これらの例は、これらのSO質問への回答で見ることができます。

スクラムのすべてのガイドラインにまだ従っていないことを認めなければなりません。スプリントの最後にリリースを行っていません。スクラムマスターは、タスクをスプリントのバックログから最後の方に移動することを望んでいません。いくつかの例として、彼が私たちの計画がどれだけずれているかを確認できるように（つまり、バーンダウンチャートが0になることはありません）、緊急のカスタマーサポートの問題には、すべての人の計画を混乱させる信じられないほどの力があります。

私の質問は、これらの問題やその他の問題を解決しようとする際に、公式のスクラムプロセスに近づこうとするのが良いのか、スクラム前のプロセスのいくつかに近づくのが良いのか、それともスクラムの原則について瞑想するのが良いのかということです。まったく別のプロセスを考え出してみてください。

4

8 に答える 8

10

早期に頻繁にリリースしないと、アジリティの重要な要素の 1 つが欠けていると言えます。これを行わない限り、プロセスは機敏ではなくなり、従来の計画主導のプロセスと同じ種類の問題に苦しむことになります。これは慣れてきたばかりの一時的な状態かもしれませんが、すぐに (そして定期的に) リリースを開始する必要があります。

ショーストッパーには常に問題がありますが、スプリントの長さを短くすることでこれを助けることができるかもしれません. お客様は一ヶ月待てないかもしれませんが、物によっては二週間待てば良いかもしれません。したがって、スプリントの長さが短いと、一部のリクエストを次のスプリントに延期して、混乱を少なくするのに役立つ場合があります。また、混乱によって実際にペースが低下していることを顧客に率直に伝える必要もあります。選択した機能が一部の要求によって遅れていることがわかっている場合、自発的に待つことを選択する場合があります。

もう 1 つ私が指摘したいのは、ほとんどの場合と同様に、学習中はパターンにできる限り忠実に従うことから始める方がよいということです。基本的な原則を十分に理解すると、プロセスを改善するためにいくつかの原則を曲げたり、壊したり、置き換えたりできる場所がより明確にわかります。本当に理解するまでは、変更したものが害を及ぼすか、または役立つ可能性があります。物事がどのように機能する必要があるかを示す経験がないため、実際にはわかりません。スクラム マスターが十分な経験を積んでいない場合は、あと数回スプリントを経験するまで、定義されたプラクティスにさらに近づくことをお勧めします。

于 2009-01-05T16:04:45.110 に答える
5

私がスクラムで読んだほとんどすべてのことは、重要なことの1つは、自分の状況に合うようにプロセスを適応させることだと言っています。2つの開発チームが同じであるということはなく、異なる人々のために異なることが機能します。

スクラムの背後にある主なアイデアは次のとおりです。

要件から開発、そして利害関係者へのフィードバックループを緊密にします。

これにより、開発チームは、実際に必要なものを構築していることを継続的に確認でき、要件や期待の変化に応じて開発を簡単に調整できます。利害関係者はいつでも機能を追加または削除でき、ニーズの変化に応じて機能の優先度を調整できます。

特定のスプリントの終了時にソフトウェアをリリース可能な状態に保ちます。

それはあなたがすべてのスプリントをリリースしているということではありませんが、顧客が最新のものを手に入れたいと決めた場合はそうすることができます。これはまた、開発チームが、プロジェクトの一部を一度に何ヶ月も孤立して作業する人々から生じる統合地獄の状況を回避するのに役立ちます。

開発で何が起こっているかを完全に透明にし、誰もが喜んでトレードオフを行う必要があります。

これは、ほとんどのプロジェクトが失敗する場所であり、全員がプロセスに参加した場合にスクラムが実際に成功する可能性がある場所です。非常に多くの開発プロジェクトが、リリースでY日にX機能をリリースする必要があり、それを変更する柔軟性がないところまで設定されています。これにより、開発者がチェックリストに必要なすべての機能を詰め込むため、機能が半分完成し、ソフトウェアにバグが発生します。

現実には、ソフトウェア開発では予期しないことが起こります。オープンなコミュニケーションとスクラムプロセスへの積極的な参加により、顧客と開発者はプロジェクトの現在の状態を継続的に評価し、プロジェクトに残っている作業の優先順位付けについて知識に基づいた決定を下すことができます。

于 2009-01-05T16:35:22.117 に答える
2

スクラムは機能します。すべての状況ですべてのチームとは限りませんが、機能することが示されています。

ビジネス環境が許す限り教科書のスクラムを採用し、それがどのように機能するかを確認してから調整することをお勧めします。

スクラム マスターがタスクをスプリント バックログから移動させたくないのはなぜですか? 彼はスクラムの原則を 100% 受け入れていませんか? （スクラムマスターにとっては心配事だと思います）

スクラムを実装するほとんどの問題は、実際にはスクラム プロセスによって明らかになったチームまたはビジネスの問題にすぎません。

于 2009-01-05T16:07:12.173 に答える
1

すべての会社が異なり、すべてのプロジェクトが異なり、すべてのクライアントが異なります。

スクラム (またはその他の方法論) にあまり厳密に従っていない環境でスクラム (またはその他の方法論) に従って失敗するのは、適切なプロジェクトでスクラムを緩く従うために失敗するのと同じくらい簡単だと思います。

最後に、QA サイトの一般的な回答は、自分のプロジェクト、会社、チーム、およびクライアントの真剣な分析に代わるものではありません。魔法の公式はなく、自分で決定する必要があります。

于 2009-01-05T16:05:54.657 に答える
1

スクラムは、ソフトウェア開発における技術的な問題に対処しようとはしません。それはほんの小さな管理プロセスです。

  • スクラムの強みは、多くの不必要または無関係な技術的作業を規定することによって邪魔にならないことです。
  • スクラムの弱点は、どのような優れた技術的プラクティスを行うべきかを教えてくれないことです。

エクストリーム プログラミングは、ソフトウェア開発に伴う技術的な問題に対処し、スクラムに非常によく適合します。スクラムの人々が全員に XP の技術的プラクティスを強制しなかった理由は、最も基本的なスクラムの実装に 2 日かかるのではなく、これらの技術的プラクティスの実装に約 6 か月かかるためです。

スクラムが「悪」であるかどうかにかかわらず、確かに欠点があります。2009 年にロンドンで開催された XP Days で、XP とスクラムの不安定な関係について詳しく説明しました: http://xpday-london.editme.com/WhereHasXpGone

于 2010-01-17T23:09:19.550 に答える
1

回答:スクラムの利点を十分に得るには、スクラムと XP の両方を一緒に採用する必要があります。

理由:

その理由は、XP とスクラムを何年にもわたって行ってきたこと、特に Jeff Sutherland の講演 (2009 年 5 月、ロンドンの ACCU で) から学んだことに基づいています。

  • スクラムは管理手法であり、必ずしもソフトウェアの生産方法ではありません。博物館の展示会の準備や宗教施設の運営など、他の分野でスクラムを使用する人もいます。そのため、スクラムには、学際的なチームが少しずつ適応的に仕事を提供するために必要なメカニズムがあります。
  • スクラムには、もともと極端なプログラミング手法がすべて含まれていました。実際、Jeff Sutherland は、極端なプログラミング手法を使用せずに、スクラムで測定されたより高い生産性を達成するスクラム プロジェクトを見たことがないと言っていました。
  • スクラムと XP はどちらも、オブジェクト指向プログラミング、特に Smalltalk を使用した同じ背景から来ています。管理者がスクラムを作成している間に、プログラマーが XP を開発しました。開発プラクティスと管理プラクティスの両方の側面が必要です。
  • XP プラクティスは、採用しやすくするために、スクラムから意図的に削除されました。- XP プラクティスを実装するのは難しく、すぐに採用するのは困難です。実際、Jeff は、Ken Schwaber が XP プラクティスを削除して、人々がスクラムを開始できるようにしたと述べています。現在の危険は、この最小限のスクラムが、人々が見て期待するすべてになっていることです。
  • 現在、多くの非技術系プロジェクト マネージャーがスクラムを教えていますが、彼らは XP を教えるスキルセットを持っていません。
  • すべての開発者が XP プラクティスを採用しやすいとは限りません。基本的なスクラムを確立するのに 2 日かかるのではなく、数か月かかることもあります。
于 2009-10-31T13:16:39.713 に答える
0

スクラムは、あなたが示している問題ではありません。ほとんどの開発方法論は機能しますが、ウォーターフォールでさえ、私たちがバッシングしたい限り機能します。スクラムによって、重要なことにもう少し集中できるようになりますが、プロセスに従わないなどの悪い決定を下すことを止めることはできません。

システムの核心は非常にシンプルです。

問題を参照してください。何が行われたかを定義します。やり遂げるための一連のタスクを作成します。それらのタスクを見積もります。短期間で何かを成し遂げられるように、十分な数を選択してください。タスクを完了します。すすいで繰り返します。

確かに、これらの手順は単純化されており、スクラム マスターと顧客は投入していません。しかし重要なのは、このフレームワークは基本的な時間管理戦略に過ぎないということです。システム内の人々が混乱していて、物事を成し遂げるのが苦手な場合、スクラムは実際には役に立ちません。

于 2009-01-05T16:15:40.923 に答える
0

スクラムを本から適用し始め、カスタマイズする前に、アジャイル マニフェストから根底にある原則と価値を本当に理解して、プロセスが変質しないようにすることをお勧めします。毎回のイテレーション (スプリント) の最後にふりかえりを実行して、プロセスを「検査および適応」し、無駄を排除してください。

スクラム マスターは、現在のスプリントから何が削除されたかを追跡できます。また、スプリントは、以前にスケジュールされたものではなく、以前のスプリントの成果に基づいて計画されます。私はその要点を理解していません。

于 2009-01-05T16:29:28.697 に答える