ReadingAgileSamuraiInShibuya20110727
← Readingagilesamuraiinshibuya
###[疑問] todesking 「誰もがこの働き方を気に入るわけじゃない」なら、アジャイルでない人たちにはどんな方法があるのか？それでも価値あるソフトウェアを作ることは可能なのか？幸せは訪れるのか？
- ウォーターフォールとか？
- アジャイルだからといって、幸せになれるとは限らない
- アジャイルの中にもいろいろな手法があるよね。ScrumとかXPとかCrystalとか。
- アジャイル開発であるか無いかでなく、開発方法のアジャイル度で考えるとよい
「動くソフトウェア」とはなんなのか？特に試行錯誤を繰り返すようなプロジェクトの場合、初期に実装されたフィーチャはリリースされる前に捨てられるかもしれない。要求される品質はフィーチャごとに異なるのではないか。
- XPにはスパイクと呼ばれるプロトタイプをつくる期間がある。この成果物はそこで捨てることが前提として同意している。
- XPについては下記の本がとても詳しい
 |
James Shore￥ 3,780
|
###[感想・質問] fukumori 「設計」「実装」「テスト」といった工程のかわりに「フィーチャ」を単位にして計画と進捗管理をおこなうのは非常に やりやすいと思っている。同じような経験を持つ人っているでしょうか？あるいは反対の経験を持つ人？
- ユーザーストーリーの切り方を失敗したことにあとで気づいた。結果的に失敗した。
- すくすくスクラムでのユーザーストーリー作成の動画が参考になる
- 本誌よりも、より具体的な計画のつくりかたは、本書の角谷氏が監訳をつとめた下記の書籍がとても参考になる。
 |
