問題タブ [development-process]

効果的なバグ追跡には高品質のバグレポートが不可欠です。理想的な世界では、すべてのバグレポートに、影響を受けるソフトウェアのバージョンやバグの再現方法に関する段階的な説明などの重要な情報が含まれます。

ただし、実際には、報告されるバグの品質は大きく異なる可能性があります。それらは、オンライン（「機能Xが機能しない、修正してください！」）、機能要求、PEBKAC、または理解できない可能性があります。

バグトラッカーのバグレポートの品質をどのように実施または維持して、効果を維持しますか？

私の父はいつも「権限のない責任は無意味だ」と言います。

ただし、開発者として、私たちは常に次のような状況に陥っています。

• ソフトウェアに「バグがない」ことを確認する責任がありますが、バグ追跡システムを実装する権限はありません
• プロジェクトの期限を守る責任がありますが、要件、品質、またはチーム リソース (プロジェクト管理の 3 つの部分) に影響を与えることはできません。
• 等

もちろん、これを回避するためにあなたが言うことができることはたくさんあります - 新しい仕事を見つける、上司と戦うなど....

しかし、この問題に対する技術的な解決策はどうでしょうか? つまり、これらの問題のいくつかを修正するようにチームを説得する必要なしに、自分でどのようなコーディングを行うことができるか、または追跡されていないバグがあなたを傷つけている理由、締め切りに間に合わない理由を示すためにどのようなツールを使用できるかです。また、これらのツールを使用して、上司になることなく、より多くの「権限」を得るにはどうすればよいでしょうか?

***例 - 上司があなたのところに来て、「なんでこんなにバグが多いの!?!?」と言います。- 私たちのほとんどは、「追跡するための優れたシステムがありません!」と言うでしょうが、これは通常、私の経験では言い訳と見なされます。では、レポート (マネージャーはレポートが大好きです) を指して、「ほら、これが理由です」と言うことができたらどうでしょうか?

さまざまな新機能を含むユーザー ストーリーを実装し、コード ベースに複雑さを加えていると想像してください。既存のコードは十分にカバーされており、インターフェースを決定したところです。テストから機能の実装を開始しています。

これで、要件に基づいたかなり複雑なテスト ケースができましたが、実装は、SCM の完全に機能するコードにコミットでき、多くのテストが (当然のことながら) 失敗する時点にはほど遠い状態です。

継続的インテグレーションでは、可能であればすべてのビルドをグリーンにする必要があるため、ビルドを壊してしまうのでコミットしないでください。しかし、 「暗くなる」べきではなく、そのような量のコードを自分で保持するべきではありません...

このような状況で推奨される手順は何ですか?

コミットされたコードが根本的に正しいことを確認するために手動でチェックを行うことなどがあることは知っています。しかし、その横に？私が尋ねる理由は、毎日非常に多くのコミットがある大きなプロジェクトだからです。

初心者の質問ですが、ご容赦ください。どのような状況で nant や msbuild などのビルド ツールを使用する必要があるのか​​ 疑問に思っています。私は中規模のアプリケーション (.net 3.0) に取り組んでいます。すべての開発者が自分の作業を行っており、自分のコードの変更をリポジトリにチェックしながら自分のマシンでビルドしています。すべてが完了したら、リポジトリからすべてのコードを取得し、自分のマシンでクリーン ビルドを作成して、バイナリをデプロイします。好奇心から、ビルド ツールはどこにあるのでしょうか。

失敗した/失敗したプロジェクトの典型的な話を聞いたことがあるはずです。

1. 経験の浅いプログラマーのチームが 24 時間年中無休で働いています
2. バグは、新しいバグを導入するためだけに修正されます
3. お客様は、基本的なこと (保存/クエリ) などを行うことさえできなかったと叫んでいます。
4. 仕様を受け継ぐことに慣れたプログラマーは即興に苦労する
5. 自動化された単体テストがないことが状況を悪化させる
6. 紙の上では見栄えのするアーキテクチャ ドキュメントは、実際には守られていませんでした
7. そもそも適合性がテストされていないサードパーティのコンポーネントがボトルネックになる
8. マイルストーンを逃した後のマイルストーン
9. 実際に実行する必要がある作業量について誰も同意しないため、チームは納期を決めることができません
10. 技術的なリーダーシップがない、または技術的な問題に対処できるカウボーイ コーダーがいない

