難しいプロジェクトの物語：官僚主義、インフラストラクチャ、およびソフトウェア開発について少し

難しいプロジェクトの物語：官僚制、インフラストラクチャ、およびソフトウェア開発プロセスについて少し

どんな小さなプロジェクトでも、Facebookで何か重要なものに成長したいと考えています。 これは常に発生するわけではありませんが、発生した場合は、プロジェクトに5人の開発者がいる場合には存在しないように見えますが、プロジェクトが立ち上がった後はかなりの注意が必要な問題やタスクが多数発生します。 以下は、比較的大規模なプロジェクトの歴史、官僚制度についての考え、インフラストラクチャーおよび開発プロセスの説明です。この経験は誰かに役立つと思います。



顧客はかなり大きな投資銀行です。 エンドユーザーの数：1万人以上



プロジェクトチーム

• 200人以上の開発者（31チームリーダー、7チームリーダーを含む）
• 3人の建築家、そのうちの1人がメイン
• 19人のテスター（1人がリード、2人がストレステスト、残りが機能テスト）
• DBMS管理以上の担当分野の5人のシステム管理者。 特別なHWチームの責任範囲におけるOSおよびハードウェア管理
• パートタイムで働くアナリストの変数番号（2〜16）
• 12名のテクニカルライターおよび翻訳者
• 3人のプロジェクトマネージャーが常に1つを監督します-休暇中の代替の2番目と3番目、病気、またはアクティブで利用可能な場合はプロジェクトマネージャーのアシスタントとして行動します。

すべての従業員は地理的に分散したオフィスで働いています。 ロンドン、ニューヨーク、フランクフルトのアナリスト。 開発センターは東ヨーロッパにありますが、開発者の大部分はリモートで作業しているため、ハンガリー人に加えて、プロジェクトにはブルガリア人、ロシア人、ウクライナ人、ベラルーシ人もいます。

開発されたシステムと簡単な歴史とは何ですか？

実際、これには、CRM、金融機関向けのOSS、および投資銀行向けの特殊なソフトウェアが混在しています。 このプロジェクトは15年以上前に始まり、元々はPerlで開発されましたが、残りのコードは（2013年まで）システムに残っています。 Perlを使いこなさないことが明らかになったとき、ITユニット内にチームが形成され、既存の機能を新しいプラットフォーム（Java）に徐々に書き直し始めました。 静かな仕事は長続きしませんでした-小規模な顧客が金融機関を吸収した結果、PHPシステムはシステムに有機的に接続されました。これは単純化されたエンドユーザーWebインターフェースであり、バックエンドは手動で処理するブローカーでした送信されたアプリケーション。 PHPの部分は比較的小さいため、もともとはPHPの部分を完全に書き換えることが計画されていました。



残念なことに、機能が生産的（市場投入）になったときなどの重要な要因のため、Javaチームは、最初の数のほぼ2倍の利点と給与のほぼ3倍の利点にもかかわらず、PHPチームに完全に負けました。 その結果、すべての新製品が最初にPHPに登場し、一定の時間を経てから、Javaチームはこの機能をJ2EEで部分的にしか再現できませんでした。 この現象の理由はさておき、この機会を利用して、この状況は、最終顧客とのコミュニケーションの「幸福」を奪われたJavaチームに完全に適しており、要件はかなりよく処理され洗練された形でチームに届き、ダモクレスと言うでしょう日付の剣はほとんどそれにかかっていませんでした。

内部開発を回避しようとすることについて

