他の人々の借金をどうするか？

開発者の職業の1つの側面は、特にソフトウェア開発プロセスに対する一般の人々の献身です。

S.マッコネル、パーフェクトコード

この出版物の目的は、複雑な歴史と重い遺産を持つプロジェクトの経験を共有することです。 次のいわゆるいわゆるを残した後 「スタートアップ」、私は新しい感覚を試してみたいと決めました：エンタープライズ、レガシーなど。 これを行うために、私は国境を越えた関心事のための企業アプリケーションの仕事を始めました。 当時の開発はすでに3年目であり、アプリケーションは数世代の開発者に耐えましたが、安定したリリースはありませんでした。



この出版物は役に立つと思います：

• 長所と短所を比較検討する同様の意思決定者
• 技術的な問題の原因と結果をよりよく理解するための「難しい」プロジェクトのマネージャー
• そしてもちろん好奇心

記事で扱われている質問：

• 開発者の低い能力、およびそれについて何ができるか？
• プロジェクトの機能以外の変更について、顧客の目に納得させる議論は何ですか？
• 特に開発の観点から、またプロジェクト全体として、アナリストとQAの仕事が非常に重要なのはなぜですか？

入力

入り口は何ですか？ 第一段階のインタビューで、私は次の詳細に興味をそそられました。

• フレームワークの使用バージョンは、長年の開発で時代遅れになりました
• 2年間で製品の安定バ​​ージョンがリリースされなかった
• システムのビジネスの複雑さは時々ロールオーバーします

プロジェクトマネージャーと主任開発者が参加した第2段階のインタビューでは、次のようなニュアンスを受け取りました。

• 現在の開発チームは、使用されているフレームワーク、言語、テスト、IoC、オブジェクト指向設計、設計パターン、アーキテクチャの能力が低い
• サブジェクトエリアは本当に簡単ではありません
• 顧客は問題がないと確信している

私がプロジェクトに参加するという前向きな決定を下すまでに、その中の良い場所や信頼できる場所を見たことはありませんでした。私が見つけ出したものはすべて問題の兆候でした。 これは私を肯定的な答えに押しやったものです=）



開始時の状態を要約すると、さらなる開発の成功のリスクを表す次のバラストカテゴリを区別できます。

• 開発者の能力が低い
• 不十分なコード品質（前の段落から派生）、大きな技術的負債
• 確立されたインフラストラクチャの欠如
• 自動テストの欠如
• 受け入れテスト文化の欠如
• バージョン管理、変更、展開の文化の欠如
• 要件は標準化されていません。
• 顧客に対する管理上の負債-実行チームの側に存在する問題の隠蔽、成功の誇張、古い負債に対する新しい約束

「救助者」であると主張する開発者（シニア、一流の開発者、技術専門家など）に勧める一般的なメッセージ： 嘘をつかないか、恐れないでください 。 嘆かわしい状態のプロジェクトを見つけたとしても、同じことを検討する前にプロジェクトで働いていた人々がそれを意味するわけではありません。 まず、プロジェクトの現在の状態は主に彼らの努力の結果であり、人々が彼らの仕事の結果に対する批判を知覚することは心理的に困難です。 第二に、おそらく、既存の問題を許可したチームのレベルでは、それらを識別することはできません。彼らにとって、客観的には、問題はありません。 この場合、すべてのビジネスロジックを含む通常のシックコントローラーは許容可能と見なされました。 ユニットテストが存在しないことは、ユニットテストに慣れていない人にとってはひどいものではありません。



このような状況では、チームに独自のベストプラクティスを植え付ける必要があります。 これを行うには2つの方法があります：進化的-使用可能な人員を訓練する（まずは独自の例によって）。 革新的なのは、より有能なパフォーマーを探すことです。つまり、チームを体系的に置き換えることです。

テストから始める

