8

PMがチームが「自分のドッグフーディングを食べる」べきだと主張するプロジェクトが予定されていますか?

これを行うのはどの時点で現実的ですか?

たとえば、エディタを作成する必要があると仮定します。このエディターは存在しないため、最初は実際にコーディングするために使用することはできません。別のエディターを使用する必要があります。

プロジェクト中しばらくの間、バグのあるエディタを使用するとプロジェクトの速度が低下し、逆効果になります。

では、どの時点で切り替えますか?

更新:チーム内で話し合った後、開発中に強調するポイントは次のとおりです。

  • 最初に可能な最小のサブセットを実装する
  • 重要な機能をできるだけ早く特定する
  • リスクを最小限に抑えるために、一部の開発者のみを新製品の使用に切り替えます
4

12 に答える 12

12

できるだけ早く使用する必要があります最初のバージョンは、(この場合は)エディターとして使用するために必要な最も重要な機能のみを使用して削除する必要があります。使い始めると、急いでどの機能が重要かがわかります。

于 2008-10-23T02:03:46.713 に答える
4

<暴言>

ドッグフードを作らないなら、ドッグフードを食べる必要はありません。

とにかく、この病的で愚かなフレーズの起源は何ですか? 犬は自分で食べ物を生産しません (下品な例外が 1 つあります)...

</rant>

PM に、開発中の製品を使用して開発を行うことと、品質の高いコードを予定通りに作成することのどちらがより重要かを尋ねます。競合がある場合、どちらがより重要ですか?

常識的な答えは、あなたが持っているツールよりも優れているときに、あなたが構築しているものを使用することです.

于 2008-10-23T02:12:56.977 に答える
3

開発エディタのみを使用するように切り替える必要はありません。それがあなたの生産に影響を与えるまでそれを使い始め、問題のあるもののリストを作り、それらを修正し、あなたがそれをほとんど/常に生産的に使うことができるまで繰り返します。

于 2008-10-23T02:04:46.040 に答える
2

プロジェクト中しばらくの間、バグのあるエディタを使用するとプロジェクトの速度が低下し、逆効果になります。

あなたはあなたの答えを持っているように聞こえます。切り替える時期は、プロジェクトが生産性を妨げない時期です。

于 2008-10-23T02:07:33.260 に答える
1

これは、「場合による」質問の 1 つです。いくつかのガイダンス:

  • プロジェクトが完全にベイクされる前に使用するリスクは何ですか? それらは受け入れられますか?
  • プロジェクトの進行が速くなったり遅くなったりしますか? これは問題ですか?
  • ビジネスの観点から、最終製品の品質は向上しますか?
  • プログラマーの生産性を向上させても、顧客にとっては役に立たない機能で終わるでしょうか?
  • 逆に、重要な機能は、開発者が「関心」を持っていないために延期されますか?
  • 「ドッグフードの味」は開発者のモチベーションになりますか?

おそらく最も役立つガイドは、最初に説明してくれた同僚にちなんで「ヘドリックの法則」と呼んでいるものです。

誰かに何かを成し遂げてもらう必要がある場合は、それを達成しないことを彼に苦痛にさせてください!

もちろん、反対側は、プロジェクトをできるだけ早く、できるだけ早く終わらせることを楽しくすることです. 個人的には、道具を作ったり使ったりするのが好きなので、慎重にできる限り早くドッグフードを提供したいと思っています. しかし、私の同僚はサディストで、「コンパイルしたらすぐに!」と答えたでしょう。

あなたのプロジェクトで頑張ってください!

于 2008-10-23T02:17:27.717 に答える
0

開発がどのように行われているかに応じて、早めまたは遅めに切り替えることができます。TDD方法論を使用している場合、またはバグの発見と修正がリストの上位にある場合は、日常生活に役立つと思われる十分な機能がある場合はいつでも開始します。機能に効果的に優先順位を付けた場合、これは開発の非常に早い段階である可能性があります。

そうでなければ、私はあなたが後の段階のいくつか、プレアルファまたはプレベータに到達するまで待ちます。これは、開発の初期段階であまり痛みを感じていないことを意味します。

他の人が述べたように、開発の取り組みを変更して、製品をより早く使用できるようにすることができる場合は、それを実行してください。さまざまな機能を評価し、最初のユーザーが製品に感情的に愛着を持てるように、できるだけ早く製品を本格的に使用し始めることをお勧めします。気になる開発者は、プロジェクトをさらに改善するために、その余分な努力を払うことがよくあります。

于 2008-10-23T02:05:20.580 に答える
0

それは、機能の「クリティカルマス」が何であるかを見つけることです。機能ではなくバグの問題である場合は、今すぐ切り替えてください。バグを修正します。ツールが役立つ前に機能開発を行う必要がある場合は、それらの重要な機能を終了してから切り替えてください。

そして、私はあなたがエディターを書いているのではないことを心から願っています!;-)

于 2008-10-23T02:05:42.560 に答える
0

正解はできるだけ早くだと思います。もちろん、バグのあるバージョンを使用すると、最初は速度が低下しますが、開発中にQAを実行するため、長期的には時間を節約できます。アプリケーションにブロッカーがある場合に大きなホールドを防ぐために、チーム全体ではなく、一部のチームを切り替えることをお勧めします。

于 2008-10-23T02:07:20.653 に答える
0

ドッグフードがおいしくなったら、そしてできるだけ早く。これは、早い段階で頻繁に価値を提供する必要があるという別の言い方だと思います。ところで、既知のバグのあるソフトウェアを配布しないでください。バグのない機能が少ないほど、バグのある機能が多いよりも優れています。

于 2008-10-23T02:51:19.397 に答える
0

サイズ、スケーラビリティ、スコープがすべてです。製品が「ドッグフード」アプローチから価値ある成功をもたらすなら、ASAP が正しい答えです。エンド ユーザー エクスペリエンスは、製品を使用した結果を左右します。

于 2008-10-23T03:08:11.250 に答える
0

「アルファ」段階に達するまでは使用を開始しないでください。すべての主要な機能が完全で、既知の重大なバグがない必要があります。その後、使用を開始できます。

開発者だけでなく、ターゲット ユーザーに試してもらうことも重要です (開発者ツールでない限り)。

「これができたら最高じゃない?」という多くのユーザーに対応できるように、十分な開発時間を確保したいと考えています。機能を可能な限り。

于 2008-10-31T19:33:54.257 に答える
0

この質問は、開発チームが使用しないソフトウェアに適用されると意味がありません。したがって、開発者はできるだけ早くそれを使用する必要があります。「実現可能」とは、それが適度にうまく機能し、物事をそれほどひどく壊さないことを意味します。

テキスト エディタを開発する場合、間違いは重大ではないため、開発者は早い段階でそれを使用する必要があります。バージョン管理システムを開発するとき、開発者はそれが健全であることが証明された後にのみ使用するべきです。Subversion チームが CVS サーバーから切り替えたとき、これは大きな問題でした。

1 つのアイデアは、チーム内に初期の採用者と後期の採用者を配置することです。後から採用した人は、初期の採用者が盲目になったことを発見する可能性が高いからです。

于 2008-10-31T19:44:56.450 に答える