案件で Agile っぽさを取り入れて毎月？円で進めていきましょうというプロジェクトをやっていたのですが、お客さんを巻き込めず失敗したので いちばんやさしいアジャイル開発の教本 人気講師が教える DX を支える開発手法 - インプレスブックス が Prime Reading で読めたので読んでみました
以下、読んだときのメモです
メモでなにか引っかかるものがあると、この本を読んでみるといいのかもしれません
売り切り型のソフトウェア開発から徐々に改善していく開発へ
使われ方をみて改善していく
机上の空論でなく実際に動くものをみて判断していく
開発したのに使われないを防ぐ、動くソフトウェアがないとそれに気づきにくい
ソフトウェア開発の不確実性、コミュニケーションの不確実性を早くクリアしていく
[https://agilemanifesto.org/iso/ja/manifesto.html アジャイルソフトウェア開発宣言]
Why agile?を説明する必要がある
開発された 6 割の機能が使われない話をすると効果ある
仮設、検証を繰り返す
MVP を作って確認していく
コミュニケーションをして改善、ビジョンを共有することが重要
ときにはピポットも必要
それぞれが自立した開発者が必要、自己組織化チーム
YAGNI、KISS で作る
チームの共通理解を育む
インセプションデッキ
ドラッカー風エクササイズ
ワーキングアグリーメント
反復的な作成物レビュー
1 ～ 2 週間ごとに作成する
タスクの見える化する
スプリントバックログをつくる
やっているタスクを可視化
プランニングポーカー
スプリントの終わりには振り返りをする
気づきを共有する
KPT をする
朝会が形骸化してしまったら
ミーティングを開催することが目的に、朝会が時間の無駄に感じると...
問題を小さいうちに改善すべき
放置されたタスクが多くなったら
四半期ごとに棚卸ししてみるなど
請負契約でなく準委任契約がいい
アジャイル開発は、探索して価値を見つけていくのが狙い
見積もりは着地点があって見積もれる
要件がすべてできってないのに見積もりできない
大きな計画、小さな計画、その日の計画を作る
アジャイルっぽくやるのに失敗した案件の原因がなんとなく整理できました
従来どおりのやりかたにそまっている人を説得するのは大変そうですが、使われないソフトウェアを作るのはやるせないのでチャレンジしていきます