私の最初の活動の1つは、テストフレームワークを接続し、同僚がテストを開始して記述できるようにすることでした。 もちろん、進化はより人道的な選択肢です。誰かを「統合」する必要はありません。時間とお金をかけて、経験豊富な（そしておそらく高価な）スペシャリストを選択する必要はありません。 知識的には、知識を共有する方がはるかに便利です。 しかし、これは長い道のりです。 お金のためにエンタープライズアプリケーションを開発する準備ができていると考える成熟した開発者がテストをマスターしなかった場合、彼の専門的な成長曲線の何かが間違っていました。 ドラマは、ほとんどの場合、新しい要件に耐えることができず、多くの人が新しい仕事を見つけることを好むということです。 最も抵抗の少ない道をたどることは人間の本性です。 この場合、トレーニングの試みは、他人の時間の無駄です。



余剰人年が在庫にない場合（商業開発の可能性が高い場合）、経験の浅いチームはスムーズに進化する可能性がほとんどありません。 すぐに新しいチームを編成する準備をして、以前よりも高い要件を申請者に提示することをお勧めします。 はい、こうして予算を増やします。 そして、これは予算のインフレではなく、過去にマネジャーによって生み出された負債の補償です。おそらくお金を節約しようとして、おそらく経験不足のためです。



行われる技術的な変更を列挙して、ユニットテストから始めました。 単体テストは、プロジェクトを適切に保つための最も安価な実装およびメンテナンスの機会でもあります。 そして同時に最も基本的なものの一つ。 テストから始めるのは良い習慣です。 テストを使用すると、馴染みのないライブラリまたは言語を使用してコーディングを開始し、タスクを設定して、何かの実装を確認できます。 テストは、何かをする前に結果を正式に記述する考え方です。 このスキルを適切なレベルに磨くと、結果を得るのは難しくありません。白いシートの恐怖を忘れます。 そして、これはプログラミングだけではありません。

SVN-> Hg-> Git

歴史的に、プロジェクトはSVNを使用していました。 メルジは困難で責任のある問題であり、秘跡的な「まだトランクに押し込まないでください。今日では展開されています。」 他のプロジェクトの同僚はMercurialを使用しました。 約1か月間、このバージョン管理システムを試しましたが、最終的には、有名で人気のあるGitへの移行を希望しました。 予想どおり、ほとんどの求職者は、新しいチームを結成するとき、他の2つのハード通貨よりもGitに精通している可能性が高くなりました。 移行の理由ではないものは何ですか？

CIおよびCD

Windowsサーバー-> Ubuntu

リモートデスクトップ+手動更新-> delpoy.sh-> Unix + Docker + TeamCity

デモとテストアプリケーションのコピーは、Windows Serverにありました。 サーバー管理とアプリケーションの更新は、リモートデスクトップに接続して手動で実行されました。 半年ほどで、マネージャー、そして彼を通して、顧客に、実稼働環境でのリリースの前提条件は、インフラストラクチャーをUnixに移すことであると納得させました。 この正式な正当化と並行して、2番目のバックエンド開発者を検索するプロセスで、LAMPスタックの管理を所有する候補者に注目しました。 幸いなことに、BashとUnixの優れたスキルを持つスペシャリストを見つけることができました。その結果、彼はチームの50％の開発者と50％のビルドおよび統合エンジニアになりました。 生産に入るまでに、完全なCIとCDがありました 。 こんにちは、 ロッテンウッド ！



このイベントは、他のイベントと同様に、純粋に技術的なソリューションではありません。 開発の方法論と概念は他のプロセスに影響を与えます。忘れないでください。 リリースの準備が「** yak-** yak and production！」に要約されるチームをリードすることにマネージャーが慣れている場合、TeamCityでエージェントを構成するだけでは不十分です。 あなたはマネージャーに「あなたはそれをただ取ることができず」「デモに売る5分前にそれを修正する」という認識を伝えなければなりません 。 はい、最初は不快になります。 運用環境の低下に伴い、すぐに展開が開始されないという事実に慣れるには、マネージャーが1か月以上かかります。 これは意図的な手順であり、10分かかりますが、何もドロップしないことが保証されており、サーバーの数に関係なく、どのサーバーでも予測可能な結果が得られます。



顧客にとって、このためのリソースと時間を割り当てる必要があるという議論は次のとおりです。