定期的に、社内開発から脱却する試みが行われ、プロジェクトは外部のインテグレーターに移されました。 入札が行われ、チームが見られ、話は銀行専用のコンピテンスセンターの開発についてでさえありましたが、そのたびに何かが一緒に成長しませんでした。 最後の試みの失敗の話は特に壮大でした-リトマス試験として、互いに独立した小さな改善の寄せ集めであるリクエストを選択することが決定されました。 これらの改善の1つは、承認されたユーザーが目に見えるニュースコメントのみを追加できるようにすることでした。 建築家と著名なインテグレーターの売り手は元気に計画を描き、完成の費用を出しました。 それどころか、ニュースにコメントすることによる改善は骨の折れるものでした-8人時。 この評価がマドリッドの要求者にどのような運命をもたらしたのかはわかりませんが、文字通り翌日、ユニフォームがビデオ会議の呼び出しのために手配され、スペイン人従業員の息子が文字通り10分で機能的なライブを行いました。 彼が以前に書いた既製のSQLおよびJavaコードを使用したことは明らかですが、データベース内の1つのテーブルと1ページのコードを必要とするタスクは完了するのに8時間かかりませんでした。 最大30分または1時間の管理のように感じます。

売り手もインテグレーターのアーキテクトも人件費の評価でほぼ16倍の差を実証できなかったのは当然であり、主な売り手のカリスマも、システムソフトウェア製品の進化とブルックスへのリンクも役に立たなかった。 内部開発のアイデアは、生き続けて勝ち続けました。

製品か製品でないか？

プロジェクトを正しくリードし、製品マネージャーを獲得し、明確なリリース計画を立てようとする試みも失敗しました。 一般的にビジネスは、IT全般、特にプロジェクトに対して功利主義的な態度をとりました。ITはビジネスに貢献します。 セキュリティがあり、オフィスの清掃と配送サービスがあります。 そして、例に過ぎないお金を要求するITサービスがありますが、ビジネスに条件を指示するべきではありません-会議室に侵入し、必要なクリーニングの口実の下で全員に30分外出するよう頼むクリーニング女性を想像することはできませんか？ それでは、より良いITは何ですか？ そのため、システムの新機能の実装のために予算がすべての地域オフィスに割り当てられました。これは製品マネージャーにとっては軽いショックでした。このように、オフィス用品の注文、ライン、オフィスへのコーヒー/紅茶/水の配達、そして予算ラインのリクエストがあります彼の製品への変更？ 当然、そのようなモデルは要件の集中化を実質的に意味しませんでした-ユニットに予算ラインにお金が残っている場合、ITはこの機能を実装する義務があります。 要件の関連性については、地元企業は必要なレポートや機会をよく知っています。

プロセス図

数年間、陰謀、最適化、常識の包含を通じて、作業を整理するプロセスはスキームになりました。これは単純化されたバージョンであり、これに注目します。



会員

エンドユーザー-システムのエンドユーザー

マネージャー-プロジェクトマネージャー

テスター-テスター

建築家-建築家

アナリスト-アナリスト

アプリケーション開発者-開発者

コードリバイバー-コードレビューを担当する主任開発者







1.エンドユーザーは、BPMシステムを通じて新しい機能を申請します。 これは、Oracle BPMへの移行を考慮した独自のソリューションです。

2.プロジェクトマネージャーはアプリケーションを受け入れ、実現不可能な/重複するものをフィルタリングします。

3.プロジェクトマネージャーは、再びBPMシステムを介して、アプリケーションをアナリスト/アーキテクトに渡します。

4a。 アナリスト/アーキテクトは、最初のビジネス\機能要件の観点からタスクを策定し、その後、プライベートな技術タスクの形式で策定します。 タスクのテキストはソース管理（Git）に、タスクはJiraおよびBPMに、要件はトレースされます（Rational ClearCase）。

4b。 アーキテクトはタスクの期限を予測し、情報をプロジェクト管理システムに入力します（Microsoft Project Server +改善）。

4c。 プロジェクト管理システムは、タスクの予測時間とコストについてエンドユーザーに通知します。

5.開発者は最新バージョンのソースコードを取得し、機能を実装します。

6.開発者は、コードレビューでコードを投稿します（Gerrit経由）。

7. CIシステム（ハドソン）がコードを取得し、テストアセンブリを実行します。

8.テストアセンブリレポートは、レポートシステムに送信されます（Microsoft SQL Server Analysis Servicesに基づく）。 コード分​​析を実施するために、コードレビューの責任者に通知が送信されます。

9.コードリバイバーにより、変更が緑色になります。

10.コードはメイン開発ブランチに転送されます。

