36

私は非常に小さな会社で孤独な開発者として働いています。私の仕事はかなり混沌としていて、もっと整理する方法を探しています。

問題の 1 つは、私のプロジェクトには実質的に管理者がいないことです。何をしているのか、何か問題があるのか​​と聞かれることはめったにありません。ある時点で、毎週のステータス ミーティングについての話がありましたが、それは少し前のことです。そういうのが欲しければ、自分で手配しないといけないようです.. タスクや明確なスケジュールが定義されていないため、次に何をすべきか少し迷ってしまうことがあります。

本や記事から、役立つかもしれない多くのことを見つけました。優れたコーディング標準 (私の意見では多少古くなっている大まかなスタイル ガイドしか存在しない)、コード インスペクション、TDD、ユニット テスト、バグ データベースなどがありますが、小規模な会社ではリソースも時間もないようです必須ではないもの。私が組み込みドメインで働いているという事実は、物事をより複雑にするだけのようです。

手抜きをして急遽ハックする風習もあると思います。これは、未完成で専門的でない製品やバグが後日出現するのを待っていることにつながります. それらを維持するのも面倒だと思います。だから、私は挑戦的なコードベースを継承しようとしており、多くの新しいことを学ぶ必要がある新しい開発を行い、同時にそのためのプロセスを構築しようとしていると思います. 最終的にはやりがいがあるかもしれませんが、経験があまりないので、うまくいくかどうかはわかりません.

このような小さなショップでは、環境はプログラミングに最適とは言えません。カスタマー サポート、電話応対、小包への署名、ハードウェアのテスト、組み立て、その他の雑多なタスクが表示されるなど、他の多くのことが時々行われる必要があります。したがって、リソースについてのアイデアが得られます。すべてが悪いわけではありません (顧客の問題を解決することで啓発されることもあります)。改善できると信じていますが、私が本当に懸念しているのは他の点です。

このような場所で開発プロセスを行うことは可能ですか?

ある種の管理を行うことは役に立ちますか？どんな？

少ないリソースで高品質の製品を作ることは可能ですか?

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

似たようなお店で働いている人もいるのではないでしょうか？

4

9 に答える 9

17
  1. すべてにソース管理を使用する
  2. 仕様を策定し、開始前に承認を得ます。抵抗はあるでしょうが、それは彼ら自身のためだと説明してください。
  3. 単体テスト！ただやりたいだけなので痛いですが、これは長期的にはあなたを救います.
  4. 余裕がある場合は、バグ追跡 (Bugzilla または FogBugz) を使用してください。
于 2009-09-23T00:33:59.857 に答える
7

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

私は個人的に のバリエーションを使用しAgile RUPます。実際のニーズを調査したり、拡張可能な高レベルの設計を行ったりするなど、事前にいくつかの作業を行います。また、いくつかの主要な高レベル要件に同意するよう顧客に依頼します。

少人数のグループで作業する場合、詳細な設計や仕様に価値がない場合があります。もちろん、多くの人が共有しているライブラリがいくつかある場合は、苦労する価値があります。

リスク（可能性と効果）に応じて、事前に何に投資するかを決定します。

さらに、多くの SW のベスト プラクティスは、バージョン管理や自動テストのように本当に「ベスト」です (私にとっては、開発の原動力として TDD を信じていないため、リグレッションを早期に検出する方法としてのみ使用していました)。「 Pragmatic Programmer 」を読むことをお勧めします。それは、これらの技術の多くを示しています。

あなたの質問に答えるために：

(1)。このような場所で開発プロセスを行うことは可能ですか?

はい。しかし、私が言うように、あなたの組織に合うようにトレーラー化してください。

(2)。ある種の管理を行うことは役に立ちますか？どんな？

管理は役立ちますが、コントロールフリークはありません。いつ何をするかを計画します: 統合、競合の解決、マイルストーンの締め切り。そして、大まかにスケジュール通りに進めます (私は特にスクラムのスプリントが好きです)。

(3)。少ないリソースで高品質の製品を作ることは可能ですか?

間違いなく仕事の大きさ、開発にかかる時間、そしてチームの大きさのバランスです。品質の定義が私と同じなら。私にとって、品質とは、効率的かつ信頼できる方法で問題を解決することを意味します。

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

問題点を指摘します。何もない場合、なぜ変更するのですか？変更したい場合は、問題または潜在的な問題を特定できる必要があります。問題を指摘します。

いくつかの大きなものは次のとおりです。

  • プロセスがなければ、新入社員は物事の対処方法を観察することから学ばなければならないため、溶け込むのが難しくなります。

  • プロセスがないと、ストレスの中で働くのが難しくなります。

  • スケジュールがなければ、進捗状況を判断するのは困難です。

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

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

ただ、私のことです。

于 2009-09-23T01:01:09.183 に答える
2

そこに行って、それをしました。