• 緊急時のダウンタイムの削減-Dockerのおかげで、あらゆるデータセンターのあらゆる仮想マシンに迅速に展開できます。
• アプリケーションをイメージと一緒に配置し、開発チームの参加なしに、任意のマシン（このようなケースも考慮されました）で実行できます。
• セキュリティ-ホストマシンからのアプリケーションを含むコンテナの分離、サーバーに対するUnixのシンプルさと信頼性。 企業のセキュリティ監査アプリケーションの通過中のいくつかのポイントは自動的に閉じられました。
• アプリケーションで使用されるスタックのネイティブ環境。潜在的な機能に適用可能な広範なテクノロジー。 優れた開発者の忠誠心。
• 追加の構成なしで目に見えるパフォーマンスの向上。

Eclipse / NetBeans /トライアルWebStorm /ブラケット-> PhpStorm

もう1つの重要なイベントは、チームのPhpStormライセンスの取得を計画し、PSRに従って統一されたフォーマットスタイルを設定することでした。 私は、どの組織も労働者に通常のツールを提供できる（ そしてそうすべきだ ） と信じています。 私の意見では、PhpStormとWebStormは、PHP / JavaScript / TypeScriptをサポートするための市場のIDEをリードしています。 優れたIDEは、プログラマーとチーム全体の個人的な効果を大幅に向上させることができます。単一のコードスタイルと、設定を通じてプロジェクトに取り組むためのさまざまな便利な「ガジェット」を簡単に実装できます。

Devprom + Excel + * .jpg-> Jira

この移行はおそらく私たちにとって最も壮大で待ち望まれていたものでした。 歴史的には、Devpromが使用されていました。 簡単に言うと、このシステムは誰にもお勧めしません。 有料ソフトウェアの品質が非常に悪いのは、私にとっては驚くべきことでした！ ランダムに、システムがフリーズ、クラッシュ、明示的な脆弱性を含む可能性があります。 各更新は、いくつかのSQLインジェクションのパッチ（および更新の頻度によって判断される新しいインジェクションの追加）に加えて、GUI要素のレイアウトに革新をもたらしたため、使い慣れたユースケースをリマスターする必要がありました。



プロジェクト管理システムは計画と開発プロセスの基礎であるため、「遅れた」不安定なソリューションの使用は他のすべてのプロセスに影響を及ぼしました。人々は、トラッカーでバグを開始するのが面倒でした（困難で長かった） 、タスクが失われ、分析ツールと評価ツールが使いにくくなり、マネージャーはあらゆる機会にトラッカーを回避するために何かをプッシュしようとしました。 したがって、使用されたツールは明らかに私たちのプロセスに有害であり、ひどいことを認めなければなりません。



Devpromと彼に馴染みのあるマネージャーの工夫のおかげで、私はいくつかの代替管理方法を観察しました。

• 写真の操作 -出力をテストした後、優先順位に従って名前が付けられたスクリーンショットのあるフォルダーがあります。 開発者は、好きな写真をつかんで「修正」し、Doneパパに写真を転送することができます。 トラッカー内の各画像のタスクを作成しようとする場合は、手で取得できます。
• 電子メール主導の管理 ：チームメンバー間のメーリングリストでは、数日から1週間、手紙が高レベルの「機能」の表に送られます。 運用開発管理にトラッカーボードを使用するイニシアチブは処罰されます。
• Excelの計画 -伝説的なスプレッドシートプロセッサを使用したバックログのコンパイルと評価。

タスクトラッカーは、IDEほど開発において重要ではありません。 これは、開発プロセスの基礎です 。プロジェクト内のアクティビティはすべて、そのプロセスで開始および終了する必要があります。 タスクもコードもありません。 Jiraは、おそらく市場で最高の商用ソリューションです。

PMレベル

開発者がチームで運用管理を実行する場合、多くは彼の決定に依存します。 彼の選択は、製品の個々の部分の実装の成功または失敗を決定します。 もちろん、これは2〜4人の開発者、テスター、アナリストなどの小さなチームに最も関係があります。 さまざまな専門家の数の増加に比例して-建築家、管理者、QA部門を紹介します-プロセスの個々の参加者の個人的な責任の程度が減少すると仮定する必要があります。

