Clever Geek Handbook

時間の急激な不足に直面して、技術的に複雑なインターネットアプリケーションの開発を管理する

エントリー



この記事では、技術的に複雑なインターネットアプリケーションの開発を加速し、過度の価格を払わない方法について説明します。 著者自身の経験をまとめて整理するために書かれましたが、インターネットプロジェクトの他の技術管理者にとっても役立つかもしれません。 読者は、現在または将来、同様の提案に出会ったときに、同様のプロジェクトに参加するかどうかを決定するための情報源としてメモに興味があるかもしれません。







このノートはまた、給料の支払いの難しさの痛みを伴う問題と、それらがどのように効果的に対処されるかについても述べています。







ノート内のインターネットアプリケーションとは、純粋な形式のWebサイトと、1ページのサイトやモバイルアプリケーションなどのブラウザ内にクライアントを持つクライアントサーバーシステムの両方を意味すると理解されています。 特異性が重要な場合があり、特別に交渉されます。







この記事で述べられている考えの多くは、他の種類のITプロジェクトにも当てはまります。 作者は彼が直接経験したことだけを書いたので、これには注意してください。 他のITプロジェクトの現実は似ているように見えるかもしれませんが、成功するためには完全に逆の手順が必要です。 プロジェクトを深く理解している場合にのみ、隣接するタイプのプロジェクト間で技術を移転し、これから大きなメリットを得ることができます。







注では、プロジェクトマネージャーの役​​割は、テクニカルマネージャーとビジネスマネージャーの役​​割に分かれています。 ITプロジェクトの場合、これは従来の部門です。 組織のタイプに応じて、ビジネスマネージャーは通常、単にプロジェクトマネージャー、プロジェクトマネージャー、またはCEOと呼ばれます。 テクニカルマネージャーは通常、CTO、部門長、アーキテクト、チームリーダー、チーフプログラマー、またはリードプログラマーと呼ばれます。これも、組織のタイプと、管理能力、プログラミング能力、またはアーキテクチャ能力を優先する優先順位によって異なります。







本文全体で、ビジネスマネージャーは単にプロジェクトマネージャーと呼ばれ、これは誰にとっても明らかですが、彼は常にビジネスマネージャーと呼ばれます。 これは、単純な真実を理解するために行われます。技術的に複雑なITプロジェクトには常に2人のマネージャーがいます。1人はリーダー（ビジネス）で、もう1人はリーダー（技術）ですが、2人がいます。 技術マネージャーがマネージャーでもあることを忘れており、プロジェクトの成功に対して何らかの責任を負っている場合、厳しい時間制限の下では、プロジェクトの崩壊につながる可能性が最も高くなります。







メモのサイズは約8万文字で、高速で読むには約2時間半かかります。 これは、プロジェクトマネージャー、投資家、および新興企業や開発へのプロジェクトアプローチに関心のある開発者にとって興味深いものです。







著者について



この記事の著者は、さまざまなスタートアップの採用CTOの形でアプリケーションを実装した経験があり、さらにインテグレーターでいくつかのプロジェクトをゼロから実装した経験もあります。 基本的に、これは、インターネットアプリケーションサーバー（技術的に洗練されたWebサイトやモバイルアプリケーション）との積極的な通信の作成です。







典型的な作業スキームは、「市場からの採用、アーキテクチャの開発、市場からの開発チームの雇用、開発者の手による開発、最も複雑な機能の独立した実装、アプリケーションの起動、そしてしばらくしてプロジェクトを終了する」です。







問題が資金調達で終わるプロジェクトを正常に終了した経験があります。







時間の不足がもたらすもの



計画の誤算。 タイミングと予算のクラッシュ。 これらは、プロジェクトの作業範囲が多少正確に決定される前に修正されます。 そうしないと、ネットワークスケジュールに基づいた計画日でさえ、プロジェクトの完了済みの販売期限に間に合わないため、タイムリザーブを最適化し、直接作業を優先して管理領域から再配分する必要が生じます。 十分な時間がないと主張して、ビジネスリーダーは絶対に満足しません。 彼は通常これを理解しており、それ自体が状況の人質です。 したがって、これは時間の深刻な不足を伴うプロジェクトであるという理解。 その結果、このトランザクションのすべての参加者がプロジェクトの過程で費やされる時間を絶えず最適化できることを期待して、スケジュールは意図的に非現実的になります。 時には判明することもあるが、そうでないこともある。







