私は大規模なソフトウェア会社で働いており、約25人のチーム(2人のアーキテクト、15人の開発者、5人のQAエンジニア、2人のBA、プロジェクトマネージャー)で大規模なエンタープライズレベルのWebソリューションを開発しています。私たちはアジャイル方法論とスクラムに従っており、頻繁に要件が変更される状況では、このような大きなチームにとっては非常に便利なようです。
ペットプロジェクトも1つあります。基本的なアイデアがあり、開発を開始しました。現在は一人で仕事をしていますが、プロジェクトに参加する友達に提案する予定です。
しばらく前に、適切なタスク追跡と形式化の要件の問題に直面しました。私が最初に考えたのは、アジャイル方法論をチームで使用するときに使用することでした。私の仕事には非常に便利ですが、1〜3人のチームには時間がかかりすぎることがわかりました。
本当に小さなチームのためのソフトウェア開発方法論はありますか?または私は自分自身を克服し、すべての私の考えをユーザーストーリーとタスクに形式化し、反復を使用する必要がありますか?
プロジェクトをディスク上の別のフォルダーにしたくありませんが、不必要な形式化に時間を無駄にしたくありません。
スクラムには、プロセスを調整する定期的な回顧があります。プロセスが時間の経過とともに進化しない場合、または大規模な組織のすべてのスクラムチームで同じように見える場合、それは正しく行われていません。
同様に、小規模なチームでは、定期的な回顧を行い、ニーズの変化に応じてプロセスを調整する必要があります。最初にすべてを釘付けにする必要はありません。通常、形式がプロジェクトが成長するにつれて成長します。顧客のニーズやその他のアジャイル原則への迅速な適応に焦点を合わせている場合は、それを「アジャイル」と呼ぶことができます。これは、大規模なマルチチームプロジェクトと同じではなく、同じように見えるはずです。
ツールとプラクティスのラインに沿ってさらに質問している場合、私の小さなプロジェクトはgitリポジトリだけから始まります。頭の中ですべてのタスク/バグ/ユーザーストーリーを追跡できなくなったら、TODO.txt
リポジトリ内。成長するにつれて、単体テスト、ドキュメント、パッケージなどを追加します。ある時点で、それをbitbucketに配置しました。後で、私はTODO.txt
bitbucketのシンプルな課題追跡に。 DoD請負業者のプロセスに匹敵するCMMレベル5まで上昇し続けることができます。
言い換えれば、あなたはそれを行うための利点として形式を追加し、そうすることはコストを上回り始める。