11. CIシステムは、メインブランチからコードを取得し、アセンブリを実行します。

12.レポートシステムでレイアウトされるレポート。

13. CIシステムは、テスト環境へのコード展開を生成します。

14. CIシステムは、機能テストおよび負荷テストのシステムを呼び出します。

15.自動モードのテストシステムは、テスト環境（JMeter、Selenium、RationalRobot）でテスト手順を実行します。

16a。 レポートシステムでレイアウトされるレポート。 テスターに​​は、テストを実施する必要があることが通知されます。

16b。 テストシステムは、プロジェクト管理システムのタスクのステータスを変更します。

17.テスターがテストを実行します。

18.成功すると、BPMシステムのステータスが変わります。

19.プロジェクトマネージャーに通知されます。

20a。 BPMシステムは、アセンブリーのpre prod環境への転送を開始します。

20b。 このイベントのマークは、プロジェクト管理システムに配置されます。

20c。 pre prod環境の機能を見ることができるエンドユーザーに通知されるもの。

21.プロジェクトマネージャーとエンドユーザーは、prod環境で機能をテストします。

22.機能を本稼働環境に移行する決定が下された場合、BPMシステムを介してプロジェクトマネージャーが本稼働環境への展開タスクを開始します。

バックグラウンドで

1.自動環境設定システム（Puppet）は、基本ソフトウェアの設定に関してランドスケープを調整します。

2.ステータス監視および追跡システム（Zabbix）は、dev、test、pre-prod、prodだけでなく、gerrit、Git、Hudsonなどの他のインフラストラクチャを含むインフラストラクチャを監視します。

3.バックアップシステムは、プロジェクトリポジトリとインフラストラクチャソフトウェアのバックアップに加えて、不可抗力またはシステムの以前のリリースを実証する必要がある場合に、生産前のランドスケープマシンのイメージをバックアップします。

4. 1日1回、主に脆弱性を検索するために、コードの静的分析が実行されます。



上記のスキームは、ちょっとした大胆さと理想主義を持ち合わせています-RPは、よく知られた信頼できる開発者からのコードを確認せずに、前製品、コードリバイバーの新機能を表示する責任を軽視します。 しかし、一般的に、このスキームは非常に大きなプロジェクトでは非常に消化しやすいです。 そして、最も注目すべきことは、そこから余分な、明らかに冗長な部分を単純に切り離すことで、別のプロジェクトの図を取得できることです。

数年にわたるプロジェクトへの参加後に著者が行ったアドバイスで非難された結論

1. ITに携わるすべての人。 ロシアと西ヨーロッパのITビジネスの関係は、時には劇的に異なります。 ITを「持っている」、これはサービスチームです。 特権的で高給の両方であるべきですが、支配的な役割を主張するものではなく、取締役会の権利に影響を与えるものではありません。 CIOフォーラムでは、CIOがCareer Is Overである理由、その対処方法、CEOがしばしば財務ディレクターの地位を獲得しますが、ITディレクターの地位を獲得しない理由について真剣に議論します。 AXOとアカウンティングの間の企業階層におけるITの位置。 謙虚に、ロシアでもそうでしょう。
2. 初心者の建築家へのアドバイス。 「大規模なプロジェクトには、適切なアーキテクチャがありません。」 松葉杖なしで設計することは不可能であり、数年後に開発されます。 あなたが考えることができるのは、ゆるい接続と合理的なレベルの抽象化だけです。
3. 開発者へのアドバイス。 「それからあります。」 深刻なシステムの誰も「正しく書き換える」機会を与えません。 ビジネスはこれを理解していません、あなたも理解しなければなりません。 最後に、このコードで子供たちに洗礼を施すべきではありません。
4. プロジェクトマネージャーへのアドバイス。 古典的な三角形の品質-期限-予算では、予算は通常固定されており、品質カテゴリはトップマネジメントのために非常に抽象的です（機能を低下させないため、品質は品質です）。 。 計画するときは、このことに留意してください。
5. ルールはありません。上記の内容を忘れてください。