Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20200726_devPM_iwamu

 20200726_devPM_iwamu

2020/07/26(Sun)
CHARITY CONFERENCE OKINAWA × devPM Vol.2 MANAGEMENT
スクラム開発お悩み相談室

HinayHinayLab

July 26, 2020
Tweet

More Decks by HinayHinayLab

Other Decks in Technology

Transcript

  1. CHARITY CONFERENCE OKINAWA × devPM Vol.2 MANAGEMENT 2020/07/26 (Sun) YogAgile

    Engineer 岩村 琢 スクラム開発お悩み相談室
  2. 自己紹介 @takusamar いわむー@ヨガはいいぞ 沖縄在住のフリーランスITエンジニア ヨガ×アジャイルで健康なチームづくり をサポートしています 2019年10月~ KDDI DIGITAL GATE

    フロントエンド開発(React/Flutter) スクラム、モブプログラミング 拠点:東京、大阪、沖縄 開発メンバーは在宅リモートワーク アジャイルゆいまーる アジャイル開発のコミュニティ「アジャイルゆいまーる」を運営 https://agile-yuimar.connpass.com/ 2 Scrum Alliance 認定スクラムマスター Scrum Inc.認定資格 プロダクトオーナー
  3. 4

  4. 5 受託開発でスクラムを導入するときにどう理解を得るか これからアジャイルをはじめようという人向けの解説書 特にエンジニア以外(PM、営業、役員、…)におすすめ • 目的を明確にする • スクラムの基礎知識を学ぶ • 他社事例から学ぶ

    • まずは小さく始めてみる 最初は問題点が出てきても、スプリントを繰り返して 徐々に改善していく様子を肌で感じる。 なんのためにアジャイル開発をやるのか、スクラムをやるのか 顧客や上司の共通認識を得る。 このプロジェクトでスクラムをやるべきという確信を持つ。 顧客や上司にもスクラム研修を受けてもらう。 最低限スクラムガイドに書かれている内容は理解している。 さまざまな会社の成功事例・失敗事例を見て、 自分たちのスクラムはどうするかを顧客と一緒に考える。 顧客や上司にスクラム導入を理解してもらうには・・・
  5. 6 そもそも受託開発(請負型)でスクラムするのは向いているのかどうか 要件が決まっている(何を作るか明確 に決まっていて、交渉の余地がない) 案件だとスクラムには向いていない。 従来の開発アプローチ 「要件は変わらないはず」 スコープ 予算 納期

    (固定) (可変) アジャイル開発アプローチ 「要件は変化する」 予算 納期 スコープ 予算や納期も固定されていて どうしようもないことも良くある その場合は品質が犠牲になる 品質 品質 予算・納期に合わせて スコープを調整することで 品質を維持する 【契約例】 • 期間は4週間 • Dev3名+SM1名のチームを提供 • POは顧客に担当していただく • 金額は固定(時間精算ではない) • 期間内の仕様変更はいつでも可能 受託開発(請負型)でスクラムをやる 場合は、期間とリソースを固定して、 スコープは調整可能にしておくと良い。
  6. 7 チームメンバーをスクラム脳にするためのポイントなど 新たなマインドセットを身につける方法として最も効果的なのは、 上手くいっているスクラムチームに入れること。 アジャイルなマインドセットの中で仕事を共にすることで、少しずつ慣れていく。 アジャイルはマインドセットである。 マインドセット = ものの見方、習慣 人生観、仕事観

    「こういう生き方をしたい」 「こういう働き方をしたい」 私はどう在りたいのか、という思い その人がこれまでの人生で積み上げてきたものなので、 簡単に差し替えることはできない。 (そういうスクラムチームがない場合は、外部からコーチを招いてスクラムチームを育てるところから始めよう)
  7. 8 スクラムチームの3つのロール(役割) • プロダクトオーナー(PO) 開発チームから生み出されるプロダクトの 価値の最大化に責任を持つ • 開発チーム(Dev Team) リリース判断可能な「完成」した

    プロダクトインクリメントを届ける • スクラムマスター(SM) スクラムガイドで定義された スクラムの促進と支援に責任を持つ POとDevチームのコミュニケーション
  8. 9 よくあるプロジェクト体制 PMの役割 • 顧客との交渉、報告 • 開発チームへの指示出し • チームメンバーのフォロー :

    責任が重すぎる。 とにかく忙しい。 ボトルネックになりがち。 スクラムではPMの役割を みんなで分担しよう! 開発チーム メンバー 顧客 PM 開発チーム リーダー
  9. 11 (顧客)PO Dev Team SM ビジネスを知っている人が 意思決定に責任を持つ リーダーやメンバーといった 固定された上下関係はない ファシリテーターとして

    POを支援する Dev Teamを支援する 外部からの指示を受けずに インクリメントを作成する 責任と権限を持つ • 顧客との交渉、進捗報告 →顧客がPOとなる • 開発チームへの指示出し →Dev Teamが考えて実行する • チームメンバーのフォロー →SMがスクラムチームを支援する スクラムのロール(役割)
  10. 12 開発チーム メンバー 顧客 PM 開発チーム リーダー (顧客)PO Dev Team

    SM 顧客と開発チームメンバーは 遠く離れた存在だった POとDev Teamは直接対話する (しかもフラットな関係で!) 顧客と開発チームの距離の変化