window.pipedriveLeadboosterConfig={です。 ベース:'leadbooster-chat.pipedrive.com'、 companyId:11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2、 } ;(function () { var w = window もし (w.LeadBooster) {なら console.warn('LeadBooster already exists') } else { w.LeadBooster = { {. q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: 関数 (n) { { this.q.push({ t: 'o', n: n, h: h }) this.q.push({ t: 't', n: n }) }, } } })() SCRUMにおけるプロジェクトマネジメント - The Codest
The Codest
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 産業
    • フィンテック&バンキング
    • E-commerce
    • アドテック
    • ヘルステック
    • 製造業
    • 物流
    • 自動車
    • アイオーティー
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
  • 会社概要
  • サービス
    • ソフトウェア開発
      • フロントエンド開発
      • バックエンド開発
    • Staff Augmentation
      • フロントエンド開発者
      • バックエンド開発者
      • データエンジニア
      • クラウドエンジニア
      • QAエンジニア
      • その他
    • アドバイザリー
      • 監査&コンサルティング
  • 価値
    • CEO
    • CTO
    • デリバリー・マネージャー
  • チーム
  • Case Studies
  • ノウハウ
    • ブログ
    • ミートアップ
    • ウェビナー
    • リソース
採用情報 連絡先
戻る矢印 戻る
2019-09-01
プロジェクト管理

SCRUMにおけるプロジェクト管理

マテウシュ・レスニアク

SCRUMは経験的プロセス制御理論に基づくプロジェクトマネジメント手法であり、アジャイルマニフェスト(2001年)の価値観に合致する。これは制限的な作業方法論ではなく、最終的な形をストレートにイメージすることなくソフトウェアを提供できるフレームワークである。SCRUM方法論の主な利点は、要件変更のコストを最小限に抑え、すぐに使える可能性のある機能を迅速に提供することである。

どのように機能するのか?

実際のところ、これはプロセス全体が常に最適化され、そのニーズに適応していることを意味する。 チーム そして 製品 の全作業期間を通じて プロジェクト.管理責任 製品開発 は、プロダクトオーナー(PO)とデザインチームの間に広がっている。POは、製品開発の方向性に関する意思決定を行う責任者であり、製品の全体的な「ビジョン」を持っている。タスク管理は、カンバンボードに基づいて行われる。 スプリント SCRUMボードと呼ばれる機能)。プロセスの各参加者は、バックログにタスクを追加することができるが、優先順位を設定する責任はOPにある。プロジェクトチームは、POのアイデアを具体的なタスクに「変換」し、その実施を計画する責任を負う。

サイクルの経過

プロセスは反復(スプリント)に分けられる。約2週間続く1つのスプリントの一部として、プロジェクトチームは事前に計画された機能の一部を実装し、テストします。

スプリントは "プランニング "から始まり、事前にPOがバックログの上位にグルーミングして設定したタスクをチームで議論し、準備する。その後、これらのタスクの難易度が見積もられ、難易度に応じてポイントが与えられる。チームの構成や作業条件が比較的一定しているため、各スプリントで実施されるポイント数は再現性があり、今後の作業計画を立てることができる。計画会議の最後に、1スプリント内で完了するポイント数の合計が多いタスクが選択され、新しいスプリントが開始される。

スクラム・ソフトウェア管理

スプリントの途中では、グルーミングが行われる。これは、OPがさらなる期待やアイデアをチームに提示するミーティングであり、プロジェクトチームはそれらを分析し、より小さなタスクに分解し、可能な提案をOPに提示する。将来のタスクを計画する際、OPはアナリスト、ユーザー、UX、グラフィックデザイナーに相談する。追加分析 (マーケット リサーチやデータサイエンス)がこの段階で必要になることが多い。いわゆるユーザーストーリーを分析・策定した後に初めて、POはそれらのストーリーをバックログとして公開する。ユーザーストーリーには、OPが与えられたタスクやタスク群に何を期待するのか、タスクが完了したかどうかを認識するためにどのような基準を用いるべきかという情報が含まれていなければならない。

スプリントの間、いわゆる「デイリースタンドアップミーティング」が毎日開催される。このミーティングで、各開発者はチームの他のメンバーに、直近の1日の作業内容を伝え、場合によっては、今後の作業を妨げる問題や障害について報告する。このように現在の状況を交換することで、さまざまなタスク間の潜在的な衝突をより早く発見することができ、開発者が問題に行き詰って作業が進まないという事態を避けることができる。デイリースタンドアップの前提は、できるだけ短く、しかし同時にその役割を果たすことである。ミーティングの常套句は、チームがそれを短く保つことを奨励する。

スプリントの間、タスクは現在のステータスに従ってSCRUMボード上で移動される。列の選択は通常、企業やチームの作業システムに対応し、バージョン管理システムやリリースの頻度に関連する。私たちの場合は以下のようになります:

  • To do - 完了待ちのタスク
  • 進行中 - 現在進行中のタスク
  • コード review - 他の開発者によるチェックを待つタスク。
  • 準備 - タスクが開発者によってチェックされ、承認される。
  • ステージング - ステージングインスタンスに配置され、POの承認を待つタスク
  • 受理 - POが受理したタスク
  • 完了 - 本番インスタンスに配置された準備完了のタスク

スプリントの後には、レトロスペクティブが行われる。これは作業の最適化に特化した会議である。チーム全員で、直前のスプリントでうまくいったこと、改善すべきことを話し合う。また、前回のレトロスペクティブを参照し、作業を改善するためのアイデアをすべて実行できたかどうかをチェックすることも多い。レトロスペクティブで議論される問題は、開発ツール、プレッシャー、タスクの難易度、コミュニケーションの問題(開発者とチーム、POの両方)など、多岐にわたります。

ソフトウェア開発プロジェクトにおけるスクラム

SCRUMマスターの責任

SCRUMプロセスの適切な実施の責任者はSCRUMマスターである。これはしばしばチームの中で最も理解しがたい役割である。SCRUMマスターには決定権がない。意思決定はチームとPOが共同で行い、SCRUMマスターの役割はプロセスの適切な進行の障害となるものを取り除くことである。

SCRUMマスターの職務には以下のようなものがある:

  • プランニング、グルーミング、デイリースタンドアップミーティング、レトロスペクティブを含むSCRUMミーティングの実施
  • SCRUMボード上のタスクがチームによって定期的に手入れされ、POによって優先順位が付けられるようにする。
  • チームとPOをつなぐ役割を果たす。そのため、プログラマーの言葉をビジネスの言葉に翻訳したり、逆にビジネスの言葉をプログラマーの言葉に翻訳したりするのが難しい役割を担っているのがSCRUMマスターであることが多い。これは、私たちの会社では、SCRUMマスターが開発者、つまり技術者であるという事実によるものである。SCRUMマスターの仕事の一般的な枠組みではその必要はない。
  • ミーティングでは、チームのトピック外れを阻止し、アジェンダを守る。
  • チーム内の雰囲気に気を配る - 主にミーティングで。
  • 対立が生じた場合の解決

あわせて読みたい:

  • コーデストのソフトウェア構築のためのグッドプラクティス。カスタマージャーニーへのアプローチ
  • Codestのソフトウェア構築のためのグッドプラクティス:GitFlow
  • コーデストのソフトウェア構築のためのグッドプラクティス。要求分析をどのように実施するか?

関連記事

エンタープライズ&スケールアップ・ソリューション

なぜリモート開発チームが必要なのか?

コスト効率、グローバル人材へのアクセス、柔軟性など、リモート開発チームを統合するメリットと戦略を探る。

The Codest
アガタ・ワザック クライアント・ソリューション・スペシャリスト
プロジェクト管理

アジャイル導入の要点:技術チームのためのロードマップ

アジャイル手法の効果的な導入方法について、専門家であるヤンPMの洞察とともに学び、効率性とコラボレーションを強化しましょう。

The Codest
ヤン・コロウシェク プロジェクトマネージャー
プロジェクト管理

PMのデスクより効果的なリモートチーム管理テクニック

PMジャンから、リモートチーム管理を最適化し、生産性を高めるための実証済みの戦略を学びましょう。今すぐ読む

The Codest
ヤン・コロウシェク プロジェクトマネージャー
エンタープライズ&スケールアップ・ソリューション

ソフトウェア開発チームを管理するための7つの重要な戦略

この記事では、ソフトウェア開発チームを効果的に管理するための主要な戦略について、コミュニケーション、プロジェクト管理ツール、チームダイナミクスの理解に重点を置いて詳しく説明する。

ザ・コデスト
プロジェクト管理

CTOガイドリモート開発者を効果的に管理

世界では、60%を超える人々がリモートで仕事をしている。この傾向は特にIT業界で顕著です。より多くの開発者がリモートワークの可能性を評価している。その理由は...

The Codest
カミル・フェレンス 成長部門責任者

ナレッジベースを購読して、IT部門の専門知識を常に最新の状態に保ちましょう。

    会社概要

    The Codest - ポーランドに技術拠点を持つ国際的なソフトウェア開発会社。

    イギリス - 本社

    • オフィス 303B, 182-184 High Street North E6 2JA
      イギリス、ロンドン

    ポーランド - ローカル・テック・ハブ

    • ファブリチュナ・オフィスパーク、アレハ
      ポコジュ18、31-564クラクフ
    • ブレイン・エンバシー, コンストルクトースカ
      11, 02-673 Warsaw, Poland

      The Codest

    • ホーム
    • 会社概要
    • サービス
    • Case Studies
    • ノウハウ
    • 採用情報
    • 辞書

      サービス

    • アドバイザリー
    • ソフトウェア開発
    • バックエンド開発
    • フロントエンド開発
    • Staff Augmentation
    • バックエンド開発者
    • クラウドエンジニア
    • データエンジニア
    • その他
    • QAエンジニア

      リソース

    • 外部ソフトウェア開発パートナーとの協力に関する事実と神話
    • 米国から欧州へ:アメリカの新興企業がヨーロッパへの移転を決断する理由
    • テックオフショア開発ハブの比較:テックオフショア ヨーロッパ(ポーランド)、ASEAN(フィリピン)、ユーラシア(トルコ)
    • CTOとCIOの課題は?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • ウェブサイト利用規約

    著作権 © 2025 by The Codest。無断複写・転載を禁じます。

    jaJapanese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek jaJapanese