ソフトウェア開発まあ、常にバグの多様性を修復するために行くつもり。だけでなく、彼らが農業、設計、テスト、およびその他の小さなパートナーの仕事に従事することができます良いソフトウェアコードに依存しているにも不可欠です。例えば、自分のバグについてのみのケアに割り当てられた以前の研究では、問題に修正し、またどのように、なぜこのようなプロセスを考慮。同社はこれらの合計アップ今日を考える、ちょうど分のクラスを追加しました。いくつかのプロジェクトは、長い時間のために、過去にされているので、私は私の思い出に頼ることができますので、地元の凹凸やエラーがあるかもしれません。あなたや、より良いプログラムはまた、翼を望んでいることを教えてください。
開発プロセス
現時点では、私はこのプロジェクトは、このような基本的なプロセスである扱っていました。良い上司やクライアントでは、クライアントの実際のニーズに応じて、それらは完全なアプリケーションの概念を設計するのに役立ちます。小さなパートナーの設計チームが関わることになる今回は、ある特定の機能を紹介するテキスト記述で、アプリケーション全体のUIの設計を示す、通常PPTの形で、正式なデザインを作るためにこれらのアイデアを置きます。小さなパートナーが行う設計した後、リーダーシップと開発チームはGouziの観察によると、確認され、そしてここで良いを達成するためのいくつかの設計、変更の必要があるかどうかを確認するために、メインのフロントエンドのチームであることになります。今回はチームが多くの人々はおそらく完了する日必要があるか、推定するために、このソフトウェア上で動作します。そして、会社の休日のスケジュールに従って、特定の配信日を決定。一般に、そのようなデータが挿入される1つのような特定のアイテムの分解機能は、これは別の特徴点です。従って、特定の開発に割り当てられた大小の特徴点を分離しました。そして、それぞれの人はそれを終えるのにかかる時間の長さについて、独自のタスクの見積もりをフォローアップします。彼は最初の他人のために、悪い印象を良くすることについて常に心配の会社に入ったとき、ここで私は思った、それは常にできるだけ予定時刻です。幸いなことに、指導者たちが私の世話を、私は推定たびに反撃する時間になります - あなたはこの事をやっていますか？ハハ、私はかなりコーラだと思います。カードが主かもしれどこがわからないので印象リーダーシップが言っているようだ、あなたは通常の勤務時間を推定するでしょう、そして1.5を乗じた合計時間を計算するには、出てきました。今、本当にそうである、それについて考えます。
デザイン案の監査法人は、一般の顧客が審査した後、顧客に配信されますでは、いくつかのローカルな変更を加える必要があります。場所は、デザインを決定するための上記のプロセスを繰り返すように改正する必要があるために、小さなパートナーは、物事の特定の設計、ワイヤーフレーム、切断計画などのシリーズを用意し始めます。同時に、パートナーの小さなグループは、いくつかの特別なニーズを研究するための基本的な枠組みを構築するために進み、ニーズに合わせて開発されます。小さなパートナーのテストでは、テストケースを準備するために開始されます。
開発の正式な段階に、私はおそらく3つのモードが経験しました。
- お客様は、もはやタイプを気にしません。これは、プロジェクトとタイの企業であり、彼らがモバイル端末を利用することについて。大きすぎるリーダーシップであってもよい「ブロー」、当社の他の信頼は、唯一の配送センターの進行状況を表示する日付と時刻に合意することができます。それは標準ではありませんが、このため、開発者として、通常、まだあなたは、しばらくの間は、クラスを追加する必要があります出荷前に、残業をするための基本的な必要性は非常に興味深いです。が、
- 「アジャイル開発。」ここで私は、引用符は、実際のアジャイル開発など、このカウントは、結局のところ、主要な技術フォーラムは、このような紙は「XXX、でも、アジャイル開発を使用していない」beholdの過去過去分詞、と私の思い出を記録するために、それは避けられない確認されていませんしますいくつかの不正確。そして、上司が、私はここに別のアップデートを持つことになり、私と話をする機会を持つことになります。ナンセンス少しプルは、全体の内容は、ストーリーボードのようにしてください。このモードでは、関数の機能の特定の部門がそれに割り当てられた特定の人物を指定する必要があります。いくつかの具体的なスプリントは、スプリント関数が決定さ備え各々が、このストーリーボードで分離しました。各スプリントは、約1〜2週間です。各事スプリントはこれらについて行われる必要があります：
- 彼の体の機能/タスクの完了。
- スプリントの一つ上のいくつかの優先度の高いバグ修正
- このテストは、スプリント機能検証テストを助けます
- コードレビュー（コードレビュー）
- パッケージの展開は、コードフリーズを伴うこと
- ハードワークの残業タイプ。あなたが見ることができます名前、強制するのが最も難しいタイプからこれ。このような特定の場合には、顧客が協力し、古い顧客の多くの年です。事業への地方政府の政策、及びその完全なお金にあなたはそれ以外の場合は、ビジネスを行うことを許可されていない、特定の時間に、デジタル化する必要があります。お客様が自然に会社2 Gouzi兵士の下、何もアプローチ、残業詠唱として、ここで私たちを投げ、このタスクを配置します。行4週間の作業計画の6週間、それがああ、これを行くことができる人です。母
同社は、伝統的な毎日の朝の会議が昨日、今日、そしてどの部分が動作するつもり作業することを報告して基本的にオープンしました。上記の3つのモードは、私は個人的にそれが唯一の以前の会議の第二の完全な使用だと思います。誰もが非常に明確に定義されている場合に行うとしても機能し明確な目標を持っているので。朝に参加すると、あなたが扱うとコードされている、非常に論理的に話します。昨日は1,2,3を説明した何を、どのような問題に遭遇、技術的な支援の必要性。そして今日、おそらくいくつかのより多くのことを行うための計画、前か、バックエンドのサポート、の部分の内容です。明らかに、会議は喜びです。いくつかの特別な会合に加えて、我々は通常の会議を立って、それが判明し、少ない人は、ハハ、ナンセンスの多くを立ちます。
完成に近づいてプロジェクト全体の開発は、一般的に小さなパートナーは各ファンクションポイントに特定のテストするときは、数回にわたり詳述されています。いくつかの経験、またはいくつかの非常に著名なバグには影響しないことが保証されます。もちろん、このプロジェクトは結局、残業の終わりである理由は、そのようなことのバグは、まあ、我々はすべてを知っています。テストと開発パートナーのための期間は、デプロイメント環境の要件に対応した小型のドキュメントを準備するようにソースコードを提供し、します。テーブルのギャングを渡ってそれを考えて、私たちを思い出させる：「呪いの顧客のコメントはああ削除されている！」、しかし、また、非常に興味深いです。
顧客への納入後、通常UAT、ユーザー受け入れテストのために使用さ2〜3週間の時間を持っています。試験期間は、ハード小さなパートナーの一部となり、顧客は、顧客がそれは改善する必要があると思う、または顧客が記録され、対応する補修開発に割り当てられたものを、バグ、見つける場所を確認するために、頻繁に通信します。顧客がバグを発見したので、より小さなパートナーの開発は、この期間中に浸る、時々バグが、時々、より深刻な一日の魚に触れることができない、一晩の修理が可能です。
正式クライアント側の後に立ち上げ、当社の開発チームは、時間は1〜2ヶ月で、サポートされます。この時間の後、いくつかの長期的なプロジェクトのために、コードがサポートチームに転送され、彼らの主な仕事は、いくつかのメンテナンスに、などとするデータとをクリーンアップ。
記載漏れがあるか、どこに向上させることができ、そして来るように頼む場合は一般的に、もちろん、これは、私が見ることができるだけで開発の観点このようなプロセスです。だから、少しは新しい経験を総括し、彼らは、同僚ために多くの注目となりそうですが、また、非常に興味深いことではありません。
特定のバグ追跡について話をしてきます。
現在、Tracのシステム、おそらくほんの数、tracの、自社メンテナンスgitlab、カマキリを経験しました。実際にカマキリがソースフレームワークプロジェクトは、他の人の上に描画され、実際に脇に置く、回帰テストのバグで動作するようには適用されませんでした。
Tracの
このTracのシステムはかなり古いのですが、機能は非常に強力。このようなバグのライフサイクルの何かが、テストでは、問題の設計要件を満たしていない小規模なパートナーを測定しました。再生、期待される結果、実際の結果、優先度等の工程を含むバグの具体的な説明。この部門の一般的な優先事項：
- 携帯電話のアプリケーションがクラッシュしたとして、極端な衝撃試験や経験、表記P0は、フラッシュバック。
- アプリケーション全体のプロセスを介して試験の完全な影響は、このような失敗するページジャンプとして、P1と呼ばれます。
- エラー未処理または分枝経路エラー、P2と称します。
- いくつかのジェスチャーの動作はP3としてマークされたり修理しないように、それはデザインと一致していませんが、顧客が受け入れることができます。
それは、典型的には、彼が特定の開発に割り当てる必要があり、対応する開発のリーダーに割り当てた後です。
実際のプロジェクトでは、現在の違いは、あなたの参考のために記録されている二つのそのような特定のモードを経験。QAとして記録されたテストは、開発はデベロッパー、以下同じと呼びます。
- QAレポートバグ==>解決済みとしてマークされDevのがバグを修正します==>のDevは/展開環境を再パッケージ==> Devのバグを修正するQAに割り当て==> QA検証バグ
- バグが解決==> QA検証バグとしてマークされた彼の新聞からのQAレポートバグ==>解決済みとしてマークされDevのがバグを修正します==>のDev /展開環境を再パッケージ==> QAビュー
おそらく全く異なる見ていないではありません。主な違いは、QAに再度割り当てるにDevのバグ修正の後に実際にあるかではありません。ここで私は良いですし、自分の欠点だと思う二つの方法があります。まず、プロジェクトの開発プロセスのタイプに応じて、使用するアプローチ決定します。
最初のアプローチでは（私たちは必死に残業モードでこのように使用されている）、利点はQAがはっきりDevのは、修復されたされ、修復されていて、認証されることができるテスト環境に配備されているバグを知ることができます。実際の作業以来、私たちは知っている、バグが修理だけでなく、実際には、コードを提出する場合、QAはまだ変更されていない、変化が確認できるQAのQA環境に再展開します。しかし、このアプローチはまた、それぞれのDev修正バグバグの後、すべてが再びtracの上でこのバグの所有者の変更を引き起こし、QAを与えた割り当てるので、私たちは誰もが修復正確に知ることができない、チームのリーダーとして、欠点を持っていますバグ、バグが好きだ誰の面でいくつかの統計情報が何でありますか。
第二のアプローチの下では、devがちょうど解決済みとしてバグがマークされている修正します。開発プロセスより標準化、テスト環境を更新するための時間ので、比較的固定されているので、内容は仕事の前に毎日更新されると仮定。バグが修復され、その日は解決としてマークされている場合、それは仕事を離れる前日に新しい環境に含まれている必要があります。このようなテストは、検証のために、すでに良いマークが何であるかを見てみましょう、その後、自分自身のスクリーニングReporterのバグを見つけるために、次の日に使用することができます。このように、開発チームの指導者は明らかにどのように深刻な、どのようなバグで、番号を修正誰が誰であるかを見ることができます。この方法であれば、実際に一致する特定の開発モデル、素晴らしいです。ただ、いくつかのクレイジー残業、1日に数回の環境を更新することができる、主要なQAが彼の手を知らないではないコードが更新されている、または、既にそれらの変更をし、バグの良い修正されている含まれていません苦痛を引き起こして自分の仕事。
GitLab
私は漠然とGitlabが特定のバグを関連付けるとDevの閲覧を容易にするために、それらを提出することができます覚えています。だから月曜日に、私は私が詳細にそれを追加します時間を見つけるだろう、最初のハハの仕事の友人から転落。