6

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

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

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

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

典型的なプロセス:

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

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

4

12 に答える 12

7

反復的な建物

ビルドを一貫して (私たちの場合は毎週または週に 2 回) 行うように移行したとき、最大の改善が見られました。

すべてのビルドが作成されると、開発チーム、QA チーム、製品管理チームと話し合い、新しいビルドに含まれる作業のリストを作成しました。

次に、次のビルドに何を含めるべきかという質問に全員が答えました。

それ以来、アジャイル開発の他の多くの機能を追加してきました (スクラムを厳密に実装しようとすることを含む)。

于 2008-10-25T18:10:34.180 に答える
5

反復開発。小さなイテレーション (たとえば 2 週間) で作業し、各イテレーションの終わりまでにアプリケーションを「準備完了」にします。つまり、テスターは喜んで結果を顧客にリリースする必要があります。

これがコアです。これに基づいて構築できます。

于 2008-10-25T18:07:03.283 に答える
4

私はミックスアンドマッチの大ファンであり、開発プロセスの漸進的な変更です。反復開発が最初の目標であることには同意しますが、さらに小さなステップでアプローチできると思います。

私の経験から、次の順序をお勧めします。まだ行っていない最初の順序を選択してください。

  • まずバグを修正します。そんなこと言わなくてもいいのに。これは正気の呼びかけであり、より短いサイクルが必要です。

  • 小さなステップ。次の機能への目に見えるステップである最小の変更を実装する習慣を訓練し、コンパイルしてテストします。コーディングを開始する前に、すべてのタスクを 1 時間未満の単位に分割します。少なくとも 15 分ごとにビルド可能で機能的なコードを目指します。これは、インクリメンタル ビルドを修正して高速なマシンを用意することを除いて、インフラストラクチャの変更をあまり必要としません。

はい！開発者が高速なマシンを使用できるようにすることから始めます。どれだけ良いアドバイスが得られるでしょうか?!

  • 毎日すべてを構築します。理想的には別の PC で、ソース管理からインストール メディアへのフル ビルドをダブルクリックでセットアップします。これは頻繁なビルドへの最初のステップですが、すでに多くのことを助けています。私たちにとって、これは信頼性が高く再現可能なビルド結果を得るための重要なステップでした。

  • 単体テストの作成を開始します。カバレッジについてはまだ気にしないでください。「最初にテストを書く」ことを強制するのではなく、フレームワークを配置してください。新しいコードと変更のテストを作成します。次に、毎日のビルドでそれらを実行します。

  • 短いサイクル。今こそ、毎週または 2 週間ごとの社内リリースを作成するためのすべてのツールが用意されていることです。コードベースは 1 日に何度も成果物の状態にあり、ダブルクリックするだけでビルドを作成でき、少なくとも何かが機能しています。 .

于 2008-10-26T00:24:02.040 に答える
4

テスト駆動および/またはアジャイル開発の管理に関する具体的な「ハウツーマニュアル」を参照してください。.

私の推奨事項は、まず TDD から始めることです。これは非常に簡単に行うことができ、品質に大きな影響を与えます。

これにはいくつかの部分があります。

  1. 誰もがツールを入手する必要があります (JUnit など、一部の文化ではこれが難しい場合があります)。

  2. マネージャーは、テストが完了するように要求する必要があります。単体テストを決して (絶対に) 回避してはなりません。誰かが「それらのテストは問題ではないので、とにかく出荷してください」と言うとすぐに、TDD の利点をすべて台無しにしてしまいます。

  3. テストケースごとに管理する必要があります: 書かれた数、合格した数。テスト ケースを介して機能を定義する必要があります。機能 [X] には [n] 個のテスト ケースがあり、そのうちのいくつかは完了しており、いくつかは進行中です。

于 2008-10-25T18:17:51.187 に答える
3

プログラマー、テスター、テクニカル ライター、そして場合によってはセールス/サービス担当者が一堂に会する部門横断的なチームを作ります。「完了」の概念を認識させます。つまり、完成させるものとは、記述、テスト、文書化、インストール、展開、および顧客が使用する準備が整ったものです。

さまざまな機能分野の全員が集まり、クライアントに何かを届けるという単一の目的に集中しない限り、アジャイル フレームワークの他の側面を実装することはできないため、これは重要です。

于 2008-10-25T17:57:18.733 に答える
3

アジャイルは現在かなり流行語ですが、特効薬ではないことを覚えておいてください。そのように開発プロセスを修正することはできません。Steve Yegge のアジャイル開発に関する優れた記事を読んで、誇大宣伝のバランスを取ることをお勧めします。

