プラットフォーム開発でアジャイルを機能させることは可能ですか? それぞれがプラットフォームの固有の機能領域を担当する一連の開発ポッドを想像してください。ここで、プラットフォームを使用して一般向けのソフトウェア アプリを構築する 2 ~ 4 のアプリ開発チームを想像してみてください。このシナリオでアジャイルを機能させるにはどうすればよいでしょうか?
2 に答える
アジャイルをどのように定義するかによると思います。アジャイルは、一連の方法論と実践の総称です。
ウィキペディアでは、次のように定義されています。
アジャイル手法は一般に、頻繁な検査と適応を促進する統制のとれたプロジェクト管理プロセス、チームワーク、自己組織化、および説明責任を促進するリーダーシップ哲学を促進します[...]。
私が作業するアジャイルアプローチを実践します。アーキテクチャチームはかなり不特定のアジャイルな方法で作業し、機能チームはスクラムを使用します。指定されていないということは、プロセスがどのようであるかについて厳密な規則がないことを意味しますが、私たちはいくつかのアジャイル原則を使用します。最も重要なのは、開発が滝のように行われるのではなく、繰り返し行われることです。
コアソフトウェア開発部門全体で、継続的インテグレーションと多くの自動テストを使用しています。毎日のスタンドアップは、定義上、機能チームが使用するプラクティスですが、状況によってはプラットフォームチームが使用することもあります。プラットフォームチームは、彼らが何をしたかについて毎週オープンなプレゼンテーションを行っています。また、ユーザーストーリーは、機能チームだけでなく、責任が重複し、製品要件がより一般的なプラットフォーム要件であることが判明した場合に、プラットフォームチームにも使用されることがあります。
ですから、そうです、状況(つまり、管理や製品の要件)が許す限り、プラットフォームチームはアジャイルが可能だと思います。何を使用し、どのように使用するかはあなた次第です。
アジャイルは、アプリケーション開発で機能するのと同じ理由でプラットフォーム開発で機能し、同じ基本的な理由で両方のケースで失敗する可能性があります。
アジャイル プロセスは、定義上、環境に適応します。通常、適用されているタスクの目的に適合するようにプロセスを適応させるのは、プロセスを使用する人々です。この適応性により、プロセスの適応性が作業環境で許容される場合、アジャイル プロセスは本質的に堅牢になります。
プラットフォーム開発では、多くの場合、リリース スケジュールはアプリケーション開発よりもさらに離れており、より安定しています。一見すると、これは、機能の増分を提供することはあまり役に立たないことを意味し、使用可能な機能の増分を顧客に提供することによって得られるのと同じフィードバック ループを提供しません。よく調べてみると、これは、作成中の機能を誰も待っていない場合、または何らかの価値がある完全な成果物のみである場合にのみ当てはまります。
一方で、環境は成功を助長します。その一方で、アジャイル プロセスに不可欠なメカニズムの 1 つが欠けています。欠落しているメカニズムを補うようにプロセスを適応させることができる限り (たとえば、テスターまたはアプリケーション開発者に中間成果物を使用させるなど)、適応したプロセスは依然として目的に適合するはずです。
ソフトウェアの設計と構築に関して言えば、ソフトウェア (仕様を含む) は多かれ少なかれ同じ方法で書かれています。モチベーションと注意持続時間に関しては、多かれ少なかれ同じ特性を持っています。新しい機能の範囲はより大きくなり、目標はより長期的なスケジュールで定義される可能性がありますが、それでも段階的に達成する必要があり、それらの段階は反復に適合するように定義して、最後にある種の進捗状況を示すことができます。 . 開発マネージャーは成果物だけでなくマイルストーンの観点から考えることが多いため、これは現在の慣行からの進化にすぎない可能性があります。
私は、さまざまなチームがプラットフォームとアプリケーションの両方の開発に使用するスクラム プロセスを見てきました。チームは、それぞれのニーズとプロセスに対する理解の違いに応じて、さまざまな方法でプロセスを実装しますが、主な成功要因は、チーム (およびチーム内の個人) の能力と、チームの管理者の能力です。