厳格なアジル

私は、しばしば、アジャイル手法には厳密な定義がないという苦情に出くわします。苦情を言う人は、これにより、特定のチームがアジャイル手法を使用しているかどうかを判断できないと主張します。アジャイル手法の実施方法を人々に教えるのが難しいと主張する人もいます。カリキュラムはどのようなものでしょうか。

ある程度、この苦情の痛みを感じていますが、治療法はないと諦めています。この厳密さの欠如は、アジャイル手法の本質的な性質の一部であり、その核となる哲学の一部です。

思考プロセス全般（特にソフトウェア開発）の基本的な問題の1つは、設定の性質が非常に多様であることです。異なる種類のシステムには、異なる種類の圧力と力が作用します。そのため、それらをすべてカバーするのに十分な厳格な行動計画を作成するのは非常に困難です。この影響は、ソフトウェア開発が、人と密接に関わる活動であり、人は本質的に矛盾し、非常に変動しやすいという事実によって増幅されます。アジャイリストがここから導いた結論は、ソフトウェア開発を厳密なプロセスに拘束しようとするのは効果がないということです。それは、プロセスを実行する一次的な（人的）コンポーネントの本質的な性質を無視することになるからです。

（おそらく、私たちの職業はコンピュータで作業することであるため、コンピュータにプログラムする方法と同じ方法で人間のシステムにプログラムしたいと考えてしまうのです。それらが非常に異なるという事実にもかかわらず。）

これらすべてを要約すると、アジャイル手法は、チームがに従うべきプロセスを決定することを根本的に想定し、さらに、チームが能動的にかつ定期的にプロセスを変更することを想定しています。適合性をテストするためにテストできる厳密なプロセスを定義しようとする試みはすべて、この哲学に反します。

これがイライラするものだということを否定することはできません。スクラムの明確な定義がそもそも得られない場合、アジャイル手法が他の選択肢よりも効果的であるかどうか、またはエクストリーム プログラミングがスクラムよりも効果的であるかどうかについて調査を行うことはどのようにできますか？クライアントがエクストリーム プログラミングを使用して構築されたシステムを望む場合、それが実際に実行されているかどうかをどのように判断できますか？「見て分かれば分かる」という感覚がありますが、その感覚を得るには経験豊富な実践者が必要であり、たとえそうであっても、そのような実践者が意見の相違を生じさせる余地は十分にあります。

私にはこの難問に対する答えがありません。実際、私は答えがあるとは思いません。それは、水泳で濡れるのは避けられないのと同じように、活動そのものの不幸な結果なのです。

2012年7月26日に再掲載