language-agnostic - 趣味のプロジェクトの仕様書を書くことが、それらを完成させる唯一の方法ですか?

Question

これが私が疑問に思っていることです。生後 3 か月の赤ちゃんが眠らせてくれる毎晩、私はコンピューターに飛び乗って、趣味のプロジェクトのコーディングを始めます。私は約 20 の異なるプロジェクトに取り組んでいます。オープンソースプロジェクトへの貢献とともに、C++ ゲームから Web アプリまで、さまざまな種類のプロジェクトです。それは本当に情熱であり、何年もの間続いています。

しかし、振り返ってみると、趣味のプロジェクトの 1 つを完全に完了することができていないことがわかります。私は常にプロトタイプを作成し、最も重要な機能をセットアップしてきましたが、時間の経過とともに、プロジェクトを終了する代わりに、現時点で「とてもクール」に見える別のプロジェクトに切り替えることになります。したがって、私は通常、終わりもストーリーもないバグだらけで不完全なゲーム、これまでで最速の PolygonDraw ルーチンを備えているものの、他に何も実装していない 3D エンジンなどに行き着きます。リストは長いです。私は未完成の Pong を 100 倍以上違った形で書いたに違いないと思います!

救済策は、趣味のプロジェクトの仕様を書くことだと言われました。

一方で、私は仕事で多くの仕様書を書いています。製品のロードマップを定義し、スケジュールを守るために、それらがいかに重要であるかを知っています。一方、スペックと趣味のプロジェクトはまったくうまくいかないようです！ゲームを構築するための学習曲線が、実際にそれを楽しくするものであるように私には思えます。ゲームそのものではありません。したがって、エンジン全体を再構築して時間を無駄にする楽しみ、最も役に立たない機能を作成する楽しみなど...

ここで質問です。趣味のプロジェクトの仕様を書いたことはありますか? 彼らは仕事とどう違うのですか？趣味のプロジェクトをどのように完成させますか?

新しいプロジェクトであるピアノソナタジェネレーターに取り組んでいる間、知っておいてよかったです :)

score 16 · Accepted Answer

仕様を書くことがあなたの問題の解決策になるとは思いません。明らかに、あなたの「趣味プロジェクト」は、あなたが楽しいと思うものです。楽しい部分は書きますが、何かを完成させるために必要な、楽しくない部分は避けます。

あなたが単に「楽しみのためのプログラミング」をしているのであれば、それは成功です。スペックを書くのは楽しいとは思いません。

何かを本当に「完成」させたい場合、最善の方法は仕様を書くことではなく、楽しみが減ったときに別のプロジェクトにジャンプしないことです。

score 13 · Accepted Answer

それはすべて「自己プロジェクト管理」に関するものです...楽しみでもあります。

私はあなたに同情します...私はリビジョン200前後ですべてが行き詰まる傾向がある多くのレポを持っていました。

私が十分な計画を立てていなかったため、約 200 回のコミットの後、物事が乱雑になり、書き直しが必要になりました...そして、あまりにも面倒に思えて興味がなくなりました。

個人的な使用のために独自の仕様を書くことを学びました

に

仕事を終わらせるために集中してください。機能クリープレーンに行かないでください
私が取り組んでいることを思い出してください
コーディングを始める前に素晴らしいアイデアを思いつくため
より長く物事をより楽しく保ちます

私にとって、自分自身の仕様を書くことは、何かを成し遂げるために不可欠です!

計画がなければビジネスを始めませんよね？

個人的なプロジェクトのために、大まかな仕様とアイデアが詰まったモレスキンの本をたくさん持っています。それらが成熟すると、ノートブックから実際のドキュメントに移行し、コーディングが開始されます。

大きな編集：個人的な効率性と、プロジェクトを完成させるための原動力。私は「Getting Things Done」を読みました...「精神」とさまざまなレベルの心のことについてのすべてのヒッピーがらくたにもかかわらず（これは確かに科学に基づいていません）、ヒントは非常に優れています.

score 7 · Accepted Answer

