アジャイルに関する FAQ

以下は、アジャイル手法に関するよくある 10 の質問をまとめたものです。ここで提案されているベスト プラクティスは、アジャイルに移行する組織を何年も支援してきた CA Agile Central のコーチング チームから直接提供されたものです。以下のリストの質問をクリックすると、トピックに直接ジャンプします。

 

  1. アジャイルへの移行がうまくいくかどうかを知るにはどうすればよいですか?私たちと同じような環境で成功した例はありますか?
  2. ドキュメントについてはどうすればよいですか?
  3. アジャイルは分散したチームに対しても機能しますか?
  4. ストーリーの適切なサイズはどのくらいですか?
  5. チームの適切なサイズはどのくらいですか?
  6. ストーリーを分割できない場合はどうすればよいですか?
  7. イテレーションの開始後にストーリーまたはタスクを変更できますか?
  8. 社内に提供する場合、ストーリーをユーザの観点から記述するにはどうすればよいですか?
  9. 配信の日付とコストを見積もるにはどうすればよいですか?
  10. 要員をイテレーションに専念させるのに苦労しています。何か提案はありますか?

1. アジャイルへの移行がうまくいくかどうかを知るにはどうすればよいですか?私たちと同じような環境で成功した例はありますか?

ソフトウェア開発は非常に困難であるため、手法を移行しても成功が保証されるわけではありません。期日どおり、および予算内で提供できない製品や、期待を満たすことができない製品は数多くあります。アジャイルは特効薬ではありません。致命的な欠陥のあるイニシアチブは失敗しますが、アジャイルのような実証的アプローチを採用した場合、より早い段階で失敗するか、またはフィードバックを活用してコースを変更できます。

アジャイルで成功した経験のあるユーザは数多く存在します。各個人、チーム、または組織は、いずれも他とは異なっていますが、すべてが同様の課題に直面します。ビジネスまたはテクノロジの領域を問わず、私たちはすべて早期に、かつ高い頻度で提供し、品質を向上させることを望んでいます。問題は、「どれだけアジャイルになれるか」ではなく、「どれだけ効果的にソフトウェアを構築したいか」です。

2. ドキュメントについてはどうすればよいですか?

アジャイル チームに関する一般的な通念の 1 つは、アジャイル チームはドキュメントを作成しない、というものです。実際のところ、アジャイル チームは、対面の会話が最も効果的なコミュニケーション手段であることを知っています。ドキュメントは、「以前からそのように行ってきた」からではなく、ビジネス価値がある場合に作成されるものです。

アジャイル チームが前もって詳細な要件ドキュメントを作成するのを見ることは多くありません。ビジネスと開発がより緊密に連携していれば、書かれた言葉への依存は少なくなり、チームは最大量の情報が利用可能になるまでコミットメントを延期できます。ドキュメントが必要であれば、イテレーション内で時間を作って完了させる必要があります。後に延ばせば、技術的な負債が蓄積され、リリースする能力を妨げることになります。

3. アジャイルは分散したチームに対しても機能しますか?

もちろんです。数多くのお客様が、分散したチームでの成功に満足しています。対面の対話が最も効果的なコミュニケーション手段ですが、同じ場所にチームを配置するのは不可能な場合もあります。変化の激しい現在の世界では、企業は従業員により適切な仕事と生活のバランスを提供し、環境に配慮するようになっているため、分散チームはますます増えています。

4. ストーリーの適切なサイズはどのくらいですか?

ストーリーは、その目的に応じて適切なサイズにする必要があります。イテレーションを計画している場合は、ストーリーが 1 回のイテレーションで完了するくらい小規模であることを確認する必要があります。一方、製品ロードマップに現れるストーリーは複数のイテレーションにまたがることもあり、それらを分割するために時間を費やすのは経済的ではない場合があります。チームがイテレーション コミットメントを満たそうとしてスコープを狭め、それに伴い、イテレーションの終了に向けてストーリーを分割するのを見ることがありますが、これは通常、ストーリーが大きくなりすぎる兆候です。したがって、スコープを適切に優先順位付けできるくらい小規模なストーリーを、労力が無駄にならないよう前倒ししすぎずに作成してください。

5. チームの適切なサイズはどのくらいですか?

