スクラムガイド | 13. スクラムの開発チーム

公開: 2022-04-25

スクラムの開発チームは、製品の作成に関与するすべての人々で構成される学際的なグループです。 今日の記事では、それが持つべき特性を見ていきます。 また、目標を効果的に達成できる開発チームの構成と責任についても検討します。

スクラムの開発チーム – 目次:

  1. 開発チームの特徴
  2. 開発チーム
  3. 開発チームの責任
  4. 概要

開発チームの特徴

スクラムの原則に従って作業する開発チームは、独立した専門家グループです。 外部の専門家や下請業者のサポートは使用しません。 しかし、チームが目標を達成するために十分に一致していることを決定するものは何ですか? また、専門分野に関係なく、開発チームのタスクにはどのような責任が含まれますか?

開発チームが効果的であるためには、自己組織化能力、成長への意欲、学際性という少なくとも 3 つの特性が必要です。

自己組織化

開発チームが属するスクラム チームについて話すとき、 「自己管理」という用語を使用します。 組織レベルでの自己管理を意味します。 スクラム チームは全体として、誰がどのように作業を行うかだけでなく、何に取り組むかを決定します。 スクラム チームでは、管理タスクの大部分がプロダクト オーナーとスクラム マスターに属します。

Development Team

したがって、開発チームの場合、自己管理よりも自己組織化が重要です。 つまり、誰が、いつ、どのように特定のタスクを実行するかを自分で決定することです。

開発の追求

効果的なチームの重要な特徴は、成長への原動力です。 その前に設定されたタスクを完了する方法は、野心的でなければなりません。 これは、開発チームの各メンバーの個々の素因や態度だけに起因するものではありません。 能力と努力の向上は、チーム全体を定義するチーム内の雰囲気によっても促進されます。

学際性

チームの学際性とは、チームのメンバーが一緒になって、各スプリントで価値のあるインクリメントを作成するために必要なすべてのスキルを備えている必要があることを意味します。 また、チームの各メンバーがそのスプリントに必要なタスクを実行することも意味します。 誰もが目標を達成するために必要なことを行います。 たとえそれが開発者の専門知識を超えた新しいタスクに取り組むことを意味する場合でも. 自分の専門的能力や役割に固執するのは間違いです。

development team features

開発チーム

スクラム ガイドによると、開発者の最大数は 8 人です。 チームメンバーはお互いを知る機会があるため、このような小さな構成はコミュニケーションと開放性を促進します。 ただし、チームは 3 人未満であってはなりません。 各スプリントでビジネスに目に見える進歩をもたらすのに十分な大きさである必要があります。

スクラム内の開発者は、さまざまなスキルと責任を持つ人々と呼ばれます。 プログラミングを行う人のために予約された名前では決してありません。 したがって、チームには、プログラマーとデザイナー、研究者とアナリスト、テスターと科学者、およびその他の専門家が含まれる場合があります。

開発者の間に階層はありません。 そのため、彼らは専門的または科学的なタイトルを使用していません。

開発チームの構成に関する重要な前提は、それが団結しているということです。 したがって、他の目標に取り組んでいる小規模なチームは、それから分離されるべきではありません。

開発チームの責任

開発チームの責任は、3 つの領域に分けることができます。 これらは:

  • 計画タスク
  • 製品の作業
  • チーム内のコラボレーションの改善

計画タスク

タスクのスケジューリングは、すべてのスクラム ベースの開発チームが果たさなければならない義務です。 これは、スプリント計画を作成し、それをスプリント バックログに入れることで構成されます。これについては、別の記事で説明します。 最も重要なことは、開発チームが協力して取り組んでいることです。 このようにして、各開発者は、特定のスプリントで実行するタスクの数を現実的に決定できます。 長期的には、これによりチームは一定のペースを維持し、より正確に計画を立てることができます。

脈動に注意を払うこと、つまり計画を毎日現実に合わせることも同様に重要です。 問題が発生した場合は、変更が必要になる場合があります。タスクを再編成したり、作業を別の方法で分散したり、新たな問題についてスクラム マスターに相談したりします。

製品の作業

製品の作業形態は、特定の開発チームが活動する領域によって大きく異なります。 一般的に言えば、各スプリントで達成すべき目標は、インクリメント、つまりビジネス価値のある製品機能を作成することです。

