一貫した変化を考えると、計画期間の短さは短すぎますか？

変更は珍しくなく、要件の変更、仕様の変更、ワークフローの変更です。変化があることを受け入れましたが、私は疑問に思います。変化が起こることを知っていると、計画期間の短さが短すぎますか？（正当化が奨励されます）

• 繰り返し（2〜4週間）？
• 一週間？
• 2〜3日ですか？
• 一日？
• 1日1/2？

会社が現在から1 [時間間隔（上から）]を「計画」し、計画が次のように聞こえると仮定します。

「[今朝/今日/今週の/ etc。]あなたは上で動作するでしょう。このと[今日の午後/明日/来週の/ etc。]あなたは上の作業になりますもの。

また、フォーカス/方向の変更が毎秒から3番目の時間間隔で一貫して発生するとします。

私はスクラムプラクティショナーなので、使用することをお勧めします。

1. 反復の期間を定義します。スタートアップでは2週間、大規模なエンタープライズプロジェクトでは1か月の繰り返しが好きです
2. イテレーションの最初に、製品バックログから開発する機能から選択します。製品マネージャーでさえ、誰も反復計画を変更する権利はありません。
3. 変更は、反復計画ではなく、製品のバックログで発生します。したがって、作業に影響を受けることはありません。

Scrumに関する詳細

多くの場合、計画を立てると、全体像が細部まで失われてしまい、最終的にはホイールを回転させてしまうことになります。それは大きなリスクです。

私はXP（またはスクラム）を使用することを好んでいます。これは、各反復の開始時に一度計画する必要があると述べています。

とは言っても、かんばんには必要に応じて計画を立てることができる非常に優れた点がいくつかありますが、私は個人的にかんばんは開発をゼロから開始するときよりも保守とサポートの状況に適していると思います。

私はこのように物事を分解します：

1. 重要なプロジェクト/アプリケーションの開発-1週間。
2. 単純な1回限りの拡張機能がリストに入れられ、優先順位が付けられ、それぞれが半日から1日の期間で対処されます。
3. 通常、バグ修正が優先され、＃2と同様のプロセスが実行されますが、より迅速に修正できる場合もあります。

ここで重要なのは、特定のタスクに対して実際にどれだけの計画を立てることができるかです。yadda、yadda、yaddaを実行する新しいWebサイトを開始すると、バグを修正するよりも前もって計画を立てることができます。誰が事前にバグを計画していますか？部長は、何かを忘れて、四半期末のレポートにそれが必要であることを発見した場合、あなたは物事を脇に置いて、それに取り組む必要があります。

毎週の反復には10時間または50時間かかる場合があります。それはすべて、他のものがどれだけ即時に行われるかに依存します。ちょっとした追加をするためにプロジェクトをわきに置くべきなら、あなたが尋ねたときに経営陣が時間の制約を理解する方がはるかに簡単だと思いますか？その小さな変更が不必要であると彼らが認めたとき、私は嬉しいことに驚き、yadda-yadda-yadda-websiteで作業を続ける必要があります。