プロジェクトの実装-一度に1ステップ

プロジェクトは、正常に完了した場合に特定の結果につながるアクションのリストとして説明できます。 1人以上の実行者がアクションを実行できます。 そのようなアクションの数は、数十から数千の範囲です。 プロジェクトは、数日、数ヶ月、または数年続くことがあります。 プロジェクトの編成と実装を促進するために設計された何百もの方法論とツールがあります。 それらのそれぞれは、特定のタイプのプロジェクトに多かれ少なかれ適しています。 それらのいくつかは混在しています。 いくつかは、さまざまな状況で役立つテクニックです。



そのようなテクニックの1つがこれです。一度に1つのステップを踏みます。



私たちは皆、プロジェクトの最も重要で重要な段階の1つが最終段階であることを知っています。 これは、仕事の結果が、それが何であれ、クライアント、一般に提示されるか、誰にも通知せずに仕事を始める時です。 この期間中に、最も複雑な問題が特定され、解決されます。 多くの場合、多くの作業が廃棄され、新しいソリューションの実装のために実現できないことがよくあります。 一般的に、最終段階の多くのプロジェクトは仕上げを急ぎます。 新しいソリューションを使用する古いシステムからの脱却、および新しいソリューションの統合として、これはすべて非常に困難であり、多くのストレスの多い状況を作り出し、かなりの害をもたらします。



このような困難を排除するために使用できる基本原則の1つは、スクラム方法論からとることができます。 不完全な作業項目（基本作業単位と考えることができます）は、いわゆる作業項目に対応する場合、完了したと見なすことができます。 「実装の条件。」 実装条件はプロジェクトごとに異なる場合があります。 一部のチームでは、これは回帰条件が満たされていることを意味する場合があります。 ただし、最も重要な実行条件の1つは、ワークアイテムが本番システムで完了して実行されることです。 ブレークスルーが3週間以上続くことはないため、3週間ごとにターゲット環境にすべての完成した要素を実装する必要があることがわかります。 その結果、プロジェクトを完了する過程で「仕上がり」がなくなります。 システムに根本的な変更や変更はありません。 最後の要素の穏やかな完成と、生産への導入のみがあります。



この原則はどのように小さなタスクに使用できますか？ プロジェクトを開始する場合でも、別のタスクを開始する場合でも、次の基準を満たす小さなステージに分割する方法を検討してください。

• 各段階で生産プロセスに最終的な変更が加えられますが、この段階ではこれ以上の変更は必要ありません。
• 各ステージには、ユーザーとシステムにとって、または後続のステージの実装を確実にするために、特定の値があります。
• 各段階を完了すると、システムは安定した状態になり、数週間経過しても何も進行しなければ何も問題はありません。

このアプローチの利点は非常に明白です。 プロジェクトの最終段階では、大きな変更はありません。 ほんの一握りの小さな追加があります。 ただし、このアプローチには重大な欠点が1つあります。それはコストです。 プロジェクトの規模と種類に応じて、このアプローチのコストは大幅に高くなる可能性があります。 しかし、これは常に決定要因ではありません。



上記の概念は、一見すると不可能に思えるかもしれません。 ただし、ほとんどの問題はこの方法を使用して解決できます。 努力の適用点とそれをワークフローに導入できる手段を見つけることだけが必要です。 数百のモジュールを持つ巨大なプロジェクトシステムのレイアウトを変更するプロセスを検討してください。 頭に浮かぶ最初のアプローチは、移行に数か月を費やし、しばらくしてシステムにすべての変更を適用し、「大きなスイッチ」を切り替えることです。 深刻な問題や会社の混乱の可能性は非常に高いです。 実際、いくつかの要素がまったく機能しないことは間違いありません。



モジュラー移行も最適なソリューションではない場合があります。 同じシステム内で2つのレイアウトを数か月にわたって同時に使用すると、開発者にとって大きな問題が発生する可能性があり、追加の毎日の負荷がかかる可能性があります。 小さなステップの原則を適用するには、古いシステムを新しいシステムに「ラップ」する必要があります。 これはどういう意味ですか？ 最初のステップとして、新しいシステムを古いシステムに変えるという原則が使用されます。 次に、ステップごとに機能が新しいレイアウトシステムに移行します。これは、開発者とCIの監督下で行われます。 小さな変更はすべて、完了するとすぐに実装されます。 結果：プロジェクトの終了時に大きな変更はありません。



別の例は、あるソース管理ツールから別のソース管理ツールへの移行です。 企業がそのようなツールを使用して再構成または再構成を必要とする数十のシステムを持っている場合、ほとんどの場合、数日（または数週間）会社を停止する必要があります。 このタスクに対処し、小さなステップの方法を適用するために、このようなアクションプランを作成できます。 古いシステムへのすべての変更は、新しいソースコード管理ツールにリアルタイムで移行する必要があります。 この方法のおかげで、すべてのシステムを段階的に新しいソリューションに再構成できますが、すべての会社のスタッフは古いソリューションを使用します。 すべてのシステムが正常に機能するという確信が現れた後、移行はユーザーに通知することのみになります。すべてが新しいツールで機能し、ツールに切り替えることができ、古いツールは無効になります。



「一度に1ステップ」のアプローチを使用すると、プロジェクト完了段階での大きな頭痛を防ぐことができます。 また、他の方法では実装できなかった、または非常に困難なプロジェクトを実装することもできます。 ただし、これには代償が伴います。 多くの場合、このアプローチをうまく適用するには、適切なベースを編成し、必要な資金を作成する必要があります。 いつものように、このアプローチを使用するか使用しないかは、状況に応じてそれぞれのケースで決定する必要があります。