問題タブ [scrum]

私は CMMI レベル 5 の認定を受けているショップで働いています。この認定は、特定の顧客や契約にアクセスできるため、重要です。スクラムと CMMI を融合させる方法を検討しています。スクラムと CMMI-3 の混合に関する情報をいくつか見つけましたが、そのかなりの部分は「手の込んだ」ものであり、厳しい精査に耐えられません。特に、組織の KPA は難しいようです。

2 つのプロセスを混ぜ合わせた経験 (良い点と悪い点) はありますか?

私はスクラムの初心者で、会社にスクラムを実装しようとしています。賛同を得ることは問題ではありません。それは私の会社であり、開発者はこのように働くことを非常に喜んでいます。

問題は、収益の 75% が固定期間/固定価格のプロジェクトから得られていることです。

Ken Schwaber は、彼の著書「スクラムによるアジャイル プロジェクト管理」の中で、本の最後の付録で、固定期間/固定価格プロジェクトの入札に関するトピックを取り上げています。

多くの内省を重ねた結果、Ken は、潜在的なクライアントに別の考え方をするよう説得できる場合にのみ、この状況でスクラムが役立つことを導き出しました。クライアントは、多くの不確実性 (最終的なコストと最終的な納期について) を受け入れる必要があり、それと引き換えに、使用可能なものをはるかに早く入手する必要があり、すべての機能を実装する必要がない可能性があるため、費用を節約できます。

これが固定長/固定価格プロジェクトでスクラムを実装する唯一の方法であるとは確信していません。

他の人がどのようにして固定長/固定価格プロジェクトに入札し、利益を得たか知りたいです。

スクラムを実装したいのですが、スプリントの長さを決めることができません。Ken Schwaber は 30 日間が事実上のものであると述べているようですが、方向転換や優先順位の再設定の可能性なしに 30 日間待つことは想像できません。

私たちのプロジェクトは通常、ウォーターフォール方式を使用して 1 ～ 3 か月しか続かないため、スクラムに移行すると微調整の機会が減る可能性があります。

1週間のスプリントを考えていましたが、これはスクラムのマイクロマネジメントのようです。

2 週間のスプリントが理想的ですが、他の人がこれをうまく実装できたかどうか知りたいです。欠点は何ですか？より短いスプリントでチームを管理するのは、より多くの仕事/より少ない仕事/同じ仕事ですか?

ところで... 3 週間のスプリントは奇妙に思えますが、3 週間のスプリントを行うのは誰ですか? なぜそれを4週間にしませんか。;)

私は現在スクラムについて学んでおり、この分野の経験豊富な専門家から学びたいと思っています。

3 か月かかる (通常、顧客への中間納品が 2 ～ 3 回ある) プロジェクトにベロシティは関係しますか?
統計を適切なものにするのに十分な時間ではないと思います。統計に十分な深さを得るために、プロジェクト全体で開発者ごとのベロシティを記録する価値はありますか?

もう 1 つの質問は、小規模なプロジェクトにとって速度は本当に重要ですか?
私たちはこの分野で多くの経験を積んでおり、見積もりは非常に正確です。私たちが抱えていた唯一の問題は、時々あなたを襲うリスク要因に関連していました.

小さなイテレーション、製品/プロジェクト管理を開発プロセスに非常に近づける隣接統合など、他の部分には多くのロジックが見られます。私たちは、それを知らずにスクラムですでに多くのことを行っていると思います。

要するに、コンセプト全体としてのスクラムが私のニーズに合っているかどうかはわかりませんが、開発プロセスを改善するために多くのコンセプト (バックログが本当に気に入りました) を使用できることがわかります。

実際には質問というより議論ですが、SO はこのために設計されていないため、適切でない場合は申し訳ありません。

あなたの「エンタープライズ」作業環境では、エンジニアはコード検査と単体テストの実行についてどのように責任を負っていますか? ソフトウェアの品質を確保するために、どのようなプロセス (正式な方法論またはカスタム プロセス) に従っていますか? 成果物に開発者の「サインオフ」シートを実装したことがありますか?

前もって感謝します！

更新: Code Collaborator を使用して検査を行っていることを忘れていました。問題は、人々に「理解」してもらい、中核となる人々のグループの外でそれを行うことに同意してもらうことです。以下で stalbot が指摘しているように、これは文化の変化ですが、問題は、レビューや単体テストなどの品質イニシアチブを促進するために文化をどのように変えるかということです。

私が働いている会社は、ソフトウェア開発に関しては歴史的にほとんどプロセスがありませんでした。現在、私たちは実際には特定の方法に従っていません。問題はもちろん、計画を立てたり、まともなリリースを成功させたり、優れたソフトウェア開発者を引き付けることさえ困難にすることです。

ある種のスクラムプロセスを実行するように彼らを説得できるかもしれないと思います。ただし、重要なのは経営陣/所有者の賛同を得ることです。特定の機能を一定期間ロックするという考えは、それらを怖がらせると思います。

誰かが私の主張をする方法について何か提案がありますか？

これまでのところ、次のことを計画しています。

1. スクラムの仕組みについてプレゼンテーションを行います。私たちが現在持っている人々とどのように連携しているのか、そしてそれがビジネスにどのように役立つのか。
2. 特定の人にトレーニングを依頼して、「一緒に進んでいく」ことのないようにします
3. 実装する日付を設定します。いくつかの計画とルーズエンドがあり、プロセスを新たに開始するためにおそらく提携する必要があります。

タイトルが示すように...新しいコードで機能せず、ある程度推定できるものにスクラムプロセスを適用するにはどうすればよいですか？

まだ何かを計画したいときに、メンテナンスおよび緊急修正（修正に5分から2週間かかる場合があります）タイプの環境にスクラムプロセスを適用するにはどうすればよいですか？

基本的に、計画外のタスクやスクラムプロセスで見積もることが非常に難しいタスクを克服するにはどうすればよいですか？それとも、この環境に間違ったプロセスを適用しているだけですか？

スクラムを使用しているが、プロセス全体ではなく時間管理ツールとしてのみ使用しているというチームに参加した場合、あなたはどうしますか? バックテストとドキュメントを元に戻すにはどうすればよいですか?

テストと文書化に特化したユーザー ストーリーを追加することから始めようと考えていました。おそらく、他の誰かがこれについてより多くの経験を持っているでしょう。

参加者の 1 人がインド (+05:30) にいて、他の参加者が米国 (-06:00 と -08:00) にいる場合に、スクラムを形成することは賢明でしょうか? それでは誰にとっても快適な会議時間はありません。

私は、開発プロセスにスクラムを使用するチームに所属しています。現在、最近気づいたいくつかの問題に対処するために、プロセスの特定の側面を改良しようとしています。そうすることで、スクラム プロセス全般について何が好きで、何が嫌いかを探り、チームとして仕事で何を重視するかを特定できるようにします。私たちが何を重視するかを特定できれば、その価値を中心に展開する実装を考え出すことができ、新しいソリューションがチーム内に定着するのに役立つと考えています。

そうは言っても、他の人がスクラムプロセスをどのように見ているかに非常に興味があります。あなたがそれについて本当に好きだったのは何ですか？イライラしたり、オーバーヘッドが多すぎたり非生産的だと感じたりしたのは何ですか? 成功と失敗の具体的な例は問題ありませんが、議論がスクラムの落とし穴やスクラムが本当に優れている場所を中心に展開する、より大きな視点に興味があります。

考え？