問題タブ [agile]

私は 10 人のチームで大規模なレガシー コード ベースに取り組んでおり、プロダクト オーナーは理想的とは言えません。私たちのバックログはかなり悪い形であり、大規模なエピックが頻繁にスプリントを破っています。チームはまた、done の定義にも苦労しています。時間に応じて、熱心にユニット テストを作成するメンバーもいれば、作成しないメンバーもいます。

それで、私はいくつかの興味深いバーンダウン パターンを見てきました。他の人が見ているパターンとその意味を知りたいと思っています。

パターン 1:

• 肯定的な説明: 「大丈夫です。」
• 否定的な説明: 「うますぎる。本当はどうなっているんだ?」

パターン 2:

• 肯定的な説明: 「これは思ったよりもずっと簡単でした。もっと多くのストーリーを取り込みましょう。」
• 否定的な説明: ??

パターン 3:

• 肯定的な説明: 「この作業について最初はよくわからなかったが、後で思ったより簡単になった」
• 否定的な説明: 「進捗が不十分です。ユニット テストを書くのをやめて、時間どおりに「完了」させましょう。」

インフラストラクチャにスクラムとスプリントを使用している人はいますか。

私は、決して終わらないスプリントの概念、つまりネットワーク拡張プロジェクトに苦労しています。

また、アイテムの時間を製品バックログに積み上げる方法についての提案もあります。これにより、リソースがスプリントでオーバーコミットされていないことを健全にチェックできます。

これは、新しい.netベースの開発プロジェクトを経験のないアジャイルな方法で開始および管理するための最良のチュートリアル、書籍、ソフトウェア、およびプラクティスです。XP |スクラムを採用するのが簡単な方法はどれですか？

今年はスクラムとアジャイルのテスト/アサーションが人気になっているようです。たとえば、Nokiaはスクラムをテストします。そのようなテストをするのは良い考えではないと思います。どう思いますか？

ユーザー ストーリーを新しいプロジェクトに実装したいのですが、アジャイル開発で使用される適切なテンプレートやその他のテンプレートはどこにありますか?

従来のウォーターフォールでは、難解なテンプレートに従って、通常は MS-Word 文書に要件がまとめられていました。「厳密な」ウォーターフォール モデルでは、このドキュメントは要件フェーズの後に凍結され、変更管理/変更管理プロセスが管理された変更の導入を担当します。(**) [通常、ドキュメントは「生きたドキュメント」になり、最終的には「生きた悪夢」になります]

現在、私は既存のデスクトップ アプリケーションを Web に (VB 6.0 から ASP.Net に) 書き直すプロジェクトを率いています。クライアントは、書き直したいアプリケーションのベースライン バージョンを持っています。[したがって、要件は凍結されています...スコープクリープはありません]。そのまま再利用するデータモデル。移行するフロント エンド/ビジネス ルールのみ。アプリケーションを見ると、それはせいぜい 3/4 の主要な画面であり、それだけです。

一部のチーム メンバーは、新しい開発に着手する前に、すべてを文書化したいと考えています (私の意見では古い考え方です)。UI を Web に変換し、古いコードを検索し、ビジネス ロジックを記述し、自動化された単体テストを実行し、統合テストに進み、画面ごと (または機能ごとにビジネス機能) を配信するのは、比較的簡単なはずだと私や他の人は感じています。

私の質問は次のとおりです。アジャイル開発では、これを最適化しない場合、どのように「アジャイル」を維持しますか。私の意見では、詳細なドキュメントを書くことは反アジャイルです。どう思いますか？アジャイルの第一人者は、上記の問題 (既存の VB 6.0 アプリを ASP.Net に書き直すという問題) にどのようにアプローチしますか?

免責事項: 1000 ページの機能仕様の作成は、契約上の義務、政治的必要性を満たすためである可能性があり、システムは本当に複雑になる可能性があります (現在、「複雑さ」の定義は暗い土地への旅です)。

もしそうなら、次のような「気分が良くない」ものにどのように対処しますか?

