先週実施したブレーンストーミングセッションの興味深い結果についてお話したいと思います。
現時点で興味深いのは、アジャイルプロジェクトを操作するためのガントダイアグラムの機能を再考したことです。 攻撃の前に、同僚と私は、この図をプロジェクト計画とその進捗を表示する多くの方法の1つと考えました。 この概算では、タスクのリスト、開発者のリスト、カレンダー、および進捗チームからの一連のレポートがあり、ガント、PERT、バックログなどのさまざまなビューで表示できます。
私たちは間違っていたことが判明しました。 「ローカルな」否定的な結果に加えて、アジャイルプロジェクトを管理するイデオロギーと哲学のレベルでかなり重要な一般化を受けました。
背景
さまざまな表示モードでプロジェクト計画を操作するためのオンラインツールを開発しています。 決定的プロセスから始めて、クリティカルパスを持つガント図とPERT図を実装しました。 現在、スクラムなどの経験的プロセスを接続しています。 サービスユーザーに提供する一般的なイデオロギーは、両方のタイプのプロセスの統合です 。
したがって、ガントダイアグラムを使用してモデル化された共通の決定要因プロジェクト計画があります。 現在、スクラムの反復を開始しています。 反復に含まれるこのガントからタスク範囲を切り取り、ガント図とバックログ図の間でビューを切り替えることができるようにする必要があります。 実装を開始した最初のモデルは単純に考え抜かれたものです。反復計画ページには、対応する2つのブックマークがあり、それらを切り替えると、ガント反復またはバックログ反復のいずれかが表示されます。 同時に、タスクのレポートは次のように構成されています。ユーザーは定期的に（1日に2〜8回）システムに短いメッセージを書き込むか、2つのフィールドで構成されるツイートを書き込みます。 最初のフィールドは、古典的なツイート（実装ステータスの説明を含む短いテキスト、2番目のフィールド）は、タスクが完了するまでの残り時間（時間単位）に対応する数字です。 「ガント」タブと「バックログ」タブを切り替えると、このデータはバックログの「セル」に移動します。
ガントのタスクの進行中に再集計された：
それはすべて、この機能を実装したプログラマー（Volodya）が、実装中に重大な論理的矛盾があるというメッセージを送信したときに始まりました。 私たちはフラスターでボードの近くに集まり、ブレーンストーミングセッションを開始しました。
問題
Volodyaは、彼が遭遇した2つの矛盾について説明しました。
1.タスクがタスクのために一時停止されている場合、ガントはタスクの段階的な「幻想」進行を示します。 さらに、ダウンタイムが長いほど、進行状況が大きく表示されます。
2.リソースの動きを示すことはできません。 スクラムのタスクに応じた人の分布は非常に動的であり、これはガントにとって問題になります。
問題を掘り下げましょう。 反復には、小さな独立したプロジェクトの特性があります。 マネージャーがこの反復のためにガントを描いた場合、計画されたものに拘束されるためには、彼のスケジュールを順守する必要があります。 タスク間の期間や依存関係を常に更新する必要はありません。 開発者の進捗は、 不変のタスクとその依存関係の厳格な構造内に示される必要があります。
このスキームでは、progress％= 100 * hours_spent /（hours_spent + hours_left）の式を使用してガントのタスクの進行状況を計算します。ここで、progress％は進行状況（％）、hours_spentは経過時間数、hours_leftは残りの実装の最後の推定値です時間。 この式は、タスクの予定期間を超えるまで機能します。 投機的な例を想像してください。タスクで何も行われていません。実装に8時間かかり、このタスクを忘れて1か月後に戻ってきました。 進捗は100 * 20 * 8 /（20 * 8 + 8）= 95％になります！ 仕事を始めていないなら！
ブレーンストーミングの過程で、いくつかのアイデアが式の修正に至りましたが、それらはすべてすぐに除外されました。 ある時点で、彼らはタスクをカレンダー内で動的に移動し、その期間を変更することにしました。 しかし、この方向は行き止まりであることが判明しました。 継続的に変化するタスクの完了率は何ですか？！ さらに、タスク間の依存関係により、反復の長さを超えてタスクの構造全体が迅速に取得されます。
ガント上のタスク間で人を移動する場合も、タスクと関係の構造を根本的に再設計する必要があります。 結果-スプリント中、ガントはすぐに関連性を失います。
問題の技術的な解決策を見つけられず、より高いレベルに移動しました-抽象化へ。
抽象化
アインシュタインはすでに気づき、表明しているようです、「深刻な問題はそれが起きたのと同じレベルでは解決できない」。 私たちはしばらく詳細を捨て、ガントとバックログの根本的な違いを探し始めました。 そして彼らは見つけた...
いくつかのスローガン（簡潔で簡潔なアイデア）が策定され、攻撃のさらなる進路が決定されました。
-ガントは静的なチャートであり、バックログは動的なチャートです。
-バックログは、1つの図ではなく、ガント図のシーケンスに投影されます。
-バックログには毎日、個別のガントチャートがあります。
これら2つの図の自由度を比較した後、いくつかの詳細が追加されました...
自由度のバックログ：
-タスクの期間
-タスク実行者
-反復中のタスクの数
自由度ガント：
-タスクの進行状況
最後に、問題の解決策を策定し、計画ページだけでなく、アプリケーション全体のイデオロギーも「フック」しました...
解決策
ガントは、アジャイル（または経験的）反復計画には適用されません。 これは、バックログまたは同様の動的な図の対象範囲です。 決定要因と経験的プロセスの境界は、プロジェクトの一般的な計画のレベルとそのフェーズ、および反復レベルの間にあります。
私たちのアプリケーションでは（これまで）記述されたレベルはなく、ドキュメントと同様に個々のプランを使用します。 新しい計画を作成するときは、決定プロセスまたは経験的なプロセスを使用して、ユーザーに進行中のプロセスを尋ねます。 この選択を行った後、ユーザーはプロジェクトの視覚化へのアプローチを一意に決定します。 計画ページでは、決定論的アプローチで、ユーザーにはガントブックマークとPERTブックマークが表示され、経験的なブックマークではバックログとバーンダウンが表示されます。
あなたへの明るい考え！