私は、ソフトウェア開発においてどのプラクティスがうまく機能するか、または機能しないかについての本をたくさん読みました。また、ITIL や CMMI のような方法論について、開発分野の Web キャストや本やブログで聞いたことはありません。
私の学校でこれらの方法論について聞いたことがありますが、それは官僚的な慣行のように思えます。
しかし、私が読んだ開発に関するすべての本は、コラボレーション、またはドキュメントよりも人について語っています。(はい、アジャイルの本がたくさんあります)
だから私の質問は: ITIL や CMMI のような方法論は、開発や開発者の日常生活に何らかの影響や関係を持っていますか? また、開発チームで使用できるこれらの方法論の優れたアイデアについて説明している優れた本やブログはありますか?
ITIL は、開発ではなく、インフラストラクチャとサポートの側面に重点を置いているため、ITIL の議論は、開発中と思われる StackOverflow の「IT」に重点を置いたバージョンにおそらくより適しています。余談ですが、IT はほとんどの企業のインフラストラクチャ、サポート、および開発を網羅しているため、他のサイトを「IT」に焦点を当てていると呼んでいます。おそらく、StackOverflow ユーザーのかなりの割合が IT 部門の開発者です。
私は、Watts Humphrey と Carnegie Mellon Software Engineering Institute の製品である CMMI と Team Software Process (TSP) を使用してきました。継続的な改善に取り組んでおり、測定が継続的な改善の中心であると信じている場合は、CMMI に価値を見出すことができます。
CMMI (および TSP) を間違った方法で行ったり、開発者を疎外したりして、最終的には見栄えのするものや、山積みの認証に見栄えのするものになってしまうのは非常に簡単です。インドの開発ベンダーを見てください... 彼らは奇跡的にすべて CMMI レベル 5 です。組織の 95% がそこにいないだけです。
時間追跡 (クロック パンチング)、欠陥追跡 (バグ クォータ)、コード行 (気が向いたら「ゲーム」する方法がたくさんあります)、およびプロセスを反復可能にする (開発者が歯車のない歯車のように感じられるようにする) に焦点を当てます。革新する自由) 多くの開発者をオフにします。<-- 括弧内のうんざりした反論に注意してください。
世の中の開発者の 90% (StackOverflow やテクニカル ブログ/Web サイトを読んでいる人はほとんどいません) がヒップから飛び出しており、改善の機会がどこにあるのかという自己認識がひどく欠けているという事実は変わりません。彼らにとって、プロセスの厳密さと、繰り返しと測定が促進するという自己認識を通じて品質を段階的に改善する機会は、CMMI の貴重な要素です。
正しく行えば、反復可能な反復、各反復からの学習、および目標の改善/絞り込みに焦点を当てたスクラムのようなアジャイル手法から同じ利点が得られます。アジャイル手法または CMMI のいずれかを採用してチームを導き、それらから十分な価値を得るには、多くの成熟度と経験が必要です。
アジャイルは魅力的ですが、CMMI はセクシーとはほど遠いものです。
アジャイルの採用は、ボトムアップで行われる傾向があります。技術者がアジャイルに出くわし、経営陣に勧めます。
ITIL/CMMI はトップダウンになる傾向があります。経営陣はそれに出くわし、技術者に押し付けます。
それは、一方が良くて他方が悪いということではありません。ほとんどの場合、各アプローチを説明するために使用される言語に影響します。そして例外もたくさんあります - CMMI を適用するのが得意な塹壕での経験を持つ人々と、アジャイルを理解するマネージャーです。
「アジャイル CMMI」を Google で検索すると、多くのヒットが得られます。進行中の議論であるため、私は特に 1 つをお勧めしません (つまり、これらの人々の一部は明らかに間違っています)。
私の見解では、プロセスの概念は、日々のソフトウェア開発作業を分析する際に役立つアイデアです。いくつかの繰り返しの活動があり、これらの活動がよく似た順序で編成されているという考えは、改善につながる質問をするための良い開始点です。また、何が反復可能で、どのような条件の下で活動を管理対象と呼ぶことができるかを尋ねることで、いくらかのマイレージを得ることができます。
エラーと過剰は、魔法のような思考が始まるときに始まります。そのようには機能しません。