-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiindwango20110831
akitsukada edited this page Aug 31, 2011
·
8 revisions
参加者：@erukiti @futoase @kwappa @akitsukada @lchin @tlync + 美人天気の中の人
#「第III部：アジャイルな計画づくり」/ "(原文タイトル?)"
原文タイトル：
原文タイトル：
- プロジェクト進行中にメンバーが他に引きぬかれたことある？
- ある。少ないメンバーでやるのも大変だったり、メンバー補充したあとも慣れるまで大変
- 思ったほど開発速度が上がってないことがわかったことある？
- あるね。
- お客さんが自分たちの本当に欲しかったものに気付いたは？
- 気付いたっていうかそもそも要求が掘り下げられてなかったみたいな感じ。
- 時間がなくなったことある？
- あんまり期日がはやまるってことはないかなー・・・
- そもそも無理なスケジュールであることのほうが多い
- P148 の「４つの基準を満たせるような計画」立ててる？
- あんまり意識してない。もともと短期間の区切りで動いているから
- チームメンバーのことがいつも見えることがだいじ
- 期日を守ろうとする姿勢は当たり前だとおもいきや、割とそうでもない意識を持っている人もいる
- 期日になってから「すいませんできてません」みたいな。
- 途中で状況確認しても「まぁやってますよ～」みたいな。
- デイリーな朝会とかあればまた違うよね
- みんなで見積もりをして内容共有するって大事。リーダーがガッと線引いちゃうだけじゃなくて。
原文タイトル：
- マスターストーリーリストに非機能要求ってどう絡んでんだろ
- 非機能要求を非機能要求として扱うんじゃなくて具体的な数値化、可否判定できる要求に変換してマスターストーリーリストに突っ込んでいく工夫はできる、レスポンスが２秒以内とか。
- デザインの要求とかは？
- 誰かジャッジする人を決めておくとかかな
原文タイトル：
- アジャイルサムライの道が簡単じゃないってここまできてから言うのがいいね
- 辛いかもしれないけど現実に向き合っていかなきゃいけない
- お客さんとの交渉をうまいことやる、重要。交渉力。
- 開発者自身が「自分は交渉できる」ことを自覚すべき
- リーダーがちゃんとチームをマネジメントしていなければならないし。
- スコープじゃなくて期日を延ばして対応しちゃいがちだったりもしませんか。
- お客さんとの「対話」が無いと、言われたことをはいやりますはいやりますみたいになっちゃう。
- ストーリーをお客さんに削除してもらう、というのもハードル高いよな。
- お客さんは全部のストーリーで「価値」だと思ってるから。
- お客さんに「優先順位」を決めてもらわないといけないよね
- そもそもなんで優先順位を決めてもらうのが当たり前になってないのか。
- お客さんだけじゃ決められないかもしれないし、お客さんも成長途上でそこまでプロジェクトすすめるスキルがなかったりする 人間だもの
- 期日「なるはや」とか検討事項を「持ち帰ります」はちょっと困りポイント.
- 期日固定とフィーチャ固定だったら期日固定。終わらないプロジェクトになるのを防ぐことができる。
- マスターストーリーリストをどうやってつくるべきか？
- 何で作る？excel trac 紙... Excelがベストかなーと思ってきた。機能的に。紙は場所的な問題もあって辛い。
- ソートも簡単 共有も簡単
- でもExcelだと作業しにくいってのもある、バージョン管理とかdiffできない
- でもお客さんは色つけたがるからExcel重宝するものだ
- なんで色をつけるのか？あまり本質的ではない付加的情報のためだ
- 紙にしてても最終的に電子的に提出必要だと結局Excelに起こす作業が必要だったり
- じゃあそういうWebアプリ作っちゃったほうがはやいのかな
- という話はきっと以前から何度もあったことなのだ
- ツール選びって重要。共有しやすい、必要最小限の機能があるツール
- 欲しいのは、ストーリーをリストできて、対応終わったかどうかだけを管理するツール
- 海外だとExcel多かった。次は紙。でもうちの会社は紙は無理だ
- それを満たすツールを作るのがやはり簡単かな。
- でも現場によって違うから難しいかな。変化を許容するのがアジャイルだし
- 各社でたぶんツールの活用の仕方とか細部が違う。ホワイトボードエキスポやっていい
- マスターストーリーリストは簡易的なガントチャートとも捉えられるかな
- ステップ１「マスターストーリーリストを作る」ができないと始まらないよな、一番難しい
- 以前やってたんだけどちょっと間違ってた。イテレーションごとの、じゃなくてイテレーション内でバーンダウン回してた
- バーンダウンチャートの目的はリリースを管理すること、ベロシティを図ること
- イテレーション内の、デイリーのバーンダウンチャートだと、日によって成果が違ってぼこぼこチャートになる。それは本来のバーンダウンチャートの目的とはちょっとちがったな
- マスターストーリーリストがないから、バーンダウンチャートをここに書いてあるやりかたで導入した部署は少ないだろう
- それはそれとして、バーンアップチャートなら、とりあえずチャートをつけて、ベロシティを図ることはできそうだ
- そもそも最初っからアジャイルってのが難しい、ということもある
- 最初からやりやすいプロジェクトはやりやすい。環境が用意されていたり 周囲の理解があったり
- 途中から導入する苦労を共有して、パターン化できたらな。
- 現実に適用できるノウハウ集、とかあったら欲しい。「うちはこうやった」集でいい。
- アジャイルプラクティスはそれに通じる本だったかな。
- アジャイルの本は「捨てるとこは捨てる」気持ちで読めばいいよね
- 全部やらなきゃいけない気になりやすいけど。
- 手法云々より、現状の問題点をはっきりするというのがそもそも現実的
- 「荒ぶる四天王は抑えられない」はポイント
- スコープをずらすんだ
- さもなくばデスマ
- スコープをずらすにはお客さんと交渉、話すしかない、我々は交渉相手が近くにいるのは幸せなことよ
- 二次請け三次請けだったら交渉相手通り、交渉できない、デスマる、文字通り死ぬ
- お客さんと話せたとしてもガチの殴り合い交渉になるだろうけどデスマで死ぬよりマシ
- アジャイルで受託開発した経験ある？
- ないな
- 受託でもアジャイルな契約をしていこう、という動きはある
- IPAも「アジャイルな契約モデル」みたいなの出してる http://sec.ipa.go.jp/reports/20110606.html
- ソフトウェアって定量化して考えられないところが本質にあるとしたら "アート"になるんじゃないの
- いや我々が仕事でやってるソフトウェアは"デザイン"でしょう
- "アート"と"デザイン"てどう違うの
- アートは気持ちの問題 ユーザーがいない ファンはいる デザインはユーザーがいる 使いやすさとかをデザインする
- アートの日本語訳「技芸」って好きよ
- 「ソフトウェア工学」って他になんかいい言葉ないかな
次回は「第9章 イテレーションの運営：実現させる」からやります。