プロジェクトの開始時に優秀な開発者を採用することの難しさ。 タイミングが崩れています。 開発者市場は裕福ではありません。特に、標準化されていない営業日で働きたいと思っている裕福ではありません。 したがって、多かれ少なかれ適切な開発者を市場から連れ出し、できるだけ早く彼らと開発を開始したいという大きな要望があります。 この衝動に屈するべきではありません。 採用期限を守るよりも質の高いデベロッパーを採用する方が適切です。最初と2番目のレポート期間を混乱させたため、プロジェクト管理者はプロジェクトの終わりまでに開発速度が大幅に向上します。 あなたの目標は、中間報告ではなくプロジェクトです。







プロジェクト開発での雇用の困難の増大。 プロジェクトの開発期間が長くなるほど、コードの記述量が多くなり、ロジックの実装が複雑になるほど、初心者は既存のコードを理解しなければなりません。 さらに、高品質のCodeReviewの条件であっても、リファクタリングの一定の遅延により、場所によってはコードが理解しにくくなるという事実につながります。 これは、コードの記述を開始してから3か月以内に、新しく雇われたプログラマーがすぐに退職し、新しい開発者の売上が100％に達するという事実につながる可能性があります。 経験豊富な技術管理者は事前にこの困難に対処できますが、初心者にはできません。







人を解雇する問題。 人を雇うことができないので、解雇に問題が生じます。 解雇された人は交換する必要があります。 交換とは、新しい開発者を雇用することを意味しますが、遅れることはありません。 したがって、プロジェクト管理者とチームは、通常のプロジェクトで解雇された人に耐えることを余儀なくされる場合があります。 繰り返しますが、暫定期限のプレッシャーにもかかわらず、最初の報告期間を遵守するよりも質の高い開発者を雇うことがより重要であるという事実に戻ります。







新しい機能の作成とバグ修正の矛盾。 時間は限られています。 行われた作業量。 また、開発の最初にエラーに通常あまり注意を払わない場合、プロジェクトの中間、特に第3四半期までに、すべての参加者と利害関係者のプロジェクトの意見に影響を与える重大な要因になります。 開発者自身を含む。 同時に、機能の向上の必要性をキャンセルした人はいませんでした。 したがって、エラーは、致命的、クリティカル、非クリティカル、および低優先度に分類するのが最適です。 新しい機能を記述する前に致命的な修正。 批評家は新しい毎日のリリースに向かっています。 重要でないものは、次の段階の終わりに蓄積され、修正されます。 優先順位の低いものは、プロジェクトの完了後に正体不明の善良なエルフによって修正されます。







個人的な練習から。 プロジェクトの経験豊富なビジネスマネージャーは、チームリーダーとアーキテクトの注意を引き付けて、信頼性が向上した開発製品には明らかに多くのエラーがあり、彼はすべてを理解しているが、耐えることさえ困難になるという事実に注目しました。 彼は、十分にテストされた別のテスターをプロジェクトに追加することを提案しました。 記事の著者であるティムリッドは、優先事項の技術プロジェクトマネージャーとして行動しているアーキテクトに、エラーを修正するか、できるだけ早く機能を書き続けることを求めました。 開発スピードを優先して決定した後、チームリーダーはプロジェクトのビジネスマネージャーにチームに別のテスターを連れて行くことができると話しましたが、開発者がいないため、既存のテスターで見つかったエラーのほとんどを修正しません。 つまり、新しいテスターは既知のエラーのプールを増やすだけで、修正の数は増やしません。 コードの品質は変わりません。 その結果、彼らは新しいテスターを引き付けることを拒否しました。



誰もがすべてを理解しました。 プロジェクトは、大企業の市場平均をはるかに超えるコード品質で予定通りに開始されました。

リファクタリングの遅延による不良コードの蓄積。 時間の深刻な不足は、コードの最終決定が明らかに難しい状況でのみ、リファクタリングに時間を割り当てられるという事実につながります。 さらに、コードの特定のセクションに機能を追加すると、デバッグエラーに関する大量の作業が発生します。 プロジェクト管理が幸運でチームリーダーが優れている場合、彼はコードの最も問題のあるセクションを追跡し、リファクタリングが必要な時期と程度を通知できます。 通常、このような領域は頻繁に更新されるコードです。1つのタスクの一部として数行、別のフレームワークの別の3行、春雨コードの3番目と10番目の編集の行が追加されました。 プログラマーに犯人はいません。 同時に、CodeReviewと高度なチームリーダーの助けを借りても、そのような春雨の形成を防ぐことは非常に問題です。 そのようなコードは時々リファクタリングする必要があり、プロジェクトには深刻な時間不足があります。







