ソロプロジェクトで機能のクリープを回避するにはどうすればよいですか？

だから私は2011年から2012年までずっと取り組んでいるプログラムを持っていますが、最後のリリースは2011年 12月でした。私は積極的に取り組んでいますが、機能クリープはそのい頭を誘い、今では未完成の機能に関する大量の情報で満たされています。

悪い点は、機能を実装するときに新しい機能が忍び寄るということです。将来、機能のクリープを回避して、1年以上で実際にリリースできるようにするにはどうすればよいですか。

このプロジェクトはiOSに基づいており、以前は各iOSバージョンの更新に関するリリースがありましたが、最後のリリースは5.1（2011）で戻ってきました。安定したリリースサイクルを取り戻せるようにしたいのですが、難しすぎることがわかりました。

私の経験では、やりたいことを邪魔しない開発とリリースのケイデンスを手に入れることができれば最も簡単です。これが私がやった方法です：

1. 機能を書き留めて、その機能にどの程度取り組みたいか、ユーザーにどれだけ利益があると思うかを反映した評価を付けます（実際のユーザーを引き付けることができる場合があります）。次に、その順序でそれらを記述します。
2. 機能をチェックイン/プッシュする前に、安定したデプロイ可能なビルドがあることを確認してください（それを容易にするためにCIシステムを強く検討してください）。

このように、必要に応じて各機能の後にリリースをプッシュするか、リリースに必要な価値を提供するロールアップを待つことができます。

注意：

• 機能には、作業中の機能よりも高い優先順位を与えることはできません（または、可能ですが、作業中の機能を中断することはできません）。それは来ることができ、次決して今。これは、今から次へ進むときに、必要に応じてリリースビルドを削減する機会があることを意味します。

答えはささいであり、しばしば不可能です。追加機能の追加を拒否します。

より詳細には、答えは本当に、新しい機能が機能クリープビンに分類される原因になります。クリープする機能は、その機能がプロジェクトの意図した用途にのみ接しているという事実にもかかわらず、プロジェクトに追加されるものであり、クリーピング機能は有用であり、不要ではないと仮定した場合、答えはそれらを別々に移動することです、しかし関連するツール。直交ツールを構築し、それらを結合するというUnixの哲学を使用してください。

プロジェクト管理の観点からは、答えは同等です。次のリリースに専念する時間を決定し、期限を設定します。機能を見積もって、締め切りに間に合うように十分にカットします。自分以外に関係者がいる場合は、彼らにとって最も重要なものを選択させます。

スケジューリングの概要については、ソフトウェアのJoelをご覧ください。

http://www.joelonsoftware.com/articles/fog0000000245.html

開発における最も重要な教訓の1つは、いつ停止するかを知ることです。

通常起こることは、開発者が機能を追加することです。その結果、より多くのアイデアが生まれます。したがって、より多くの機能が追加されます。つまり、あなたが言ったように、プロジェクトがベーパーウェアになる方法の1つです。開発者はプロジェクトを「完成した」とは決して見なさないため、リリースされません。

習得したい習慣は、リリース/バージョンを「完成した」プロジェクトとして考えることをやめることです。むしろ、開発を長期的なプロセスと見なしてください。リリースは、いつかあなたがプログラムに期待するものへの道に沿ったマイルストーンと考えてください。したがって、リリース/バージョンは、長期的なプロセスにある場所のスナップショットに過ぎません...十分に検討され、テストされたスナップショットです。

実際にできることは、座って次のリリースを指定することです。徹底的に徹底する必要はありません。次のリリースに不可欠だと思われる3〜5個の新しい主要機能を書き留めてください。（機能の実際の数はアプリの種類によって異なる場合がありますが、バグの修正やGUIの軽微な変更はカウントされません）これらに取り組みます。他のアイデアを思いついた場合は、それで構いません...次のリリースでメモを作成して実装するだけです。これらの3〜5個の項目を完了すると、リリースのベータ版の準備が整います。

新しいアプリケーションを開始するとき、私は通常、アプリケーションの最終的な「ビジョン」について考えます。それは、私にとって、アプリのバージョン3で欲しいものです。そのベンチマークで、私は固体バージョン1を作るもののアイデアを持っています-ちょうど基本。

概要：

各リリースは、プロジェクトの完成した「ビジョン」である必要はありません。そのビジョンに向けたマイルストーンです。

何らかのアイデアのためにブランチを作成するのが安価なバージョン管理システムを使用し、リリースパスから除外します。たとえば、gitでは、アイデアを「忍び寄らせる」ことができますgit stash。後でこれらの隠し場所を確認し、おもしろそうな順序でそれらを選択できます。

大規模な機能の場合は、実際のブランチを作成します（複数のコミットを実行できます）。適切な例：ガベージコレクターに世代別サポートを追加したいときに、ブランチを作成しました。スタッシュは、気を散らす小さなものを非常によくキャプチャします。大きな機能はスタッシュとして始まり、ブランチになり、準備ができたら最終的にマージできます。

スタッシュとブランチを使用すると、マネージドチームプロジェクトのように、アイデアをストックして優先順位を付け、ソロプロジェクトのリリースの範囲を確立できます。

アイデアを思いついたら、どこかに行かなければなりません。どこかで最高ののはコード：リポジトリです。良いアイデアを忘れるよりも、クリーピング機能の方が優れています。しかし、もちろん、すべての機能を同じメインラインに忍び込ませた場合、ユーザーが使用しないように注意しなければならない半分行われたものでいっぱいの乱雑なリリースをカットしない限り、リリースを遅らせ続けます。