-
Notifications
You must be signed in to change notification settings - Fork 0
読書会 2nd 2014.10.15 ディスカッション
t-kitamura edited this page Nov 20, 2014
·
28 revisions
- 日時: 2014/10/15 (Wed) 19:00-21:00
- 場所: Oinai烏丸
- 告知: http://connpass.com/event/8760/
(疑問点とか、良かったコトとか、ディスカッションネタ)
- [前川] 最終責任時点とか、プロジェクトが走っている中で判断できる？それが分かる時点で割りと計画駆動な気もするのだが。
- [とく] そういう判断を行おうとするという対話が大事だと思います（模範解答）。ビジネスにおいて約束が重要だという考えが一方であるので、LRMがいつぐらいに到来するのかは予見しておきたいです。
- [横田] いつが最終責任時点なのかは正確に把握できないと思うので、実際には「xxxの情報が揃ってから判断しましょう」とタイミングを合意しておくぐらいで良いのかなと思います。
- [大友] 以前は忘れちゃいけない項目に関しては、リスク一覧に記載して決定が遅れるとまずくなるであろうタイミングも一緒に書いて、関係者で定期的に見なおしていました。
- **[北村]**予見と適応のバランスだとあるが、要件定義やアーキテクチャ設計を事前にしておくという事は予見として良いことだろうか？
- **[北村]**ウォーターフォールとアジャイルのハイブリッドなどと言って、V字モデルの上位層だけウォーターフォール的に行い、下位層だけアジャイルで行うといった方法が取られたりして賛否両論を巻き起こしているが、それはありなのか？
- **[北村]**一方で、アジャイルという言葉を立てに、計画をないがしろにしすぎる人もいる気がする。
確度が高く予測できる部分はちゃんとサボらず予測しておくことも重要だとも思う。 - [前川] 👍 「カオスと秩序のバランス」をとらずにカオスに全振りするパターンが割とダメパターン、というか所謂カウボーイプログラミング的ですよね
- [とく] バランスとってるって、どうやって見える化するんでしょうね。僕にとっては建前として良い言葉を並べてるような感想を持ちました。
- [前川] 「カオスと秩序のバランス」という言葉ほどバランスでない気もしてきました。結局漸進的に見積もりを固くしていってるだけなのかなーと。Scrum自体そう（だと思ってる）ですし。
- [大友] アジャイル時代のモデリング
- [前川] 結局これはリスク対応なのだと理解していないとダメだと思う。使用でも設計でもチーム運営でも、やばいと感じることを早めに試してリスクヘッジをしておく、と。熊とワルツを踊ろう。
- [とく] スクラムでは、積極的にすばやいフィードバックを得ようとする。とあるが、何と比べてるんでしょうね。XPのほうがいいんでない？
- [前川] 何と比べているかといえば、WFなんでしょうね。XPの方がいいってのはよくわかんないっす。イテレーションが短いから？プラクティス的にはどっちも顧客受け入れテストやってますし。
- [とく] 計画駆動でプロトタイプとか作ることをしなければそうでしょうね。
- [前川] そうか、それがあったか。
-
[前川] 結局、バッチを小さくするのは多能工養成ギブスなんじゃないかなぁ。。。
- 多能工になる => 優秀なのでスループット上がる => 作業効率あがる、みたいな感じで、バッチサイズを小さくすることによるメリットよりも、人を強引に成長させる（そしてついていけない人を振り落とす）って側面もあるのではないかと。
- [とく] 仕事のきりをよくしやすくなりますね。
- **[北村]**作業者の手待ちばかり気にして、作業の手待ちに注目できていないのはそうだけど、「たいていの場合、作業の手待ちのコストは作業者の手待ちのコストよりはるかに大きい」の具体的なイメージができない
- [前川] 作業者の手持ち=作業者の時給 くらいのコストですけど、 作業の手持ちは、即遅延コストにつながるので、例えばプロダクトが一ヶ月遅れて億単位の損害出すのと、人一人を一月なんもさせずに100万無駄にしたってのでは、どっちが損失でしたかね？って話かと。
- **[北村]**ここに書いてあるテスターのケースならばどうすれば良かったのか？
- [前川] テスターを雇ったのがそもそも間違い 👎
- **[北村]**手が空いたのだから何か別のことをやっておいてもらおうはNG？
- **[北村]**まぁ遅延コストは当たり前だろうけど、遅延させない前提なら？
- [横田] デザインする人、プログラム書く人、テストする人と役割が分かれているチームの場合と、何でも出来る人が集まったチームの場合とでは違ってくる？
- [とく] タスクごとの達成の条件が狭まるとか、WIPのチェーンのQueueが工程ごとに明確化しなければならないというテクニカルに解くべきことが増えそうですね。
-
[とく] 作業を事前に定義できる前提だったら、100%稼働がいいよね、そうでないなら適応力をチームに持たせつつ、達成までのボトルネックを解消することで、プロジェクトを短くしよう、という話ですかね。テスターだからずっとプロジェクトに必要そうだけど、要件考えたりアーキテクチャ考える人だったら、人を解放する系の話をしときたいですね。
- [前川] 人を解放する系の話聞きたい 👍
- [とく] Non functional requirementとして、ユーザーで検証することが難しいもの（信頼性とか移植性とか）ってどうするんでしょうね。完了の定義の問題だーって言うのは別になんでもいいのですが。
- [前川] WFだとテストでさらっと紛れ込ませるんですが、Scrumだとどう混ぜるんでしょうね。そこまでやってないや。。。
-
[前川] え、バグトラッキング不要な儀式なん？「全ての」ってのがポイントか？
-
**[北村]**いわゆる要件定義や要求定義ってどのようにやってますか？
-
**[北村]**ストーリーカードのみ？
-
[とく] whatの話が不明確であればあるほど、ストーリーカードっぽくならざるをえないという印象を私は持っています（目的やペルソナのコンテキストからはじめて細かくいろいろかく）
-
**[北村]**今後の保守のためのドキュメントってどうやって作成してますか？
-
[北村] CleanCodeを書けという話は前提として。
-
**[北村]**仕様決定の背景や、複雑な仕様や、全体を俯瞰するようなものなど。
-
**[北村]**儀式的には作らない？ジャストインタイムで必要になったら作ってるだけ？
-
[とく] 経験上、コンポーネント配置と、Interfaceとテスト設計に時間をかける感じの進め方が結構よかったです。仕様はまあ細かい事かいたところで、そういうややこしいことがその先別者にしたくなるような場所じゃないですかね。
- [とく] この表って使い道ありますかね？誰用だろう。