対立 深刻な時間不足のプロジェクトでは、非常に頻繁に発生します。 唯一の解決策があります-技術プロジェクトマネージャーのソフトスキルが必要であり、一部は非常に強力でなければなりません。 したがって、開発者が専門の開発者の立場から開発リーダーの立場に移る前に、人間、コミュニケーション、紛争解決のスキルを積極的に開発する必要があります。 実際、開発者の管理活動に対する準備の事実は、相互合意のために人々と交渉する能力によって決まります。







開発チームの衝突は、通常、参加者が仕事をより良く、より速くしたいという欲求から生じることを理解することで、衝突の解決が大いに助けられます。 さらに、これにはさまざまなソリューションが使用されます。 速度や品質の優先順位が異なる場合があります。 これらは産業上の対立であり、個人的なものではありません。 そのような対立は、正しいか間違っているかを見つけるのではなく、当事者を教育し、共同の決定を下すことによって最もよく解決されます。







戦略的決定に対する戦術的決定の普及および戦術的決定の成長。 この状況は、スタッフをリファクタリングおよび採用する状況と非常によく似ています。 プロジェクトには最終期限があり、暫定的な期限があります。 次の中間体では、戦術的な成功に応じて間違いなく頭に当たりますが、最後の中間体はすぐには出ず、一部の人は計画の範囲から外れます。 これは特定の人にとっては問題ではありません。 これは役割の性質です。 個人はその役割に従うか、それを乗り越えることしかできません。 役割が戦略目標に圧倒されていると感じた場合は、ビジネスプロジェクトマネージャーと話し合い、ソリューションオプションの長所と短所を述べ、ビジネスプロジェクトマネージャーが決定したことを実行することをお勧めします。







プロジェクトビジネスマネージャー



ビジネスプロジェクトマネージャーは、プロジェクトで最も重要な人物です。 アイデアの源泉であり、最終的な聴衆との接点であり、プロジェクトのユーザーの代表であるのは彼です。 顧客の場合、彼は顧客の利益の代表でもあります。 プロジェクトはエンドユーザーに対して機能することを覚えておく必要があります。プロジェクトが成功したかどうか、作成した製品を使用できるかどうかはエンドユーザーのみが決定します。 スタートアップでは、ビジネスリーダーの役割は、スタートアップの創設者の1人である起業家によって果たされます。







実務経験から、時間などの基本的な要因がビジネスプロジェクトマネージャーに常に圧力をかけていることがわかっています。 企業プロジェクトの場合、これらは契約の締結中に設定された厳しい期限です。 プロジェクトを統合する際に、一部のインテグレーターは20％の時間不足を定め、開発者にこれらの時間の20％を無料で働かせることを余儀なくしています。 スタートアップの場合、これは開発チームのメンバーに支払わなければならないお金です。 投資されたスタートアップの場合、これは投資を得るという名目で非現実的な期間投資家に報告しています。 プロジェクト管理のその他の問題はすべて、この要因から直接生じます。 主なものは少し高いと考えられました。







ビジネスプロジェクトマネージャーの品質は、時間制限のある環境で作業する能力によって正確に決まります。 まず、絶えず優先順位を変更して開発チームをdevelopmentてないでください。 第二に、誤算を理解し、問題の解決に役立ちます。 第三に、戦術的なビジネスタスクを構築して、プロジェクトを正常に完了するという戦略的な目標を達成できるようにすること。







状況により、ビジネスプロジェクトマネージャーは、一見狂ったように思われる決定を下すことがあります。 さらに、開発チームによるグループの意思決定の場合、これらの特定の条件で他の正式に正しい最適なソリューションを実装することは単に非現実的であるため、これらの決定はしばしばサポートされます。 賢明なビジネスプロジェクトマネージャーは、何が起こっているのかを説明し、すべてを完全に理解していることを示すことで、この狂気の打撃を軽減できます。