あまり複雑にはなりませんが、アプリケーションに含めたい機能と要件をすべてリストアップすることは本当に役に立ちます。ほとんどの趣味のプロジェクトと同様に、2 か月間コードを書いて完成させるだけではありません。ここで 1 時間、あちらで 2 時間などです。基本的に、最後に何をしていたか、アプリケーションのこの非常に優れたアイデアの本来の目的が何であったかを忘れてしまうのはよくあることです。

仕様と要件を書き留めるのに数時間を費やすと、6 か月後に自由な時間が得られるか、ADD がそのプロジェクトに切り替わり、これが何をすることになっていたかを思い出そうとするときに、非常に価値があります。

score 6 · Accepted Answer

最近、仕様を書くことがプロジェクトを完成させるために本当に必要なことだということを知りました。

私もあなたと同じように、たくさんのプロジェクトを次から次へと飛び回って、決して完成させることはありませんでした。約 6 か月前までは、実際に仕様を書き始め、プロジェクトのロードマップのようなものを作成していました。

私が言えるのは、チェックポイントのあるレースのように、プロジェクトを小さなステップに分割するため、実際に機能するということだけです。チェックポイントを完了としてマークし始めると、気分が良く、中毒性があり、集中できます。フィニッシュライン。

この方法では、同時に 1 つまたは 2 つのプロジェクトしか保持できませんが、実際にはそれらを完了できます。そしてもちろん、約 1 か月以上プロジェクトに触れなくても、プロジェクトに遅れずについていくという非常に貴重なボーナスがあります。仕様は、プロジェクトの目標と目的を思い出させるために常に存在します。

これは私の個人的な経験にすぎません。ぜひ試してみてください。うまくいけば、それもあなたのために運動します。

score 4 · Accepted Answer

私はいくつかの趣味のプロジェクトを行い、それらのいくつかを完了することができました. 私はそれらすべてを終わらせようとしますが、いくつかは集めることができません。

私が考える理由は、プロジェクトを完了するために必要な詳細の量が非常に多いため、情熱的なプロジェクトからプロジェクトの雑用に変わるからです.

私が私のほとんどを完成させるのに役立ったのは、最後の仕上げが残るまで彼らが情熱を持っていたということです. だから私はただそれらを耕した。

仕様は役に立ちますか、ある程度はい。彼らはあなたをプロジェクトにさらに引き込みますが、ほとんどの場合、情熱が薄れ、次の光沢のあるオブジェクトを探すポイントがあります.

score 4 · Accepted Answer

それは私にはうまくいきません！実際、私が仕様を書き上げているときはいつでも、通常はプロジェクトをさらに大きくし、完成する可能性を低くしています。

時にはそれを行うための最良の方法は、ただそれを行うことです.

Ze Frank はこれを私よりもはるかにうまく説明しています: http://www.zefrank.com/theshow/archives/2006/07/071106.html (罵倒のあるビデオリンク)

編集：追加するだけです。新しい壮大なアイデアのために、半分完成したプロジェクトを残したいと思っている場合は、それを実行してください。振り返るな！

完了は、独自のペットプロジェクトの要件ではありません。誰もあなたが始めようとさえしないようなことを終わらせなかったとしても、誰もあなたを責めることはありません。

あなたが始めた理由は情熱のためでした。それは非常に重要です。自由な時間に無理に「ずるずる」する必要はありません。あなたの最も重要な資源である情熱を消耗させてしまいます。

score 2 · Accepted Answer

それらを終了しますか？

趣味のプロジェクトを決して終わらせないのは理にかなっていると思います。生きている限り働き続けることができます。Aciddose は彼のバーチャルインストゥルメントxhipに何年も取り組んできましたが、頑固に 1.0 に到達することはありませんでした。それでも、彼と彼のソフトシンセのユーザーは楽しい時間を過ごしているようです。

「完成」ではなく「リリース」だけを目指した方が満足度が高いのかもしれません。ベータ版では、夢を見続けることができます。

score 2 · Accepted Answer

私は通常、作業を開始するときに最初の仕様セットを作成します。