ただし、技術的な専門家として、あなたが直接影響を与えない要因が少なくとも2つあることを忘れないでください。 さらに、プロジェクトが成功する可能性は、それらに直接依存します。

• プロジェクトの総予算と、それに応じた人員配置表。 専門家の数が一桁少ない場合、競争力のあるアプリケーションの類似物を書くことはできません。 プロトタイプよりもさらに、「スタートアップ」は熱意を持って飛び去ることはありません。
• フードチェーンの中で直面している活動-顧客分析とビジネス分析。

プロジェクトマネージャーがあなたの側にいて、トップマネジメント（または組織の構造に応じて顧客）から追加コストを引き出すことができる場合、マネージャーがプロジェクトとプロセスで必要な機能以外の変更の重要性を顧客に守ることができれば、成功のチャンスがあります。 残りはあなたの完璧さに依存します。



経営陣が開発チームの声に耳を傾ける準備ができていない場合、回復のチャンスはありません。 上司の決定に直接影響を与えたり、プロジェクト管理を変更したりすることはできません。 しかし、他人の過ちに対して責任を負いたくない場合は、可能な限りすべてのことを聞かなければなりません。

開発レベル

開発者としての経験から、プロジェクトに問題がある場合、たとえば、技術的な借金がある場合、リファクタリングを容認して胸を急がせることができます。テストでカバーします。 開発自体から離れて、鳥瞰図からプロセスを見てください：コードレビュー、安全なブランチとプールリクエスト、CIの統計コード分析ツール-問題の拡散を防ぐための多くのツールがあります。 問題の原因を排除することがはるかに重要であり、症状を排除することは二次的な問題です。 そして、あなたが2番目の時間を十分に持っているという事実ではなく、ほとんどの遺産では、あなたは長い間生きなければなりません。 主なものは、転移を防ぐことです。



時々、間違いは本当に遺伝子にあります。 その後、最良の方法は、母集団から低品質の遺伝子型を切り取り、必要な優性形​​質を持つ新鮮なサンプルに置き換えることです。



1年のリファクタリングの後、開発者を評価する価値は、多くのメリット（機能+適切なコードベース）によってではなく、技術的な負債とサポートされていない、またはテストされていないコードの形で残された最小限の害によって評価する価値があるように思えます もちろん、上司は別の現実を見ることができます。 しかし、開発の現実は、平均的な開発者がほとんどあらゆる複雑さの「機能を手に入れる」のが簡単なほどです。 中長期的には、この追加によってアーキテクチャが劣化せず、脆弱で理解しにくいテストが付属し、SOLIDの原則に基づいて設計されたことがはるかに重要です。 この点で、私は1人のシニアが2人のミドルと2人のミドルから4人のジュニアを好むでしょう。 あなたとあなたの製品の距離が長いほど、この論文はより重要になります。



残念ながら、必要な予算を持っていても、許容できる時間枠内で十分に強力なチームを編成することはほとんど不可能です。 最も一般的な技術やフレームワークであっても、資格のあるスペシャリストは非常に不足しています。 産業レベルの開発プロセスを構築すると、これを相殺できます。 可能なユーティリティと手法を使用して、コード品質を分析および制御します。 合理化されたコンベヤの背後に平均的または初心者の開発者を配置すると、熱烈な目を持つ愛好家をマスターに「コミット」させるよりも、予測可能な結果と体系的な開発が得られます。 あなたの仕事は、安定したプロセスを組織し、参加者のプロセスへの取り込みを促進することであり、英雄的な威厳のある職人の決定の結果を英雄的に排除することではありません。

分析

ビジネスアナリストが未加工の要件を開発に投入している場合、想像力を有効にせず、コーディングを開始しないでください。 質問と競合するすべての場所のリストを作成し、彼に手紙を送ります。 または、印刷物についてすべての疑わしい問題を一緒に話し合います。 ただし、アナリストが承認したファイルに特定の要件があり、コーディングのタスクを開発者に委任できるようになったら、コーディングを開始する必要があります。 理想的なポーズの開発タスクには、関連する要件の参照に加えて、「ビジネスロジック」、最悪の場合は、指定された開発者が変更が行われるシステムのコンポーネントにまだ詳しくない場合に使用される設計パターンの高レベルの説明を含めるべきではないと考えています



