私が働いている会社は、ソフトウェア開発に関しては歴史的にほとんどプロセスがありませんでした。現在、私たちは実際には特定の方法に従っていません。問題はもちろん、計画を立てたり、まともなリリースを成功させたり、優れたソフトウェア開発者を引き付けることさえ困難にすることです。
ある種のスクラムプロセスを実行するように彼らを説得できるかもしれないと思います。ただし、重要なのは経営陣/所有者の賛同を得ることです。特定の機能を一定期間ロックするという考えは、それらを怖がらせると思います。
誰かが私の主張をする方法について何か提案がありますか？
これまでのところ、次のことを計画しています。
プロジェクトが標準/典型的な IT プロジェクトのようなものである場合、プロジェクトが失敗したか、バグが多かったか、コストがかかりすぎたか、顧客 (内部または外部) が必要とすることをしなかったか、開発に時間がかかりすぎた可能性があります。 .
プロセスを提唱する場合は、構造を持つだけで柔軟性を失わないことを示す必要があります。
意思決定者へのポイント:
いくつかの小さな変更が最初に実装されます。これは概念実証であり、必要に応じて安全かつ簡単に取り消すことができます。 たとえば、これは、認識されているリスクを軽減していることを示しています。そして、認識されたリスク を軽減する必要があります。とはいえ、提案を行う前に、いくつかのデータを収集する必要があります。なんで？良い質問です。ベースラインが必要な理由は 2 つあります。
私の経験では、設計方法論や実践が一度試験運用された後は、管理を売り込む方が簡単です。私なら、通常は可能であれば社内向けの小さなプロジェクトを選んで、新しいスクラム プロセスを「パイロット」するよう依頼します。一般に、パイロットは限定的にコミットするだけでよいため、パイロットに参加してもらうのははるかに簡単です。
新しいスクラム化されたパイロット プロジェクトが進行するにつれて、スクラムが以前の (ない) 方法よりもプロジェクトをどのように成功させているか (付箋、メモ帳、Word 文書など) を必ず文書化してください。ここでは残酷に正直になり、可能な限り実際の言葉で物事を定量化するようにしてください.
プロジェクトが完了したら、メモをまとめ、完了したプロジェクトを証拠として使用して、調査結果を経営陣に提示します。次のような調査結果を使用します。
一般に、リーダーがドルとセントの結論を引き出すことができる場所に導くことができれば、リーダーは新しい製品または方法論を採用します。また、これも重要なことですが、パイロット中に元のプロセスのアイデアがうまくいかないことがわかった場合は、元のプロセスのアイデアから離れる準備をしてください。
幸運と幸せな生産性!
スクラムを「負けない」命題として売り込むことができます。スクラムを使用するとどうなるか見てみましょう:
私がこれまでスクラムに対して見た唯一の合理的な反論は、プロジェクトの費用や所要時間を予測することは実際には不可能だということです。これは、スクラムが、プロジェクトの開始時に全員が学習し、要件が変化することを認めているためです。Waterfall はこれができるふりをしていますが、これがどれほどうまく機能するかは誰もが知っています。
Joel Testを実行して、実行する必要のある作業量を決定します。リリース日の見積もりに問題がある場合は、エビデンスベースのスケジューリングを調べてください。
主要な意思決定者が経験した過去の問題点にスクラムがどのように対処するかを示す何らかの議論を提供します。これを示す証拠も提供できる場合は、追加のポイント。
経営陣がそれを知らず、気にしないために、プロセスがない可能性もあることに注意してください。マネージャーがプロセスに関心がない、または理解していない場合、そのようなプロセスは、すべてのプログラマー (または少なくともチーム リーダー) に同意してもらい、新入社員に「これが物事のやり方です」と伝えることから始めることもできます。もちろん、これを行う場合は、マネージャーの要件と互換性のあるプロセスを選択する必要があります (たとえば、マネージャーがマイルストーンに関する毎日の更新を要求する場合、最初の 2 週間はコーディングのないプロセスを選択しないでください)。 .
これは、マネージャーと話し合って、彼らの基本的な反応が「コードを書き続ける限り問題ではない」という場合にのみ適切です。新しい作業を追加するプロセスとしてではなく、完了した作業の順序を再配分する手段としてプロセスを提示すると、そのようなアプローチで成功する可能性が高くなります。