0.はじめに

対象者

「アジャイル開発」に関して全くの初心者

注意

私はアジャイル開発の経験ありません。
参考図書から説明できそうな部分を切り取っています。参考図書が伝えたいことのニュアンスが変わっているかもしれません。最終的には参考図書を読んで欲しいです。

伝えたいこと

アジャイル開発の用語
アジャイル開発のマニフェスト
概算見積は当てずっぽう

参考図書

アジャイルサムライ−達人開発者への道−

目次

アジャイル開発とは
アジャイルの見積
付録

1. アジャイル開発とは

アジャイルとは「俊敏」

アジャイルソフトウェア開発は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。

Wikipedia より引用

「agile」の意味は「俊敏」

アジャイル開発の手法

スクラム
エクストリーム・プログラミング (XP)

アジャイル開発の始め方より引用

ソフトウェア開発の3つの真実

プロジェクトの開始移転にすべての要求を集めることができない
集めたところで、要求はどれも必ずといっていいほど変わる
やるべきことはいつだって、与えられた時間と賃金より多い

参考図書 P13より引用。

アジャイル開発は、この３つの真実を受け止める必要がある。

アジャイルソフトウェア開発宣言

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。
すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

http://agilemanifesto.org/iso/ja/manifesto.html より引用。

アジャイル開発の原則

http://agilemanifesto.org/iso/ja/principles.html 参考

価値ある成果を毎週届ける

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

アジャイル原則より引用。

不要な機能は作っていないか？
客にとって不要なドキュメントを作っていないか？

リリースに備えておく

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

アジャイル原則より引用。

そのために、技術的なことも必要。

自動テストフレームワーク
- Junit
- Selenium
技術的負債を減らす（リファクタリング）
テスト駆動開発
継続的インテグレーション
- Jenkins
- Maven(ビルドツール)

チームをアジャイルにするためのコツ

同じ仕事場で働く
積極的に深くかかわる顧客の存在
- 信頼関係が大事
自己組織化
- チームで力を合わせる
- 役割に人を合わせるのでなく、人に合わせて役割を決める
- [個人的見解]「それは私の仕事ではない」と言わない
成果責任と権限委譲

参考図書 2.2章から参考

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

アジャイル原則より引用。

よくある役割分担

アジャイルな顧客

何をつくるかを決める
優先順位をつける
スコープについて厳しい判断を下す（何を作らないか）

参考図書2.3章より引用。

判断材料は開発チームが提案すべき。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

アジャイル原則より引用。

チームメンバを探すコツ

ゼネラリスト
- フロントエンドからバックエンド
- アナリストからテスタ
曖昧な状況に抵抗がない人
我を貼らないチームプレイヤー

参考図書2.4章より引用。

何かをあきらめなくてはいけないとき

プロジェクトに影響を及ぼす要素

品質：固定して考える。しかも高い水準で。最優先事項。
時間：固定して考える。何かしらをリリースする。
予算：固定して考える。追加資金要請は難しい。
スコープ：柔軟に扱う。ここを調整。

64%の機能がほとんど使われていない

無駄な機能を作っていないか、振り返ろう！！

プロジェクト期間は6カ月以内がよい

プロジェクト期間が長くなるほど、リスクは増加する。
経験的にプロジェクトの守備範囲は6カ月以内

考えてみて！

あなたの知る炎上プロジェクトは、6カ月以上だったか？
6カ月以上のプロジェクトで、炎上しないプロジェクトはあったか？

2. アジャイル開発の見積

概算見積の問題

概算見積なんて当てずっぽう
見積を未来の正確な予測として思いこむことが問題

参考図書7.1章より引用

ソフトウェアの不確実性

1/4～4倍違う。
前もって正確な見積なんて無理
初期見積で約束なんかできない

http://image.slidesharecdn.com/20110609scrumandorganizationja-110609101524-phpapp02/95/scrum-8-728.jpg?cb=1307614739 より引用

相対サイズで見積もる

人は相対見積の方がうまくこなせるらしい
ポイント制など。ポイントの単位は気にしない。
- 登録: 5pt, 表示:3ptなど
イテレーション(1週間～１か月）でこなせるポイント（ベロシティ）を計測
ベロシティを評価しながら、計画を見直す
具体的な見積方法
- 三角測量
- プランニングポーカ

参考図書7.2章より引用

3. 付録

アジャイル開発に対する批判

結構多い

参考資料

うそのアジャイル、まことのアジャイル公開用

「スクラム実践入門」技術評論社

感想

思ったことです。テキトーに流してください。

アジャイルに関する批判が結構多い。
アジャイルを無責任に広めるのはもうやめよう
やることが最初に決まっているプロジェクトならば、ウォータフォール開発でもいい？でもそれって「最初にしっかり決める」ために、結構な時間を使っていない？

考えてみて！

私たちのシステムを、お客さんはいくらで購入しているのだろうか？
その価格に見合った価値を、システムは提供できているのだろうか？
自分が「客」の立場だった場合、そのシステムを購入するだろうか？

アジャイル開発するには？

チームメンバに相談。

手段が目的になってもいいから、やってみるのはいかが？
きっと今より高い価値を提供できると思う。
顧客にどうかかわってもらうか？
技術的な問題をどうする？