アジャイル?スクラム?
質問
アジャイル開発とは?
スクラムとは?
アジャイル開発とは
アジャイルソフトウェア宣言
「いままで」のことに価値はある事を認めつつ、「これから」のことにより価値を置く。
アジャイル開発とは
アジャイル開発が必要とされた理由
1. ソフトウェアの大規模化・複雑化
- ソフトウェアは本来、設計と製造工程が分かれる性質のものではない
- 製造業や宇宙開発で用いられたプロセス管理をそのまま転用してしまった
- その結果、実際に価値のあるソフトウェアの実装よりも、関係調整やドキュメント作成といった工程に時間を使い、複雑性の解消よりも、複雑性の管理に時間を使うプロジェクトが増えてしまった
- この結果、完成品と顧客が求めていたものとの差が大きくなってしまった
アジャイル開発が必要とされた理由
2. マーケットの不確実性への対応
- 開発したソフトウェアは「マーケットで受け入れられるかどうか」が大事
- ソフトウェアは政府や大企業が使うものから、一般の人々が使うものになった
- その結果、マーケットがプロジェクト期間中に大きく変動するする事も頻繁に起こるようになった
- 時間と費用をかけて開発したにも関わらず、それがマーケットニーズに合うかどうかは最終工程にならないと分からないという事を避けたいと思う企業が増えた
アジャイル開発に対する誤解
誤解1 アジャイル開発は決まったプロセスである
典型的な発言
ウォーターフォールかアジャイルか、うまく使い分ける必要があるよね
- アジャイル開発は、アジャイルチームを作るための方法論で、軽量開発プロセスの総称
- 「アジャイルなチーム」を作りながら、ウォーターフォールで意識させるスケジュール不安を中心に対応するプロセスや文化を作る事も可能
アジャイル開発に対する誤解
誤解2 アジャイル開発では設計をしない
典型的な発言
アジャイルには反対。ちゃんと設計しないと駄目だし。
- アジャイルでも設計は必要
- チーム内での認識共有のために設計書を書くのは有り
- ただし、設計書よりも動くソフトウェアを重視する
- そのため、設計だけでは進捗とみなさない
アジャイル開発に対する誤解
誤解3 アジャイル開発には優秀なメンバーが必要
典型的な発言
うちのメンバーは優秀じゃないので、アジャイルはできない
- アジャイル開発はチーム運営、組織学習のプロセス
- 最初からうまくいく組織は少ない
- 出てくる問題を解決していく事で、個人が成長しアジャイルなチームに近づいていく
アジャイル開発に対する誤解
誤解4 アジャイル開発では中長期計画がない
典型的な発言
アジャイルだから、計画しなくてもいいんでしょ
- 中長期計画を立てられないという訳ではない
- 不確実性が高い中では中長期計画を立てる事にさほど意味がない、と意思決定する事はある
- チームは計画が変化したときに、それに合わせて柔軟に動いていく事が重要
アジャイル開発に対する誤解
誤解5 アジャイル開発は開発者に決定権がある手法だ
典型的な発言
アジャイルにすると開発者が好き勝手に開発するんでしょ
- アジャイルなチームは、プロダクトの顧客ニーズやビジネス価値について深く理解するようになる
- そのため、ビジネスサイドはより抽象的で不確実性の高い段階で、要求を定義できるようになる
- このような関係性の中で、開発に関わる意思決定が開発側に徐々に委譲されていくことになる
アジャイル開発に対する誤解
「アジャイル開発」を開発手順や開発フローのような「手続き」の進め方として認識される傾向があるが、実際は「チーム全体に対してメンタリングを行い開発効率を向上させる方法論」
✕ 「開発手法はアジャイルでやる」
◯ 「アジャイルなチームになる」
アジャイルなチーム
- 情報の非対称性が小さい
- お互いの認識のずれが小さい
- 認知の歪みが少ない
- 感情や思い込み、心理的な仕組み等(認知的不協和など)による不適切な判断・行動が少ない
- チームよりも小さな限定合理性が働かない
- 自分にとって良い事かではなく、チームにとって良い事かを優先する
- 対人リスクを取れていて、心理的安全性が高い
- 発言が自分のキャリアやステータス、イメージに悪影響を与える恐れを感じずに、自分を表現できる
- アットホーム、食事をする、よく会話する ≠ 心理的安全性が高い
- 課題・不安に向き合い不確実性の削減が効率良く出来ている
- プロジェクトの目的や、実現方法の不確実な部分を効率良く削減している
- チーム全体のゴール認識レベルが高い
アジャイル(なチーム)になるメリット
アジャイルになるメリットは色々と書かれますが、一言で言えば「不確実性に向き合えるようになる」という事です。
人にとって不確実なものは「未来」と「他人」
不確実なものは実際にやってみて知識を得ようとする考え方がアジャイルの基本的な発想
アジャイル(なチーム)になるメリット
よく言われるようなメリット
- 変化に対して柔軟に対応できるようになる
- 顧客満足度が向上する
- 開発者、チームが成長する
アジャイル開発の手法
アジャイル開発の手法(スクラム)
スクラムガイド 表紙等を抜くと僅か13ページの公式ガイド
- アジャイル開発をする上で、現在最も流行っている手法
- まずスクラムガイドを読んで理解する事が大事(読まずにスクラムをやっている会社も多々ある)
- スクラムはあくまでフレームワークなので、自社に合った形でカスタマイズも可
注意点
- テストの自動化は出来れば必須
- 個人、組織の意識改革も必須
アジャイル開発の手法(スクラム)
アジャイル開発の手法(その他)
XP(エクストリームプログラミング)
リーン開発
何か色々あるけど、とりあえず情報量的にもスクラムで良いんじゃないかな。
質問
プロジェクトマネジメントとプロダクトマネジメントの違いとは?
プロジェクトマネジメントとプロダクトマネジメント
プロジェクトマネジメント
- プロジェクトには「はじめ」と「おわり」がある
- QCDを満たしてプロジェクトを「終わらせる」ことが目標
- Q(クオリティ:品質)、C(コスト:費用)、D(デリバリー:納期)
- 最大のリスクは「終了しないこと」。つまり納期を超過して完成の目処が立たなくなること
プロダクトマネジメント
- プロダクトが継続的に収益を上げて、損益分岐点を超え「終了しないこと」が最大の目標
プロジェクトマネジメントとプロダクトマネジメント
プロジェクトマネジメントとプロダクトマネジメント
参考文献
このスライドは、以下2冊の本のお世話になりました。
End of Contents
Author And Source
この問題について(アジャイル?スクラム?), 我々は、より多くの情報をここで見つけました https://qiita.com/roi-dev/items/e6a96d4766e6739e3014著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .