アジャイル開発が失敗したので勉強してみた
業務でアジャイル開発に挑戦してみよう、ということで実際にやってみたのですが、結果はよくわからないまま終了といったところで
「これがアジャイルなの?」という疑問が残ったのでアジャイル開発のセミナーを見に行ってみました。
最初に実施してみた時と勉強との差分をまとめます。
最初に実施したとき
正直な話、アジャイル開発って何?ってレベルで開始しました。
こんな感じでやってました
- タスクを細分化する
- それぞれをチケット化し毎日進捗を刈り取る
- 大きなタスクはスプリントという名前を付け、何度かに分けて開発
- リーダが担当者にタスクを分配
- タスクに短い期限を設定する
- タスクが期限内に終わらない場合は期限を延ばす
- 割り込みが発生した場合は期限を延ばす
- タスク中にやることが見つかった場合は新しくタスクを生成する
やってみて気になったこと。
- そもそもやり方あってるの?
- いまいちメリットわかんない。
- それぞれのタスクが予定期間に終わらない場合は?
勉強した内容…
そもそもアジャイル開発とは多数の軽量な開発手法群の総称であり、単体で意味を表すわけではないようです。
私はアジャイル開発という手法があるのだと勘違いしてました。。。
またウォータフォール開発は計画重視手法ですが、アジャイル開発手法は適応的開発手法と呼ばれており、変更に対して素早く適応することに主眼を置くとのことでした。
アジャイル開発では特にチームのコミュニケーションを最重要視します。これはアジャイル開発手法が短期間で動作するソフトウェアを作る必要があるためだと考えます。
アジャイル開発手法
スクラム
技術的要素が排除されており、共通のゴールを目指してチームで仕事を進める場合に適用可能なフレームワークだそうです。 主にチームのコミュニケーションを重視しています。
エクストリーム・プログラミング(XP)
従来の開発手法は全ての仕様が正しく定義されておりドキュメントとして整備されていることが必要だった。もし仕様定義後に仕様が変更される場合は変更コストがかさむため、なるべく仕様検討段階で予見しておく必要があるが現実的に全ての事象を予見することはほぼ不可能であるためしばしば失敗を引き起こしていた。
XPは従来手法の変化に弱い点に対して生み出された手法で変化を受け入れることができるような開発手法、とのことです。
XPは「5つの価値」という名称で呼ばれるXPをあらわす根幹のキーワードを掲げています。
- コミュニケーション
- シンプル
- フィードバック
- 勇気
- 尊重
また「5つの価値」とは別にやるべきことをまとめた19のプラクティスが定義されています。プラクティスとは習慣、実践の意味です。
共同のプラクティス
- 反復
→全体の開発期間はイテレーションと呼ぶ1〜2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返し、徐々に完全なシステムを構築していく。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。 このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。 - 共通の用語
→用語集を作成し、チーム全員(開発者・管理者・顧客)の使用する用語とその概念の不一致を解消する。 - 開けた作業空間
→会話しやすく、作業に打ち込める雰囲気を作る。顧客も含めて一箇所に集まって作業を行う。 - 回顧(頻繁な振り返り)
→現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。
開発のプラクティス
- テスト駆動開発
- ペアプログラミング
- リファクタリング
- ソースコードの共同所有
- 継続的インテグレーション
- YAGNI
→You Aren't Going to Need It.(必要なことだけ行う)。先を見据えて、前払い的に機能を増やし、実装を複雑化させることは避ける。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。これにより、後のイレギュラーな変更に対応しやすいようにする。シンプルで洗練され、安定性の高い機能・コードのまま、同時に将来的な汎用性も高めることは問題ないが、把握を難しくし、不安定化を招く機能・コードは、可能な限り削り落とす。
管理者のプラクティス
- 責任の受け入れ
- 援護
- 四半期毎の見直し
- ミラー
- 最適なペースの仕事
顧客のプラクティス
- ストーリーの作成
- リリース計画
- 受け入れテスト
- 短期リリース
勉強後に変わったこと
「やってみて気になったこと。」で記載したことをそれぞれ補足
そもそもやり方あってるの?
- 全ての機能を実装していたのでなんちゃってアジャイルになっていた。
→ 本来であれば実際の使用ユーザと密にコミュニケーションし、機能を修正したりエンハンスしたりする必要があるが、開発終了後にユーザに提供していた。。(今見返すと全くアジャイルじゃないですね笑) ] - タスク化はしたが、ユーザ側の操作単位ではない感じであった。(ストーリーになってない)
- タスクを分配する際にリーダが割り振っていた。
→各自の主体性は低かった。 - また主要部分は2人で開発していたのであまり効果がなかった。
いまいちメリットわかんない。
→あまり実装する機能に変化が生まれない状況だったのでメリットがなかったと思われる。
実装する機能が刻一刻と変化する場合や機能の取捨選択が可能な(理解のある)契約であれば「実装機能に対して柔軟に対応できる」メリットがありそう。
それぞれのタスクがイテレーション中に終わらない場合は?
ここはちょっと見つからなかったので推測になりますが…
重要度の高い機能であれば次のイテレーションでも継続して実施する必要があると思います。
ただしなぜ終わらなかったのか、は必ずイテレーションの最後のレトロスペクティブ(振り返り)で原因を特定し次回のイテレーションやプロジェクトでは同じことにならないようにすべきと考えます。
ちなみにどういったケースでこういった事象が起こるのかを考えてみました。
- タスク分割の粒度が大きすぎる
- 各自のスキルがタスクに対して足りていない
- タスクに対して過剰に設計している
- 開発者に過度な割り込みが発生している
それぞれの対処法を検討してみると以下のようになりました。
- 原因はタスク分割の経験が少ないだけだと思いますので、イテレーションを経験するごとに正確なタスク分割ができるようになるはず…。とりあえずそのまま続けてみる。もちろん振り返りを行いながら全員で タスク分割の経験値を積む必要がありますね。
- 原因はスキル不足なので、チーム内に有識者がいれば教えてもらう。もしくは次のイテレーションで実装する機能を落として学習してもらう時間を設ける。といった案を思いつきました。
- これは開発者の意識の問題なのでプロジェクトリーダーからアジャイル開発の思想を伝えることが必要かもしれません。(もちろん、より良いものを作りたいという気持ちは大事ですし、わかります…。)
- 基本的にイテレーション中は割り込みを発生させないのがアジャイル開発の大前提ですが、そうはいっても仕事なのでなかなか難しそうです。。ここはプロジェクトリーダーが何とかするしかないのか…といったところです。ちょっとマネージの経験が無いので何も思いつかないのが悲しいところ。。。
対処法がわかったら追記します。
初記事はまずタイトル通り備忘録ということでアジャイル開発について勉強したことをまとめてみました。 ざっくばらんですがまた覚えたことがあったら追記しよう。
うーん、ブログを書くのがmixi(古い)ぶりで全く書けない…笑
単語帳
以下、忘れそうな単語をメモっておく。
ストーリー
ユーザから見た機能をストーリーと呼ぶ。
誰が何をどうしたら何がうれしいのか、をまとめる。
イテレーション
開発サイクルの単位でスクラム開発ではスプリントと呼ぶ。1~4週間で設定されることが多い。 イテレーションが終わるタイミングでは動作する物が作成されていないといけない。
リリース
実際に製品をユーザに使ってもらう段階。 これはビジネス要素が強いので顧客側が主体となる。 3ヵ月で設定されることが多い。
レトロスペクティブ
いわゆる振り返り。
イテレーションの最後に実施する。
よかったことと悪かったことをメンバで洗い出し、次回のイテレーションでよかったことは継続、悪かったことは改善し組み込む。
スパイク
見積もりのための調査や開発。