組織哲学の計画、構築、実行
ソフトウェア開発が組織の計画、構築、実行モデルにどのように適合するかについての論理的な説明を探しています。
ソフトウェア開発プロジェクトがこの構造にどのように適合するかを説明するものを見つけるのに苦労しています。実際、PBRの執筆内容はすべて非常に少ないようです。
私が見ているのはisacaのCOBITと呼ばれるもので、内部的にはプランビルドランと呼ばれる3つのステージがあります。これはその用語の出典ですか？
私は、物事がどこに行くのか、なぜ物事がそこに行くのか、そしてそれがどのような価値を持っているのかを明確に探しています。
これは少し外れたトピックに見えるかもしれませんが、「ライフサイクル」の下で最もよく見えた
昔の暗黒時代には、ソフトウェアは有名なウォーターフォールアプローチを使用して構築されました。計画、要件の分析、システムの構築、システムの構築、テストシステム、実行システムです。
これは50年代にさかのぼります。当時、この職務の分離とタスクの専門化は、テイラー主義の環境で強力な現実でした。
COBITとIASCAよりずっと前に、計画、構築、実行の概念の起源があると思います。一部の賢いコンサルタントは、技術者以外の管理者や監査人が簡単に把握できるように、詳細な段階を省略しています。
現在、大手のコンサルティング会社は、このアイデアを成功への確かな道として売り続けています。
ただし、実際のソフトウェア開発に携わっていた人なら誰でも、すべての詳細を最初から計画することはできず、不確実性に対処するためにある程度の柔軟性が必要であることを知っています。これが、今日アジャイルが非常に人気がある理由です。適応型および反復型の計画は、開発とともに行われます。また、DevOpsの人気と成功の高まりは、開発（ビルド）と運用（実行）を統合する方が良いことを証明しています。
プロジェクト管理自体を見てください。 PMBOKは、複雑なプロジェクトには段階的なエラボレーションが必要であると説明しています。 PMBOKとISO21500はどちらも、計画をフェーズ（計画/構築/実行の場合）ではなく、プロジェクト全体で実行される一連のプロセスとして捉えています。
これを念頭に置いて、どのように計画/構築/実行を実装できますか？計画部門のプロジェクトマネージャーは、テクノロジーとビジネスの理解を徐々に失っていますか？ビルド部門の開発者で、作業を整理するための計画をたてる必要がありますか？稼働後、サポートは実行され、ビルドされないため、同じ開発者はサポートに介入しません（システムを最もよく知っているにもかかわらず）。
私の個人的な生活の中で、私はそのような変容を目撃しました。その結果、プロジェクトを遂行するのが困難になり、部門間コミュニケーションの大きなオーバーヘッドが発生しました。同じ人々が計画/構築/実行組織の前に統合チームとして効率的に提供したとき。