Readingagilesamuraiinshimane20111117
← Readingagilesamuraiinshimane
読書会が目的では無い！！っと思っていても、
こうやって実現できたことに、少なからず達成感を感じました。
参加者の皆様を始め、
多くの方々のご支援、ご指導があったからこそ実現できたと心から感謝しております。
第1回はAgilityPointなるものを使って藩決めをしました。
発起人のAgilityPointを50として、各々ご自分のAgilityPointを見積もってもらう、10秒で。
みんなで共有して、AgililtyPointが高い順に、1,2,3,1,2,3と言った具合に藩に分けていったわけです。
以下のフォーマットで討論の内容を整理しました。
- 気になる文章に対しての疑問
- 疑問に対しての意見
- 発起人の考え
- P.4 「本当に大事なことに集中して、それ以外のことは忘れる」とあるが
漠然としていてイメージできない、それ以外はやはり必要ではないのか。- 情報共有のための文書は無駄ではないと思う
- 進捗会議のための文書などは必要に応じて作るべき
- プロジェクトとしてその文書が必要であるかを議論する。 どんな課題があって、それに対する解が文書作成だとして、 それがそのプロジェクトにどんな影響（効果）を及ぼすのか…。詳らかにした上で取捨選択をしてはどうか？
- P.5 「必要とあらば進路を変える」とあるが具体的な方法やタイミングについては触れられていないため
どのようにするのか分からない。- もっと読み進めたらわかるのかもしれない
- この段階では、「必要とあらば進路を変えることができるんだ！やっていいんだ！」と感じることができればよいと思います。
- P.6 「期待をマネジメント」とあるが暗黙的な期待をどう浮き彫りにすればいいんだろうか。
- 対話して認識を共有すると全てではないが、お互いに伝え合えるのではないか
- 暗黙的な期待が後々牙をむく可能性があることを、プロダクトオーナー、 ステークホルダーも含めたチーム全体で認識しながらプロジェクトを進めると、自然と対話が増えるのではないか？
- そもそもアジャイル開発をすれば必ず成功するなど、まず誤解を解く必要があるのではないか
- 何を以って成功なのか？また、成功の評価はいつするのか？プロジェクトの終わり？プロジェクトの終わりはユーザーにとっては始まり…。
- P.9 「現実に適応する計画づくり」とあるが指標のベロシティは本当に定量的なのか。
- イテレーション毎にベロシティが変動するなど安定していない場合は定量的と言えないのでは
- 僕は一歩を踏み出す為のベンチマークにしか過ぎないと思ってます。少しの明りを灯す程度。ベロシティを言い訳に使っては元も子もない。
- P.9 「つまり、やることを減らすんだ」とあるがどうしてもやらなければならないことがあるのでは。
- お客さんに最低限ここまでは作って欲しいと言われている場合は、協調してイテレーションの期間を延ばしてもらうしかないのでは
- やることは減らせない、品質は下げれない、期日は変えれない場合は、やはり従来通りやるしかないのではないか
- やることを減らすにはどうしたらよいか？やることを減らしたらどんなメリットがユーザーにあるか？徹底的に議論する。生まれたばかりの赤ちゃんに来月までに歩けるようになれ！って言いますか？できないこともしっかりユーザーと共有しよう！
- ストーリーの精度/粒度を高くするにはどうしたらよいのか。
- チームが成長する中で徐々に粒度が定まり精度が高まるのではないか
- 「期待をマネジメントする」ってどのように捉えたらいいか？
- 期待のマネジメントでは、プロダクトやプロセスへの要求だけでなく、感情的なものも扱うと良さそう。
- チーム内（メンバー同士）、チーム間に存在する期待もマネジメントしたい。
- ”暗黙的な期待”とは、、まずは”その存在”を認識し、向き合うことが重要。少しずつ可視化する。
- マネジメントは誰がするか？
- チーム？
- 良いキーワード、注目したいキーワード
- 価値を生み出すか、生み出さないか
- 質の高い仕事への情熱
- 大事なのは考えぬくこと
- ベロシティで仕事量を把握できるか？
- ベロシティの扱いは注意が必要そうだ
- チームが届ける価値の量（の目安）として、素早く見積もるのには有効だ
- スコープを柔軟に
- ユーザーにどう理解してもらうかが重要
- 「やれることをやるだけ」とあるけど、、
- 見積もりとの差をどのように調整するのか？->続きを読み進めて考えたい
- やれることの量
- 「信じることのできる計画」×「お客様と一緒に」→どう実践するのか、続きを読み進めて考えたい
- 良いキーワード、注目したいキーワード
- 隠し立てしない
- スコープは柔軟に
- 価値のある成果を毎週届けるとあるが、、、
- そもそもお客さんにとっての「価値」とは、お客さんによって異なるのでは？
- お客さんの視点で考えてみると、実は大部分はほとんど価値がないものづくりでは。
- お客さんの価値を共有しておかないと定期的に価値を届けられないのでは？
- 動くソフトウェアを定期的にお客さんの目の前で見せて、そこからフィードバックを得る
- 共有の手段＝フィードバックとも言えるのでは。
- 「お客さんに価値ある成果を毎週届ける」というのは、気弱な人にはおすすめできない。
- 気弱な人もチームでやれば届けられるのでは？
- お客さんにとって価値ある成果を毎週届けたいなら無駄を省いて価値につながらないものを捨てるしかない。
- 無駄なものを明確にする。
- 上記以外に抽出した部分
- 必要とあらば進路を変える、計画を変えるんだ。現実を変えるんじゃない。
- 価値ある成果を毎週届けることをお客さんにコミットメントして、彼らの資金の使い道を示すことができたら成果責任（Accountability）を果たしたといっていい。
- 違いがあるとすればToDoリストやタスクのことをマスターストーリーといったこじゃれた名前で呼ぶくらいだ。
- こじゃれた名前にすることで、わかりづらいのではないか。
- 逆に身近な分かりやすい名前にしたほうが、受け入れやすいのではないか。
- 「Feature」、「Story（UserStory）」、と「ユースケース」。粒度や関係性がわかりにくく、 「ストーリー」と「ユースケース」については捉え方、役割、説明、作るタイミングなど人によって異なった。
InfoQ:ユースケース、それともユーザストーリー？
MartinFowler's Bliki in Japanese - ユースケースとストーリー
- 開発チームはベロシティ（１回のイテレーションで完了させられるストーリーの量）を実測することで、自分たちのこなせる仕事量を把握できる。継続的に記録したベロシティがあれば、自分たちがこの先こなせる仕事量を予測する判断材料になる。
- ベロシティの実測はどのような方法がいいのか。
- ベロシティが計算できるチームが身近にいると実測方法について参考になる？
- 「できないものはできないんだ」
- それはそうだけど・・・。
- 現実はそう言えないこともある。
- 上記以外に抽出した部分
- 「非現実的な計画」→「奇跡」→「動くソフトウェア」
Keep
無事に終わって安堵した。
運営側に徹底したが、とにかく楽しかった。
活発な意見が飛び交い、楽しんで貰えていることが伝わった。
準備期間や読書会中など、Agileなコミュニティの温かさを心から感じた。
Problem
2節しか読めなかった。
運営に対してフィードバックが欲しかった為、
ふりかえりの時間にあててしまった。他の方法でフィードバックもらうこともできたかも。
第1回では藩の中で討論が閉じてしまい、
他の藩の考えや疑問やひらめきを共有することができなかった。
ユーザー企業様の参加が無かった。
Try
次回からは読書会に対してのふりかえりに時間は割かず、
本の中身に対して議論を深めて頂けるようにナビゲートする。
次回は議論の内容をみんなで共有する時間を設ける。
できれば参加への敷居を低く、ユーザー企業様のご参加も歓迎したいので、
ポジションペーパーやwikiなど、馴染みのないツールは極力使用させないように、
付箋、ホワイトボード、カメラなどのツールを駆使してトラッキングする。