実際、ビジネスプロジェクトマネージャーに精通する場合、理論と実践の違いを正確に理解していること、プロジェクト管理の理解と状況判断をどのように組み合わせているかを正確に知る必要があります。 これは、彼自身が尋ねる質問からも含めて、インタビューで明らかに見られます。







いずれにせよ、ビジネスリーダーがプロジェクト中に何をしようとも、あなたは彼と一緒にいて、彼を助ける必要があります。 彼の行動や要求がどんなに奇妙に見えたとしても。 彼の行動は常にプロジェクトの成功を目指しており、彼はこの目標によってのみ導かれ、プロジェクトの成功はあなたの主な目標です。







誰に連絡するべきではない







ITを理解しておらず、ITの経験がない人が率いるプロジェクトに参加しないでください。 ストールの所有者は、開発チームをストールスタッフとして扱います。 タジク人としての建設会社の所有者。 通常のセキュリティ違反者としての元セキュリティマネージャー。 人がリーダーシップのスタイルを変えることは困難です。







プロジェクトのコアビジネスに関与していない人が率いるプロジェクトに参加しないでください。 元ハイエンドシステム管理者は、モバイルアプリ開発プロジェクトの最高のビジネスプロジェクトマネージャーではありません。 一方、そのような人が5年以上ITプロジェクトを管理している場合、反対に、彼はプロジェクトに多くの有用なものをもたらすことができます。







状況に関係なく独自の明確な見解を持っている独断論者も最良の選択ではありません。 状況が変化するにつれて、彼らは真空中の球形の馬に適した抽象的な解決策を主張し続けます。 協力を開始する前に、状況を理解する能力があるかどうかを常にテストし、その中に理論的知識を適用し、該当する場合は再考してください。







プロジェクトテクニカルマネージャーは、何も学ぶことがない人に興味を持つことはほとんどありません。 「なぜ私は彼のために働いているのであって、彼と私のためではないのか？」という質問は彼らと共に絶えず起こります。 一方、多くの人々にとって、これは非常に快適な状況であり、高給によって大幅に軽減することができます。







すぐに決定を下すことができない人とプロジェクトに入ることは避けてください。 すぐに無作法というわけではありません。 予備的な反省は数週間続くこともあり、この決定の結果と価格を完全に理解しながら、状況に応じて即座に決定が下されます。 人がこれを行う方法を知らない場合、彼は緊急の決定を引き出し、問題を積み上げ、締め切りの圧力を高めます。 これは確実にプロジェクトを殺します。







プロジェクトテクニカルマネージャー



プロジェクトがインテグレーターまたは大企業によって編成されている場合、技術プロジェクトマネージャーは、この部門の伝統的な開発技術のスタック全体について深い知識を持ち、それを扱った豊富な経験が必要です。 記事の著者は、このセクションのこの種のプロジェクトについては触れません。







技術マネージャーが会社から会社へとさまよう場合、または彼が新興企業に魅了される場合、各プロジェクトには独自のニーズがあるため、すべてがより興味深いものになります。 アーキテクチャ設計の段階で、技術マネージャーが突然、自分が知っているテクノロジースタックを使用しても費用対効果が低いことに気付くようなビジネス要件があります。 そして、あなたは新しいスタックを学ぶ必要があり、すでにそれは深刻な時間不足の状況にあり、プロジェクトの開始時にはクリティカルパスにあります。







たとえば、著者の主要な技術スタックを見てみましょう。









スタック外の言語：C ++、アセンブラー、Visual Basicのさまざまな方言、JavaScript、TypeScript、Go、Java、 Formula 、およびあらゆる種類のFortranおよびPascalの若者。







MS DOS 3.0, Windows 3.1, OS/2, CentOS, Ubuntu, Debian, openSUSE, AstraLinux FreeBSD.







CentOS, Ubuntu, Debian, openSUSE AstraLinux.







: Symfony2, Symfony3, Kohana 3, Yii 2, React Native, SailsJS, ExpressJS, MFC, Bootstrap 3, OWL for C++ .







ElasticSearch, MongoDB, Beanstalk, BerkeleyDB, Docker, Composer, Capyfony, RabbitMQ, Memcached, Git, Jira, RedMine, PHPUnit, SphinxSearch, Axshare, WinAPI API Rational Rose, MySQL, Domino.Doc .







IDE: NetBeans, PhpStorm, Visual Studio, , mc vi.







-- , , .







. , , . .







, . . .







, . -. - . , , .







, , , , . — , .







