アジャイルでイケてるチーム入門

アジャイル開発について
- 歴史
- 誤解
- 目指すべきところ、とにかく明日からやること

をまとめてみました。開発フローも何もかも全然わからんという人の入門になれば

Transcript

1. アジャイルでイケてるチーム入 門 Haruhiko Tano
2. アジェンダ - アジャイルが生まれた背景 - アジャイルに対する世の中の誤解 - アジャイルな状態って何？ - 明日からやること
3. アジャイルが生まれた背景 - システム開発といえばウォーターフォール - 性質上、プロジェクト開始時に予算が決まり、ステークホルダーと調整がしやすいこ とからBiz側に好まれる（ほぼ間違っているが、、、） - ウォーターフォールが悪いわけではなく、「不確実性を隠蔽する、透明性を欠く」とい う状態が問題
4. アジャイルが生まれた背景 - ウォーターフォールは論理的には正しい。ただ失敗して悲惨なことになるのは歴史 が証明している - システム開発の領域が、受託から事業寄りにシフト - 業務をシステム化→ユーザーにサービスを届ける - 不確実性が一層高くなり、最初に要件決めてもピボット前提 - そこで生まれたのがスクラム、アジャイルという開発手法
5. アジェンダ - アジャイルが生まれた背景 - アジャイルに対する世の中の誤解 - アジャイルな状態って何？ - 明日からやること
6. アジャイルに対する世の中の誤解 - アジャイル開発すれば、より早く多くのものを開発できる - アジャイルに要件、仕様はいらない - アジャイルは開発チーム内の手法
7. アジャイルに対する世の中の誤解 - アジャイル開発すれば、より早く多くのものを開発できる 一番多い誤解。ムダなものを作らない。プロセスを効率化することで早くなることはある が。作るのが早くなるというわけではない コードを書くというのは伝統芸能の職人の作業に近く、そのイメージを持つと、早く作れと いうことがズレているのがわかる
8. アジャイルに対する世の中の誤解 - アジャイルに要件、仕様はいらない アジャイルにも要件、仕様は必要。スプリント中はエンジニアはHowの部分（どう実装す るか）に集中してWhatの部分（仕様、要件など）は全く意識しないのが理想。 ウォーターフォールは最初に全てを固めるが、アジャイルは段階的に行っていくのが特 徴
9. アジャイルに対する世の中の誤解 - アジャイルは開発チーム内の手法 アジャイルにはBiz側の理解、協力が必須。コード書ける必要も、作り方知る必要もない が、どういう状態が健全なのかは理解する必要がある アジャイルは手法ではなくチームの状態のことを指す。
10. アジェンダ - アジャイルが生まれた背景 - アジャイルに対する世の中の誤解 - アジャイルな状態って何？ - 明日からやること
11. アジャイルな状態って何？ 一言でいうと自律した開発組織 自律というのは - 何を作るのかをコストを含めて自分たちでステークホルダーと調整できる - 何をどう作るのかを自分たちで決めて実装できる - 自分たちの開発プロセスを自ら改善することができる - 上記が上手くいっているかを自分たちで適時振り返り、施策を行うことができる ということ
12. アジャイルな状態って何？ ベロシティ、KPT、リファインメント、スプリントレビュー、プランニング、バーンダウン チャート、かんばん、イテレーション、ユーザーストーリー、デイリースクラム、継続的イン テグレーション これらは効果的な手法だが、やることが目的ではなく あくまで自律した開発組織を実現するためのやり方に過ぎない
13. アジェンダ - アジャイルが生まれた背景 - アジャイルに対する世の中の誤解 - アジャイルな状態って何？ - 明日からやること
14. 明日からやること いきなり全部やるのは難しいし、ぶっちゃけトップダウンでやるより、自分たちで議論して 徐々に進めていくほうが上手くいく。 まずは - タスクのバッチサイズは極限まで小さく - 成果物は常に動く状態にする - 進捗の透明化（タスクの進捗の見える化、ドキュメント化） ことの徹底から始める。
15. ご清聴ありがとうございました。