2

I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess

The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.

What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:

  • Essential de facto literature that we should read first?
  • Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
  • Practical "do this and this" guidelines?

Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.

4

4 に答える 4

4

強くお勧めする読み物には次のものが含まれます: The Agile Manifesto と The Pragmatic Programmer. その後、おそらくスクラム ソフトウェア開発、またはテスト駆動開発に慣れたいと思うでしょう。少なくとも、次のものが必要です。

  • ソース管理リポジトリ
  • バグ追跡システム
  • コミュニケーションのためのツールの標準セット (最近では、wiki は文書化に人気がある傾向にあります)、
  • IDE
  • テスト フレームワーク

多くのことは、チームのスキルと、対象とするアプリケーション ドメインに依存します。いくつかの方法論に慣れてから、実践してください。一日の始まりに 15 分間のスタンディング ミーティングを行います。失敗したテストを書き、合格させ、繰り返すという考え方でコードを段階的に開発します。などなど

于 2009-11-12T08:14:51.937 に答える
2

まずはスクラムを試してみることをお勧めします。軽量のプロジェクト管理フレームワークとして、小規模なチームのニーズに適合させる必要があります。
それをそれほど苦痛にしないために、スクラムに精通している誰か（おそらく認定スクラムマスター）を一時的に雇うこともお勧めします。3〜4か月後、自分でスクラムを実行し続けることができるはずです。経験豊富なチームメンバーの数ヶ月に本当に投資することは報われるはずです。そして、私は、分析者、コンサルタント、またはあなたが問題にとどまっている間に来て、分析し、プレゼンテーションを行い、お金を取り、そして行く人と呼ぶものを意味するのではありません。私はあなたと一緒に働くだけでなく、毎日の練習を通してあなたにスクラムを紹介するチームメンバーを意味します。
代わりに本を読んだり、1人か2人のチームメンバーをトレーニングに参加させたりすることもできますが、スクラムを日常業務に取り入れて例を挙げて学び始める人がいるのが最善だと思います。

（日常業務に基づく）適切な説明の詳細な説明は、Trenches（代替ソース）のスクラムとXPです。

于 2009-11-13T09:39:13.623 に答える
1

開発プロセスに対する他人の見解に固執することは、誰にとってもうまくいくわけではありません。本当の基本から始めましょう

  1. 開発プロセスの基本を正しく理解してください - The Joel Testを参照してください。
  2. すべてを追跡します。JIRA、FogBugz などのシステムを使用して、これまでに報告されたすべての問題、機能、およびバグを追跡します。各タスクに費やした時間を追跡します。あなたが持っている情報は、より良い準備になります。
  3. トリアージ - 利害関係者と協力して、自分が重要だと思うことだけでなく、自分が行っていることが実際に重要であることを確認します。私の経験では、開発者と顧客はしばしば大きく異なる見解を持っています!
于 2009-11-12T08:19:21.397 に答える
1

私はリーン運動の先駆者であるメアリーとトム・ポッペンディークによる最近のリーン文学の大ファンです。

これらの本は、ソフトウェアの世界に頭を下げてビジネスの目標を無視するのではなく、ソフトウェア チームの視点からビジネス バリュー チェーン全体を見る非常に実用的な本です。

于 2009-11-13T04:18:27.623 に答える