もし、ソフトウェア業界におけるソリューション開発の現在の能力よりも、市場がより早い変化を必要としている、という前提を認めるなら、「そのために何ができるだろうか？」という問いを持つことになるだろう。私にしてみればその答えは、アジャイルだ
アジャイルは使える – そして、スケールアップ可能であるという結論までを語る本。原書はScaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series)
社内の先輩が「面白い本を見つけたので読書会をしようと思う」という話をしてくれた。
その方はマネージャになるのだけれど、データ分析とかが得意なアーキテクトでもあり、
「この人が開催する勉強会は面白い」と思って、「絶対面白いからやりましょう」と伝えた。
それから、数か月がたち、今月で勉強会も終わりを迎えようとしている。
最初は20名ぐらいの参加者だったけど、今は、数人になってしまった。
でも、毎回、とても面白いディスカッションができていて、勉強会の価値はあったんじゃないかな。
自分は、「スクラムの本質」で、自分のチームのスクラム部分を話したり、
「継続的インテグレーション」で、CIサーバ環境を作り、その結果成功したチームと失敗したチームの事例紹介をした。
中でも、CIサーバは、その環境にのせて流れに乗るまでがつらいようで、
わずか数件のチャレンジでありながら、％でいうと25％しか成功しなかった。
そこで学んだのは、「導入して流れをつかむまではサポートがいる」ということ。
まず、驚いたのが、「テストを作りメンテナンスしていく」ことができない人が75％もいることだ。
さらに、「テストを書いたこともない」という人もいるのにはびっくりした。
よって、サポートとして、テストの作り方や、テストのメンテナンスなど、テクニカルな面が必要になることがわかった。
また、一部チームからは「CIに登録しただけで、その後サポートがない」というFBももらった。
誰もが、CIの魅力には飛びつくが、いざ自分がやるとなると、そこまでコストを割いてくれないという
悲しい現実を知った。
最終的には「現場が続ける」必要が出てくる。そういったチームは、「誰かがテストをしてくれる」という感覚で
サポートを求めるので、丁重に断っていった。
アジャイル開発のスケールアップは本当に難しい。
以下、気になったワード。
- テストと品質保証の組織もまた大きく変わる
- アジャイル開発では、継続的、並行的、早期にテスト
- アジャイルマニフェストの原則には「最善のアーキテクチャは自己組織化されたチームから浮かび上がるとあるが、アーキテクチャはアジャイルチームにとって非常に重要
- ↑のような自然発生するアーキテクチャを「ローカルなアーキテクチャ」と著者は読んでおり、システムレベルのアーキテクチャとわけて書かれている
- 「ローカルレベル＝協調的に自然発生」「システムレベル＝システム全体として、システムアーキテクト、ビジネスアナリストが決定」
- アジャイルコンポーネントチームは、開発者、テスター、プロダクトオーナー、アジャイルマスター or スクラムマスターという構成になり、そのチームの外にアーキテクトやQA担当（全体を統括）が存在する（これは案かも）
- 正しい方向に方向付けられる必要があり、リーダーシップ不在ではなく、リーダーシップのそのスタイルに特徴がある。管理されているのではなく、リードされている形
- 定量的評価例
- 居てレーションに入れたストーリーの数と達成したストーリーの数
- ストーリー受け入れ率
- 却下されたストーリーの数
- 延期されたストーリーの数
- 次のイテレーションにずれこんだストーリーの数
- 追加されたストーリーの数
- テスト数、カバレッジ、バグ数
- 自動化されたテストの率
- うまくいったこと
- うまくいかなかったこと
- 独立している（Independent）
- 交渉可能（Negotiable）
- 価値がある（Valuable）
- 見積もり可能（Estimatable）
- 小さい（Small)
- テスト可能（Testable)
- 概観、評価、そしてパイロットの準備（やはり成功例から広めるのがはじめやすい模様）
- パイロットでは、スクラムマスタートレーニング、プロダクトオーナートレーニング、指標を確立・・・とすすめる
- 組織への展開で、トレーニング、アジャイル関係の読み物の提供、体験記などのFBを行う
- アジャイルプロセスアセスメント指標を作る
- バックログの管理ができているか？
- リリース計画はできたか？
- ビルドは成功し続けているか？などなど、アジャイル開発の流れを再確認してレーダーチャートにする
- レーダーチャート：プロダクトオーナー、リリース計画作りと追跡、反復計画作りと追跡、テストプラクティス、プラクティスやインフラの開発などの視点で作る
| テスト駆動開発入門 | |
 | ケント ベック Kent Beck ピアソンエデュケーション 2003-09 おすすめ平均 |
翻訳が残念
リファクタリングって何あとで読もうと思うTDDの指南書