• 単体テストを書かない
• 継続的なビルドがない
• リファクタリングしない
• チームのコーディング標準がない
• ペアプログラミングではない
• 反復を行わない
• 毎日のスタンドアップはありません
• ふりかえりなし

現在、一部のアジャイル組織はこれらのプラクティスの一部を省略していますが、ほとんどの成功した組織にはそれらのほとんどが組み込まれています。

従来の開発プロセスの混乱に対処するために何をしていますか?

開発プロセスを改善するために、アジャイル開発のどの側面を最初に実装する必要がありますか?またその理由は?

私は、プロセスを再設計するのではなく、プロセスを「微調整」する必要がある状況にあり、「アジャイル」が今日のマントラのようです。品質、市場投入までの時間、ドキュメント、透明性など、何かを改善する変更を 1 つだけ加えることができる場合、最も目に見えるプラスの影響を与えるものは何ですか?

正しく選択すれば、次の選択をすることができます。:-)

更新: 現在の SDLC は何ですか?
環境: 基本的に「再起動」。少数の開発者。10^5 から 10^6 の LOC を備え、世界中に何万もの展開されているレガシー製品。製品は相互に強く依存しています。リファクタリングなしの多くの 1 回限りのものを含む、長年にわたって追加された重要な機能。タイトなスケジュール; 表面的な QA; 事後分析や「プロセスの第一人者」はいません。

典型的なプロセス:

1. 設計・仕様書作成 すべての利害関係者によるレビュー。
2. 1 つ以上の機能/修正をコーディングします。
3. サプライズを考慮して設計/仕様を修正します。
4. 機能をテストし、欠陥を記録します。
5. 新しいタスクと残りのタスクに優先順位を付けます。
6. 設計・仕様・スケジュールの見直し。
7. 必要に応じて手順 2 に戻ります。
8. ベータ版をリリースし、フィードバックを記録します。
9. 必要に応じて手順 2 に戻ります。
10. 公式リリース。

たくさんの有益な提案と洞察をありがとう！

私たちはTracをバグ追跡 / 開発 / wiki システムとして使用していますが、Trac Agile/Scrum プラグインまたは機能のいくつかを使用した経験のある人はいますか? 何かお勧めはありますか？

それとも、枯れ木のユーザー ストーリーのインデックス カードと手描きのバーンダウン チャートとして Trac チケットを複製した方がよいでしょうか?

ここで同様の質問を見つけたことに注意してください。それは特にスクラムに関するものですが。彼らはアギロをお勧めします。アギロを試した人はいますか？

私は MVCStoreFront アプリで Rob Connery の Web キャストを見ていました。

次のようなテストがあります。

私はすべて単体テストに賛成ですが、この形式のテスト ファースト開発が本当に有益かどうか疑問に思うことがあります。たとえば、実際のプロセスでは、コードの上に 3 ～ 4 層があります (ビジネス リクエスト、要件ドキュメント、アーキテクチャ ドキュメント) 、実際に定義されたビジネス ルール (割引価格は価格 - 割引) が誤って定義されている可能性があります。

その場合、単体テストは何の意味もありません。

さらに、単体テストは別の障害点です。

今、テストに欠陥があります。明らかに単純なテストでは大したことではありませんが、複雑なビジネス ルールをテストしているとしましょう。ここで何を得るのですか？

保守開発者がアプリケーションを保守している 2 年間、アプリケーションの寿命を早送りします。ビジネスがルールを変更し、テストが再び失敗し、一部の新人開発者がテストを誤って修正しました...ここで、別の障害点が発生しました。

私が見ているのは、より多くの可能性のある障害点だけであり、実際に有益なリターンはありません.割引価格が間違っていても、テストチームは問題を見つけます.ユニットテストはどのように作業を節約しましたか?

ここで何が欠けていますか？今のところ、TDD を有用なものとして受け入れるのに苦労しているので、TDD を愛するように教えてください。プログレッシブであり続けたいので、私もそうしたいのですが、それは私には意味がありません。

編集: テストが仕様の強制に役立つと何人かの人々が言及し続けています。多くの場合、仕様も間違っていたというのが私の経験ですが、仕様を書くべきではない人によって仕様が書かれている組織で働く運命にあるのかもしれません。