また、私は紙で考えるのが大好きなので、画面、UML、図、フローチャート、デザイン要素を描きます...プロジェクトの範囲を定義し、何があったかを確認できるようにするだけです。マインド。考えるのに本当に役立ちます。

これらのドキュメントは、プロジェクト全体の私の仕様になります。他のものも追加していきますが、古いものを維持しようとはしていませんが、それは仕事のプロジェクトでした: 私は自分がどこに向かっているのかを知っており、コード。

もちろん、私の趣味のプロジェクトのいくつかは共同で行われます。このような場合、チームとのコミュニケーションを改善するために、より多くの仕様を書き留め、DB ダイアグラムなどのドキュメントを最新の状態に保つようにしています。

score 2 · Accepted Answer

また、まだ完了していない趣味のプロジェクトがいくつかあります。私は約 10 個持っており、そのうちの 1 つだけの仕様を書きました。これは最大のスコープ (ゲームでもあります) です。

仕様のないものもあるものも仕上げていません。これは、作品を公開したり、誰にも見せたりしないため、バグだらけで「完成しない」ためだと思います。

これは、スペックの有無にかかわらず、時間、モチベーション、助け、自信などの他の要因ほどプロジェクトの成功に影響を与えないことを意味すると思います。

score 2 · Accepted Answer

完了に向けて前進するために私がこれまでに見つけた唯一の最良の方法は、他の誰かがあなたと一緒にプロジェクトに取り組んでいることです. 同じことに興味を持っている友人 (または 2 人) を見つけて、一緒に設計/コーディングします。アイデアを跳ね返す相手がいるだけでなく、やる気を起こさせる相手もいます。言うまでもなく、進歩は 2 倍の速さなので、諦める前に終わらせることができます :)

もちろん、ソース管理が必要ですが、プロジェクトですでにそれを使用していましたよね? :)

score 1 · Accepted Answer

はいといいえ。考えていることをノートに書き、実行するたびに追記していきます。これは、他の誰かが仕様を確認する必要がある作業プロジェクトとは多少異なるプロセスです。

始めたことの約半分を終えます。

score 1 · Accepted Answer

私は、安全性が重要なアビオニクスから、数独ソルバーのような使い捨ての個人プロジェクトまで、さまざまなシステムの開発を支援してきました。アビオニクスシステムでは、システムを安全に運用し、誰かを殺すのを防ぐために仕様が重要であったことは明らかですが、私は個人的なプロジェクトで気にしたことはありません。

これは、仕様が一般的に読み書きするのがつまらないためだと思います。Joel はこれについて興味深い記事を書きました。

痛みのない機能仕様

残念ながら、私は自分の仕様書を職場で読むのをもっと楽しくする勇気がありませんでした。

仕様を書く代わりに、他の人のために、または他の人と一緒に、いくつかのプロジェクトに取り組んでみてはいかがでしょうか? それは、何らかの外的動機を与える可能性があります。私は劇場でいとこのドライブのためにいくつかのウェブ開発を行っています.彼らが機能を必要とする場合、私がそれを完了するまで、彼らは私にそれについて尋ねるのをやめません.

score 1 · Accepted Answer

私があなたに与えることができる最大のアドバイスは、何かを世に出すことです.最初のバージョンの仕様は、必要な機能のほとんどすべてを備えていなくても、実際に完成できると感じるほど十分に小さくしてください.

何かを世に出すと、ソフトウェアのユーザーからのプレッシャーで、うまくいけばそれを続けられるでしょう。また、開発の方向性が、ユーザーが望んでいる方向性と同じであることも保証されます。

実際にユーザーをまったく獲得できなくても、プロジェクトをやめることをそれほど気にする必要はありません。誰も興味を持っていなければ、おそらく追求する価値はありません。

ユーザーからのプレッシャーだけでは集中力を維持できない場合は、オープンソースにしましょう。それに十分な関心があれば、他の誰かがあなたが中断したところからそれを取り上げ、あなたはより大きくより良いものに自由に進むことができます.

score 0 · Accepted Answer

