freks blog

about

「いちばんやさしいアジャイル開発の教本」を読んだ

案件で Agile っぽさを取り入れて毎月?円で進めていきましょうというプロジェクトをやっていたのですが、お客さんを巻き込めず失敗したので いちばんやさしいアジャイル開発の教本 人気講師が教える DX を支える開発手法 - インプレスブックス が Prime Reading で読めたので読んでみました

以下、読んだときのメモです
メモでなにか引っかかるものがあると、この本を読んでみるといいのかもしれません

読書中のメモ

売り切り型のソフトウェア開発から徐々に改善していく開発へ
使われ方をみて改善していく

机上の空論でなく実際に動くものをみて判断していく
開発したのに使われないを防ぐ、動くソフトウェアがないとそれに気づきにくい
ソフトウェア開発の不確実性、コミュニケーションの不確実性を早くクリアしていく

[https://agilemanifesto.org/iso/ja/manifesto.html アジャイルソフトウェア開発宣言]

Why agile?を説明する必要がある
開発された 6 割の機能が使われない話をすると効果ある

仮設、検証を繰り返す
MVP を作って確認していく
コミュニケーションをして改善、ビジョンを共有することが重要

  • クライアントと開発者
  • 開発者同士

ときにはピポットも必要
それぞれが自立した開発者が必要、自己組織化チーム

YAGNI、KISS で作る

チームの共通理解を育む

インセプションデッキ

  • Why、How を明らかにする
  • 外部からチームの期待を可視化

ドラッカー風エクササイズ

  • チーム内部の期待の可視化
  • 何が得意か、どう貢献するか

ワーキングアグリーメント

  • 約束事

反復的な作成物レビュー
1 ~ 2 週間ごとに作成する

タスクの見える化する

スプリントバックログをつくる

  • 優先順位
  • 見えてなかったタスクを可視化
  • わかったことを可視化

やっているタスクを可視化

  • タスクボード

プランニングポーカー

  • タスクを大きさを見積もり

スプリントの終わりには振り返りをする
気づきを共有する
KPT をする

朝会が形骸化してしまったら
ミーティングを開催することが目的に、朝会が時間の無駄に感じると...
問題を小さいうちに改善すべき

放置されたタスクが多くなったら
四半期ごとに棚卸ししてみるなど

請負契約でなく準委任契約がいい

アジャイル開発は、探索して価値を見つけていくのが狙い
見積もりは着地点があって見積もれる
要件がすべてできってないのに見積もりできない

大きな計画、小さな計画、その日の計画を作る

まとめ

アジャイルっぽくやるのに失敗した案件の原因がなんとなく整理できました
従来どおりのやりかたにそまっている人を説得するのは大変そうですが、使われないソフトウェアを作るのはやるせないのでチャレンジしていきます