孤独な開発者はどのようなソフトウェア開発プロセスを持つべきですか？

Question

私は非常に小さな会社で唯一の開発者として働いています。私の仕事はかなり混沌としており、私はそれをもっと組織化する方法を探しています。

私のプロジェクトには実質的に管理がありません。まれに誰かが私に何をしているのか、何か問題があるかどうか私に尋ねることはほとんどありません。ある時点で、毎週のステータス会議について話がありましたが、それはもう少し前のことです。私のようなものが欲しいと思ったら、私は自分自身を手配しなければならないと思う。時には、私は仕事や明確なスケジュールが定義されていないため、次は何かを失うことがある。

書籍や記事から、私は役に立つかもしれない多くのものを見つけました。良いコーディング標準（私の意見では幾分古くなっている荒いスタイルのガイドしかありません）、コード検査、TDD、単体テスト、バグデータベースなどがありますが、小さな会社ではリソースや時間がないようです必須ではないもの。私が埋め込みドメインで働いているという事実は、事態をもっと複雑にしているようです。

私は、コーナーをカットし、短期間で迅速なハッキングを行うというカスタムもあると感じています。これにより、未完成のプロフェッショナルな製品やバグが後で出現するのを待っています。私は彼らも維持する痛みであると思います。ですから、私はチャレンジングなコードベースを継承しようとしています。多くの新しいことを学ぶことを必要とする新しい開発を行い、同時にすべてのプロセスを構築しようとしています。それは最終的には報われるかもしれませんが、それほど経験がないので、私がそれを取り除くことができるかどうかはわかりません。

このような小さな店では、環境はプログラミングにとって最適ではありません。顧客のサポート、電話への応答、小包への署名、ハードウェアのテスト、アセンブリなど、さまざまなタスクが表示されることがあります。だから、あなたはリソースについてのアイデアを得ます。それはすべて悪くない（いくつかの顧客の問題を解決するために啓蒙している）と私はそれが改善できると信じていますが、それは私が本当に心配している他のものです。

このような場所で開発プロセスを実行することはできますか？

何らかの管理をするのに役立つでしょうか？どんな？

小さなリソースで高品質の製品を作ることは可能ですか？

何十年も成功してきた会社が変わる必要があると自分自身や他の人たちに納得させるにはどうすればよいですか？何が不可欠でしょうか？

誰かが同じような店で働いているのでしょうか？

Answer 1

私のアドバイスは極端ではありません。私の経験から、純粋なアジャイルまたは純粋な伝統はうまくいかないでしょう。プロセスを使用する前に、解決することが何を意味するのかを理解してください。

私は個人的にはAgile RUPのバリエーションを使用しています。私は、実際のニーズを調査し、可能な拡張で高水準の設計を行うなど、いくつかの先験的な取り組みを行っています。また、顧客にいくつかの主要な高水準要件を承認するよう依頼します。

小グループで働く場合、詳細設計や仕様は価値がないかもしれません。もちろん、多くの人が共有するライブラリがあれば、それは問題になるでしょう。

リスク（尤度と影響）に応じて投資先を決定します。

さらに、多くのSWのベストプラクティスは、バージョン管理、自動テスト（私が開発の主導権としてTDDを信じていないので、私は早期に回帰を検出するためにしか使用しませんでした）私はあなたが 'Pragmatic Programmer'を読むことをお勧めします。

ご質問にお答えする：（1）

。このような場所で開発プロセスを持つことは可能でしょうか？

はい、私の言うとおり、あなたの組織に合ったトレーラーです。

（2）。それは何らかの管理をするのに役立つでしょうか？どんな？

管理は役立ちますが、コントロールフリークはありません。次のようなときに何をすべきか計画する。そして、おおまかにスケジュール通りにしてください（特にスクラムのスプリントが好きです）。

（3）。小さな資源で高品質の製品を作ることは可能ですか？

間違いなく、作業の規模、開発に時間がかかり、チームのサイズがバランスしています。品質の定義が私と同じ場合。私にとって、品質とは、効率的で信頼できる方法で問題を解決することを意味します。

（4）。何十年も成功してきた会社が変わる必要があることを自分自身や他の人たちにどのように納得させるのでしょうか？何が不可欠でしょうか？

問題を指摘してください。何もない場合、なぜ変化するのですか？変更したい場合は、問題または潜在的な問題を特定できるはずです。問題を指摘してください。

いくつかの大きなものがあります：

• 任意のプロセスがなければ、それは彼らが物事に対処する方法を他の観察から学ばなければならないと調和するように募集新しいのために困難です。

• ストレス下で作業するのは難しいです。

• スケジュールなしでは、進捗状況を判断することは困難です。

• 自動テストを行わないと、問題と回帰を特定するのに時間がかかります。

• バージョン管理なしでは、間違いをロールバックすることが難しくなり、各チームメンバーに作業の分離が混乱することになります。

Answer 2

