チームでSCRUMを使用するよりも、より形式的で軽量なプロセスを使用する必要があるのはなぜですか？
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 SCRUMまたはその派生物は、おそらくソフトウェア開発を管理するための良い方法であることを理解していると言って、質問を始めたいと思います。すべての大企業と私のマネージャーがそれを使用している、または使用しているようであり、私はそのすべての経験について本当に議論することはできません。しかし、私は「理由」とすべての読書を理解するのに苦労しています。職場での公式のSCRUMトレーニングでさえ、私のために仕事をしていません。それはすべてレトリックです。そこで私は答えを求めてここに来ました。 これまで、私は4〜5人のメンバーからなるチームで非常に効果的かつ完全に自己組織化し、トレーニング、方法論、または特別なソフトウェアを必要とせずに開発してきました。キューブでのディスカッション、アドホックミーティング、1対1のコードレビューのみ。私は現在、SCRUMが進むべき道であり、それに付随するすべてのものであると言われている職場の立場にいます。彼らが私にSCRUMを説明するとき、私はこのようなものを読みます： プロセスとツールを介した個人と相互作用 包括的なドキュメントよりも機能するソフトウェア 契約交渉を介した顧客コラボレーション 計画に従うことによる変化への対応 それは素晴らしいことですが、それはすべて私にとって常識のように思えます。なぜこれが成文化される必要があったのですか？そして、私は方法論が変化への対応に役立つと言われています。どのような具体的なSCRUMの側面により、以前はアドホック会議、キューブディスカッション、および開発者計画会議で達成できなかったほど柔軟に対応できますか？彼らは、2週間ごとに作業成果物、またはスプリントを用意する必要性を説明しています。私の特定のプロジェクトでは、「クライアント」は存在せず、ソフトウェアは1年以上は完成しません。その間は、毎月またはそれ以下で上級管理職にデモを行うだけでしょう。では、なぜ隔週ごとに成果物が明示的に必要なのでしょうか？チーム全体が次のスプリントのストーリーとタスクをレイアウトするスプリント計画会議の重要性を強調しています。これは、私が過去に開催した即席の計画会議と同じです。なぜ隔週月曜日に発生しなければならないのか、そして、なぜチーム全体が関与しなければならないのですか？私はすべてのメンバーが製品を「所有する」という概念を理解していますが、実際には、各ストーリーをタスクに分割するのに実際に貢献できるのはごく少数の個人のみであり、他のメンバーはただ見過ごしています。 繰り返しますが、私は大多数の人々がこのプロセスの背後にいることを理解しています。理由を理解したいだけです。私の問題は、これらのことをすでに実践していて、それらを不必要に成文化することを好まないことですか？または、これらの手法が不適切に行われているため、これらの手法の利点をまだ見ていませんか？任意の実数この上、個人情報やアドバイスが、私が受信に使用しています熱弁は対照的に、非常に高く評価されるだろう。