正式なプロジェクト管理システムを必要としている 4 人の開発チームがあります。スクラムとカンバンについては大まかに理解していますが、実際に試してみるまで真に理解することは困難です。1 つを数週間試してから別のものに切り替えるという贅沢はないので、同じような状況にある誰かが、どちらがより効果的で、その理由について考えてくれることを望んでいました. また、開発を管理するための他のシステムがうまく機能した場合は、ぜひお知らせください。
別の注意: もちろん、チームが成長する可能性があるため、適切に拡張できるシステムが必要になります。
さらに別の注意: 私たちは、Windows で 3 つの別々のソフトウェア アプリケーションに取り組んでいます。これらはすべて、私たちが作成した中央ライブラリに基づいています (つまり、4 つのプロジェクトと言えるでしょう)。
スクラムとかんばんはどちらも、実際にはプロセスの「スケルトン」です。どちらもソフトウェア開発に固有のものではありません。スクラムはソフトウェア開発組織によって普及しましたが、ソフトウェア プロジェクト管理手法ではなく、一般的な管理手法として位置付けられています。かんばんは製造業から生まれ、最初は保守チームによってソフトウェア開発に適応されました。スクラムとかんばんはどちらも、その作業を行っているチームを通じて作業単位の流れを管理し、見積もりをより正確に行うことができるように作業の流れの速さを測定し、ボトルネックを非常に明確にして対処できるようにすることを目的としています。
どちらもソフトウェア開発に固有のものではないため、スクラムとカンバンを使用するチームは、ソフトウェア開発プラクティスをプロセスに追加して、ソフトウェアを段階的かつ反復的にリリースおよび改善できるようにします。ほとんどのチームは、スクラムまたはカンバン プロセス内で作業しているかどうかにかかわらず、XP の技術的プラクティスと Crystal の反射的プラクティスを採用しています。
XP は基本的に、単一のチームに適用されるスクラムに加えて、コードを「高品質」にするものと、プログラマーがそれを達成する方法についてのガイドラインです。Crystal Clear は同じ場所にある小規模なチームにも適用されますが、XP プラクティスも推奨されていますが、プログラミング プラクティスについてはより柔軟です (プロセスを説明している本は優れており、どのようなプロセスを選択する場合でも、非常に貴重なアドバイスが満載です)。スクラム チームは通常、Crystal の内省的なプラクティスも採用しています。定期的な「ハートビート」ふりかえりと、主要なマイルストーンごとに大規模なふりかえりです。かんばんには継続的な反省と改善が必要ですが、ふりかえりを使用するチームもあります。
小規模なプログラミング チームで漸進的/反復的なプロセスの適用を開始する場合、XP は技術的能力の基準をかなり高く設定し、十分に文書化されているため、開始するのに適したプロセスだと思います。継続的フローとかんばんがソフトウェア開発業界のさまざまな分野にどのように最適に適用されるかについては、kanban-dev メーリング リストや他の場所でまだ議論されています。
プロセスを改善し、特定の状況に適応させるために、定期的なふりかえりも実施することをお勧めします。
スクラムは中小規模のチームで機能すると思います。XPと比較すると、詳細が省略されているため、XPから借用するか、意味のあることを行うことができます。どちらの方法を選択する場合でも、ニワトリ（顧客/管理者/利害関係者/ドメインの専門家）の役割を考慮する必要があります。自分で役割を果たさなければならない場合もありますが、ドメインに関する知識が豊富な外部ペースカーがあるため、多くのアジャイル手法が機能します。
その他の重要な側面は、チーム間のコミュニケーションレベルと、何らかの形式の品質保証メカニズムです。同じ建物にいない場合、ペアプログラミングを行うのは困難です。スクラムはスプリントサイクル内で機能を受け入れようとし、XPは単体テスト、コードレビュー、継続的インテグレーションを使用して1日以内に機能を統合しようとします。
*）スプリントの範囲は15〜30日です。
最も重要な部分は、継続的な改善を促進する反映/振り返りのメカニズムを導入することです。いくつかのプロセス モデルから始めて、ニーズに合わせて時間をかけて進化させます。やる価値のないことはやめましょう。価値の高いことをやり続ける。価値があると思われる新しいことを試したり、特定の問題に対処したりしてください。
その規模のチームでは、形式化されたシステムが課すすべてのオーバーヘッドから多くの利益を得ることはできません。代わりに、適切な管理手法を試して、全員がお互いに耳を傾け、ブロックが削除されていることを確認してください.
質問は何ですか？どの方法論が最も適しているのでしょうか?
私は、いくつかの共通ライブラリを共有する 2 つのチームで、それ以上の規模のチームと協力してきました。スクラムはうまく機能しました。現在、私は 6 人のメンバーからなるチームで働いており、XP を使用していますが、XP も同様に機能していると思います。最初のチームが製品を開発し、「宇宙」からの影響はそれほど大きくありませんでした。したがって、より長い反復はうまくいきました。いいえ、お客様のプロジェクトを開発しているため、リリース サイクルが短いほど有利です。
しかし、SCRUM と XP はそれ以上のものです。現在、TDD とペア プログラミングを使用しています (どちらも XP の世界から来ています)。また、SCRUM に近いスタンドアップ ミーティングも毎日開催しています。そのため、XP と SCRUM を導入して、プロジェクトと状況に合わせて機能するようにしました。
短いサイクル (1 週間) とこのサイクルのレビューから始めます。チームで新しい方法論を採用するにはしばらく時間がかかりますが、メンバーが学習して変更する意思があれば、うまくいきます。