では、あなたが10番として連れてこられるとしたら、あなたの最初のステップは何ですか?

更新: まず第一に: 参加してくれてありがとう。うーん...私は #10 として参加しています。クライアントに提案を行ったとき、私は最初のアーキテクトであり、ソリューションを固定していました。残念ながら、私は別の場所に配属されたため、配達の責任を負うことができませんでした。:)

それが既存のデスクトップ アプリケーションの Web 化であるとしましょう。私は今、＃10として連れてこられています。悲しいことに、逃げることは選択肢ではありません。これは、アジャイルのベストプラクティスに従うことで逆転できると確信しており、コミュニティからアイデアを引き出したかっただけです.

より大きな問題は、おそらく次のようなものです。開発チームが仕様を持っておらず、実行中のアプリケーションの (ベースライン化された) コードしか持っていない場合、元のソリューションでは、コードを見てその場でビジネス ルールを抽出する必要がありました。現在、経験の浅いプログラマーは、VB 6.0 のコードを見てドキュメントを欲しがるのをためらっています。では、アジャイル プロセスを導入する場合、どのようにこれと戦うのでしょうか?

私は過去に継続的インテグレーション サーバーを使用して大きな成功を収めましたが、ソース コントロール システムでコード フリーズを実行する必要はありませんでした。

しかし、最近はどこを見ても、ほとんどのショップが、製品のリリースや新しいテスト バージョンの準備をするときに、コード フリーズという概念を使用しているようです。この考えは、私の現在のプロジェクトでも実行されます。

早期に頻繁にチェックインし、単体テスト、統合テスト、受け入れテストなどを使用する場合でも、コード フリーズが必要ですか?

ASP.NET を使用して Web アプリケーションを開発する場合、コンテンツ/機能の開発を設計から分離して、2 つを別々に並行して開発できるようにする方法についてヒントはありますか?

状況は次のとおりです。

• 顧客は、必要な機能について同意している
• お客様がページの外観 (スタイルとレイアウト) について考えを変えている
• Web デザイナーは専門家ではありません。
  • クリーンな CSS ベースのレイアウトをゼロから開発していない
  • サードパーティのサイトからさまざまなテーブルベースのレイアウト (CSS を使用) を取得し、レイアウトの例/プロトタイプとして使用して顧客と話し合う

これを考えると、テーブルベースのレイアウトが完成する前に機能のコーディングを開始するにはどうすればよいでしょうか?

それを行う1つの方法は次のようになると思いました：

• レイアウトやスタイルを気にせずに (各ページにアクティブな要素を作成することを含む) 機能をコーディングします。
• 最後に、デザイナーと顧客がデザインに同意した後、アクティブな要素をデザイナーのプロトタイプ ページにカット アンド ペーストします。

これはそれを行う唯一の方法ですか、それとも最善の方法ですか? 他にどのような方法がありますか？これを簡単にするためのヒント、ヒント、またはトリックはありますか?

私はかなり小さなスタートアップで、スクラム/アジャイル開発サイクルの形式を使い始めました。

多くの点で私はスクラムを楽しんでいます。スプリントは比較的短く（2週間）、チームの進捗状況を追跡するためのバーンダウンチャートが好きです。フィーチャーボードも好きなので、次に何をすべきかを常に知っています。ボードからフィーチャーのカードを取り出し、それを完成させてから、バーンダウンパイルに入れるのは気持ちがいいです。

しかし、私たちは今、18回目のSprintリリースサイクルに入っており、少し燃え尽き症候群を感じ始めています。私が仕事や同僚が好きではないということではなく、これらのスプリントが...まあ、スプリントであるということだけです。最初から最後まで、私は文字通り、開発速度を維持するために時間と競争しているように感じます。スプリントが終了したら、1日かけて次のスプリントの機能セットと見積もりを計画し、それからまた出発します。

成熟したアジャイル/スクラム開発プロセスで働く人々にとって、これは正常ですか？それとも何かが足りないのですか？通常、スクラム環境で、割り当てられていない/追跡されていない時間に、いくつかの小さなことを実行し、頭をすっきりさせる時間がありますか？