私たちが毎日忘れている平凡な真実： 人々は自分の考えが明らかだと思う傾向があります 。 業界の平均的な高いIQにもかかわらず、残念ながらテレパスは常に休暇中です。 テレパスモードに入り、アナリストのために作業を行う場合、次の罪の責任があります。

1. 1に近い確率で、タスクは計画よりも多くの時間を要します。 確かに、評価を与えて、開発者は常にコーディングの時間を表明します。 経験豊富な私たちは、デバッグ、テスト、ドキュメントのメンテナンスなどのリスクを負うことができます。 しかし、最高の開発者でさえ、ビジネスアナリストとして働くのに必要な時間を正確に予測できるとは思えません。 アナリストがプログラムを作成することはありません。 そして、あなたに答えるための時間の超過のために。
2. 実装に入ると、それらは要件に記載されておらず、顧客と合意していないため、すべての空想に責任を負います。 次に、これはバグではなく機能であると長い間皆に納得させ、最終的に実際の要件の出現でこのコードを書き換える必要があります。 そうですね。 文書化されていない動作や、プロジェクトの誰も覚えていない所有者のイニシャルを使用した謎めいたコードにつまずくことは、さらに悪いことです。
3. 優秀なアナリストから専門的な成長の機会を奪っています。
4. 宇宙のエントロピーを増やし、分業のメリットを相殺します。

口頭での議論と通信の結果は、最終要件ファイルに記録する必要があります。 適切な開発計画と体系的なコーディングに必要なドキュメントのパッケージを開発します。 システムの特定の部分を記述するために必要なフォーマットを決定します。 たとえば、各画面フォームには、次の一連のドキュメントが必要になる場合があります。

• 機能の説明、フィールド間の依存関係のフローチャートを含むVisioファイル
• 検証ルールと各フィールドのデータ型の説明を含むExcelファイル
• レイアウトPSDファイル、関連ソース（フォント、アイコン）

このようなパッケージは、開発段階だけでなく、受け入れテストとユーザードキュメントの開発でも需要があります。



システムの現在および必要な状態を理解するために、これらのファイルをソースコードと並行してバージョン管理することが理想的です。 残念ながら、ほとんどの複雑なオフィス形式では、Gitのソースコードとの類推によるバージョン管理は適用できません。



ビジネス分析は、開発そのものと同じように形式化およびデバッグするために重要なプロセスです。 そして、あなたは開発者とアナリストの関係の一種の消費者なので、あなたの義務は、相互の喜びのためにこれらの関係を築くのを助けることです。

見積もる

マネージャーが、分析が実行されなかったタスクを評価するように強制する場合、可能なものの一番上に置きます。 たとえば、このようなタスクにはフィボナッチ13または21を使用しますが、通常計画されているタスクの最大値は5です。したがって、この段階ではより正確に推定できない複雑さを明確に反映します。



もう1つの極端な例：最小評価を設定します。 私は1を使用しますが、多くの楽観主義者は「5/10/15分でできる」などの約束をする傾向があります。 はい、もちろん編集がありますが、その導入には数分かかります-トラッカーとのやり取りのオーバーヘッド、ハードカレンシー、ドキュメント、テストは含まれません。 「小さな」修正に1エンジニアリング時間がかかることをマネージャーに混乱させないために、関連する小さな編集を1つのタスクにまとめることをお勧めします。

QA

「ページMのフォームを修復する」フォームまたは無害で馴染みのあるページに大きな太字の疑問符の付いたスクリーンショットでバグレポートを受け取った場合、問題を修正することはできません。 アプリケーションの機能に応じて、バグレポートの形式を策定します。 製品テストに携わるすべての人に、修正に必要なデバッグ情報の取得方法、策定方法を示し、伝えます。 再生できないものを再現しようとしないでください。



別のニュアンス：チームにテスト文化がない場合、マネージャーは製品の手動テストは開発者次第であると信じるかもしれません。 あなたの使命は彼に簡単な算数を見せることです。開発者の時間は通常、「手動」のテスターの時間のN倍です。 チームの開発者による数日間のテストの間、選択したテスターの給与の給与は簡単に燃やされます。 単純な開発を忘れないでください。



