-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20111206
irasally edited this page Dec 6, 2011
·
12 revisions
- 2011年12月06日 19:00-21:00
- エスプランニング開発室
- 参加者 7人
- 6.4 ～ 7.1
- フローチャートと、それに対応するざっくりしたペーパープロトタイプがあれば「アプリケーションの中核をなすユーザーストーリーのほとんどを導き出せると思う」は言いすぎじゃないかな
- そこが一番難しい、ほとんどが出るとは思えない
- それだけ準備があれば「アプリケーションの中核」は出るんじゃないのかな
- 中核がブレている場合があるから安易に考えるのは危険じゃないかな
- 「ユーザーストーリーを収集している中でフローチャートとペーパープロトタイプがある」という前提がなかなかない
- それだけでもよい話し合いができるんじゃないかと思う
- 1日みっちりで10～40のストーリーを出すこと
- 1日かけて10個って少なくない？
- この場でゼロから考えるんじゃなくて、ある程度準備してこの場に臨むんじゃないかな
- ノープランで参加するとかはまずないよね
- 大風呂敷を広げてやりたいことを全部出して、計画段階で「やっぱりできない」とたくさん削られたらがっかりしないのかな
- 普通は予算がはっきりしない状態でここまでストーリー出さないんじゃいかな
- 最初にこれだけストーリーを出して「収まりませんでした」で納得されるのかな
- 「全部はできませんよ」という前提で話をするんじゃないかな
- これって予算もメンバーも全部決まっていないとできないんじゃないかな
- でも、ここで出したストーリーを全部製品にすると確定しているわけじゃないよね
- 現実は「予算を考えるとここまでだよね」というふるいにかけることがおおいのかもね
- やりたいものがわかった -> 継続的な契約のチャンスだよね
- ある程度「やろうとおもっていてできていないこと」が溜まったら切り捨てて、新しいストーリーを収集することになると思う
- バックログにたくさんたまっているのは良くない状態
- 普通は予算がはっきりしない状態でここまでストーリー出さないんじゃいかな
- 一回ストーリー収集ワークショップやったら次はいつやるのだろう
- ワークショップにもいろいろな種類がある
- プロジェクトの切れ目で1日かけてじっくりやるもの
- 短い時間でさっくり近い時期の目標を話すもの
- ワークショップにもいろいろな種類がある
- 最大でも「1日」がアジャイル的だよね
- このストーリー収集を何日もかけて行うのがウォーターフォールじゃないのかな
- そうでもあるし、そうでもない時もある
- 大規模な開発だと時間をかけてストーリーを集めないと全体像がつかめないので時間がかかることもあると思う
- 「深堀りをしない」というのがアジャイルのポイントじゃないかな
- このストーリー収集を何日もかけて行うのがウォーターフォールじゃないのかな
- この方法は大規模プロジェクトだとなかなかうまくいかない気がする
- アジャイルは小さなプロジェクトのほうが向いているよね
- 角さんのユーザーストーリーのプレゼン資料がよいよ
- ワークショップは大枠が何かを捉える（＝導きだす）、共有する、実現するものは何かをはっきりさせるフェーズ
- ユーザーストーリーは本当に必要？
- お客さんとどの段階で同意できるか（ざっくりな同意でよいかどうか）に拠るんじゃないかと思うんだけど
- 実現方法をどこまで任されているのかの違い
- 詳細レベルまでOKしないと「要求を満たしていない」とされるのであればざっくりした段階の話し合いはあんまり意味がないんじゃないかな
- 大枠を満たした後、改善してほしいところがあった場合に、新しい要求と捉えられるのか、仕様変更と捉えられるのか、要求を満たしていないとされるのかの違いで、ユーザーストーリーの必要性が変わってくるように思う
- 現実のアジャイル的な開発では「仕様変更への対応の速さ」が利点になるのかな
- アジャイル的な開発をしておくと傷が浅くて済むよね
- 短いスパンで見える形で出すことに重要性、意味があると思うよ
- 実現方法をどこまで任されているのかの違い
- お客さんとどの段階で同意できるか（ざっくりな同意でよいかどうか）に拠るんじゃないかと思うんだけど
- 規模が大きい物をどうやってうまくやるか
- 要求をエピックに分けることができたらうまくいくこともあるかも
- 「お客さんにとって価値があるもの」を届けるまでの最低ラインが大きくなる気がする
- フィードバックがもらえるまでの段階にいくまでの時間がかかる
- フィードバックをもらえる、までならそれほど時間がかからないけど「価値ある形」となると時間がかかるよね
- apache が立ち上がっているだけでも「ユーザーの価値か」-> イテレーション0ならそれでもいんじゃないかな
- 実際にリリースできる「価値ある動くもの」ってどんな単位？
- ビジネス的価値がないものをリリースしても意味が無いんじゃないかな
- ケーキの例えがあるけど「ホールケーキじゃないと嫌だ」といっているお客さんにケーキ1ピースを先にリリースしても価値はないんじゃないだろうか
- フィードバックがもらえるまでの段階にいくまでの時間がかかる
- 永和さんの「価値創造契約」の話
- 規模感はどのくらいなのかな
- どこまで大きな規模で適用できるのだろう
- リリース頻度が高いことによって在庫を減らすことができるし、フィードバックを得ることができる
- お客さんにとっても嬉しいことなんじゃないかな
- 本当は切り出してリリースしたものは切り出した単位でお客さんに使われている（＝価値があるものである）べきなんじゃないかな
- でも実際、全部がそろうまでお客さんの業務で利用できなかったりするよね
- 部品であっても在庫を減らせるのだからそれもアジャイルじゃないのかな
- そもそも生きたシステムじゃないなら本来在庫だよね
- 「在庫を減らすこと」だけがリリース頻度を上げる目的ではないんじゃないかな
- 開発者にとって「在庫を減らすこと」になってもお客さんにとっての価値が違うかもしれない
- 「ムダを無くす」はアジャイルに入っているのかな
- 結果として無駄のない開発ができますよというのはありそう
- 現実的には「フィードバックできるものを見える形ではやく提供される」ことにお客さんが価値を見いだせるかどうかにかかってるんじゃないかな
- ケーキ1ピースが嬉しいかどうか
- 「在庫になるからいらない」となれば完成するまでリリースできない -> アジャイル的なリリースはできないんじゃないかな
- 1ピースの価値を伝える、理解してもらうことが必要になるんじゃないかと思う
- 資産価値としての在庫ではなくて、段階リリースするものを生かせるかどうか
- 段階リリースしてもお客さんのところで触られず、眠っているだけであればそのリリースに価値はないと思う
- リリース頻度を上げて在庫を減らすこと、進捗を知らせることがアジャイルの価値なんじゃないかな
- アジャイルは在庫管理と進捗管理の比重が大きいからなあ
- 何を大切と捉えるかは人によって違うと思うよ
- Lean生産方式では在庫を減らす重要性が書かれていない？
- 結果として在庫を残さない生産方式だけど「在庫を残さない」ことは目的ではなくて結果じゃないかな
- Lean生産方式では在庫を減らす重要性が書かれていない？
- お客さんにとって大事なモノが違うから、どういう1ピースが嬉しいかもお客さんによって違うよね
- だからお客さんによって何を優先してリリースするかは違ってくるんじゃないかな
- 「実際業務上使えない」段階でリリースされることでお客さんにどんな価値があるんだろう
- フィードバックを得られる、欲しいものに近づける（軌道修正）
- そういうものを「いい！」と思ってくれるお客さん、積極的に関わってくれるお客さんであれば段階リリースは意味あるものになるよね
- 段階リリースでお客さんにものを見せて、最終成果物が「製品」となった例
- 最終成果物ができるまで、業務上の価値はなかった（在庫である）
- しかし、よいものができてお客さんは満足していたと思う
- 考え方と現実とのギャップがあるよね
- リリースにも色々あるよね、プロジェクトによってどの段階を「リリース」と定義するかには差がありそう
###「お客さん」と「エンドユーザー」が違うことのジレンマ（請負とか）
- これはずっと抱え続ける課題なんだよねぇ
- 「お客さんの担当の人」が「何か変えたい」と思っていて「変えられる」文化があることが必要
- 請負構造によるコスト
- 請負構造がなくなっていけば、結果的に無駄はなくなるし、お客さんとも近づけるのかもね・・・
- 実際にユーザーストーリー収集ワークショップやったことある人いる？
- お客さんとがっつり話し合いをしながらユースケースを洗い出したことがある
- 大変だったけどその場で話を聞いて合意をとれたことがよかった
- お客さんと話し合ったことがないなあ
- 文書としてそういうもの（ユースケースとかユーザーストーリーっぽい提案書）を作って提出したことがあるけど見てもらっていない
- ユースケースなどの文書が揃うことが目的になってしまっていたと思う
- 本来なら詳細レベルのユースケースは必要なところだけを作るべき
- 文書としてそういうもの（ユースケースとかユーザーストーリーっぽい提案書）を作って提出したことがあるけど見てもらっていない
- お客さんと話しながら作業をするのならユーザーストーリーのほうが合っている（粒度）と感じたよ
- お客さん不在だとユーザーストーリがあっても内容が荒くて使えないような気がするよ
- お客さんの在、不在ではなくどの段階での合意かによるんじゃないかな
- 社内システム開発だと「できそうだな」と思えるところは多い
- お客さんとがっつり話し合いをしながらユースケースを洗い出したことがある
- アジャイルに夢を託している人には二種類あるんじゃないかな
- プロジェクトをまともに回したい
- お客さんに価値を早く届けたい
- アジャイル開発にはどっちの要素もあるよね
- どちらか片方を強調しすぎると、話の流れがおかしくなるかもしれないね
- アジャイルだと開発が楽になるわけではないよね
- むしろ各自の責任や自己組織化が必要になる
- 「刺身にタンポポ」の方が楽だもんね、それではよいものが作れないと思っているからよくしていきたいと思っているわけだけど
- ウォーターフォール VS アジャイルなのか？
- アジャイル宣言はウォーターフォールへのアンチテーゼなんじゃないのかな
- アンチテーゼの部分はあるけれど、それが全てではない
- 「ウォーターフォールをより良くしよう」というという流れもあった中で「全く別のもの」として宣言されたのがアジャイル？
- アジャイルサムライの巻末にあるアジャイル宣言を読んでみよう
- 確かにウォーターフォールはよくないと言っている部分もあるようには思う
- でも全く価値をおいていないわけではないと読めたな
- 珍しくセンセイがまともなことを言っている
- ものを作るための文書ではなく「文書化のための文書」＝「文書を作るために文書を作る」ことはよくないよね
- 「概算見積もりなんて当てずっぽうだ」を理解してもらうのが一番難しいんだよね。
- 「このプロジェクトをやり遂げられそうなのか？」よりも「この予算でどこまでできるのか？」という問題のほうが現実では多いなぁ
- 社内システム開発だとどうなんだろう
- 予算の話があまりでない
- スコープの調整しやすい
- ジョンソンかわいそう・・・・
- 一番真摯な答えは「（ここがはっきりしないと）わかりません」
- 認められるかどうかは別にして
- 見積もりに「正確さ」を言う形容詞をつけるのはおかしい
- 見積もりには「概算」なので「正確に」という言葉を使うのは矛盾だよね
- だから「はっきりしないもので、不確実である」ということを本でも強調されているよね
- 見積もり段階で「スコープ」は確実？
- 不確実性コーンはスコープ固定で話をしているはず
- スコープが固定だとお金でなんとかするしかなくなるよね
- あとの追加予算は絶対に認めないケースが多い
- 期間も変えられない
- だからお金を変化させるしかない
- そうして予算が膨らんでいってお客さんと開発者の溝ができるケースもあるよね
- なんでこんなに高いの？
- だってスコープ変えてもらえないし・・・
- 悪循環
- この章の見積もりというのは「お金」のことを言っているわけじゃないんじゃないかな
- お金の「見積り」だけをしているというようには読めないなあ
- 今のところ、だいたいプロジェクトがこんな感じになりそうをいう感覚をつかむだけじゃないかな
- 四天王のマトリックスからだいたいこんな感じのプロジェクトになりますよが見積もりなんじゃないかな
- だからあとからスコープを柔軟にすることも考えに入れた見積りになるんじゃないかな
- 現実「見積り」というとほぼイコール予算を出すことになってしまうことは多いけど
次回は2011年ラスト、12/20開催です。7.2からとなります。