, , , . , : , , , , , . . , .







, , .







5-6 . , . -. , - , .







? できます。 Scrum Scrum Guide. . - - .







? できます。 , , , , . - .







開発者



« » , . , . , . .







— . . , — . . — . , . — . , , . , — . , , .







? たくさん。 , .







, , , . , - -. , — , . , .







. , . , , , . , , « » , - - , « ».







- . , , . . — - , , , ; JavaScript- , frontend-; , backend-. .







. , . , «» . , , - , .







.







計画中



. . , . , — .







, . , . , . , , . . . .







. -, , . . -, , . -, , . , , . -, , . -, . , .







— , . , , . , . .







, , . . - , - .







. -, .







. Excel . Excel . , - . Jira. , — , — .







Jira - . . . , . . . . , .







: , . .







Excel , . 300-500 , . . , « » , « -», « - », « » « » — , . . Jira . Jira , . , , , . . . , Jira, « » «» — .







, - . , : , , , , , . , , . .







- , , . 60% , 5% «» , 20% « » 15% , .







, : , .







. — . , . , . , — 1/4 . (, 5 , , , ), -, . , 10 , Code Review. - Code Review 10-15% .







. , , , , . , , . 30 , . ?







, , . , .







, - . , , . — .







時間の追跡



, - . . , 10 24 . , . 24 . 30 . «» . . 30 — 24 = 6 ?







, 8 . - 8 . — , . . , 6-6.5 . 7 , — . - - .







6- . , , 6 . . , , Jira , — .







- . 8 , 6 , 8- 6- . , . .







, , 8 . .









. . . . - . - . - . - , , .







, , - . 何に注意を払うことが重要ですか？ -, . , . -, . , , . -, . - , , .







— . . . . . .







開発開始



- , , . , .







. Android-, iOS- NodeJS-, ( , — — ), . , : , .

, - - Axure/Axshare - Photoshop, - , . ?







. , . : , , , , .. .







, - , - — / , - — , - (, ). . . , IOPS — — - .







, , , , . , , .







( , , , , .) , , . . , .







. , . - . , Sphinx Docker. Lua, NodeJS, Tarantool, React Native .

. . — /. , , , — .







インターフェースの下位レベルはリポジトリです。 リポジトリは、外部ソース（データベース、検索エンジン、キャッシュ）から要求されたデータを返し、外部システム（データベース、検索エンジン、メール送信アプリケーションなど）にデータを転送するだけです。 リポジトリの大きな利点は、アプリケーションコードと外部システム間の接続が根本的に弱くなることです。 SMS配信サービスプロバイダーまたは最終的なデータベースを選択する決定は、最後に行うことができます。







個人的な練習から。 実際には、メモの作成者は、データベースなしでコードを記述して最初の数か月間、2つのプロジェクトを進めていました。 つまり、リポジトリのインターフェイスが作成され、その下に単純なスタブストレージが書き込まれ、ある時点で、アプリケーションコードを変更せずにスタブストレージから実際のデータベースに切り替えました。



これらのプロジェクトの1つでは、Tarantoolのドキュメントによると、プロジェクトに最適であることが明らかでしたが、チームを使用した経験はありませんでした。最初の1か月で勉強する時間がなく、データベースなしでコードを書くことにしました。 Tarantoolを、大量取得および大量更新されたレコードを含む、Key-Valueデータを保存するためのベースとして使用することが計画されました。 使用が制限されていたため、インターフェイスは簡潔で、その数は十数個のメソッドをほとんど超えませんでした。 データベースに重大な問題が発生した場合、同じインターフェースに基づいてRedisとの作業を整理することが計画されていました。



その結果、Tarantoolアプリケーションへの統合が成功し、期待どおりに機能しました。

最上位はAPIです。 クライアント/サーバーアプリケーションの場合、これは従来のREST APIまたはWebsocket APIです。 MVCアーキテクチャを備えた従来のサイトの場合、これはドメインモデルとコントローラーの間の同じクラスの中間層です。 また、従来のサイトの場合、リンクの命名規則、リンク自体のリスト、およびコントローラーの比較を規定することが重要です。







