わかりやすいAgile開発の教科書はお勧めです

「わかりやすいアジャイル開発の教科書」を献本して頂き、じっくり読んでみた。
アジャイル開発を実践する時に最初に参考にするガイドブックとして使えるのではないかと思う。
感想を箇条書きでラフなメモ書き。

【1】アジャイル開発が目指すものは何なのか、というWhyを説明してくれている。
アジャイル開発そのものを自己目的化しないためにも必要。

【2】ソフトウェアの価値とは何なのか？
この部分は、日本のIT業界が遅れている所だと思う。
理由は、受託開発案件が多いために、プロジェクトを納期までにとにかくCloseさせることに精一杯であり、納品したソフトウェアやシステムが顧客に役立っているのか、という観点まで頭が回らないから。

普通は、１次開発で赤字を出しながらも何とか本番稼動させて、２次開発や運用保守で、顧客の業務と実システムの不一致や、業務の改革まで目を向けるようになる場合が多いように思う。
本来は、システム導入によるIT化によって、ユーザ企業の業務改革に役立てたいのだが、肝心のシステムを稼働する品質に持って行くのが、現場ではとにかく大変なのだ。
アジャイル開発はその問題への対処の一つとしてあげられているわけだ。

では、価値づくりのプロセスとして具体的にどのようにやれば良いのか？
「わかりやすいアジャイル開発の教科書」では、要求開発におけるコタツモデルを参考にしながら、経営者・IT技術者・業務担当者の観点で、あるべきシステム像を見出そうとしている。
この考え方はなるほどと思う。
但し、立場が異なる３つの組織を束ねて何らかの結論を導く必要があるから、高度なファシリテーション能力やマネジメント能力が必要とされるだろうと思う。

【3】「わかりやすいアジャイル開発の教科書」で面白いのは、実体験に基づいた事例がふんだんに紹介されている点だ。
著者の方の深い経験がすごく感じられる。

「価値が分からないストーリーカード」は要件定義に慣れていない人がはまりやすいアンチパターン。
技術者という立場を離れて、顧客の立場で考えることができるか、という点が大切。

「タスクカードの書き方がバラバラ」も、プロジェクト管理やタスク管理に慣れていない人に多いアンチパターン。
どんな作業をして欲しいのか？
アウトプットは何なのか？
作業しやすいタスクの粒度に注意しているか？
この辺りは、チケット駆動開発を実践しているととてもよく分かる部分。

「％マジック」もありがちなアンチパターン。
ウォーターフォール型開発では、１機能の進捗を工程別に％で計算する時が多い。
特に工事進行基準でプロジェクトの売上計上を実施しているなら尚更だ。
９０％まで終わりました、と報告を受けたのに、いつまで経っても作業が完了しない場合が多い。
アジャイル開発の観点では、いくら設計書を作ったとしても、プログラムを書いたとしてもテストしていなければ、動くプログラムがなければ進捗はゼロに等しい。
チケット駆動開発を実践していると、ワークフローをどのように決めて運用するのか、という問題に置き換えられるだろう。

「サインアップの注意」としては、本来は、担当者自らタスクを取りに行くハッピーサインアップであるべき。
とは言え、プロマネの立場としては、プロジェクト運営上、役割が漏れていないタスクがないか、常に確認する必要はある。

「KPTが飽きられた」ケースもよくある。
チームで毎週いくら問題を出したとしても、問題が解決されて問題が減らないと成長している実感が無い。
KPTが上手く回っている時は、Problemにあがった問題に対し、Tryでいくつかの解決案が提示されて、実際に実行した結果、解決されて、そのノウハウがKeepに入り、最後は暗黙知としてKeepから消える。
KPTを上手く回すには、チームに変化や成長が必要だと思う。

「ペアプロがトレーニングになってしまう」場合もよくある。
特に、ペアの二人の能力差が大きい場合は特にそうだ。
だから、ペアを固定せずに、チームメンバー全員に技術ノウハウや業務ノウハウが共有されるようにどんどん回すべき。
ソフトウェア開発では一人で作業することはほとんどなく、ペアプロや本番リリース作業の立会のように同一時間帯に同一の場所で二人で作業するときもあれば、コードレビューや受入検証のように非同期で二人が成果物を作ってチェックし合う(ペア作業)時もある。
ペアプロやペア作業を意識してチームに浸透させれば、メンバーの作業の能力が平均化されるため、トラックナンバーが１となるリスクを減らすことができるし、ジョブアサインの選択肢が増えるのでプロマネとしても助かる。

【4】第４章「アジャイルを現場に定着させよう」の部分は、ファシリテーターとしてチーム運営する時に役立つノウハウが詰め込まれている。
アジャイル開発の面白さは、TDDやCIのような技術面と、チームビルディングの観点があると思う。
各メンバーの専門能力を組み合わせて、チームをいかに有機的に形成していくべきか、という手法について、アジャイル開発にはたくさんの事例が今までたくさんあげられてきた。
プログラマ出身のプロジェクトリーダーやプロジェクトマネージャにとって、最も役立つ部分ではないだろうか？

「わかりやすいアジャイル開発の教科書」を最初に読んだ時、読者層は開発者が対象と思ったけれど、何度も読み直すうちに、現場リーダーが本来読んで欲しい対象なのかな、と気づく場面が多かった。
色んな人が、自分の役割や立場の観点で読めるのだろうと思う。
また、チケット駆動開発をアジャイル開発のタスク管理の事例としてあげられていたのも嬉しかった。

個人的には、「わかりやすいアジャイル開発の教科書」に描かれている絵が可愛いので、内容が難しくない印象を受けるのも良い点になるかなと思う。