アジャイルの核心を理解していないと、アジャイル開発のいくつかの側面を「いいとこ取り」するのは難しいかもしれません。アジャイルは何よりも考え方です: 柔軟であること、物事が変化することを受け入れること、1 つまたはいくつかの機能を完成させることに焦点を当てた短い反復でコードを書くこと。単一の完全なモノリシックな仕様を取得し、すべてのコードとドキュメントを作成して出荷するのとは反対です。

アジャイル開発が機能することを証明したいのであれば、「早期にリリースし、頻繁にリリースする」ことの意味を示すためにスプリントを使用することにおそらく投票するでしょう。

于 2008-10-25T18:09:09.677 に答える
3

既存のプロセスに完全に依存しますが、私たちが行った最善の動きの 1 つは、アイテムのバックログと毎日の 3 つの質問 (最後に会ってから何に取り組みましたか?今日取り組むべきことは何ですか? 前進を妨げている障害は何ですか?) 午前中にミーティングを行い、現在の状況と、短いイテレーション サイクルの終点に向けて前進するために何ができるかを確認します。

実行すべき作業の動的なバックログ、現在取り組んでいること、次のイテレーションに向けて進めていることを確認できるのは良いことです。個々の開発者がどこにいるかを把握し、前進するための障害を排除するのに役立つのは良いことです。開発者が暗くなるのを防ぎます。

とにかく、それが私の考えです。それは私たちのために働いた。

于 2008-10-25T18:28:54.660 に答える
1

テスト駆動開発を試してみます。これにより、多くのことが得られます。

  • かなり良い単体テスト カバレッジが得られます (単体テスト カバレッジが重要だと言っているわけではありません)。
  • 開発者は、コードが実際に機能していることに自信を持つことができます (詳細については * を参照してください)。
  • コードをより簡単にリファクタリングできます (テストがあるため)。

[*] - このエリアの Kent Beck は、影響図について言及しています。インフルエンス ダイアグラムでは、ノード間の矢印は、最初のノードの増加が 2 番目のノードの増加を意味することを意味します。円の付いた矢印は、最初のノードの増加が 2 番目のノードの減少を意味することを意味します。

-----> [Stress] <--o-- / --o--> [RunTests]

ストレスを感じれば感じるほど、テストは少なくなります。テストが少なくなればなるほど、より多くのエラーが発生します。エラーが多ければ多いほど、ストレスを感じます。繰り返す...

開発者がストレスを感じ、しばらくすると自分のコードを信頼できなくなるというこの循環を解決するにはどうすればよいでしょうか?

最初の開発をテストすると、影響図が変わります。

[TestFirst] <--o-- / --o--> [Stress]

最初の開発をテストすればするほど、感じるストレスは少なくなります。感じるストレスが少ないほど、最初に開発を行うテストが多くなります。

これにより、コードを信頼する開発者が開発したコードをより適切にテストできます。

于 2008-10-25T21:44:27.930 に答える
1

自動ビルドで実行される自動テスト。

于 2008-10-25T19:31:56.543 に答える
1

すでに提供されたすべての優れたアドバイスに加えて、私も同意しますが、自動で反復可能なテストを使用して QA を強化することをお勧めします。自動化に投資することで、既にデプロイされているコードを変更する際に自信を持つことができます。

新機能を実装すると同時に、新機能の回帰スイートを作成します。

QA は、開発プロセスの穴を見つける代替手段として探索的テストを使用できます。

于 2008-11-02T08:10:13.213 に答える
1

まだ単体テストを行っていない場合は、単体テストから始めてください。単体テストを行っている場合は、テスト駆動開発に切り替えてください。これらはどちらも既存のプロセスに簡単に追加でき、すぐに利益をもたらします。プロセスの変更に取り組む準備が整ったら、反復開発を導入します。現在のプロセスがすでに反復的である場合は、反復を顧客に頻繁にリリースしてフィードバックを取得します。

「アジャイル」な方法を要約するとしたら、高品質のビジネス価値を早期かつ頻繁に提供することです。上記のプラクティスは、その道に沿って長い道のりを歩むでしょう.

[編集] 私が提案しているのは、アジャイル手法を採用するアジャイル アプローチを採用し、すぐに多くの価値をもたらす簡単なことから始めることだと思います。

于 2008-10-25T18:17:12.577 に答える
0

アジャイルの最も価値があり、実装が容易な 2 つの側面は次のとおりだと思います。

  1. 毎日のスタンドアップ - チームとの簡単なミーティングを毎日行い、ステータスを確認します。3つの質問を使用してください。クロストーク、おしゃべり、愚痴は避けてください。迅速かつ適切に実行してください。

  2. タイムボックス イテレーション - プロジェクトを 2 ～ 3 週間のサイクルに分割すると、合理的な期限内に管理可能な目標に向かって作業する必要があります。

于 2008-10-25T21:04:18.887 に答える