この小さなデータセットを記述した後、アプリケーションは十分な数の開発者が任意の順序で開発でき、タスクの割り当ては、タスクの一部として実装するためのインターフェイスとAPIのリストまたはAPIに基づく最終機能に制限されます。 任意の順序とは、プログラマの雇用順序に関係なく、チームの他のメンバーが雇用されている間にタスクを実装するコードを作成できることを意味します。 また、任意の順序とは、コードでのプログラマの作業の同期を取り除くことができたことを意味します。一部の機能では、バックエンドはフロントエンドよりも時間がかかり、一部では逆の場合もあります。 そして、重要なのは、機能の一部を終えてアセンブリをテストできる間、プログラマの1人が他のプログラマを常に待っているのではなく、タスクの順序だけをリストすることです。







技術プロジェクトマネージャーが幸運でテスターの雇用を正当化できた場合、彼はすべての人に素晴らしいサービスを提供できます。 つまり、APIの機能テストと統合テストを作成します。 APIは機能のバックエンド部分を完全にカバーするため、これらのテストを使用して、インターネットアプリケーションのバックエンドの実際の開発の進捗を追跡できます。これは、正常に完了したAPIテストのシェアです。 また、これらのテストにより、どのAPIメソッドとどのパラメーターが機能しなくなったかがわかります。 これは、5〜6か月の急速な開発の後に重要になります。







また、テストデータにも注意を払う必要があります。 それらはまだ必要です。 開発者がすぐに利用できるようになると、デバッグの時間を節約できます。 アプリケーションデータベースの構造と、このテストを通じてデータ間の関係の完全性を調べた直後に、それらをアプリケーションに打ち込むことが最適です。 テストデータは、古いデータを削除して新しいデータを入力できるフィクスチャとして実装するのが最適です。







この記事の著者は、開発環境の編成の重要性、コードフォーマット標準、Gitリポジトリのブランチの命名規則、CI、CDなどについては書いていません。 誰もがそれを知っています。 そして、これは本当に重要です。 しかし、それらの重要性を知ることよりも、これらの重要な慣行に従うことの方がはるかに重要です。







テスト中



特定の製品レベルの品質を保証するには、テストが必要です。 技術プロジェクトマネージャーがテストなしで、または簡単な手動テストでこの品質を達成できる場合は、機能させます。 何らかの理由で単純な手動テストの品質に合わない場合は、他のオプションを検討する必要があります。 しばらくの間のチーム開発でも、簡単な手動テストの助けを借りて、許容できるコード品質を維持できることを覚えておく必要があります。 著者の実践では、この期間は通常6か月です。







テストは次のように分類できます。









優れたアプリケーションアーキテクチャにより、複雑なテストオプションへの移行が遅れる可能性があります。 複雑なリンクやアプリケーション内のリンクが少ないほど、手動で簡単にテストできます。 開発中の各モジュールが他のモジュールから完全に独立している場合、新しいモジュールを開発するときは、手動でテストするだけで十分です。 次のモジュールテストは、変更を加えた場合にのみ必要です。







無関係なコードは、アプリケーションの内部接続が小さいほど、再利用されるコードが少なくなり、開発がより複雑で高価になるため、達成不可能な理想です。 したがって、コードの大部分は関連しています。 アーキテクトのスキルは、この接続性を、新機能または修正された機能をテストするときに明らかになるように整理することです。テスト担当者は、この編集の影響を受けたものを推測できるはずです。







そのため、いくつかの器用さを備えて、最初の6か月は自動テストなしで特別な結果なしに実行できます。 これの鍵は、アプリケーションのさまざまな部分の最小限の接続性と一定のコードレビューを備えた適切に設計されたアーキテクチャであり、コードレビュー：アーキテクチャ内の違反を追跡し、暗黙的な依存関係を排除し、プログラマーに例として独自のコードを使用してより明確、明確かつ正確に記述する方法を教えます







例外は複雑な機能であり、常に単体テストでカバーする必要があります。 通常、このような機能はすべてのコードの1〜2パーセントです。 ただし、変更が行われたときのデバッグを含む、このようなコードのデバッグのコストは、テストを記述するコストを常に上回ります。 テストにより、何かを壊すリスクなしに変更を加えることができます。 実際には、機能は技術仕様の作成時に複雑であると認識されており、これによりテストの計画とビジネスリーダーのニーズの保護の両方が容易になります。







