これはすべて、生産在庫、原材料、または半製品であり、利益を上げるために最終製品に変えて販売する必要があります。 在庫はマシン間で移動および蓄積されます。 ハンバーガーのバンズにゴマを振りかける機械の隣には、この同じゴマの入った容器があります。 コンベヤーの最後には、既製のパンとロールの箱があり、空腹の消費者にトラックに乗せるのを待っています。
ストッキングにはお金がかかります。 パン屋が小麦粉を貯蔵するための6つの50トンのサイロを持っているとします。 これは、平均して毎日約150トンの小麦粉が含まれていることを意味します。 今日の価格で、それは死んだ資本で73,000ドルです。
損傷などの他の費用があります。 小麦粉は数か月間保存できますが、完成したパンはオーブンを出るとすぐに価値が失われ始めます。 24時間後にはほとんど費用はかかりません。
では、なぜ株式を保管するのですか？ 次に、不足に関連するコストはいくらですか。 ごまパンの新しいバッチを注文するのに2日かかる場合、それらがダイナーで突然終了した場合、ハンバーガービジネスは2日間停止します。 在庫は、予期しない停止を防ぐバッファーです。 現在、これらのバッファーの最適な量を計算するための多くのアルゴリズムが発明されています（最初は、 リーン製造 、 制約の理論 ）。
どうしてこんなことを言っているの？ そして、ソフトウェアの生産において、「在庫」が蓄積される場所もあります。 そして、これらの在庫を保管するには、膨大な時間と費用がかかります。
「なに？ ソフトウェアとロールの生産を比較することは可能ですか？」
アイデアを原材料および半製品と考えてください。 テストピースのように、アイデアは製品の機能としてエンドユーザーに提示される前に、いくつかの処理ポイントを通過します。
- 意思決定（この機能を実装する必要がありますか？）
- 設計（仕様、計画、レイアウトなど）
- 実装（コードの記述）
- テスト（バグの発見）
- デバッグ（エラー修正）
- リリース（プログラムのコンシューマへの配信、サーバーへの展開）
（PS「滝」はそれとは何の関係もありません。いいえ。絶対に違います！
在庫はこれらすべての段階の間に蓄積する可能性があります。 たとえば、プログラマーがコードの記述を完了すると（ステップ3）、テスターに送信します（ステップ4）。 常に、一定量のコードがテストのために並んで待機しています。 これが在庫です。
そのような株のコストは莫大です。 彼らはリリースの時間に6か月、さらには12か月を追加することができます。 この間ずっと、ユーザーの手に渡るのではなく、生産のさまざまな段階で多くのコードとアイデアが使われていませんでした。 これらの遅延は、革新的な製品（iPhone）と永遠に続くキャッチアップアナログ（Windows Phone）の決定的な違いになります。 iPhoneがわずか6か月前に登場した場合、消費者にWindows Phoneを購入させることはほとんど不可能です。
多くの市場では、ネットワーク効果が機能します。そして、最初にすべてを受け取る勝者になることです。 そのため、開発段階での株式の規模は非常に重要です。
最も埋蔵量が蓄積されている3つの場所を見てみましょう。
バックログ。 各プロジェクトの周辺には、新機能のアイデアが集まり、実装するよりもはるかに高速に表示されます。 したがって、それらは実装キュー（バックログ）に書き込まれます。 バックログのアイデアの多くは、実際には価値がなく、思いついた人を怒らせないようにのみ記録されています。 その結果、誰もが幸せです。
問題は、バックログ機能の90％が実装されないことです。 そのため、そのような機能の記録、設計、検討、または議論に1分も費やすことは時間の無駄です。 一部のチームが定期的な「バックログのコーミング」を実践し、最終製品の一部にならないような貴重な時間を慎重かつ系統的に浪費していると聞いたとき、目を奪います。
提案：バックログが1か月または2か月以上の作業を超えないようにしてください。 バックログがいっぱいの場合は、古い要素を実装するまでそこに新しい要素を追加しないでください。 バックログから機能を議論、設計、または指定する時間を無駄にする必要はありません。 話し合うことを禁じられているもの、実装前に取り組むことを禁じられているもののリストとみなすべきです。
バグ追跡システム。 これは素晴らしいことです。 特に、バグレポートが詳細で、完全で、具体的である場合。 しかし、現実の世界では、単一のエラーメッセージを見逃したくないという願望は、ある日あなたのトラッカーに3000のオープンエラーがあり、そのうちのいくつかは関連性が長く失われ、他は再現できず、ほとんどの場合、それらは完全に重要ではないため、修正する価値はありません。 これらのバグレポートを収集するのに何ヶ月も何年もかかりましたが、どうすればこれが可能なのかを自問してください。3000のエラーがあり、製品は明らかに非常に優れており、ユーザーはそれを愛し、毎日使用していますか？ そして、製品を開発するのではなく、これらのエラーを単に過度に熱心に収集したことは明らかです。
提案：
- すぐに書き留めるには小さすぎるエラーをふるいにかけます。
- バグトラッカーからのすべてのエラーを修正する時間が2週間を超えないようにしてください。
- それらがさらにある場合は、率直に愚かで取るに足らない誤りに達するまで、修正を停止して開始します。 その後、「修正しない」マークでそれらをすべて閉じます。 重要なものを見逃すことを恐れないでください-深刻なエラーは確かに複数回発生します。
リリース待ちの機能。 これまで、多くのチームは、通常、新しいバージョンを展開するプロセスが複雑で費用がかかる場合、四半期または年次バージョンのリリースサイクルに取り組んでいます。 ユーザーが自分でインストールする必要があるオペレーティングシステムおよびその他のソフトウェアは、このカテゴリに分類されます。
これは、最も高価な在庫の1つです。 彼らはあなたにお金をもたらすことができますが、彼らはリリースを待っているだけでほこりを集めます、そしてその間、より機敏な競争相手の製品はすでにそれをしています！
最悪なのは、開発者がそのような遅延の壊滅的な影響を感じないことも多いということです。チーム全体が毎日ビルドを行い、新しい機能を毎日使用しているからです。 Microsoftの誰もが1年前から使用しているWindows 8に非常に満足しているので、Mac OS X Lionの世界でWindows 7コンピューターを販売しようとするOEMの苦労を理解していません。
提案：既製の機能が無駄にならないようにしてください。 数年ではなく数か月ごとに更新されるように展開プロセスを再設計します。 すでにこれを行っている場合は、毎週更新してみてください。 バーをより高く上げ、できるだけ小さな変更をロールアウトします。
だから私は何につながっていますか？ フォグクリークには、3種類の在庫がすべてありました。巨大なバックログ、バグレポートの巨大なデータベース、そして何年もリリースを待っていた機能です。 私たちはこれをすべて自分の肌で感じました。 そして、株のサイズを制限するシステムが必要であることに気付きました。
最初に私はファイブ・シングスと呼ぶものを思いつきました。 プロジェクト管理のためのプログラムは、近い将来の計画で、誰もが5つ以下の事柄に答えることができるというものでした。 この形式では、アイデアは決して実現されませんでしたが、 Trelloの基礎を形成しました 。
Trelloは少量の在庫でうまく機能しますが、大量の在庫を押し込むとすぐにかさばって不快になります。 これは意図的に行われます。 これにより、在庫が多すぎる場合に確認することができます。 （スクリーンショットをクリックして、独自の開発ページをご覧ください）。
毎日Trelloボードを見て、たとえば17もの機能が準備が整っており、リリースを待っていることがわかります。 これにより、可能な限り迅速に輻輳を解消できます。
誰かがクレイジーな新しいアイデアを提案するたびに、バックログを確認します。エントリが多すぎる場合は、このアイデアについて話し合ったり考えたりする時間を無駄にしないでください。
このアプローチにより、白色光を決して見ることのないものに取り組む時間を大幅に短縮できることを心から願っています。 「バックログの調査。」 なんてナンセンスだ！