本Planning Extreme Programmingは大いに役立ちました。壁に貼られた 3x5 のカードを使用しました。これにより、上司は私の進捗状況を常に把握し、見積もりと計画を手伝ってくれ、順調に進むことができました。計画ゲームは、上司の期待が非現実的である場合に良い弾薬を与えます。

他の人が述べているように、単体テストは、あなたが単独の開発者であっても役に立ちます。TDD スタイルは価値があると思います。

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

以前に XP スタイルのイテレーションを使用したことがあります。アイテムのバックログ (スプレッドシートや 3x5 カードのような単純なものでも) を確立することもできます。

デスマーチを避ける。2週間連続で残業しないという意味で40時間に固執する。テクノロジーだけでなく、原則やベスト プラクティスなどの新しいスキルを学ぶために、仕事以外の時間に時間を割いてください。

于 2009-09-23T01:22:54.043 に答える
2

所有者と協力して、短期、中期、長期の目標を設定する必要があります。メールだけでも進捗状況を知らせたいと思うでしょう。

就業日に何らかの順序を強制する必要があります。そうしないと、何も成し遂げられません (これらの長期的な目標)。

コーディングができるとき、ハックに取り組んでいるとき、メールに返信するときなど、1日をチャンクに分割します.

間違いなくバグトラッカーをセットアップしてください。これにより、メールをクリーンに保つことができます。後で分類するためにバグを転送するための電子メール アドレスを設定することもできます。バグ報告者は最終的にバグ トラッカーに飽きて、とにかくバグをメールで送りたくなるからです。

編集

そしてlod3nが言ったように、ソース管理ですが、あなたはそれをすでに正しく使用しています???!!?!

于 2009-09-23T00:37:00.790 に答える
1

クレイジーに聞こえるかもしれませんが、私がスクラムを使用するのは、スプリントとバックログの概念が好きだからです。現実的な目標を設定しやすくなります。もちろん、スクラム マスターとチームのアイデアはすべてあなたにありますが、バックログで追加のチーム メンバーをピックアップする可能性のある外部プロジェクトに取り組んでいる場合は、作業を簡単に分散できます。多分私はバックログが好きです。スクラムでは、製品の機能について話すために誰かを製品マネージャーにする必要があります。バージョン管理は必須であり、ソフトウェア開発プロセスを心配してもおそらく b4 を実装する必要があります。私は 2 人の開発者から始めて、1 年で 12 人になった会社で働いています。私たちは、バージョン管理がなく、低いコーディング基準から始めました。必要な変更は段階的に行われるため、急いで 180 を行う必要はありません。

于 2009-09-23T01:33:32.030 に答える
1

欠陥と新機能の両方について、バグ追跡システムを用意します。記憶に頼らないでください。

継続的インテグレーションと自動ビルドは、1 人の開発者でも役立ちます。

ソース管理の推奨事項を十分に強調することはできません。

于 2009-09-23T00:37:30.040 に答える
1

代わりに自動化された機能/統合テストを使用できるため、単体テストは必要ないと判断しました。インクリメンタル開発では、統合前にテストする必要がないためです。

于 2009-09-23T00:50:21.077 に答える
0

他の人の推奨事項と同様に、リソースが不足しているが、物事がどのように行われるかについてもっと意見があれば、既製のオープンソースの製品やライブラリをうまく利用する必要があると思います。これにより、他の人の努力が活用され、時間が節約され、コードベースが難解になりすぎず、スキルセットが追加されるため、他の場所では役に立たないものの専門家になることはありません。

于 2009-09-23T01:48:22.453 に答える
-1

まず、開発プロセスとベスト プラクティスを区別しましょう。ソース管理、欠陥追跡、単体テストなどのベスト プラクティスは当然のことです。

次に、実際の開発プロセスがあります。チームの規模に関係なく、プロセスを持つことを常にお勧めします。秘訣は、適切なプロセスを見つけることです。あなたは今プロセスを持っています - それはあなたにとってうまく機能していないように見えるアドホックなプロセスです。教科書の開発プロセスを直接適用できることはめったにありません。必要なのは、企業のニーズと文化に合わせてプロセスを調整することです。できるだけ多くの開発パラダイムを見て、適切なものを見つけようとすると、ニーズに合わせて成形され始めます。さまざまなプロセスを試して失敗する必要があるかもしれません。おそらく、Personal Software Process は、RUP の変種であるアジャイル プロセスであり、適切な開始プロセスになるのでしょうか? たくさんのオプションがありますので、試してみてください。

また、組織の他のメンバーと協力する必要があります。彼らはプロセスの一部である必要があります。あなたは 1 人の開発者かもしれませんが、開発プロセスには開発者だけでなく、製品に発言権や影響力を持つすべての人が関与します。

これは具体的な答えではないかもしれませんが、私のポイントは、何らかのプロセスが必要になるということです. したがって、それらを調査し、試してみて、機能するものが得られるまで、ニーズに合わせて成形してください.

于 2009-09-23T00:58:04.250 に答える