プログラマーがコードを書き始めたとしましょう。 彼らはテストを書きません。 この分野の技術プロジェクトマネージャーの作業の重要な部分は、正式に対処されていないアプリケーションの部分でのエラーの発生を追跡することです。 つまり、プログラマーがクライアント部分に何かを実装していたため、メインページで突然エラーが発生しました。 これらの呼び出しのいくつかは、コードを自動テストでカバーすることを決定する時が来たことを示しています。 ビジネスプロジェクトマネージャーはこれに同意しないかもしれません。 この場合、エラーが多すぎると判断するまで待つ必要があります。







不安定なコードの段階であるこの段階でのテストは、APIでカバーする必要があります。これらのテストを書くには少し時間がかかり、どこで落ちたかがすぐにわかります。 これらのテストをプロジェクトのビジネスマネージャーに「販売」するのが最も簡単です。なぜなら、彼は最適化されているものを正確に理解し、これらのテストが既に認識している問題を直接解決するからです。プログラマーはある場所で支配し、別の場所に落ちます。







約9か月のプロジェクト開発の後、大規模な機能テストがもはや保存されないことが明らかになりました。 ユニットテストとアクティブリファクタリングの番です。







時間の深刻な不足では、誰もユニットテストを書く時間を与えず、これらのテストの必要性を理解することすらありません。 ビジネス要件は、ビジネスプロジェクトマネージャーが新しい結果を定期的に生成することを余儀なくされるように調整されています。 「開発を停止し、すでに費やした時間の3分の1を費やします-3か月-単体テストを記述すると、アプリケーションは再び安定します」というオプションは失敗します。 メモの作成者は、誰かがこのオプションを実装することに同意したことを知りませんでした。 メモの著者は、誰もがそれを突破できるとは聞いていませんでした。 記事の著者は、文学におけるそのような奇跡についても読んでいませんでした。







テストでコードをスムーズにカバーする、一般的に使用されるアプローチ。 または、新しい機能のみが対象となり、古い機能は徐々にレガシーになります。 または、変更およびバグ修正の影響を受ける機能がカバーされています。 「クラスに触れた-テストでカバーする」スキームが使用されます。







テストカバレッジの選択は、資金と決定レベルによって異なります。 最初のオプションは、システムを安定化する必要性を明確に理解した上で、明らかにお金が不足しているためです。 決定は、ビジネスプロジェクトマネージャーが行います。 2番目のオプションは良好な資金調達に関連付けられていますが、製品は雪崩のような使用に対応する準備ができていません。 決定は、投資家の同意を得て、ビジネスプロジェクトマネージャーが行います。 3番目のオプションは、製品の迅速なスケーリングのためにお金を受け取る状況で得られます。 決定は投資家が行います。 既存のコードの品質とその根本的な安定化が重要になるのは3番目のバージョンです。







問題が遅れているが、お金がない場合、つまり、プロジェクトが最初のオプションに従って開発されている場合はどうすればよいですか？ このような状況では、最も問題のあるコードのみをテストでカバーする必要があります。 これは、以前に見つかったエラーのローカライズの場所、最長のエラー修正の場所、または多数の接続、依存関係、複雑なロジックのコードセクションに存在するコードを調べることで区別できます。 これを行うには、プロジェクトの最初からエラーのログを保持する必要があります（たとえば、Jiraでエラーを修正するためのチケットの形式で）、エラーを修正する時間を測定し、開発者に難しいと感じるコードのセクションについてインタビューし、コード自体を理解する必要があります。 後者は、すでに非常に適切なコードの改善に影響を与えるプログラマーの提案を拒否するために必要です（つまり、他のコードほどひどいものではありません）。







そして最後の1つ。 すべてのテストが3秒未満で実行される場合、プログラマがテストを実行するのは難しくないことに注意してください。 特に、ブラウザで起動が表示され、ページを更新するだけで実行される場合。 テストが10秒以上実行されると、プログラマーは怠laになり、最後に編集されたコードをサーバーに送信しますが、テストの実行を待ちたくありませんでした。 また、失敗したテストのメインブランチに定期的に存在することで、開発者はテストを実行する意欲が非常に強いことに注意してください。







完全なテストスイートの作成には、開発時間全体の30％がかかります。 手動でのテスト、修正、再テストなどは、機能するまで全体の40％かかります。 同時に、自動テストにより、特定のレベルのコード品質が保証されます。 選択はあなた次第です。







インフラ



プロジェクトインフラストラクチャは、開発インフラストラクチャ、通信インフラストラクチャ、および環境インフラストラクチャ（開発、テスト、展開ランドスケープなど）に分割できます。







