いいえ、文字通りではありません。むしろ、高品質のソフトウェアを作成する能力に影響を与えたポリシーの赤いテープのホラーストーリーはありますか？この質問のような一般的な人材やシステム管理ポリシーについて話しているのではなく、不正なソース管理ポリシー、テスト手順、バグ追跡プロセスなど、開発プロセスを直接対象としたポリシーについて話しているのです。
インデント対スペースやブレーススタイルなどの聖なる戦争ではなく、伝説のTPSレポートのような嫌な官僚主義の例をお願いします。
私は自分のグループの開発プロセスをレビューしているので、これは私にとっていくぶん関連性があります。そして、あなたが対処しなければならなかった最悪のプロセスのいくつかを（文脈のために）見たいと思います。構造化されたポリシーまたはプロセスが行き過ぎになるのはいつですか？
私は文字通り、私が働いているシステムの1つについてTPSレポートを提出します：http：//tps.tmccom.com/
そして、はい、私はサイトがどれほど時代遅れで標準化されていないかをよく知っています。
古い大規模なコンピューター会社での以前の仕事では、CRT プロセスがありました。ソフトウェア製品には高可用性コンピューティングが含まれており、リスクを非常に嫌うものだったので、それが完全に行き過ぎたアイデアだったとは言えません。しかし、それは時々煩わしく、開発を確実に遅らせました。
基本的に、システムは、コード ピアが 3 人にレビューされた後、CRT フォームに記入するというものでした (ある時点で Web アプリケーションに変換しました)。
CRT (変更要求チーム) は、週に数回、すべての要求を確認し、経営陣、チーム リーダー、および問題のコーダーと話し合い、すべてのフープが通過したことを確認します。それ... QAは新しいテストの通知...など
ありがたいことに、Web アプリケーション バージョンは好評を博し、非常に詳細でやり過ぎだった古いマニュアル フォームは削除されました。少なくとも私たちの組織からは...
私は現在、3 つの別々のユーティリティで自分の時間を概説する必要があります。
1 週間の時間を高レベル (コンサルティング時間、休日、休暇、病気など) で入力し、それぞれの 1 日あたりの作業時間を示します。これはクライアントへの請求用です。
クライアントには、リクエスト レベルで時間を入力する必要があるタイム トラッキング システムが導入されました。クライアント関連の管理時間 (会議、トレーニングなど) には、独自の汎用バケットがあります。請求不可のアイテムには別のものがあります。これは 1 か月間のもので、1 週間あたりの時間を示しています。
私の会社には、特定の週に行ったすべてのことを詳述する時間追跡ツールもあります。時間は 15 分単位で追跡され、非常に細かく設定されています。つまり、「リクエスト 12345 の場合、見積もりを書くのに 0.25 時間、要件ドキュメントを書くのに 0.50 時間、ファイル x のコーディングに 0.50 時間を費やしました。」また、見積もりをシステムに入力し、効果的にロックダウンする必要があります (ウォーターフォール FTL!)。承認のためにクライアントに何かを送信する前に (何かがコーディングされるずっと前に)。
また、非常に厳格なピア レビュー プロセスもあります。クライアントに送信する公式のもの (要件ドキュメント、変更要求、コードなど) はすべて、最初にピア レビューを受ける必要があります。クライアントには、週に 1 回開催される変更管理委員会もあり、本番環境にインストールされるすべてのものを承認します。
私はかつて、大学時代の何人かの友人に、私の仕事がどれだけ多くのプロセスとパラノイアに取り囲まれているかを正確に説明したことがあります。それが終わるまでに、(緊急でなく、本番サポート以外の状況で) 既存のレポートに 1 つのフィールドを追加するための見積もりが、すべてのプロセスが考慮された後の架空の状況であることがわかりました。 、基本的に単一のフィールドを既存のselectステートメントに追加すること（またはDBクエリにSQLを使用しないツールを使用するのと同様のもの）の絶対最小値で3時間でした。さらに、この見積もりは非常に小さいため (3 時間というのは、必要な項目ごとに必要な最小時間 0.25 時間に加えて、生産変更管理会議に 30 分を加えたものにすぎないため)、私のチームにリードしてもらう必要があります。最初にサインオフしてください。
*はぁ*
今日の暴言はこれで十分だと思います。