テストは体系的に定期的に行われるプロセスであり、4月のサブボトニックのようなイベントではありません。 組織にまだQAがないが、それが何であるかを知っている場合-使用可能なすべての手段でそれを近づけてください。 認定された受け入れテストはありませんが、開発チームは、検出されたすべてのバグについて極度になります。 テストが不規則な場合、バグはまれですが、多くは同じではありません。 これは、自動的に検出された大量のバグがあなたの人生を害し、開発プロセス全体に深刻な損害を与えることを意味します。 言及されたプロジェクトでは、QAスペシャリストの人事部をノックアウトし、適切な候補者を検索するのに約1年半かかりました。



不規則で組織化されていないテストのリスクは何ですか：

• テストがまれである場合、バージョンはひどく「バギー」、血の腸の疫病、ああ、すべてがなくなっているように見えます、私たちはすべてを落とすでしょう、私たちはすべて火に走ります!! 次の期限を破るリスク。
• 多数のバグを同時に検出することは、 （見たところ）完成したバージョンに非常に多くのバグがあるという事実として主観的に認識され、開発者としての信頼性が損なわれます。
• 手動で、時折、組織化されていないテストの場合、バグレポートの品質は低くなります。つまり、再現が難しく、無関係で、複製されます。 開発者は、それらを再現するために余分な労力と時間を費やします。 私の経験では、多くの場合、バグを再現するには修正が必要です。 そして、再現に失敗した場合、費やされた時間を二重に失望させます。
• 多数のバグを修正する時間は、それらを定期的に計画に含めるよりも、評価するのが困難です。 プロセスがデバッグされ、テストおよび開発の生産性のメトリックがあれば、開発の残りの部分と並行して、修正の評価を長期計画に入れることができます。
• リリースの前日に予定通りになったすべてのバグを「修正」する機会は、マネージャーと若い開発者の両方にとって非常に望ましいでしょう。 しかし、そうではありません。 リリースの品質は不十分であるか、破損しています。
• ケースバイケースのテストを行うスペシャリスト（研修生、プロジェクトマネージャー、アナリスト、開発者自身（神は禁じられています！）、コーヒーレディ、会計士、配管工）の定義：a）。 彼らにとっては一時的であるため、この役割では効果が低いb）。 計画やシナリオに従って協調して行動する可能性は低いc）。 低品質のレポートを保証する

健康的なテストを整理することは、開発者自身の関心事です。

最高は善の主な敵です！

運が良ければ、開発を理想的な状態にデバッグしても、管理者と顧客が自動的に満足するわけではありません。 第一に、たとえばPMが顧客に慢性的に曲がり、チームの知識がなくても物理的に開発の義務を果たすことができる場合、開発の安定性と生産性の成長に伴い、義務は増加します。 第二に、以前に表明されていない問題が常に存在し、他の人が所有していない場合は、最も高い優先度を受け取ります。 ここでスキームは次のとおりです。「fakapila」チームが以前に安定性と新しい機能を備えていた場合、顧客はアプリケーションが遅いと見なし、「エピックfakap」として記述することができますが、最初はこれに対する要件はありませんでした。 または、既存のすべてのロジックを分解し、それを必須アイテムとして設定する特定のペットの特徴を思い出し、反論を非専門家主義および妨害行為とみなします。 ここでは、すべてが顧客の適切性と管理層に依存します。 そのような状況では、一貫して議論し、論理に訴え、またはより感謝している組織を探すだけです。



留意すべきもう1つの注意点は、製品が成長するにつれて、変更を行うコストが必然的に増加することです。 常に。 上記のすべてのベストプラクティスおよびその他のガジェットは、このコストの増加率を低下させるだけです。 , , , , :



— : , ** , .

— : , CI/QA-- «», …



, , , «» «» :

3. «»

したがって、このようなキャラクターの場合、順序を復元することはそれほど重要ではありません。開発者以外の場合、機能的な変更以外の変更は一時的でオプションです。明確な例を含む論理的根拠が重要です：何、どのように、そしてなぜ。McConnellが言及している開発者の職業と同じ側面。