1. 使用ソース管理EVERYTHING
2. の仕様を開発し、起動する前にサインオフを得る - 抵抗があるでしょうが、それは自分の利益のためだ説明します。
3. ユニットテスト！あなたはただそれをやりたいので、痛いですが、これは長期的にあなたを救うでしょう。
4. あなたが買う余裕がある場合は、BugzillaやFogBugzを使用してください。

Answer 3

オーナーと協力して短期的な中長期目標を設定する必要があります。あなたは電子メールでしか進捗状況を知らせたくないでしょう。

あなたの就業日には何らかの命令を実行する必要があります。何も成し遂げられない場合（長期目標）。など

間違いなくセットアップバグトラッカーを電子メールに答えるときに、togtherそれを維持するためにハックに取り組んでいるときときにコーディングすることができ、

はチャンクにあなたの一日を分割

。これにより、電子メールをきれいに保つのに役立ちます。後で分類されるバグを転送する電子メールアドレスを設定することもできます。これは、バグ記者が最終的にバグトラッカーに疲れてしまい、とにかくあなたにバグを電子メールで送りたいからです。

編集

そしてlod3nとして、ソースコントロールを言っていますが、それはすでに、右使用している??? !!？！

Answer 4

不具合と新機能の両方について、バグ追跡システムがあります。あなたの記憶に頼らないでください。

継続的な統合と自動ビルドは、単一の開発者にも役立ちます。

ソースコントロールの推奨事項を十分に強調することはできません。

Answer 5

私はdon't need unit tests because I can have automated functional/integration tests insteadと決めました。インクリメンタル開発では、統合前にテストする必要がないためです。

Answer 6

まず、開発プロセスとベストプラクティスを区別します。ソース管理、欠陥追跡、ユニットテストなどのベストプラクティスが与えられています。

実際の開発プロセスがあります。私はいつもプロセスを持っていることをお勧めします。トリックは正しいプロセスを見つけることです。あなたは今、プロセスを持っています。それはあなたのために余りにもうまく機能していないような特別なプロセスです。まれに、教科書の開発プロセスを取って直接適用することはできますか？あなたが必要とするのは、企業のニーズと文化に対するプロセスを調整することです。できるだけ多くの開発パラダイムを見て、適切なものを見つけようとすると、彼らはあなたのニーズに合わせて成形を始めます。さまざまなプロセスを試して失敗する必要があるかもしれません。おそらくパーソナルソフトウェアプロセスは良いスタートプロセス、おそらくアジャイルプロセス、RUPの変種でしょうか？あなたにはたくさんのオプションがあり、それらを試し始める。

また、他の組織と協力しなければならない場合もあります。それらはプロセスの一部である必要があります。あなたは孤独な開発者かもしれませんが、開発プロセスには開発者以上のものが関わっています。

これは具体的な回答ではないかもしれませんが、私の要点は何らかのプロセスが必要だということです。だから研究を始めるとそれらを試して、あなたのニーズに成型するまで、あなたは何かが働くまで。

Answer 7

ありましたか。

書籍Planning Extreme Programmingが多くを助けました。壁に貼られた3x5のカードを使用しました。これは私の上司に私の進捗状況を知らせ、見積もりと計画を助け、私を軌道に乗せさせた。あなたの上司の期待が非現実的であれば、計画ゲームは良い弾薬を与えます。

ユニットテストは、あなたが唯一の開発者であっても、他にも述べたように、役立ちます。私はTDDスタイルを貴重なものにしています。

lod3nは、ソース管理について絶対に正しいです。

以前はXPスタイルのイタレーションを使用しました。 （スプレッドシートや3x5カードのような単純なものでも）項目のバックログを設定することができます。

死者を避けてください。残業2週間連続して働かないという意味で40時間に固執する。新しいスキルを学ぶ以外の余暇に費やしてください。技術だけでなく原則やベストプラクティスも学びます。

Answer 8

私はスプリントとバックログのコンセプトが好きなので、私はスクラムを使用しています。現実的な目標を簡単に設定できます。もちろん、スクラムマスターとチームのアイデアはあなたですが、外部のプロジェクトに取り組んでいる場合、余分なチームメンバーをバックログで拾うことができる可能性がある場合、作業を配布するのは簡単です。たぶん私はバックログが好きかもしれない。スクラムでは、製品の機能について話すために、誰かをプロダクトマネージャーにする必要があります。バージョン管理は、おそらくソフトウェア開発プロセスを心配するb4でも実装する必要があります。私は2人の開発者から始まって1年に12人になった会社で働いています。私たちは、バージョン管理と低いコーディング標準で始めました。あなたがする必要がある変更は徐々になりますので、180度を急ぐことについて心配する必要はありません。1か月に1つのことを変更し、変更をサポートしているものを見つけて物事をスムーズにするという目標を設定します。

Answer 9

他人の勧告だけでなく、リソースが逼迫していても、やり遂げられたことについてもっと多くの意見がある場合は、棚やオープンソースの製品やライブラリを十分に活用する必要があります。これは他の人の努力を活用して時間を節約し、コードベースがあまりにも難解にならないようにし、スキルセットに追加するので、他の場所では役に立たないものの熟練者になることはありません。