私のほとんどの趣味のプロジェクトも実際には終わっていません。問題はないと思いますが、何かに取り組んで学んでいる限り。現在、仕様を作成していませんが、TDDの練習/トレーニングを行っています。スペックであるテストを書くときにそれを持ち出します。いつか私は座って、ソフトウェアが何をすべきかを概説する一連のテストを作成します。ある日、私はそれらのテストに合格させます。コードをすべて頭の中に置いておく必要がないという点で楽しいです。いつでも座って、壊れたテストを修正することでさらに進歩することができます。物事はうまくいきます、その種のシュールです。

score 0 · Accepted Answer

私はほとんど同じ問題を抱えています。私が気づいたことの1つは、私の野心を下げることです。WAYWAYlowのように。仕様を作成することは、「仕様は1ページのみにすることができます」、「仕様は300語以内にする」など、仕様に何らかの制限ルールがある場合に、野心を支配する1つの方法です。「1日のコーディングでできることだけを指定してください」。バランスを正しく取るには、ある程度の練習が必要です。最後の制限を守った場合、1日でプロジェクトを完了できない場合は、プロジェクトを強制的に却下するというルールを課すことができます。

これの良いところは、達成可能な目標に制限されることです。これは最初は本当にばかげているか間違っているように聞こえるかもしれません。あるいは、それは合理的に聞こえるかもしれませんが、あなたはそれを助けることができません、あなたは普通のことではなく、素晴らしいことをしたいです！あなたが数時間でしか成し遂げることができない小さなことではありません！

しかし、これを覚えておいてください：

「機能する複雑なシステムは、機能する単純なシステムから進化したものであることが常にわかっています。逆の命題も当てはまるようです。ゼロから設計された複雑なシステムは機能せず、機能させることもできません。動作するシンプルなシステムから始めて、最初からやり直す必要があります。」</ p>

—ジョン・ガル

すでにFINISHEDおよびWORKINGプロジェクトをベースにしている場合は、その野心的なプロジェクトを作成する方がはるかに簡単です。そうすれば、「より複雑なもの」は1日で収まるプロジェクトになる可能性があります。これは私が目指している理想と哲学です。成功する可能性が最も高いと思うからです。過去に成功したプロジェクトを見ると、意図的かどうかにかかわらず、それらの大部分はこのように進化しました。

score 0 · Accepted Answer

私は自分のプロジェクトの仕様書を、職場、大学、および自由時間に常に書いています。プログラマーの最大の弱点は記憶力です。そのため、考えている時間を何らかの構造化されたドキュメントに書き留めて、考える時間に忙しくしておくとよいでしょう。気が付く前に、完全なデータベーススキーマを作成しているか、要件仕様を作成しています。

現在、私は SQL スキルの向上に取り組んでおり、経験を書き留めるクエリを書く間に多くの空き時間を費やしています。いくつかの微調整の後、何をする必要があるかを概説したまともなドキュメントができました。

score 0 · Accepted Answer

私が大いに役立っているのは、新機能を小さなタスクに分割し、それぞれを夜のハッキングセッションで実行できるようにすることです。そのため、時間があれば、リストからタスクを 1 つ選んで終了するだけです。多くの場合、これで「流れに乗って」「もう 1 つだけ」行うには十分です。

これは、一度に 1 つの機能に対してのみ行うため、アプリケーションに追加できる他のすべての優れた機能に気を取られることはありません。

score 0 · Accepted Answer

根本的な問題はスペック不足ではなく、何か（なんでも）を仕上げるのが難しいことだと思います。

それは大変な作業です。プログラムが 90% 完成したように見えるかもしれません。しかし、最後の 10 % を実行する (すべてのバグを根絶する、アプリケーションの品質をリリースする、ドキュメントを作成するなど) には、最初の 90 % と同じくらい多くの作業が必要です。また、プログラムのマーケティング、サポートメールへの返信、他の人のバグの修正に真剣に取り組みたい場合は、さらに多くの作業が必要です。そして、おそらくあなたが最も興味を持っている種類の仕事ではないでしょう.

