この短い投稿では、プロジェクト管理の問題を取り上げ、かんばんと滝を組み合わせるというアイデアを実装するためのプロトタイプとしてこれを追加します。
前文
繰り返し写真に直面しました：マネージャーは期限を言い、タスクトラッカーを与える必要があります。 解決策はこれです-MS Project / TeamWorkまたはWaterfallに馴染みのあるツールで、カスタムJira / Trelloまたは他の何かを追跡するためのプロジェクト計画。 私は、マネージャーの苦痛を前後に更新することで見ており、ウォーターフォールとかんばんとを結合するためにアイデアが生まれました：系統的かつ実用的に（Gtk＃でひざまずきの自家製の実装の一部として）。
アンブラ、そのまま
系統的に
かんばんは、何よりもまず、タスクのステータスの変化の分析です。 おなじみの滝は、タスクシーケンス分析です。 この点で、一見、交差点はありません-スケジュールされたタスクはステータスを変更できます（さらにMS Projectまたはどこでも）。 ただし、かんばん予測は、タスクが最終ステータスに達するまでの時間に基づいており、ステータスは実行者自身によって変更され、事実を作成しますが、ウォーターフォールは予定された日付を提供します。 これを1つにまとめるには、かんばんパスに沿った任意の方向に実行者がウォーターフォールタスクを追跡できるようにするのに十分な原始的です。 ウォーターフォール計画を作成した後、マネージャーの通常のタスクはそれからの逸脱の分析になります-開発者や他のプロジェクト実装者の通常の業務はタスクのステータスの変更に限定されます。
魔法のようなものはありませんが、そうではありません。 ステータスの変更によりフォロワーのステータスをリセットするタスクがあります。たとえば、機能の実装をやり直し始めた場合、テストステータスは良い方法でゼロになります。 そのような関係の割り当ては、あまり考えずに、タスク間の「強い関係」の作成と呼ばれていました。
したがって、かんばんとウォーターフォールは互いに完全に互換性があり、追跡タスクは強い結び付きで簡素化できます。
ほぼ
実際の実装では、C＃とGtk＃が選択されました（私はLinuxユーザーですが、クロスプラットフォームが欲しかったため）。 実装にPlanTrackという名前を付けました（これもまた長い間考えていません）PlanTrackで、現在の状態はプロトタイプです。
現在の実装についての誓い
判明したように、Gtk＃はあなたが望むほどクロスプラットフォームではありません（Windowsの場合、たくさんのライブラリをドラッグする必要があります）。 次に、Sqliteベースの選択も非常に単純でした。プラットフォームごとに異なるアセンブリが必要です。 Linuxでプロジェクトをビルドする場合は、コードの3行を変更する必要があります（DBHelper.csで：System.Data.SQLite-> Mono.Data.Sqlite、および同じファイルの2つの場所SQLiteConnection-> SqliteConnection） 。
また、お菓子用。 急いでコードをおaびします。いつものように時間を使い果たしました（休日でも仕事をしています）が、それでもポイントではありません。 LinuxとWindowsのフロントエンドエコノミー全体の痛みは大きく異なります。
また、お菓子用。 急いでコードをおaびします。いつものように時間を使い果たしました（休日でも仕事をしています）が、それでもポイントではありません。 LinuxとWindowsのフロントエンドエコノミー全体の痛みは大きく異なります。
スクリーンショット 
Windowsアセンブリへのリンク（readmeをお読みください！）
イスタンブール
投稿の内容はアイデアに関するものではなく、実装に関するものではないかもしれません（Gtk＃での私の練習は誰にも当てはまりそうにありません）。
投稿では、独自のツールを作成すること自体が正当化される可能性が高くなります。 私は（PMとして）プロジェクト管理に関するさまざまな決定を1回または2回以上行いました。私が働いていた場所では地元の決定です。 1Cでさえ占めています。 そして、あなたは何を知っていますか？..それは価値があります。 鋭利なツールを使用すると、自分の仕事を自分がどうすべきかについての考えの下に引っ張るのではなく、すぐに釘を直接打つことができます。
プロジェクト管理のためのこれらすべてのアプローチ、プロジェクト管理のためのこれらすべてのソリューション...あなたはそれらを知る必要があります-しかし、与えられた時間に与えられた状況に合うものを選択するためだけです。 私は、仕事を方法に適応させるのではなく、仕事に方法を適応させることを提唱します。
これが流域です。 おそらく、RUP / XP /スクラム/ <リストは長い>を取っているとは信じられませんが、今は回復します。 いいえ、治癒しませんが、問題が発生します。 いいえ、MS ProjectとJiraを使用して発言することはできません。今、それらを追跡して計画を立てると、すべてが正常になります。 いいえ、良くありません。
たとえば、誰かがExcelを使用し、マクロでVBAがあなたのビジネスに合ったものを実行するとよいでしょう。 ある大企業（ロンドン証券取引所で転職）で働いていたのですが、SAPのリワークを注文した人はいませんでした。 プロジェクトの評価と追跡は、彼ら自身、彼らのプロジェクト、彼らの方法のために行われました。 そしてExcelで。 また、会社での仕事は500倍（誇張することなく）少なくなりました。そして、自分のデザインソリューションの作成が報われました。 なんで？
ニーズに合ったプロジェクト管理ソリューションの作成が会社の能力ではない場合、プロジェクトは会社にとって優先事項ではなく、ビジネスにとっても有利ではありません。
すべてが原始的です。 プロジェクト会社の未来は、この未来の計画プロセスによって提供されます。 ツールが計画ルールを規定している場合、その中に定められたプラクティスがどれほど優れていても、将来は柔軟ではなく、ビジネスの状況に対応しません。 プロジェクトの管理方法を考えているビジネスの状況に対応します。
良い休日と成功したプロジェクト！
その結果、アイデアは次のとおりです。電気テープ付きハンマーは購入したハンマーよりも優れており、上記の3日間の取り組みの例は、おそらくこれが非常に現実的であると確信させるでしょう。 それを読んだすべての人に感謝します。