「アジャイルサムライ」読書会 in HDE 第三回 の記録

範囲： P.10-27

深く関わる顧客の存在（P.21）

• 顧客のいうことばかり聞いていてもよくわからなくなってくる
• 無条件に受け入れていては・・・ 　「顧客の関わり方」が重要
• 一方的な要件だけ伝えてくる顧客は良くない（関わるとはいえない？）

ソフトウェアをデモする（P.25）

自分の製品をクラウドエキスポでデモをしたことがある

• デモをしてよかったと感じた
• 製品に対して責任を持つようになる 　テストをしないものをデモしてひどい目にあったｗ
• テストは重要っすね 　UIの部分だけを見せた→顧客はほぼ完成していると思い込み→せっつかれて大変だった
• できた部分だけを見せる、というもの見せ方を考える必要がある

やり方が一つなんてことはない

プラクティスをどう提供するかは状況次第

• まさにそのとおりだと思った 　柔軟にプラクティスをどう適用するか考える必要があるな 　プラクティスをたくさん習得しようとモチベーションも上がる

ペアプロをプロジェクトのスタート時に教育の一環としてやっている ペアプロの効果があがったと思った理由は？

• 意識のズレが少なかった
• ペアプロをすればどんな効果があがるか

客を巻き込むために２週間で何かしらの客の課題解決をやってみせる（P.22）

• 他に方法がないのか？

「顧客」って？

本当の顧客なのか、プロキシ型のオーナーなのか

• 後者なら積極的に関われていない？

職能横断型のチームを作るには

ゼネラリストが必要

• メンバーに能力が足りなければどうすればよいか？
• やるしかない！？ 職能横断型のチームを目指して行おうという意気込みで
• とはいえ、アジャイル的な役割もある（後ほど）

同じ職場

すぐに質問できる（物理的に近い）ようなところは成功している

• ペアプログラミングで意識の統一を！ｗ
• 同じ職場でも国が違うと価値観の違いが・・

開発者をテストを大量に書く（P.27）

テストを書かない現場にいるので「良い事言ってる！」と共感

• テストはバグを見つけるもの、というイメージでやっている
• テストは動くことを保証するためのもの

テストを書かないことで上手く言ってないこともある

• バグが出たり、リファクタリングも怖くてできない

成果責任と権限委譲

こういう刺激ある環境で働きたい

• 後ほどアジャイルチームの話が出てくるので

人に合わせて役割分担する

出来る人に仕事が偏らないか？

• 足りないところに人をアサインできるようになると考えては？
• ゼネラリストを育てる
• 縦割りよりは柔軟にできる

連続的な取り組み

• 「運用」のことも考えてほしい
• 運用を意識して作ってほしい

殺されちゃうよ？

できないことはできないと言う 無理にやってもらっても結局辞められたりしたらそちらのほうが問題

KPT

付箋にページ数を書くとわかりやすいのでは

• ページ番号だけではだめ