3-11 アジャイル開発って？

ソフトウェア開発でよく用いられ、DXなどの文脈でトレンドとなっているアジャイル開発。アジャイル開発は価値観であるというところに立ち戻りつつ、その特徴について話しています。

0:15 新年のご挨拶、1:05 アジャイルがトレンド、2:22 プロジェクトでの困りごと、5:30 アジャイル開発とは、10:53 アジャイル開発の特徴、20:30 プロジェクトの困りごとに対するアプローチ、27:30 銀の弾丸ではない

プロジェクトで困ることは？

マサトの経験
- タスク進捗管理の形式、設定する会議の種別などが曖昧な場合、担当者としては報告の内容に困る。
- Trello （チームの進捗管理ツール）などを使って管理しようとしているが、メンバの中でTrelloの形式に慣れていない人がいると、やりやすさに差が出てしまって結果的にうまく管理が行き届かないように思う。
- プロジェクトの進め方について十分にコンセンサスを得られていないかも？エンジニアリング会社のIT部門に属しているため、従来のエンジニアリングのプロジェクトマネジメントに慣れた人には、Trelloなどの進め方に慣れるのに時間がかかるのかもしれない。
その他、想像ですが・・・
- 実行
  - 計画どおり進まない
  - 進まない原因がわからない、分析できない、わからない
  - 原因を分析する取っ掛かりがわからない、観点がわからない
- 計画
  - 計画、マイルストンの立て方がわからない、いけてない
  - そもそも計画を立てるときのゴールがわからない
- チーム
  - 責任の押し付け合いが発生する

アジャイル開発 Agile software development：これは価値観！
- Waterfallなど計画に重きを置く開発手法（重量ソフトウェア開発手法）に対抗
- Agile Manifesto ( https://agilemanifesto.org/ https://agilemanifesto.org/iso/ja/manifesto.html )
  - プロセスやツールよりも個人と対話を
  - 包括的なドキュメントよりも動くソフトウェアを
  - 契約交渉よりも顧客との協調を
  - 計画に従うことよりも変化への対応を
- Agile software development principles：12の原則
アジャイル開発の具体的な手法として Scrum や XP (Extreme Programming)、Kanbanなどがある。※次回でScrumを取り上げます！

マサトの悩みは、メンバ間での上記の価値観が違うことに起因するのかもしれません。

前提：事前に全てを正確に予測し、計画することはできない <=> predictive でなく adaptive
方法（参考：Agile Software Development (Wikipedia) ）
- Incremental：少しずつ作る、計画、設計、実装、テストを行って実際に動作するものを一歩ずつ作る
- Iterative：反復する = 計画、設計、実装、テストの一連を反復する
- Evolutionary：デモを通じてstakeholderからfeedbackをもらい、計画を見直す
効果：リスク低減、変化するニーズへの素早い対応、早い市場投入
注意：cross-functionalなチームが必要となるため、メンバにinterpersonal skillが必要。自己組織的なチームを作ることが目的の一つであり、チームワーク、顧客との協調を重視。

計画がいけてない、ゴールが不明なら・・・そもそも計画する意味はあるか？変化が多い、不明なことが多いなら、アジャイル開発を用いてみては？
計画通り進まないなら・・・Scrumのスプリントなどでvelocity（決まった期間内にこなせるタスクの量）を測ってみては？
メンバ間で責任の押し付け合いがおきているなら・・・チームワークを重視するアジャイル開発を試してみては？ただしinterpersonal skillなどに対するtrainingを忘れずに。

プロジェクトをどの形式で進めるか、はArchitectural Decisionsの一つと捉えられると思います。

開発者が地理的に分散している場合、上手くコミュニケーションをとらないとチームが維持できない。
動作するものを少しずつ作れないのであれば、素早くfeedbackを得られないため、アジャイルは向かない。リスクマネジメントに重きを置いているスパイラルアプローチや、VでなくW-shapeなどの適用を検討してみては？
そもそも、要件がある程度明確（スコープ、コスト、スケジュール）なのであれば、計画したほうが良い。
人命にかかわるなど、要件の中でとても重要視されるものがある場合、アジャイルではなく計画したほうが良い。
大人数が関わるプロジェクトでは、上手くスケールさせるために仕組みが必要。例：scaled agile
参考：Wikipediaに落とし穴の例が取り上げられています https://en.wikipedia.org/wiki/Agile_software_development