使用するのに理想的な範囲は、5 ~ 9 人のユーザです。チームが大きくなると、会議が長引き、直接関連しない情報の量が増加します。また、各ユーザが、日々の立ち会議や計画会議に出席する価値に疑問を覚え始める危険もあります。もちろん、チームを分割するのはそれほど簡単ではない場合もあり、それによってオーバーヘッドが追加される可能性があります。ふりかえりミーティングを使用して、より大規模なチームで続行する方法や最適な分割オプションに関するアイデアを生み出してください。

6. ストーリーを分割できない場合はどうすればよいですか?

ストーリーを初めて作成するユーザの多くはこれが難しいことだと予想しますが、実際のところ、これは通常、自分の作業を整理することです。たとえば、目を閉じて、これを読んだ後にすぐ行うことについて考えてください。これでストーリーが分割されました。確かにそれはバックログに詳しく記録する必要のない小規模なタスクかもしれませんが、より大きな何かの一部であり、アイデンティティを持っています。

ストーリーは簡単に分割できます。必要なのは、適切なときに、適切な詳細レベルでそれを行うことに慣れることだけです。すべてを前もって行う必要はありません。これは継続的なプロセスです。アジャイル計画のレベルを下っていき、ストーリーについて議論するときに、対話によってストーリーの分割が促進されます。たとえば、次のイテレーションの計画を準備するときに、そのイテレーションで予定されているストーリーの選択肢について議論します。行った意思決定により、ストーリーの承諾基準か、または独立してスケジュール設定できるより小規模なストーリーが生成されます。

7. イテレーションの開始後にストーリーまたはタスクを変更できますか?

イテレーション内のタスクは、実行する必要がある作業を正確に反映する必要があります。タスクを低く見積もった場合は、時間単位の見積もりをできるだけ早く更新して、チームの他のユーザが最新のステータスを確認し、必要に応じて支援を提供できるようにする必要があります。

ストーリーは、イテレーション中に変更されることが期待されていません。通常、承諾基準を作成し、ストーリーを見積もり、およびストーリーをタスクに分割するプロセスにより、必要なすべての情報が明らかになります。ストーリーのスコープに追加するリクエストがある場合、チームは次のイテレーションを待つことを検討するようにプロダクト オーナーに求める必要があります。スコープの変更を待てない場合、影響を検討し、重大な場合はイテレーションをキャンセルします。スコープの削除には、はるかに簡単に対応できます。不要であることが発見されたら、すぐに処理を停止します。

8. 社内に提供する場合、ストーリーをユーザの観点から記述するにはどうすればよいですか?

ストーリーを提供する相手と、その相手がそのストーリーからどのような価値を取得するかについて考えます。価値を明確化する方法で何かを表現することは常に可能であるはずです。よく使用されるユーザ ストーリー テンプレートは、「(ユーザのタイプ - 誰)として、私は(何らかの目標 - 何を)望んでいて、それは(何らかの理由 - なぜか)」というものです。最後の部分(なぜ)は非常に重要であり、軽く考えてはなりません。ストーリーを作成する必要性を正当化できない場合、そのストーリーは重要ではなく、再検討される必要があります。

9. 配信の日付とコストを見積もるにはどうすればよいですか?

成功するすべてのビジネスでは、配信の日付とコストに関する期待を設定する必要があります。アジャイル組織でもこれは同じです。見積もりは当然ながら推測であるため、どのような保証もできません。アジャイルの見積もりの主要理念は、作業者ではなく作業成果物レベルで見積もりを行うことです。

スクラムなどのイテレーション ベースのアプローチでは、チームのベロシティを使用して、バックログ上のアイテムの期待される配信日および配信コストを予測できます。フロー ベースのアプローチでは、サイクル時間およびスループットを使用して期待を設定します。どちらのアプローチでも、予測可能なインクリメンタル配信モデルが必要です。安定したサイクルがなければ、最初の見積もりは従来の計画ペースのアプローチによる結果をわずかに上回るだけです。しかし、小規模なバッチ、高速なフィードバック リズムに注力できれば、早期に確認を行うことができ、従来のアプローチよりはるかに早く、より高品質の見積もりを提供できます。

10. 要員をイテレーションに専念させるのに苦労しています。何か提案はありますか?

複数の作業を抱えているユーザが多いと、コンテキストの切り替えによって生産性が大幅に低下し、スループットに影響が及びます。優先順位付けを厳格に行い、進行中の作業を制限するとことで、ある作業が完了してから次の作業に着手するように強制します。

 

グループがときおりチーム外の専門家の知識に頼る必要が生じることがあっても、それは問題ではなく、むしろ期待されることです。チームの他のメンバと同じように、専門家の作業を計画および管理する必要があります。

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。