私のグループはまもなく Team Foundation Server に移行します。実際、私は努力をしています。
決定しなければならないことの 1 つは、使用している方法論 (アジャイル、CMMI など) です。
つまり、私たちがどの方法論を使用しているのかわかりません。つまり、積極的には使用していません。また、私はアジャイルやその他の方法について十分に精通しておらず、もしあるとすれば、私たちのやり方にどれがたまたま当てはまるかを知ることはできません。
デフォルトの方法論はありますか？たとえば、非常に単純なプロセス (要件の取得、コードの取得、テスト、QA へのプッシュ、QA テストの実施、本番環境へのプッシュ) を経る場合、名前さえありますか?
おまけとして、TFS では、最初に間違ったものを選択した場合のペナルティは何ですか? アジャイルか何かに移行することを決めた場合、後でギアを切り替えるのはどれほど難しいでしょうか?
方法論を切り替えることに大きなペナルティはありません。インストール時にデフォルトのものを選択するだけで、特定のプロジェクトに使用するものを選択できます。実際には、TFS が最初に SharePoint プロジェクト ページを構成する方法だけに関係があります。ページが作成されたら、必要なものをページに追加できます。そのため、プロジェクトの方法論を変更することに決めた場合、それを行うのは難しくありません。
TFS が標準で提供する 2 つ (アジャイルと SCCM/ウォーターフォール) については、実際にはプロセスの問題です。「早期かつ頻繁に」リリースし、バグが発生したときに小さなパッケージをリリースしますか、それともプロジェクトを実行しますか?大規模なイテレーションでは、リリースの頻度ははるかに低くなりますが、明らかなマイルストーン リリースはありますか?
質問 (正確ではありませんが、常に役に立ちます): 製品には、エンド ユーザーにとって意味のあるバージョン番号がありますか? たとえば、多くの Web サイトは常に改善やパッチをリリースしており、大幅な改善やオーバーホールはあまり行われていないため、アジャイルです。一方、MS Office のような製品には意味のあるバージョン番号 (2003、2007 など) が付けられています。おそらくSCCM。
明確な方法論がない場合は、方法論を作成する絶好の機会です。どのリリース サイクルが適切かを判断し、それぞれにプロジェクトを作成し、TFS が自動的に設定するものを確認します。検出？明らかに欠けているものはありますか？
方法論を識別できない場合は、アドホックな方法論を使用しています。既存の方法論に似ているかもしれません (偶然)。ただし、方法論に従うことは成功することと同じではないことに注意してください。私は失敗した方法論の重いプロジェクトをたくさん見てきました。そして、多くの「ズボンのシート」プロジェクトが大成功を収めています (おそらく、ほこりが落ち着いたときに少しリファクタリングが必要な場合)。
方法論の変更は、何よりも文化に依存します。制度は変化に抵抗する傾向があり、一部の個人はそうします。ただし、これもまた状況に依存します。既存の状況が明らかに崩れている場合、機関は皆を驚かせるような急な変更を行うことがあります。
一部の方法論は他の方法論よりも「重い」ものです。それらは変更が困難です。テスト駆動開発でさえ、事後にそれを採用することは古いコードに多くのテストを追加することを意味するという点で「重い」です。ほとんどの実際のトランジションでは、他の理由でファイルが編集されるときにテストを追加するだけです。同様に、TDD からウォーターフォール スタイルに移行するには、使用されていない大規模なバインダーに大量のコードを文書化する必要があります。
最も基本的な方法は、ステップからステップへと進むだけなので、反復法または「ウォーターフォール法」になる傾向があります。とはいえ、今はあまり人気がないようです。