アジャイル開発について知るために「アジャイルサムライ」を読み進めていきました。第一部 「アジャイル」入門のまとめです。
- Q. 客側の立場にたつと以下のどちらが信頼できるか
- 実態のよくわからないドキュメントや設計書・計画を納品してくれる
- 短いスパンで動作する各重要パーツを成果物として見せてくれる
後者のほうが成果物が目に見える分、直感的に説得力があるし、わかりやすい。 仮にこういったスタンスで開発していくとすれば、その中で必要なことは 以下の 6 点になる。
- 大事なことだけに集中して、その他は忘れる
- 動くものを届ける
- フィードバックを求める
- 必要なら進路を変える
- 成果責任を果たす
アジャイル開発の原則
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
「完了」というのは文字通り、すべてが終わったことで、 計画書・設計書を出した段階では終わったことにはならない。 動かないソフトウェアを「どこまで完了」したとは言いづらい。 すなわち進捗管理がしにくい。
アジャイル開発では「完了」とは動くソフトウェアを届けた状態のことを指す。
アジャイル開発の原則
動くソフトウェアこそが進捗の最も重要な尺度です。
- プロジェクトの開始時点にすべての要求を集めることはできない
- 集めたところで、要求はどれも必ずといっていいほど変わる
- やるべきことはいつだって、与えられた時間と資金よりも多い
- 同じ仕事場で働く
- 積極的に深く関わる顧客の存在
- ビジネス側と開発者はプロジェクトを通し日々一緒に働かなければならない
- 自己組織化
- 当事者意識・プロダクトが動くことへの責任・自発的に働く意識
- 成果責任と権限委譲
- 職能横断型チーム
- 役割分担を決めない
- チーム内でのインフラ・フロントなどや、顧客と開発チームの役割さえも
- テストをたくさん書く
- アーキテクチャの設計と改善に継続的に取り組む(=> リファクタリング)
- コードベースをいつもリリースできるようにしておく(=> 継続的インテグレーション)
- 開発チームの成功を阻む障害を取り除くこと
- 継続的に計画を立てる、見直す、方向性を調整する
- チームまわりの人間関係を円滑にする
- マネージャ不在でもプロジェクト業務に支障が出ないようにする
メンバー内で以下のことを共有してみると良い
- 自分は何が得意なのか?
- 自分はどうやって貢献するつもりか?
- 自分が大切に思う価値は何か?
- チームメンバーは自分にどんな成果を期待していると思うか?
- ゼネラリスト
- 曖昧な状況に抵抗がない人
- 我を張らないチームプレイヤー