標準とプロセスの改善は、それらを持たない組織にどのように導入すべきですか？

私は、プロセス改善の実装を通じてソフトウェア開発プロセスを改善することを任されてきました。そのプロセスの改善として、CMMI for Developmentバージョン1.3をガイドラインとして使用し、ベストプラクティスを全体的または部分的に採用することになります。標準とプロセスの改善を導入して、開発者からの反発と抵抗の程度を最小限に抑えるための最良の方法は何ですか？

1. ソフトウェアプロセス改善（SPI）プロジェクトを開始します。その範囲と目標を定義します。標準化に独自の目標と測定値が組織に適用できる場合、それは間違いなく役立ちます。
2. 標準を採用する責任者を割り当てます。また、大規模な組織の場合は、数人または部署になることもあります。重要なことは、標準化を担当するすべての人が次のようになるということです。
   • 全体像を見るのに十分な専門家
   • チームに対処し、変更の採用/交渉を支援するのに十分な影響力
3. 採用する標準と組織に適用されるその詳細の両方をカバーするトレーニングを開発します。そして、訓練を受けていないすべての人々が潜在的に変化に抵抗している限り、それは本当に重要です。たとえば、私が大企業で働いていたとき、私はすべての新入社員にQAプロセス、CMMI、ISO、および品質管理システムについて指示しました。そのような訓練は義務でした。これは、品質管理プロセスに関する知識を向上させ、ソフトウェア品質の重要な問題に関する従業員の意識を高めるのに役立ちました。
4. 変更について交渉し、一般的に受け入れられているプラ​​クティスを特定のニーズに合わせて調整します。官僚主義や、誰も本当に必要としない重いプロセスの実装を回避するのに役立ちます。
5. 実装されたプロセス改善がどのようにサポートされているか、およびそれらが組織で十分に効果的であるかどうかの監視を確立します。

また、組織内で本当に品質に関心のあるすべての人々を見つけることができる場合にも役立ちます。おそらく、これらは、変更を促進し、成熟した慣行を確立するのに役立つ最も重要なリソースです。

ハードノックの学校からのカップルの考え：

1）ほとんどのプロセス改善イニシアチブは、時間の80％をプロセス設計に、20％を教育と社会化に費やしています。これらの割合を反転します。従う平凡な標準は、従わない完璧な標準に勝ります。

2）人々に彼らの働き方を変えるように頼む理由を明確にしなさい。ビジネスケースは何ですか？理想的には、すべてのチームに個別に利益をもたらします。時々それはただの全身改善です。いずれにせよ、ケースを表示します。

3）単純化してから標準化します。その逆は行いません。

4）これをPMOに完全に委任することはできません。直属の上司を引き込む必要があり、ビジネスユニットの責任者は苦情が来たときに関係を断ち切る必要があります。

5）フレンドリーなアーリーアダプターを見つける。人々はそれがすべてかかるのにどれだけ時間がかかるかについて不平を言うでしょう。「15分しかかからなかった」と指さして言うことができる人が必要です

6）メトリックについては、定性よりも定量を強く求めます。それ以外の場合は、すべてが1か月遅れるGo Liveの前日まで、環境に優しいプロジェクトがあります。

7）ツールよりもテクニックを強調する。優れた計画は、MS Projectよりも重要です。

8）ニーズに応じたレベルのプロセスを導入します。すべてのレストランにはプロセスが必要ですが、ノブとフレンチランドリーにはマクドナルドとは異なる種類が必要です。ソフトウェア会社も同様です。

幸運を！

評価を受けずに正式な監査と評価を受けていない場合でも、CMMIに基づいて努力することは、おそらく良い考えです。CMMI、CMMI、およびリーンやシックスシグマなどの他のプロセス改善手法、CMMIおよびアジャイルソフトウェア開発については、数多くの資料が入手可能です。SEIは、リソースのコレクション全体持つ異なるCMMIの側面や組織のさまざまな種類の指導について、自由に利用可能ないくつかを、。

段階的アプローチではなく、CMMIを実装するための継続的アプローチを詳しく検討することをお勧めします。これは、組織が現在どこに立っているかを正確に判断し、最もビジネス価値を高める分野を改善するためのはるかに効率的な方法だと私に思わせます。これにより、改善の取り組みをビジネス目標に合わせるだけでなく、進捗マイルストーンをすばやく達成し、改善の効果を示して、すべてのレベルからの賛同を増やすことができます。

ただし、草の根の取り組みの場合、プロセスの改善は一般的に成功するということを覚えておく必要があります。プロセスの変更が上から指示された場合、「塹壕内の」開発者は、塹壕内で行われていることと連絡が取れていないように見えるかもしれません-アイデアが良いものであっても、おそらく反発があるでしょう。これに備えてください。

ある種のエンジニアリングプロセスグループも有益な場合があります。改善の影響を受けたさまざまな組織コンポーネントとチームの代表者を集め、全員の声が聞こえるようにします。これには、各役割の代表者だけでなく、さまざまな製品開発チームが含まれる可能性があります。あなたの組織がどのように構造化されているかを知らなければ、あなたが誰を見たいのか正確には言えませんが、グループの組織のあらゆるレベルの人々を含めます。また、このグループで行われた議論と決定を組織がコメントや問題提起のために利用できるようにします。

変更ごとに：

• 1つの変更点と、それによって開発がどのように改善されるかを説明します。
• 変更を実装します。
• 改善を示す
• 改善を示さなかった変更を削除する

明らかに、分析は時間の経過とともに行われる必要がありますが、効果的であることが実証されるまで、変更は受け入れられません。それが、サイクルごとに2〜3個以下の変更を実装する理由でもあります。そうしないと、改善があるかどうかを測定できないことがよくあります。

実際に環境にとってベストプラクティスであることを示す分析を行わずに、盲目的にベストプラクティスを実行することほど、私を苛立たせるものはありません。ベストプラクティスの改善を示さない最高無駄にしてダメージを与える最悪です。

プロセスのすべてのステップと方法論のすべての実践は分析され、有益であることを証明する必要があります。そうでない場合は、削除する必要があります。 この分析は、ステップやプラクティスの追加や削除に関係なく、継続的に行う必要があります。