Mike Cohn￥ 3,360
|
###[感想] norry_gogo 「誠実に仕事を進める」という事が、アジャイルな開発において色々な局面で大事になってきそう 「誠実な仕事ぶり」がアジャイルな顧客に伝わっていれば、変化に対応しなければならない局面にも耐え易い？
###[感想] jiskanulo ストーリーを始めるまえにあらかじめ顧客とメンバーとでそのストーリーについて「完了」の定義をしっかり決めないと、いざレビューのときにめんどうなことになります。自分の経験です。
- 明日から「イテレーション」「マスターリスト」とかいっても、反感を買う現場は多い。わからないものを毛嫌いするのは人間の本能。
- 来週から毎週レビュー会をしましょう。成果を確認する会を30分しましょう。とか、平たい言葉にすることが重要。気づいたら、アジャイルやってました。ってぐらいで良い。
###[疑問] shishi ASPやPaaSなどのように多くの顧客に同時に影響を与えるシステムの場合、巻き込むべき顧客は誰か？
- 優良顧客を対象にしては？
- 営業戦略として、ペルソナを立てることもできる
###[感想] norry_gogo 最初は社内ツール等で社内に「積極的に深く関わる顧客」を体感してみるとかよさそうか
###[疑問] norry_gogo アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりと分かれていない、とあるが、 アサインできる要因が限られている等の事情で、成果責任を果たす為にパフォーマンス重視で考えるといつもこの役割分担に結果なるなあ…等、ある程度役割が明確な場合もありそうな気もするのですが？ そこはチーム全体で「どう振る舞えば最善の成果をお客さんに届けられるか」と考えれば同じ事なのだろうか？
- 役割の線を越えて、協力してチームとして成果を出すんだという、自己組織化への意識が大切
- 線を引いて、1つの役割しか意地でもしない人は向かない
###[疑問] todesking 「アジャイルな顧客」はどこにいるのか？
- 図の左側
###[疑問] shishi Page32 挿絵 「キーボードを持った顧客」とはどういう意味か？
- 意味がわからないから、あとで @kakutani に質問する -> AgileSamuraiFAQ -> ここはこの章の最初に書いてある従来のチームからアジャイルチームになった時の違いを意識すると分かりやすいです。従来のプログラマは言われた事や自分の担当部分でのみ仕事しがちですが、アジャイルチームになった場合には自分が顧客になったつもりでコードを書こうって意味です。その前の節の言葉を借りれば、自分の資金を投じたプロジェクトであれば、自分はより質の高いコードを目指すし、心血もそそぐだろうっていう事の比喩だと解釈しています (nawoto)
- アジャイル原則の1番目や、プロペラ帽子(顧客の役割の帽子)は顧客の役割を演じているということ？
- プロペラ帽はXPで複雑なコードを書くと被せられるアイテムらしい
- Agilesamuraifaqに「良くある質問」として監訳者達が回答を寄せている
###[疑問] Yousuke Hirowatari BtoCサービスなどリリース前の紹介ができないプロジェクトの場合、「顧客」は用意できないのか？
- この章での「顧客」は仕様を定義する人
###[質問] gilbite 「積極的な顧客」って実際どのくらいまで巻き込んだことがあるか、みなさんの経験をきいてみたい。
- ここに経験書いて
###[質問] sochiai アジャイルコーチのことが本ではさらっとしか触れられていないが、アジャイル未経験のメンバーやモチベーションが低い人がいる場合はアジャイルコーチのコーチングが非常に重要になりそうですが、アジャイルコーチの効果的な方法とかあるのかな？ どなたか経験したことあるかたいますか？
- すぐに成果は出ない。少しずつ変化していくことが重要かと思います。
- はじめのうちはわかりやすい言葉に置き換えてイメージしやすくする （いきなりカタカナばかりの単語を見るとぽかーんとしちゃうので）
- いちおうアジャイルコーチという肩書で仕事してるので何か質問あるww? 上の事で補足するとすると、もちろんメンバーのモチベーションについての事もやったりしますが、最終的にはその部分はチームがやっていかないといけない事なんで、そのやり方を伝えたり、相談に乗ったりする方に僕は軸を置いてます。分かりやすく言いましょうとか僕も良く言います。で、僕はこんな感じで伝えてますみたいに手本を見せたりとかです (nawoto)
###[疑問] shishi 色々な職能を横断して行わねばならないと言うことは、いくつかの能力を持たない、一つの技能のみを持つ人はアジャイルチームのメンバーとは言えないのか？
- 技能に関しては、身につければ協力できる。そのための取り組みがチームとしてできるかも重要
###[疑問] shishi 不足している箇所に情熱をもっているメンバーがいることが前提になっていないか？そう都合良く人材がいるものだろうか？
*とても気になるので意見求む
- バスは目的地が定められている
- バスは停留所のルートと時間が定められている
###[Point] HIROCASTER インセプションデッキは全部書ききらなくても、それぞれに意味がある。特に
- やらないことリスト
- 夜も眠れない問題（放棄するリスクと対処する価値のあるリスクの明確化）
###[疑問] norry_gogo インセプションデッキはプロジェクト開始前の課題であり、プロジェクトの状況や方針に大幅な変更があれば、そのタイミングで改訂とあるが、プロジェクト開始前のタイミングにおいて「期間の見極め」や「何がどれくらい必要なのか」は、どのくらいの感覚で出ると好ましいのか？
- インセプションデッキは見積もりと平行して作成され、上記はこの時点では大体の概算でよい。プロジェクトを進めて行く中で明確になる情報で必要に応じ更新される
###[感想] remore 「チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがだめになる」 ⇒合意に欠かせない人を定義はできるか。できるだけ多くのチームメンバー＋顧客の中のキーパーソン＋ステークホルダーとか、でしょうか。
手ごわい質問をするのを手助けしてくれるのがインセプションデッキ。
- 作成期間：数日から2週間程度
- プロジェクトに直接関係ある人が作成するのがふさわしい。顧客、ステークホルダー、チームメンバー、開発者、テスター、アナリストなど。特にステークホルダーを巻き込むことが大事。
- プロジェクト進行中も随時改訂
- 出発点であり、生きた成果物
- インセプションデッキ日本語版 | Ryuzee.com http://www.ryuzee.com/contents/blog/4009
###[感想] remore 「やらないことリストを作る」「夜も眠れなくなるような問題は何か」「何を諦めるかをはっきりさせる」の3つを特に現場で活用したいと思った。また、「やらないことリスト」については先日実践してみたけど、重要な（手ごわい）ことについてやらないと宣言するのって案外難しい。（見つける難しさと、それを実際に発言して合意形成する難しさ（こちらはメンタルの部分含めて））
- 事前にWikiを書くこと
- 事前にポジションペーパーを書くこと
- 疑問点を先に書いておくこと
- 進行がスケジュール通りだった
- 懇親会の会計終了後に実は伝票間違っていて、追加請求されてその場に残っていた方々で2,000円ずつ追加支払いした
- 飲み会の場所確保に戸惑った
- 当日話された内容が上記に書かれていない（みんなで書いて共有しようよ！）
->(jptomo)議事録をスクリーンに写しながら進行を進めると良い？ - 発言できなかった人がいた
->(jptomo)グループ分けし、その中で誰かわかっている人にファシリテータをやってもらい、進行を進めると良い？ - 疑問点が消化できなかった →消化できなかった理由が気になります →Wikiに書かれた疑問のことであれば、時間的な都合でいくつか割愛しました。
- チケットの印刷を忘れた方が多かった
- どなたがどなたなのか把握しきれなかった
- インセプションデッキ！(@remore)
- 人数的に融通の利く懇親会の会場を押さえておきたい
- 全員で発言という形での全員参加
- 簡易的な座席表(ポジションペーパーとの紐付け)をホワイトボード
- 読書会の感想をブログに書く
- １回は何らかの発言を行う
- 次回、自己紹介をするなら1人1分以内(エレベーターピッチ)