あなたのチームは、作業方法（スクラムなど）に従わなくてもうまく機能していますか？

私は過去9年間に多数の小さなチームで働いてきました。それぞれには、短い会議、改訂管理、継続的統合ソフトウェア、問題追跡などの明らかな優良事例がありました。

この9年間、開発方法論についてあまり聞いたことはありません。たとえば、「私たちはスクラムをやっている」、「アジャイルをする」、または参照を超えるものはありませんでした。すべてのチームはうまく機能しているように見えましたが、多くのプロセスを踏まなくても、ただのフリーフローで、自然にうまく機能していました。

スクラム/アジャイル/その他に遭遇することなく、他の誰かが長期間進歩しましたか？

私がこれらにさらされた唯一の露出は、このようなサイトを通してです。私はスプリント会議のような質問を読みます-何を話すべきか ...そしてすべての話は方法論の有限状態機械に従う人々のようなほとんどロボットのことを説明しているようです。それは本当に（誇張されていますが）そのようなものですか？インターネットに投稿している人々は、「ベストプラクティス」を大声で支持しているだけで、教科書の見方も同じで、実際に人々がどのように働いているのかを反映していないのでしょうか？

さらに（私は英国にいるので、関連があるかもしれません）...私が取り組んでいるチームのいずれかに方法論が導入された場合、彼らはそれを愚かで不必要であるとして拒否するでしょう...オン。同意する傾向がありますが、次のプロセスは少し不自然に思えます。これは典型的ですか、それとも一般的ですか？

ここで20年以上の開発経験があり、正式な方法論を使用したことはありません。決してそれらを必要としませんでした、そして、私は将来、それを使うつもりはありません。方法論は一部の人にとっては問題ないかもしれませんが、優れたテスト済みのコードを書く熟練したプログラマーに代わるものではありません。

個人的には、多くの人がその日の一番ホットな新しい方法論に従うことを気にせず、コードの品質にもっと集中するのは難しいと思います。

正直なところ、あなたの小さなチームがプロセスを考えずにここ何年も大事故を起こさずに働いてきたなら、おそらく何らかの形のアジャイルを行っていたでしょう。すべてのアジャイルプロセスとは、反復、ストーリーボードなどについてほとんど何も言わない「アジャイルマニフェスト」http://agilemanifesto.org/に準拠することです。アジャイルの最初のテナントは、「個人およびプロセスとツールを介した相互作用」。うまくいっているチームは、プロセスについて真剣に考える必要はありません。

異なるブランドのアジャイル（スクラムなど）は、お互いに協力することに慣れていない新しいチームがある場合に非常に役立ちます。彼らは、まとまりのあるチームを構築するためのフレームワークを設定し、まとまりのある製品を構築します。

あなたがやっていることが機能している場合、それを続けてください。成果物が常に遅れている場合、残業を定期的に行う必要がある場合、または何かを展開した後に大きなバグを修正する必要がある場合は、何かが間違っています。そのとき、問題を修正するために一連の小さな変更を行います。

すべてが正常であり、常に問題ない場合は問題ありません。したがって、新しい（チームが何らかの方法論-公式またはその他の方法に従っている）を導入することは、実際には時間の無駄です。

しかし、方法論が本当に役立つのは、チームが問題に遭遇したとき、または外部ソースから問題が発生したときです-方法論は、それらを保護するのに役立つ良い実践を導入するだけではありません。あなたが意識的にそれらをしているとき、ストレス下で良い慣行を維持することははるかに簡単です。

正式な方法論は必ずしも必要ではないと思いますが、効果的なIMHOを実現するためには、すべてのチームが仕事に何らかのパターン（必ずしも繰り返す必要はなく、イベント駆動型）が必要です。

解決する問題がなければ、幸運です。

定義済みの方法論がなくても、多くのチーム（特に非常に小さな会社）がうまく機能しているのを見てきました。

方法論（または手法）を実装するのは、楽しいか、インターネットでブログの投稿を読むのは非常に危険です。

大丈夫なら、何も変えないでください。可能な場合は、いくつかの最適化を試してください。

非常に理にかなった方法論、非常識に接する方法論があります。彼らは皆、常識を成文化し、面白い名前をつけてから、たくさんの本/セミナー/などを売っているようです。

あなたの経営陣、または実際にあなたのチームが常識に欠けていて、（意識的であれ暗黙的であれ）有機的に独自の賢明な方法論が整っていない場合、彼らは研究する価値があり、方法論の一部を担いますそのチームの経験に関連しています。

最新の<insert-buzzword-here>労働慣行を全面的に課すことは、それが解決しようとする以上の混乱を引き起こす可能性があります。しかし、通常、非コーディングラインマネージャーが熱心にチェックできる多くのチェックボックスメトリックを提供できます。

アジャイルやスクラムとは呼ばなかったかもしれませんが、プロセスがなく、使用していないという意味ではありません。

ソフトウェア開発自体と同じです。名前で明示的に考えていない場合でも、おそらくいくつかのデザインパターンを使用することになります。