-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20120117
sandinist edited this page Jan 26, 2012
·
8 revisions
- 2012年01月17日 19:00-21:00
- エスプランニング開発室
- 参加者 9人
- 8.1 ～ 8.4
前回の復習。
- 間違ったマネジメントとアジャイルな計画作りと対比しているけど、正しいマネジメントとアジャイルな計画作りを対比したほうがよいと思うよ
- そもそも「固定化された計画」はよくないマネジメントなのでそこは気をつけて読んだほうがよいよ
- 確かにそうだね
-
個人の力量はあるけれど「チームで」全体量をやるという形（できる人が自ら仕事を引き受ける形）は双方のモチベーションが保たれると思う -> これは「アジャイルな計画」だから？
- 小さなプロジェクトで特性に合わせてタスクを取っていくと同じようなやり方になるよ
- マネジメントがうまくできているかどうかの問題だと思うよ
- 縦割りだと仕事分散ができないことはけっこうあるよね
- 大規模だと機能単位で縦割り -> 他の機能は触れない、わからない、分担できないとなる
- プロジェクトは良い形で進まなくなる事が多い
- コードの共有はとても大事だね
- アジャイルな開発でも、余裕がなくなってくると手が早い人がどんどん片付けていく(ボードからカードをはがしていく）ことになる
- そうするとスキル差があるとおいてけぼりになってしまう
- 早い段階でのコードの共有が大事、余裕がある時に先を見て準備をしておく事が必要だね
- 小さなプロジェクトで特性に合わせてタスクを取っていくと同じようなやり方になるよ
-
「プロジェクト計画は厳格なコミットメントじゃなくて予想」ということを相手（お客さん）は求めていない。相手はコミットメントを求める。ということが最大の問題になるよね
- コミットメントを求めるところとアジャイル開発をするのは無理？
- 契約をカチっとする（期間、お金、工数）ことを求めているところとは難しいかも
- コミットメントの意味は広い
- チームを買ってくれるという形だとまた違うけど、通常は成果物に対しての約束(=コミットメント）を求められるよね
- そうすると、契約でバッファを詰んでおくいうことが解決策になるのかな
- バッファを詰んでおく事はあんまりお互いに得しないけどね...
- ただ、担当者に取っては失敗するよりも常にバッファを詰む事で保険をかけておける方が幸せという見方もある
- 1回の失敗も許されないから、自分のお金じゃないから
- 3倍のバッファを予算に入れて大手に頼むのであれば、3分の1の価格で3社に頼む方が成功する確率が上がったりして…
- 「はじめの方に全てを決めないほうがお互い得ですよ」というのを納得してもらうというのも方法の一つだよ
- 「あまったら返します」も納得しやすいのかもしれないね
- どういう契約になるんだろう？ -> 現実「お金を返す」契約って見たことがない
- やれないことはないと思う（追加費用の申請とか）
- 永和さんの価値創造契約ってどんなのだろう
- どういう契約をしているかについて http://www.esm.co.jp/new-agile-contracts-service.html
- 何にせよ信頼関係が大切
- 信頼関係がなければどの形で提案してもお客さんは疑心暗鬼になってしまうと思う
- 「君がそういうなら大丈夫だね」と言ってもらえる関係を築いていきたいね
- 信頼貯金大事
- 発注側の気持ちを変える事は本当に難しいよね
- 対お客さんだけでもなく対社内（営業の人とか）についても考えなければいけないね
- どのようにお客さんに説明する事が会社としてベストかという調整
- 圧倒的な生産性でカバーできるようにという考え方もあるかも
- コミットメントを求めるところとアジャイル開発をするのは無理？
- 「良い質問」の答えは何だろう
- お客さんとの関係が作れていなくても後者の選択肢を取るべき
- 判断してもらえるまで待つ、正直に言う
- 気まずくなる -> 仕事を打ち切られる、チームを外されることもあるかもしれないけど、そのくらいの覚悟を持って悪循環を断つ必要がある
- そういう意味で「アジャイルサムライの道が簡単だなんて言ったおぼえはない」と書いてあるのかな
- お客さんとの関係が作れていなくても後者の選択肢を取るべき
- 自社開発の場合に「仕事量が多いがスコープは変えられないと言われた」場合はどうすればいいだろう(お客さん＝会社との関係を簡単には崩せない）
- 「説明」することに力を入れる（根拠を示す）
- 解決案もあわせて提案する
- アラートを上げ続ける
- 同じ会社＝味方だと思うこと
- 同じ方向から「一緒に問題を考える」
- 問題 VS 私たち
- 社内だからわかりやすいこともあると思う（どうすれば嬉しいか、目的が何か、というのが見えやすい）
- 仲間を見つける、バディを見つける
- まだできることはありそうだから、いろんなことを実践してみたい！
- 「共犯者になろうとしちゃだめだ」はすごくよい言葉
- できないことを「できます」というのも共犯
- 敵じゃないことと共犯者になるというのは違うところが難しいね
- 正しいことを一緒にやれるかどうかだよね
- 「前の担当者がひどかった」などのマイナス要因からのスタートはつらい
- タイポは#19 に載っていた
- スタンディッシュグループの調査結果
- 資料が古い、新しいのってあるのかな
- 機能をどう数えるかによっても使われている割合って変わるよね
- ソフトウェアは「よく使う」以外は後から追加することができる
- ソフトウェアの特徴だよね
- 「MMF」Minimum Marketable Features
- リーンだとMinimum viable product (MVP)という言葉で出てくる概念
- MVPはプロダクト全体、MMFは一つの機能をさす
- 市場価値「M」は誰がどう作るのか
- 顧客目線でどのような価値を生み出すか
- リーンだとMinimum viable product (MVP)という言葉で出てくる概念
- 文章の誤り #2
- 「顧客に優先順位をつけてもらう」というところが難しいよね
- 5章でもでできたね、難しい問題
- これができてないとこれができない、というので決まる優先順位は結構ある
- そう考えていくと、ファーストリリースで市場価値のあるものを届けようとすると大きくなるよね
- ケーキを1ピースだけ作るとすると最初の数個のコストは上がる
- ファーストリリースでとりあえず出しても動かしてもらえなかったり
- でも、フィードバックもお客さんの価値(=市場価値)と考える事もできるよね
- 最初のころは市場価値のないもの（基盤）をたくさん作っていかないといけないので進んでいないように見えたりする
- 技術的リスクだけじゃなく、仕様や使用感のリスクの高いものも前に持っていきたい
- 早めに触ってほしいものは先に出したい
- マスターストーリーに入らないもの（環境構築、学習コスト）をどう取り込んでいけばいいか
- 前半のベロシティは伸びない前提でやっていくのがいいのかな
- 「慣れ」「加速していく」までにはあるていど時間がかかるものとしたほうがよい
- 同じメンバーで同じような案件を行う場合はちょっと違うけど
- ずっと先の計画はある程度見積もりの精度が出てから出したほうがいい（出せるなら）
- 最初に概算でも計画は出さなくてはいけないから、やはり「確定ではない」ことを理解してもらう事が大事になるね
- 「完了とは完了のことだ」
- ストーリーを開始する前にストーリーの終わりを定義するようにしているよ
- アジャイル開発以外でも常に完了条件を意識することは大事
- 始められる状態になっていることが大事(Ready Ready)
- どうやったらストーリーを開始できるのか、その状態にあるのかを定期的に（打ち合わせやイテレーションの振り返りで）共有する
- お客さんとの間でも最初に「どうすれば始められるか」の意識をあわせておくことが大事
- 「できる状態になっているか」の見せ方が難しい
- ただ、ボードにカードを並べているだけだと「できる状態かどうか」を共有できていないかもしれない
- 打ち合わせ、慣れ・経験、複雑だとアローダイアグラムを使うとか
- それを計画に落としていく感じ
- ある程度は経験則で「これくらいまでにこれは必要」というのを考えているなぁ
- 期日の調整の方法はマネジメントのごく一般的な方法、アジャイル的な方法ではないよ
次回は1/31（火） 8.5- になります