この言葉の意味、品質の評価方法、品質の維持方法。
人々があなたのサービスを利用し、それらを高く評価することを望むなら、プロジェクトに取り組むとき、品質は最初に来るべきです。 チームのすべてのメンバーが品質に責任を負います-サービスを作成する人々の仕事がその品質を決定します。 プロジェクトに携わる各従業員は、品質の最大化と問題の解決に貢献する必要があります。
品質の定義
チーム内の異なる人々は、品質を異なる方法で理解します。 一般に、品質とは、トランザクションの開始から完了までのユーザーサービスのレベルであり、次のものが含まれます。
- （できる限り広い範囲の）ユーザーに最適なデバイスセットへのアクセスを提供します。
- デバイスの十分な使いやすさ
- できるだけ早くユーザーに技術的および情報的なサポートを提供する機能
- データのセキュリティと保管と使いやすさ
- コアソフトウェアとITインフラストラクチャの効率とセキュリティ。
- プログラムコードの完全なパフォーマンス。
- 同時に多数のユーザーと対話する場合のサービスの高速化（負荷テストが必要です）。
- より多くのトラフィックを処理する必要がある場合に、サービスの機能を迅速に向上させるためのすべての条件の存在。
- 要件または設定の変更に応じてサービスの機能をすばやく追加または編集するチームの能力。
「技術的負債」についての一言
「技術的負債」はソフトウェア開発で一般的な用語であり、多くの定義があります。 一般に、「技術的負債」とは、通常、ソフトウェア製品の開発を適切に実行できない場合に、ソフトウェア製品の開発を完了するために行われる妥協の決定を指します。 これは、プログラム全体の作成が完了したという事実にもかかわらず、いくらかの改良が必要であることを意味します。
「技術的負債」を蓄積せずにプログラムを開発することは不可能であるため、チームの人々は互いに適切に処理した経験を共有する必要があります。 大量の「技術的負債」により、プロジェクトのさらなる作業が遅くなります。 作品を整理して、将来的に徐々に減らすようにするには、そのボリュームを知る必要があります。
すべてが品質に責任を負います。
サービス品質は、ソフトウェア製品をテストするときだけでなく役割を果たす。 また、品質の責任を負うのは少数の従業員グループではありません。 システムの品質は、それを作成した人によって保証されます。
従業員は、システムの新たな品質問題に気付くことができるはずです。 それぞれが品質の向上と問題の解決に貢献するはずです。
ソフトウェア製品がどれほど成功しているのか、テストを行わずに要件を満たしているかどうかを理解することはできません-通常および非標準の作業条件下で。 Dylan Robertの著書 『 Learning From First Responders 』を読んで、ソフトウェアのテスト方法と高負荷下でのチームのパフォーマンス（この場合、2012年の大統領選挙の最終段階）を調べてください。
すべてのチームメンバーはデジタルサービスの品質に責任を負いますが、最終的な責任はサービスマネージャーにあります。 彼がチームの他のメンバーと直接対話することが重要です。 そうしないと、従業員が品質を確保するために必要な対策を理解できないというリスクがあります。 従業員は、ユーザーストーリーを作成するときに品質の問題を考慮し、時間とリソースを次の目的に使用する必要があります。
- 作成中のプログラムのテスト。
- プログラムを簡素化し、ユーザーへの可用性を定期的に確認します。
- エラーシナリオの分析と必要なアクションの計画の開発。
スペシャリストを集めて特別なツールを使用することは、テストの有効性を確認するのに非常に役立ち、不正アクセスに対する保護をテストする場合に適切です-開発チームの一部ではない従業員を使用してこのタスクを実行すると、ソリューションの有効性を確認し、システムの弱点を特定して、外部からの問題を調べることができます
また、品質保証を確保するための専門家の雇用-彼らは、品質に関連するすべての活動を適切に調整し、トレーニングのシステムを編成し、高品質のサービスを作成するために必要なリソースを提供することができます
- マイルストーンでプロジェクトの進捗を単に評価するのではなく、特定の責任を引き受けてチームとやり取りし、チームのすべての品質を向上させます。
- 短期間だけ責任を負い、サービスを開発および改善する標準プロセスの一環として従業員に品質を管理する機会を与えます。
この資料については、 IIDFアクセラレータの多くのスタートアップと議論しました。
質問：技術的負債をどのように処理しますか？ プロジェクトでこのコンセプトを使用していますか？ もしそうなら、その量をどのように計算しますか？ それを排除するための特別な内部チームルールはありますか？
Dmitry Sokolov、Pocket.DJの創設者およびプロジェクトマネージャー
CTOは、技術的負債を最小限に抑えるためのタスクの実装を通じて考えています。 彼はそれに対して個人的な責任を負い、それを管理します。 20日と21日ごとにリファクタリングが行われます。 技術的な負債の危険性が事前に明らかになっている場合、CTOはタイムラインを計画するときにチームに通知する必要があります。
Alexey Fedorishchev、プロジェクトマネージャーHappyCart.co
これはマーケティングの問題だと思います。 「機能」を測定し、その実装を追跡する方が簡単です。 品質に対する責任について：はい、それは普遍的です（4-7人のスタートアップがそうであるように）。 そして、品質の問題における仲裁人は、クライアントが自分のルーブルで投票することです。
StartExam、プロジェクトマネージャー、Sergey Svechnikov
私たちは技術的な負債を処理しません。 チームは小さく、ほとんどがフルタイムではありません。 これに基づいて、我々はまだそのような規則を規制していません。
Timeviewerプロジェクトの創設者、Vladimir Kovalev
使用しますが、呼び出しません。 当初、私たちはこれに出会い、サービスのプラットフォームと構造を書き直して設計することを余儀なくされました。そのため、複雑なロジックを持ち、多数のデバイスをすばやく使用できるシステムの設計で豊富な経験を持つイゴール・ラビノビッチを採用しました。
今、私たちはより小さな「技術的負債」に直面しています。 Assemblaで必要なすべての機能と改善点を説明し、リリースごとにすべてを分解します。 既存のプラットフォームに実装できるものは、より迅速に行う必要がある場合は、何かを行い、「クランチ」でそれを解決します。 しかし、書き換えロジックを備えた新しいリリースを待ち望んでいる「負債」は数多くあります。
今、私たちはより小さな「技術的負債」に直面しています。 Assemblaで必要なすべての機能と改善点を説明し、リリースごとにすべてを分解します。 既存のプラットフォームに実装できるものは、より迅速に行う必要がある場合は、何かを行い、「クランチ」でそれを解決します。 しかし、書き換えロジックを備えた新しいリリースを待ち望んでいる「負債」は数多くあります。
アレクサンダーカロシン、Lastbackendの創設者およびプロジェクトマネージャー
ハイテク製品があり、「急いで」それを行うことはできませんでした。 これには2つの主な理由があります。開始時のリスク-視聴者の流入により、技術的負債のあるプロジェクトには、転倒と安定性の欠如という大きなリスクがあります。 そして、技術的な負債を伴うプロジェクトは、いずれにせよ整頓され、（ほとんどの場合）ゼロから書き直されなければならないという事実。 これに関連して、すぐに「正しいこと」を行うことが決定されました。 そして、この問題が発生する前に削除しました。
通常、すべてが異なって行われます-プロジェクトを維持できる「クランチ」だけが書かれていますが、これらの松葉杖の重要な部分をリクルートするとき、リファクタリングはまだ行われ、最終的には非常に高価です。
通常、すべてが異なって行われます-プロジェクトを維持できる「クランチ」だけが書かれていますが、これらの松葉杖の重要な部分をリクルートするとき、リファクタリングはまだ行われ、最終的には非常に高価です。
Gov.ukの資料に基づく出版物：