インフラストラクチャは常に通信に関するものであることを理解する必要があります。 開発チームの各メンバーは、インフラストラクチャ全体がどのように構成されているかを理解する必要があります。 インフラストラクチャを文書化し、すべてのチームメンバーが文書にアクセスできるようにする必要があります。







機能のうち、開発の開始時には開発ランドスケープのみが作成されることに注意してください。 同時に、特定の段階でプロジェクトのビジネスマネージャーは、外部ユーザー（投資家、顧客、経営陣など）のデモスタンドとしてそれを使用し始めます。最初の使用時には、新しい環境を作成することが望ましいです。 それはデモになり、その後開発環境は開発環境のままになるか、開発環境と開発環境の一部（通常はサーバー）がデモになります。







このような部門の必要性の兆候は、ビジネスマネージャーがテストサーバーにデータを保存することです。 技術プロジェクトマネージャーは、一部のデータが貴重になったと判断した場合、環境を安定したデータとテストデータの2つに分割するように依頼する必要があります。







デモ環境が登場した後、多くの場合、テスト環境の必要性が十分に認識されています。 その目的は、バージョンをデモ環境に配置する前に、ビジネスエグゼクティブがアプリケーションが動作していることを確認できるようにすることです。







ベータテストに参加する際、ビジネスマネージャーはテストベンチに製品環境データを保持することを強く望んでいます。 この場合、著者は次の構成を検討することをお勧めします。









最新の仮想化テクノロジーを使用したホスティングを選択した場合、小さなデータセットを使用してデモ環境を作成することは、実稼働環境を停止することなく複製する非常に簡単な手順です。 さらに、一部のホスティングプロバイダーでは、多数のノードで構成される運用環境のクローンを作成できます。 ホスティングを選択する場合、このオプションに特に注意を払う必要があります。そうしないと、手動で環境を作成したり、環境のクローン作成を自動化したりする時間を大幅に節約できます。







ドキュメンテーション



文書化の目的は、参加者がかつて行われたことを理解できるようにすることです。 深刻な時間不足の状況での文書化では、ほとんど常に時間を節約します。 そして彼らはそれを正しくやっています。 実際、次のことが重要です。









これを行うには、次のようにします。









インフラストラクチャを完全に文書化することもお勧めします。







ソフトウェア製品のアーキテクチャに関するドキュメントは、別の便利な種類のドキュメントです。 システムがどのように開発されたか、一般的にどのように配置されているか、どのような重要な決定が行われたか、なぜそれらがまさにそのように行われたかを説明する必要があります。 実際、これは重要なドキュメントです。新しいテクニカルプロジェクトマネージャーで開発を続けることができるからです。 深刻な時間不足の状況では、技術プロジェクトマネージャーは、プロジェクトの開発が終了した場合および解雇された場合にのみ必要となります。 洗練されたビジネスリーダーは、コードでプロジェクトの作業を開始する前にこのドキュメントを必要とします。特定のアーキテクチャ上の決定を採用する理由を理解し、もしあれば、それらに影響を与えます。







運転開始



製品が突然動作し始めます。 , , , , . , .







. -, . -, , . -, , — .







, . , , , , . , - . . , .







, . , MVP. .









, . . - , , , , .







, , - , , - . , . .







, , , . - . - — . - .







, - , - , - . , . , . , , — .







, . , , , . , SMS- .







.







. , — , . , . . , . 15- .







:









, , , - . .









, MVP . MVP: , , , .







誰もがそれを知っています。 . . , , , .







, , . . : , : , , .







— MVP. -, , . -, « ». -, - . , , .







MVP : . . , MVP.







, — . - . , , , . , .







, , .









. , . . — . , - .







, — MVP, — .







. . . , , MVP — .







, - . , . , — .









. . - . , . , .







- . , . . . , .







, , , . , . , . , -. , , - . .







, , , . . . 25 40% .







, , . , , . , , - , . , , . , . , . — .







? , , . - — . , . , , .







, , . , - . , , , , .







, , «» . ?







-, , , , , . . , , .







-, , . , , , .







-, , . , . , - ( ). .







( — ) .







, . , , , . — - . , , . , — . .









35 , . . , .







- , . — . , .







, . . . .







— , . , , , , , , , .







. , - , . . , . . , . - « ».







. , , .







おわりに



? , . , , .







More articles:


All Articles