Skip to content

Readingagilesamuraiinsapporo20120605

Jump to bottom Edit New page
irasally edited this page Jun 9, 2012 · 7 revisions

第22回読書会

  • http://atnd.org/events/29633
  • 2012年06月05日 19:30-21:00
  • エスプランニング開発室
  • 参加者 11人
  • 第15章 15.8 - 監訳者あとがき

最終回

15.8 この先どこへ向かえばいいのか？

  • インセプションデッキは「プロジェクトの開始」の時だけでなく、必要だと思った時にはじめればよいよ
    • 「アジャイル」という単語を出すことが許されない職場の雰囲気がある
      • アジャイルの用語を出さないで説明する、目的は同じだから受け入れられることも多い
      • 仲間を作っていく（自分が多数派になる）
  • 職場でアジャイル開発が一切許されなかったらどうすりゃいいの？
    • お客さんが乗り気にならないといけないからそこが一番の壁だよね
    • チームだけでインセプションデッキを作っても意味が無い？お客さんがいないと成り立たない？
      • チームの中で同じ事を共有できるから意味がある
      • やらないよりはやるほうが良い
      • お客さんロールの人を作ってやってみる -> お客さんの気持ちを考えてできるところまでやってみる
  • インセプションデッキとプロジェクト憲章は同じ事を実現したいもの
    • 最初に作っても、更新していかないと意味が無い、常に意味のある生きたものにしておきたい
    • 形骸化の危険性、形骸化してしまう問題はどちらにも発生している
    • インセプションデッキの方がシンプルだよね
  • 「もうやり残したことはないし、何もかもわかった」と思ったその瞬間、君はもうアジャイルじゃなくなる
    • そうだよなあ
  • 「現場の性質と状況に馴染むようにする」のが一番難しい
  • 「アジャイルでしょうか？」という質問
    • 「アジャイルでやってます！」「アジャイルをやってます！」「アジャイルを適用してます！」というのって、なんか違う気がするなぁ
  • お客さんに"アジャイル"とか"ウォーターフォール"という言葉を使った説明はあまりしないよね
    • 中途半端にお客さんに知識があると、開発プロセスについて口出しされる（「これでやって」「こういう方法は変えたくない」）
    • 全く知らないお客さんだと、説明しながら一緒に作っていくことができて、やりやすい
      • やり方をこちらに任せてくれる
      • 出来上がったものを見せながら作っていくと、風通しが良くなってくる
      • 「こういうことを実現してほしい」という目的だけがはっきりしている事が多い
    • アジャイルというバズワードが好きな人には「アジャイルっぽく」という言葉を使って、方法についてはこちらが具体的に提案していくこともあった
  • 請負開発でうまくやっていく方法
    • 単位を小さく、スパンを短く
    • 言葉の使い方が違う状態でスタートするのはとてもしんどいなあと思う
    • 大きい単位でストーリーが出てくるので優先度をつけながら実装している
  • 「お客さんとプロジェクトの進め方を共有すること」はインセプションデッキで実現できることとは違いますよね？
    • ミーティングの粒度とか成果物を定期的に見せるというのを決めるのってどのタイミングなんだろう？
      • ケースバイケースなんじゃないかなあ
      • お客さんが不安に思わないことが大事
      • わりとお客さんの感じを見て直感的に決めることが多いなあ
      • 割と早いうちに決めることが多いかなあ
        • 途中で足りないと思ったら増やせばいいし、多いと思ったら減らせばいい・・ということができたら良い
      • 進めながら、全体像が見えてきてからやり方を固めていく感じ
      • 週1回は絶対に必要だと思う、それは最初に言う
      • 可能であれば最初の1週間はお客さんのところで仕事をするとスムーズだよね
      • 成果物の内容は契約に関わってくるから見積もり時点で必要
  • 誰かにアジャイル開発を押し付けるのはダメだ：チームに取り入れてるために規範を示すことと、押し付けることの違いは？
    • 規範を示していても押し付けられている感覚になるのでは
      • これはどうしてもそうなるんじゃないかなあ
    • （一緒にみんなをひっぱって）初動に協力して、というのが押しつけになるんじゃないかなぁ。既に流れている流れに乗っかっては押し付けにならないんじゃないかなあ。
    • アジャイルって「精神の否定」をしないものなんじゃないかなーと思っている → 「このやり方はダメ」と言わないこと
    • 「これをみんなでやりましょう！」といって行動を強制することが押し付けなんじゃないかなあ
    • 説得のTips：こういう方法で説得していったほうがうまくいくんじゃないの、というくらいの意味なんじゃないかなぁ
    • 「誰もがその気になるわけじゃないという現実を受け止めねばならない」ということだよね
    • 「誠実に伝えること」
    • 「とりあえずやってみる」ことをやりながら試行錯誤していく
  • 現実問題、テクニカルな方面で必要なプラクティスについては押し付ける（出来る人が引っ張る）のも大事だと思う
  • 開発手法に関することに興味をもって学ぼうと思っているきっかけってなんなんだろう
    • もとからそれが好き
    • 何かで危機を感じた時
    • なかなかメンバーは開発手法について学ぼうという意欲がないようだ・・・
      • プログラミング側のことが好きだからかも
      • チーム全体について考える立場に至っていないというのも考えられるね
      • 現状に満足している、変えたいという強い気持ちがないから学びに繋がらないのでは？
  • 指導・教育についてみんなどうしている？足りないなあと思うことが多いよ
    • ドキュメントや文章を書くこと
    • 論理的思考
    • 訓練
    • お客さんとのやり取り、質問、論理的な話の上で成り立つ相互理解、コミュニケーション
    • 教育、育てたり伝えたりすることの責任

アジャイルソフトウェア開発の原則

  • せっかくここに書いてあるのでちゃんとこのタイミングで読んでおこう
  • アジャイルソフトウェア開発の12の原則はアジャイルサムライの本の中に全て出てくる → 1個だけ出てこない？（8がでてこない）

監訳者あとがき

  • しっかり読みましょう
  • そして読んだことや感じたことをもちよって、おかわりしましょう：http://atnd.org/events/29662
  • "読者の皆さんにとって、ソフトウェアを作るという仕事の価値は何でしょうか？" → 宿題！

札幌道場 終了！！！！

Add a custom footer
Add a custom sidebar
Clone this wiki locally