アジャイルとスクラムによる開発手法
Azure DevOpsによるプロフェショナルスクラムの実践
著：Richard Hundhausen
他訳：福竹裕昭
他訳：小川雄太郎
出版社：マイナビ出版
Azure DevOpsをつかった、アジャイル・スクラムの解説書
アジャイルという恐ろしい開発手法のテキスト
アジャイルって、短期間で、要件定義からシステムテスト、リリースをくり返す、小さな連続したウォータフォールとおもっています。
一部を段階的にリリースするようなシステムには向いているけれど、基幹システムのように一括してリリースするようなシステムにはアジャイルはつかえない。
ウォータフォールならば、SEは要件定義と設計をして、PGは開発と分化しているのだけれども、アジャイルって要件定義から開発、テストまでを全部自分でこなさなければならない、何でも屋だ。
だから、PGあがりのメンバーは、なれない要件定義や、基本設計をやらなければならない。
向いていない子は、脱落していくが、はしっこい子は、全工程を短時間で何回も回せるから成長が早い。
もっとも、まとめて、２カ月に１度、リリースするけど、スプリントは、２週間みたいなこともあるようですけれど。
登場人物
プロダクトオーナー 出資者
スクラムマスター 親方、マネージャー
開発者＝メンバー 多くて９名
プロダクトバックログ 開発対象の機能の一覧
ブロダクトバックログアイテム １つ１つの機能のことをいう PBI
スプリント 開発期間 通常は、１週間から１カ月程度
スプリントプランニング 最初の計画 ここから開発対象となる プロダクトバックログを選定する
デイリースクラム １日１回メンバーがあつまって行う打ち合わせ
スプリントレビュー 成果物の検査
スプリントレトロスペクティブ スクラムが終了した時点での振り返り
機能では、
１週間で完成 規模小
２週間で完成 規模中
４週間で完成 規模大
といった機能だと、期間が２週間だと、４週間もかかるバックログはつみのこされてしまう
みんなでプログラミングという手法が紹介されている
・スウォーミング 特定PBIがおわるまで複数のメンバーが集中対応する
・ペアプロ ２人のメンバーが１つのタスクに蜜に協力して対応する
・モビング すべてのメンバが特定PBIが終わるまで集中対応する
テスト、特に回帰テスト
皆が、いろんな改修をやりながら開発をしていくわけなので、デグレードが発生することもあり、回帰テストを何度も行わなければならない。その手間を防ぐために、DevOpsというツールを盛り込んでいる 開発と運用の一体統合ということだ。それを実現するために、CI/CD：ビルドテスト・デリバリの自動化、継続的デリバリで、テスト工程に自動化ツールを仕込んでおく。 GitHub,Jenkins、GitHub Actions、CircleCI 等
非機能テストでは、負荷テストに、Jmeterなどもつかっている
PBIはすべての工程を通り抜けたものでなければ完成しない
本書では、テストはあまり重視していないが、結果を残さなくていいのだろうかとおもってしまう
プロジェクトの見える化
・タスクボード
・かんばん
・スループット
ホワイトボードに、ぺたぺたと、ポストイットが張っているあれである
進捗の数値化、見える化と、着地予測は、プロジェクトの常である。
最終章に、大規模プロフェッショナルスクラムなるものがあり、最先端のアジャイルかなと思う
複数のアジャイルマスターがあつまって対応する
結合時のテストなど、デグレードなどどうするのかとおもってします。
うまくまわっていればよいが、どこかが崩れたら、どういうリカバリーをかけるのか、想像もつかない
目次
発刊によせて Foreword
翻訳者まえがき
イントラダクション
第1部 スクラムの基礎（Scrumdamentals）
第1章 プロフェッショナルスクラムとは
第2章 Azure DevOpsとは
第3章 Azure Boardsとは
第2部 プロフェッショナルスクラムの実践
第4章 プリゲーム（Pre-game）
第5章 プロダクトバックログ
第6章スプリント
第7章 テスト駆動型計画
第8章 コラボレーション
第3部 改善手法（Improving）
第9章 フローの改善
第10章 継続的改善（Continuous Improvement）
第11章 大規模なプロフェッショナルスクラム
索引
原著者紹介／翻訳者紹介