ここでは、直接話し、次のルールを適用すると便利です。

製品の作業に着手するときは、改善されているだけでなく、以前のバージョンよりも完成度が劣っていない状態のままにしておく必要があります。

この原則を適用することは、チーム全体がインクリメントに責任を持つことを意味します。 開発者が不用意にタスクを実行し、製品の品質が低下した場合、他の誰かがその作業を行う必要があります。 一方、開発者が製品のバグに遭遇した場合は、自分で修正するか、バグ情報をできる人に渡す必要があります。 スプリント内での製品インクリメントの取り組みについては、別の記事で詳しく説明します。

チーム内のコラボレーションを改善する

チームの運営方法に取り組むことは、個々の開発者の効率と有効性を常に改善することです。

ただし、開発者間のコミュニケーションに関する作業でもあります。 改善は、効率的かつ正確なタスク分割を可能にするソリューションを考え出すことにあります。 また、スキルの練習:

  • 人ではなく解決策を批判する– 仕事を説明するために使用する言葉を変えると、態度が変わり、コラボレーションが改善されます
  • 自分のアイデアから距離を置く– ユーモアとより率直なフィードバックを可能にします
  • 信頼の構築 – 信頼のおかげで、環境の否定的な反応を恐れることなく、開発者が提案するより多くの革新的なアイデアが生まれる可能性があります

チームのコラボレーションの改善は、チームがどのように機能するかを継続的に検討し、この記事で説明されているスクラム イベント中にフィードバックを提供することによって達成されます。

Development Team in Scrum

概要

今日の記事では、スクラム開発チームの特徴、構成、および責任について説明します。 学際性、自己組織化、開発への欲求が、この小さなチームの特徴です。 そして、チームワークの継続的な改善と製品に関する効果的な作業– これらは、すべての開発チームが果たさなければならないタスクです。

私たちのコンテンツが気に入ったら、Facebook、Twitter、LinkedIn、Instagram、YouTube の忙しいミツバチ コミュニティに参加してください

Scrum Guide | 13. Development Team in Scrum caroline becker avatar 1background

作者: キャロライン・ベッカー

プロジェクト マネージャーとして、Caroline は、最適なワークフローを設計し、プロセスを最適化するための新しい方法を見つける専門家です。 彼女の組織力と時間的プレッシャーの下で働く能力により、彼女は複雑なプロジェクトを実現するのに最適な人物となっています。

スクラムガイド:

  1. 基本的な用語、役割、および概念の用語集
  2. スクラムとは?
  3. スクラムの価値
  4. あなたの会社にスクラムを導入する方法は?
  5. スクラム チーム - それは何ですか?どのように機能しますか?
  6. プロダクトオーナーとは?
  7. プロダクトオーナーのよくある間違い
  8. スクラムマスターとは?
  9. 優れたスクラムマスターの特徴
  10. スクラムマスターのよくある間違い
  11. スクラム マスターはどのような統計と指標を追跡する必要がありますか?
  12. プロダクトオーナーとスクラムマスターの協力
  13. スクラムの開発チーム
  14. 開発者のよくある間違い
  15. スクラム成果物
  16. スクラムのスケーリング
  17. スプリントバックログ
  18. 製品バックログとは何ですか?
  19. ユーザーストーリーとは?
  20. INVEST で最高のユーザー ストーリーを作成する
  21. 最も一般的なユーザー ストーリーの間違い
  22. ユーザーストーリーの承認基準
  23. スクラムの見積もりとストーリー ポイント
  24. 企画ポーカー
  25. チーム見積もりゲーム
  26. 増分の定義
  27. スクラムイベント
  28. スクラムにおけるスプリントとは?
  29. スクラム チームのコミットメント - 製品の目標、スプリントの目標、完了の定義
  30. バーンダウンチャートとは?
  31. バーンダウン チャートを作成して解釈する方法
  32. バーンダウンチャートのメリットとデメリット
  33. スクラムとスクラムバンのかんばんボード
  34. スクラムの速度 - 開発チームの速度
  35. デイリースクラム
  36. スプリント計画
  37. スプリントレビュー
  38. スプリントレトロスペクティブとは何ですか?
  39. スプリントふりかえりでよくある間違い
  40. 製品バックログ育成