精神的にも大変です。未完成のプロジェクトには無限の可能性があります。自由な野心、崇高な理想、革命的な思想を投影できる空のキャンバスです。それが完成して現実のものになったら、それが何であるかを確認する必要があります。限定。欠陥がある。それを生み出したアイデアほど美しいことはありません。

とはいえ、何かを仕上げることも非常にやりがいがあります。多くのことを学び、自分のアイデアの現実性をチェックし、何かを完成させた満足感を味わい、他の人が自分の仕事についてどう思うかを見ることができます。

いくつかのアドバイス：

本当にプロジェクトを終了したいのかを確認してください。つまり、報酬はすべてのハードワークに値するということです。（そうでない場合は、その事実を受け入れて、幸せないじくり回しを続けてください。）
「つまらない」部分を通して、自分をやる気にさせる方法を見つけてください。それがあなたを集中させ続けるなら、おそらくスペック。しかし、ToDo アイテムを刻む、クッキーで自分にご褒美をあげる、名声と幸運を夢見るなど、自分に合ったものを見つけてください。
早期にリリースし、頻繁にリリースします。「大きなリリース」のために節約すればするほど、そのリリースが実現しない可能性が高くなります。
最初にリリースしてから書き直します。大幅な書き直しをしたいという衝動に駆られたら、まずリリースを行い、次に書き直しを行います (まだやる気がある場合)。ソフトウェアは決して完璧ではありません。中途半端な (しかし既存の) コードをリリースするというプレッシャーを一切受けずに完璧を目指して努力するなら、決してやり遂げることはできません。

score 0 · Accepted Answer

短い答え: 趣味のプロジェクトの仕様を開発することは、完了を保証するために必要でも十分でもありません。

そうは言っても…

私はすべての個人的なプロジェクトのためにエンジニアリングノートを作成しています。私はノートブックを使用して、自分が取り組んでいるプロジェクトに関するあらゆる種類のことを記録しています。これには、プロジェクトの動機、プロジェクト中に活用された貴重なリソース、プロジェクトの過程で開発されたもので、後で再利用される可能性があるもの、得られた重要な洞察などが含まれます。あなたの質問に加えて、ほとんどのプロジェクトの仕様も含まれています. 私はこれらの仕様を作成するためにアジャイル/リーンアプローチを採用していますが、これはコスト/メリットの観点から説得力があります。

ところで...私は非常に多くの個人的なプロジェクトを抱えていますが、完全に機能するシステムには至りませんでした。これらのいくつかは、「いつか多分」完成するかもしれません。目的を達成したため、意識的に他のいくつかの作業を停止することを選択しました (たとえば、新しいテクノロジーを紹介したり、言語機能をよりよく理解するのに役立ちましたなど)。リターンが得られたので、レバレッジが高いと感じたプロジェクトに時間を再配分することにしました。

score 0 · Accepted Answer

残念ながら、DIFL エンジンのコアの仕様を書いた後 (私のホームシステムの外にはその痕跡がないので、調べる必要はありません)、まだ完成していません。

score 0 · Accepted Answer

本当の質問は、あなたの趣味は何ですか? プロジェクトを終了するか、いじくり回すか。最後の 10 ヤードを獲得するのが面倒な場合は、それが自分にとって価値があるかどうかを判断する必要があります。詳細な仕様を書くことはうまくいきます。あなたがそのような自己規律に興味があるなら、自責の念もそうです。それがあなたのメイクアップに反する場合、それを簡単にするものは何もないので、最終目標があなたにとって価値があるかどうかを判断する必要があります.

そして、この点についてプログラミング固有のものは何もないことを示すために、あなたは本当にこの男が好きかもしれません. 彼の作品の主なポイントの 1 つは、ピカソやダヴィンチなどのコンセプチュアルアーティストが、最終的な実行をまったく気にかけなかったということです。または、スケッチを未完成および未公開のままにします。

language-agnostic - 趣味のプロジェクトの仕様書を書くことが、それらを完成させる唯一の方法ですか?

23 に答える 23

Related

Reference