『実践アジャイルテスト』第03章のコメント・疑問
第2部 組織的なチャレンジ(P35)
第3章 文化的なチャレンジ(P37)
3.1 組織の文化(P37)
3.1.1 品質の考え(P38)
P.38 「・・・、当初の想定通りうまくいかなかったことに対して、振り返られることはありませんし、・・・」 レトロスペクティブは重要です！ (Ｙｏｕ＆Ｉ)
「品質の番人」！品質保証部門が開発部隊から嫌われる大きな理由のひとつですね！（ヤマモト）
「後知恵を出す立場から、チームの一部という立場に変わる」ことがアジャイルになるということ、でしょうか。（ヤマモト）
P.39 「プログラマにコーディング標準に従うように強制させる」 第30回名古屋アジャイル勉強会での角谷信一郎さんのお言葉：
「アジャイルは自己組織的、管理されたければサボれ」はとても印象深いお言葉でした。 (Ｙｏｕ＆Ｉ)
P.39 「スキルと適応性」 アジャイル開発をするには、今まで通りでは、ダメ。ゼッタイ。チームのメンバーにも新しいスキルを身につける等の変革が必要となる。 (Ｙｏｕ＆Ｉ)
P.40 「こういった人たちはアジャイルプロジェクトの中で生き抜くことだけでなく、・・・」 普通は出来ても出来なくてもずっとプロジェクトに居続ける事が多いと思う。 (Ｙｏｕ＆Ｉ)
P.40 「メンター」 アジャイルメンター(agile mentor)とは、優れた指導者の事。アジャイルコーチとの切り分けとしては、コーチはチームの外から見守る。メンターはチームの中で先導役を行う。
参考：永和システムマネジメント アジャイル組織導入 (Ｙｏｕ＆Ｉ)
3.1.2 持続可能なペース(P40)
P.40 「組織によっては業務を測るために残業時間を見ます」 残業時間を見ているのにチーム内での残業時間格差はなんなんでしょうね。 (Ｙｏｕ＆Ｉ)
従来のテストはプロジェクトの後半に急いでどたばたと行われてきた。それに対してアジャイルプロジェクトでは、ストーリーやタスクはそれに着手したイテレーションの初期からテスト化されるなど、テストは常時進められていると言えるでしょう。結果として、持続可能ギリギリのペースでプロジェクトが進められるのかな、と思います。（ヤマモト）
3.1.3 顧客との関係(P41)
「アジャイルチームは顧客と共同作業し」ます。これ重要。（山本）
P.41 「顧客と開発チームの関係は、ベンダーとサプライヤーというより、パートナーシップの関係です。」 こうありたいですね。 (Ｙｏｕ＆Ｉ)
3.1.4 組織の大きさ(P42)
組織が大きくなれば運営は難しくなりますが、意識的にコミュニケーションを活性化しましょう、ということでしょうか。（ヤマモト）
3.1.5 チームの能力を高める(P43)
チームに決定権を与え自由に行動させることによって、チーム間でコンフリクトが発生した場合の調整は？
⇒これは管理者の役割ですよね。（岩井）
3.2 テスト/QAチームがアジャイルに適応するための阻害要因(P43)
3.2.1 アイデンティティの喪失(P44)
新しいやりかたに戸惑いを覚えること。（ヤマモト）
3.2.2 追加の役割(P44)
必要な技能に関するエキスパートがいないこと？（ヤマモト）
3.2.3 トレーニング不足(P44)
3.2.4 アジャイルの概念の理解不足(P45)
アジャイル開発を「ミニウォーターフォール」と理解するのは誤りとありますね。設計・実装が作りっぱなし、テストはコードに対して受身に行われるだけ、といった状態を戒めているのでしょうか。（ヤマモト）
→従来的にテスターが設計時点から絡まないで作業を進めてしまう事かな思いました。 （Ｙｏｕ＆Ｉ）
P.45 「アジャイル開発には、XP、Scrum、Crystal、FDD、DSDM、OpenUPやそれら複合など多くのアプローチがあります。」 この辺の違いをちゃんと押さえた事が無いですね。（Ｙｏｕ＆Ｉ）
共同のプラクティス(反復、共通の用語、開けた作業空間、回顧（頻繁な振り返り）)
開発のプラクティス(テスト駆動開発、ペアプログラミング、リファクタリング、ソースコードの共同所有、継続的インテグレーション、YAGNI（今必要なことだけ行う）)
管理者のプラクティス(責任の受け入れ、援護、四半期毎の見直し、ミラー、最適なペースの仕事)
顧客のプラクティス(ストーリーの作成、リリース計画、受け入れテスト、短期リリース)
Scrum
[InfoQ]スクラムのスクラム - 問題と価値 (Mike Cohnの記事の日本語訳)
Crystal(Crystal Clear)
FDD(Feature Driven Development：ユーザー機能駆動開発)
DSDM(Dynamic Systems Development Method)
OpenUP(Open Unified Process)
RUP(Rational Unified Process)をアジャイル対応したもの？
古い記事ですがITProのサイトにまとまった記事がありました。
SDLC局面？ Software Development Life Cycleの各フェーズ、ということでしょうか。（ヤマモト）
3.2.5 過去の経験や態度(P47)
新しいプロセスを機会と捉えること。トレーニングや試行期間を確保すること。が、できれば理想ですねえ。（ヤマモト）
P.47 「アジャイル開発は誰にとってもできるものではなく、トレーニングや試行期間が必要。」 アジャイル開発をする為にアジャイルを学ぶだけではなく、現行のやり方についての振り返りというか、それぞれの開発の現場のやり方を見直す事も必要かなと思います。トレーニングにそこまで含むのかは不明ですが。 (Ｙｏｕ＆Ｉ)
3.2.6 役割による文化の違い(P48)
3.3 変革の導入(P48)
3.3.1 不安について語る(P48)
3.3.2 チームがオーナーシップを持つ(P49)
これもよく分からんですが...自己組織化重要ということでしょうか。主体的で自己変革するチーム。（ヤマモト）
この文脈のオーナーシップは、コードの共有とかではなくて、プロジェクト自体のオーナー
⇒指示待ちでなく裁量権・自己決定権と責任があるというような意味なんですかね？（かかむ）
チームがオーナーシップを持つ
⇒一人一人が当事者意識を持つ、ということでしょうか？ 「自分の担当外だから」といって壁をつくる人はよく居ます。（岩井）
3.3.3 成功を祝うこと(P50)
達成感ないとバイタリティが失われていくので、こうゆうの大事ですよね（かかむ）
3.4 管理職の期待(P51)
3.4.1 管理職の文化の変化(P51)
P.52 「ジャネットの話：従来のウォーターフォール型では、・・・最後でパニックになる」 頻繁に問題が発生する状況で顧客は付いてこられるのかふと疑問に思いました。 (Ｙｏｕ＆Ｉ)
P.52、53
テストマネージャーの移行の話で、プラクティスを取り入れる前にアジャイルプロセスを取り入れたのでミニウォーターフォール型
になってきたとあるが、もう少し具体的に書いてくれるとうれしい（かかむ）
P.53
「テスターが従来の定義され順次に実施されるテスト・・・」
⇒「定義され」というのが良く分からなかったのですが、その後に続く「テストはコーディングと統合された活動」
という部分から、「テストが１つの独立した工程と位置付けられる」ことだと理解しました。（岩井）
3.4.2 管理職の言葉を話す(P53)
P.54 本項では「管理職」と「マネージャー」が使い分けされているようで、どう違うのか文脈が読み取りにくい。 (Ｙｏｕ＆Ｉ)
P.54 アジャイル開発におけるコスト見積や管理に関するオススメの書籍やサイトはありますか？（岩井）
3.5 変化は簡単ではない(P55)
以降の3.5.1～3.5.6は地味だが、改善活動として現実的な態度だと思いました。
でも最後がプロジェクトを去るで終わってるのがさびしい気もします。だからこそ、
プラグマティックなのかな。（かかむ）
3.5.1 我慢する(P55)
3.5.2 痛みを感じさせる(P55)
失敗しないとわからんと突き放しているニュアンスでよいですか？
諦めるなとも言ってるようにとれる（かかむ）
3.5.3 信用を築く(P55)
3.5.4 あなた自身のプロフェッショナル開発に取り組む(P56)
3.5.5 品質の番人の考え方には用心する(P56)
「強いる人ではなく、協力者になりましょう。」このフレーズは好きです。駄目と叱責したり追及しないで、
改善を促せるようになりたいです。願望（かかむ）
3.5.6 去る決断をする(P56)
3.6 まとめ(P57)
下から２番目「テスターはマネージャの期待に・・・」は、テスターに限ったことではないと思います。（岩井）