標準とプロセスの改善は、それらがない組織にどのように導入する必要がありますか？
私は、プロセス改善の実装を通じてソフトウェア開発プロセスを改善する任務を負っています。その中で、ガイドラインとして CMMI for Development、バージョン1. を使用し、全体またはベストプラクティスを採用する可能性があります。ある程度。開発者からのプッシュバックと抵抗の程度を最小限に抑えるために、標準とプロセスの改善を導入するための最良の方法は何ですか？
- ソフトウェアプロセス改善（SPI）プロジェクトの開始。その範囲と目標を定義します。標準化に独自の目標と対策が組織に適用できる場合、それは間違いなく役立ちます。
- 標準の採用責任者を割り当てる。また、大規模な組織の場合は、数人または部門でさえあるかもしれません。重要なことは、標準化の責任者はすべて次のようになるということです。
- 全体像を見るのに十分な専門家
- チームに対処し、チームが変更を採用/交渉するのを助けるために十分に影響力がある
- トレーニングの開発採用したい標準と組織に適用されたその詳細の両方をカバーします。そして、訓練を受けていないすべての人々が潜在的に変化に抵抗する限り、それは本当に重要です。たとえば、大企業で働いていたとき、QAプロセス、CMMI、ISO、品質マネジメントシステムについてすべての新入社員に指示しました。そのような訓練は義務的でした。これは、品質管理プロセスに関する知識を向上させ、ソフトウェア品質の重要な問題に関する従業員の意識を高めるのに役立ちました。
- 変更の交渉そして、特定のニーズに合わせて一般的に受け入れられている慣行を調整します。官僚主義や、誰も本当に必要としない重いプロセスの実装を回避するのに役立ちます。
- モニタリングの確立実装されたプロセス改善がどのようにサポートされているか、およびそれらが組織で十分に効果的かどうか。
また、組織内で本当に品質に関心があるすべての人々を見つけることができる場合にも役立ちます。おそらく、これらは、変更を促進し、成熟したプラクティスを確立するのに役立つ最も重要なリソースです。
ハードノックの学校からのいくつかの考え：
1）ほとんどのプロセス改善イニシアチブは、時間の80％をプロセス設計に、20％を教育と社会化に費やしています。これらのパーセンテージを反転します。従う平凡な基準は、そうでない完璧な基準を打ち負かします。
2）人々に彼らの働き方を変えるように頼んでいる明確な理由を特定します。ビジネスケースは何ですか？理想的には、すべてのチームに個別にメリットがあります。時々、それは単なる全身改善です。いずれにせよ、ケースを表示します。
3）単純化してから標準化しますが、その逆ではありません。
4）これをPMOに完全に委任することはできません。直属の上司を引き込む必要があり、ビジネスユニットの責任者は苦情が来たときに関係を断ち切る必要があります。
5）友好的なアーリーアダプターを見つけます。人々はそれがすべてかかるのにどれだけ時間がかかるかについて不平を言うでしょう。 「15分しかかからなかった」と指差して言うことができる人が必要です
6）メトリックについては、定性的よりも定量的を強く押します。それ以外の場合は、すべてが1か月遅れるGo Liveの前日まで、環境に優しいプロジェクトがあります。
7）ツールよりもテクニックを強調する。適切な計画はMSProjectよりも重要です。
8）ニーズに応じたレベルのプロセスを導入します。すべてのレストランにはプロセスが必要ですが、ノブとフレンチランドリーには、マクドナルドとは異なる種類が必要です。ソフトウェア会社も同じです。
幸運を！
評価を受けずに正式な監査と評価を受けていない場合でも、CMMIに基づいて努力することは、おそらく良い考えです。 [〜＃〜] cmmi [〜＃〜] 、CMMI、およびリーンや シックスシグマなどの他のプロセス改善手法について利用できる文献はたくさんあります。 、および CMMIおよびアジャイルソフトウェア開発 。 SEIには、CMMIのさまざまな側面とさまざまなタイプの組織のガイダンスに関するリソースのコレクション全体 があり、一部は無料で利用できます。
段階的アプローチではなく、CMMIを実装するための継続的なアプローチを深く検討することをお勧めします。それは、あなたの組織が現在どこに立っているかを正確に判断し、最もビジネス価値を付加する分野で改善するためのはるかに効率的な方法として私を驚かせます。これにより、改善の取り組みをビジネス目標に合わせるだけでなく、進捗状況のマイルストーンをすばやく達成し、改善の効果を実証して、すべてのレベルからの賛同を得ることができます。
ただし、覚えておくべきことは、プロセスの改善は、草の根の取り組みである場合、一般的に成功するということです。プロセスの変更が上から指示された場合、「塹壕内の」開発者は、塹壕内で行われていることと連絡が取れていないように見えるかもしれません-たとえアイデアが良いものであっても、おそらく反発があるでしょう。これに備えてください。
ある種の エンジニアリングプロセスグループ も有益かもしれません。改善の影響を受けたさまざまな組織コンポーネントとチームの代表者を集め、全員の声が聞こえるようにします。これには、各役割の代表者だけでなく、おそらくさまざまな製品開発チームが含まれます。あなたの組織がどのように構成されているかを知らなければ、誰を見たいのか正確には言えませんが、組織のあらゆるレベルの人々をグループに含めます。また、このグループが行った議論と決定を組織がコメントや問題の提起に利用できるようにします。
変更ごとに：
- 1つの変更点と、それによって開発がどのように改善されるかを説明します。
- 変更を実装します。
- 改善の実証
- 改善を示さなかった変更を削除します
明らかに分析は時間の経過とともに行われる必要がありますが、効果的であることが示されるまで変更は受け入れられません。そのため、1サイクルあたり2〜3回の変更しか実装しません。そうしないと、改善があったかどうかを測定できないことがよくあります。
ベストプラクティスを分析することなく、実際にベストプラクティスが環境に適していることを示すことなく、何も私をイライラさせません。 ベストプラクティス改善を示さないものは、せいぜい無駄であり、最悪の場合は損害を与えます。
プロセスのすべてのステップと方法論のすべてのプラクティスを分析し、有益であることが証明する必要があります。そうでない場合は、削除する必要があります。 この分析は、ステップやプラクティスの追加または削除に関係なく、継続的に実行する必要があります。