いつでも発展途上

猫と珈琲とゲームが大好きです。ITエンジニアらしいです。メモ代わりにいろいろ書いています。

ドラクエ10の提案広場で見つけたちょっと好きな話

ゲーマーを自称する自分ですが、DQ10が面白すぎてほかのゲームに手がつけられないのでわりとだめっぽい状態です。おもしろいんですよDQ10
このDQ10、公式サイトにユーザーからのご提案を受け付ける「提案広場」っていうのがあるんですが、そこがわりと提案広場っていうよりも不満広場って感じになっていて、どれだけ実現可能性が低い提案ができるか競っているのではというぐらい日々カオスな提案が読めます。
「2ヶ月に1度バージョンアップとか言ってるけど、本当はもうできてるんでしょう?はやく出してよ」とか、「お金を倍払うからもっと早く機能を追加して」とか、一応 IT 屋さんのはしくれとしては寒気がするような提案もたくさん載っている、なかなかスルリングなところです。
で、そこにこんなステキな意見が載っていまして、ブクマまでしたのですが元記事が消えてしまっていたのでバックアップのためここに引用しときます。

タイトル:同じでなくたっていい
書いた方:キョウ
内容:
勇気を振り絞って放った渾身のギャグがスベったとき、みんなと感覚がズレてる人が居てその人だけ大爆笑・・・みたいな経験ありませんか?
こういうことに限らず、ズレてる人に救われることってあると思うんです。
同じ感覚の人が集まると、摩擦も無くて心地良いですけど「調和を乱す奴は許さない」みたいな空気になりがちな気もします。
悪い方向へ向かい出したときに歯止めが利かない怖さもあります。
自分の感覚から見てズレてると思う『変な人』っていうのを少しだけ認めて、自分の世界の片隅にその存在を置いておくと、それがいつか自分を助けてくれる事があるかもしれませんよ。
大多数が「変な意見」と思ったからといって、その意見を排除できてしまうような提案広場にはならないで欲しいと思います。

これを読んで、いいこと言うなぁ、とわたしはしみじみディスプレイの前で思ったのでありました。

kobo Touch を買ったので感想とかを書いてみる

じつは先週、楽天 kobo Touch を入手してました。発売日に。
この手の電子書籍リーダを所持していなかったので(iPad除く)興味本位で注文してみましたが、

  • 初日にアクティベーションできない人(私含む)が続出
  • EInkの扱いに戸惑う人々の不満続出
  • その他いろんな不具合がどどんと続出
  • 楽天レビューは大荒れで封印→非難を浴びる

というかんじで世間的には散々な出だしだったようです。が、個人的にはけっこう気に入ってます。
なんといっても 軽い です。毎日持ち歩いても気になりません。私みたいな体力がスライム級の人間にはこれほどありがたいことはありません。これだけで自分の中では他の端末に大勝利です。
が、初代 iPad を毎日持ち歩いても平気な方には関係ない話かもしれません。
そして USB でつないで手動でファイルを放り込めば読めるというぞんざいな わかりやすい扱いができるのも良いです。達人出版会 とかで買った本を読むとかなり快適です。
が、これも手持ちの .pdf やら .epub なファイルが無い人には関係ない話かもしれません。
逆にあんまり気に入ってない箇所は、セットアップがとにかく超めんどくさかったことと、ストアで本が探しづらいところ、そしてオライリーの PDF な ebook が読みづらいことです。特に最後のは痛かった。
ストアについては、わたしにもっと英語力があれば、洋書がたくさん買えるみたいなのでお得感が増したかもしれないです。いろんな意味で今後を見守って行きたい kobo Touch です。

「塹壕よりScrumとXP」読書メモ (3)

前々回前回 にひきつづき「塹壕よりScrumとXP」の読書メモです。自分用ですので全くまとまっていませんし、誤りがあるかもしれません。(まさかこんなに長くなるとは…)

スプリントバックログ(続き)

  • スプリントを始めるたびにきれいなバックログが作られる(紙を張り替える)
  • 重要度の高いストーリーを上に貼る
  • バーンダウンチャート
    • 縦軸にストーリポイント、横軸に日付を取った折れ線グラフ
  • 危険な徴候
    • 線が上にふくれる:見積りより遅い。バックログアイテムを減らす
    • 線が下に下がる:見積りより早い。バックログアイテムを増やす
    • 下のストーリーから終わってる:重要度を間違ってる!
    • 計画外アイテムばかり終わってる:スプリント計画が…!!
      • 計画外アイテムとは、文字通りスプリント計画になかったアイテムのこと。
      • (アイテムって言葉は、ストーリーまたはタスクのことかな?)
  • トレーサビリティはどうなってるんだ!
    • 毎日デジカメで撮る
    • でも、そんなに重要じゃないはず
    • 気になるならホントの価値を見積もってみよう
  • 見積単位
    • 1実効人日=6実効人時
    • (7や8じゃないし、ましてや10や13なんかじゃない!)
    • ストーリーは時ではなく、日単位で見積もっている
    • 0.5が最小

チームの部屋をどう改造するか

  • 設計コーナー
    • のびのびと設計できる(日本じゃ難しそうだ〜)
    • 重要な設計ドキュメント、タスクボードなどを貼る
  • チーム全員同席!!
    • 席を移動するのはめんどい。でも、効果的なチームを作りたいなら他の選択肢はない
    • 大事なこと:声の届きやすさ、目の届きやすさ、隔離されていること
    • 専用の部屋があれば一番良い
    • POはチームと同席すべきじゃない (近くにはいたほうがいい)?
    • マネージャやコーチは、緊密に関わるべきだが、あるときは自律に任せること

どうやってデイリースクラムを実施するか

  • タスクボードの近くで、毎朝、立って話す。ポストイット、バーンダウンチャートを更新する
  • ルールを決めて、それを一貫させること
  • スクラムマスタが全部やるのは非効率
  • (最初に運営ルールをまとめておくのは大事そうだな)
  • 遅刻したら缶にコインを入れる。溜まったお金はチームのイベント等に使う(これ面白い)
  • やることがない人がいたとき
    • タスクボードを流して、考えさせる
    • ペアプロする
    • 終わってないものがないかチームに尋ねる
    • 次のスプリントから追加する (POに知らせること)
    • それでも駄目なら…
    • (なるべく自律的にタスクを発見できるように人を育てるのが大事ぽい…)

スプリントデモをどうやるか

  • デモは、何があってもしなければならない。たとえできていなくても!
  • 厳しいルールだが、得られるものは大きい
    • 目標が毎週達成されるので士気があがる
    • チーム外の人にも結果がわかる。チーム間のやりとりが発生する
    • お客から生のフィードバックがある
    • 確実に作業を「完了」できる (99%の未完より、少ない完了)
  • チェックリスト
    • 成果物がなにかを説明できてるか
    • 準備に時間をかけすぎてないか(派手なプレゼンは不要)
    • 美しくより、手際よく
    • 技術より、ビジネス視点で
    • できれば見ている人に触ってもらう
    • あんまり細かすぎる話はしない
  • 「10000ユーザの負荷テスト」みたいなデモできない話は、テスト結果レポートを見せて説明する、のでもよい

スプリントのふりかえりをどうやってするか

  • 起こったことを明確にする。改善の大切な機会
  • チームの外の部屋ではやらない
  • PO+チームで実施
  • スプリントバックログを見ながら、できごとを一巡りする
  • 見積と実際の速度がちがうところは、要因を分析してみる
  • 次スプリントへむけてのブレスト。良かったこと、もっとよくできそうなもの、改善点 (KPT?)
  • それらにチームで投票し、次にやることを決める
  • チームが得たナレッジは他のチームにも共有した
    • マネージャが非公式に動き、他のチームのふりかえりで広めたりした
  • 問題を明確に認識さえすれば、それは自然と解決していく
    • なにか不平を言うたびに新しいやり方を導入していると、みんな問題をあげるのが嫌になってしまう
  • 典型的なふりかえり事項
    • 「ストーリーをブレイクダウンする機会をもっと増やそう」
      • 問題を認識したことで、次のスプリントでは皆がそう動く
      • 繰り返し起こるならスプリントの期間を長くする
    • 「外部の邪魔が多い」
      • フォーカスファクタを低くする
      • 邪魔する人をメモっておく
      • スクラムマスタかPOを通すよういっておく
      • 持ちまわりで「ゴールキーパ」を設定し、そこに全部の邪魔を流すようにする
    • 「仕事抱えすぎた」
    • 「作業環境がうるさい、汚い」
      • 環境を改善するか、いっそ移動する。上位管理者への働きかけ
      • (これは気にする人と気にしない人の同居がむしろ問題になったなー、自分の場合)

スプリント中の休憩期間

  • 休まないと死ぬる
  • スプリント間に休憩期間がまったくないと、チームもPOも情報を整理する期間がなくなってしまう
  • スプリント振り返りとスプリント計画はちがう日にする
  • 「自由研究日」を設ける (Googleみたく)

リリースの計画と価格確定させた契約をどうするか

  • この質問に答えるよう試みる:「この新しいリリースバージョン 1.0 を、最も遅い場合、いつ納品できるのか」
  • 価格確定された契約の場合、最終的になにを納品すべきか判別するために、重要度に「しきい値」を設ける
    • 例:重要度100以上のアイテムは1.0に含めないと死刑に処される。
    • 例:50〜99は含めるべきだが、速やかな追加リリースでもいいかもしれない。
    • 例:etc...
  • 重要度の高いアイテムは、あらかじめ見積もっておく必要がある
    • 正確さのため、チームに見積もらせること
    • あまり時間をかけすぎないこと
    • 見積は確定したものではないことを理解すること
  • フォーカスファクタを決め、チームのスプリント速度を見積もる
  • ここまでできたら、最終的な納品日までの期間に、ストーリーを重要度順におさめていく
  • 現実はそのとおりにはいかない。スプリントごとにお客さんと調整しよう
  • 真剣に学びたいなら「アジャイルな見積と計画づくり」を読もう (うう、買ったけど未読…)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ScrumとXPの結合

  • XPはプログラミングに、Scrumはマネジメントと組織に、それぞれフォーカスしている
  • かぶってるプラクティスはScrumに従った
  • ペアプログラミング
    • コードの品質が高まる
    • 相互チェック「おいおい、この機能はほんとにこのスプリントに必要かい?」
    • 非常に疲れるので常にやるのは無理
    • 知識がすごい早さで共有される
    • ペアプロがあわない人もいる
    • コードレビューも兼ねられる
    • 強制はしないこと
  • TDD
    • 難しい。習得に時間がかかる
    • ペアプロで習得するのが効率的
    • 設計によい影響をあたえる
    • 新しく立ち上げたチームで始めるには時間がかかる
    • しかし、得られるものは大きい
    • 既存の(TDDでない)システムでTDDするのはとても大変
    • 手動の回帰テストを楽にする方法を先に考えること。TDDはそのあとでもよい
  • インクリメンタルな設計
  • CI
    • CIサーバは審判
    • チェックイン→ビルド→失敗するとメールが来る
    • 仕組みをつくるのは手間がかかるけど、その価値はある
  • コードの共同所有
  • 情報満載の仕事場
  • コーディング規約
  • 安定したペース、活気ある作業
    • すぎた残業は、生産性と品質を犠牲にする

テスト

  • 受け入れテストは避けられない!
  • チームのコード品質をあげることで期間短縮はできる
  • テスタをチームに入れる
    • テスタは「完了」を通知してくれる。デモにも最適
    • まだテストするものがないときは、環境づくりをする
  • スプリントの作業量を減らし、受け入れテストサイクルを短くする
  • 次のスプリントで、受け入れテストチームが発見した前のスプリントのリリースのバグを直すはめになる
    • 混乱する
    • うまい解決策はあるのか?
    • 1:古い機能が未完成であるうちは、新しい機能に手を付けない
    • 2:新しい機能に手をつけてもいいが、古い未完成の機能を優先する
    • スプリントの間に長さ不明なリリース期間を設けるのは、スプリントのリズムを崩すのでお薦めしない
  • 受け入れテストから戻ってくるバグフィックスを考慮にいれてスプリント計画を立てる
  • 良いテストツールや自動テストを使おう

複数のScrumチームを運営する

  • 大きすぎる少数のチーム > 小さな分割されたチーム
  • バーチャルチームの存在
  • チーム分割は本当に難しい
  • 最適なチーム規模は 3-8 人
  • 複数チームのスプリント期間は同期させたほうが効率的
  • チーム割り当て
    • 最初だけえらい人が決めて、あとは自律的な解決にまかせる
  • コンポーネント(DB, フロント等) に特化したチームはうまくない
  • チームを再編成するときは、それが一体化を壊す可能性を意識する
  • 「一時的なチームメンバ」を入れることはよくない
    • ("客先常駐"の商売とは相性が悪い考えですな)
  • Scrum of Scrum
  • (この項、あまり理解できていない)
    • だいたいは報告の場になる。大抵の人は情報に飢えている
    • デイリースクラムを同時に行わないことで、POやマネージャが参加しやすくする
    • 火消しチームにScrumチームを守らせる
  • 複数チームがいる場合も、POとバックログは1つ

地理的に離れたメンバーがいる場合

  • Webカメラ、ヘッドセット、会議マイク、デスクトップ共有などのツールを駆使する
  • 別の拠点につながる「遠隔ウィンドウ」をつくる
  • 定期的にお互いを尋ねる(物理的に)
  • オフショア開発
    • 離れたチームではなく、離れたチームメンバからはじめた
    • 最終的には、離れたチームに行き着くだろう
    • (あまのりょーさんの MY JOB WENT TO VIETNAM? を思い出しました)
  • 在宅勤務
    • 全員同席プラクティスとの兼ね合い
    • Skypeでデイリースクラムに参加
    • 特定の日だけ在宅にするとか
    • (チームによって適切な方法はかわりそう)

Scrumマスタチェックリスト

ここまで。明日のCSMが楽しみ!
大切な事は、自分の仕事の現場で最良な方法をつねに模索し続けることだと理解しますた。

「塹壕よりScrumとXP」読書メモ (2)

昨日に引き続き「塹壕よりScrumとXP」の読書メモです。自分用なのでまとまっていません。かっこ内は自分の感想です。

スプリント間のコミュニケーションについて

  • 「スプリント情報ページ」をつくり、何が起きているかを明らかにする
  • URLをメールし、紙に書いて貼り出す
  • デモの予定も知らせる
  • 「何が起こっているかわからない」と言わせない
  • (徹底した情報公開。エンジニアのマインドセットも変更が必要そう・・・)

スプリントバックログ

  • スプリント計画ミーティングと、最初のデイリースクラムのあいだにScrum Masterが作成する
    • (この日は遅くなるね!)
  • スプリントバックログを書くには、壁のタスクボードがよい
    • (Excelでいろいろ試したあとでの結論らしい)
  • ホワイトボードは埋めないほうがよい
  • 付箋はテープで貼らないと落ちる
  • タスクボードの要素
    • Not Checkout: スプリントの作業前ストーリと、そのタスク。
    • Checkout: 作業中のタスク。
    • Done: もはや誰の作業も不要なタスク。全タスクがDoneになったストーリーはDoneになる。
    • Unplanned items: 計画外アイテム (?)
    • Next: つぎのスプリントに含めるストーリー?

時間切れにて中途半端ですが、今日はここまで。

「塹壕よりScrumとXP」読書メモ (1)

こんど Henrik さんの CSM を受講するので「塹壕よりScrumとXP」をちゃんと読んだ。

はじめに

  • Scrum はフレームワーク。どうやるかまでは教えてくれない。これはぼくの戦争体験談だ (!!)

プロダクトバックログ

  • 実現したいストーリーの集まり。Scrum でいちばん重要なもの
  • 重要度は一意になるようにつける。あとでPOがソートできるから
  • PO (顧客) の言葉でわかるように書くことがだいじ
    • (俺は実装するだけだから、みたいな人ばかりだと無理ってことかな)
  • PO が重要度を決め、チームが見積もりを出す。逆はやっちゃだめ
  • Excelが顧客にやさしいときもある。ツールの選択は柔軟に

スプリント計画ミーティング

  • スコープ、重要度、見積もりという3つの変数について話しあう場
  • POが参加してくれない問題をどう解決する?
    • わかりやすく説明して説得する
    • 代理人をたてる
    • 参加できるまで延期する
  • 内部品質と外部品質
    • 外部品質はユーザにわかるもの。使いやすさ、操作性の良さなど
    • 内部品質はユーザには見えない。コードの質、テスト結果など
  • 外部品質はスコープとして扱える(=交渉できる)が、内部品質はできない
    • スコープとして扱うと、保守性が下がり、かえってコストが高くなる
    • 例:「これ応急処置でやっちゃおう」
    • POはこのことを学習してくれる
  • ミーティングは短く終わらす。タイムボックスをからだで覚える
  • スプリントの最適な長さはいろいろ試して決める
    • 決まったら固定する
    • 著者のチームでは3週間だった
    • 長さが決まると快適になってくる。リリース日についても悩まない
  • スプリントのゴールを決めるのはむずかしい
    • でも、ないよりはまし
    • 「どうしてこのスプリントを実施しているのか?」をつねに考える
  • プロダクトバックログ→スプリントバックログ への移動
    • ストーリーの大きさでスプリント中にやれる事が決まる
    • だから相対見積もりがだいじ
  • スプリントに含めるストーリーが何かはチームが決める
    • POではない
    • 含まれたストーリーが不服な場合、POは他のストーリーのスコープを変えたり、分割したりして調整できる
    • (外部品質を別ストーリーに移したりってこともあるな)
    • (ここが一番「これ応急処置でやっちゃおう」になりそうなので気を付けないと)
  • 見積もりはどうやるか
    • 小さいチームなら直感で決められる
    • 見積速度:1スプリントで完了したストーリーの大きさ
    • 稼働人日×フォーカスファクタ=見積速度
    • フォーカスファクタは前のスプリントを参考にして求められる
  • コンピュータ上でストーリーの洗い出しをやっていると、問題点に気づきづらい
  • PCをいじってる人以外は、自分が参加してるという意識を持ちづらくなる
  • だからインデックスカードを使うお!!
    • Excelからカードを自動生成する (!)
    • チームがホワイトボードにカードをはる
    • カードは重要度順に並べ、タスクに分割し、付箋をはっていく
    • POがExcelに反映する
  • ストーリーごとに完了の定義をきめるのはだいじ
    • 厳密なチェックリストより、直感を重視する
  • プランニングポーカー
    • チーム全員がストーリーを理解するのを助ける
    • 相互協力できるようになる
  • ストーリーを明確にする
    • ストーリーに対する誤解を避けるには、ぜんぶのストーリーについてちゃんと(POのいる場で)話し合う
    • (わかったふりして飛ばすとそこで躓くのは、よくありますね…)
  • ストーリーが小さすぎたり、大きすぎるときは要注意
  • タスク分割はWF的に感じられる場合もある?
  • Techストーリーについて
    • 直接顧客への価値にむすびつかないけど、やらないといけないこと。例えばCIサーバの構築とか
    • 通常のストーリーに組み入れられないか検討してみる
    • 無理そうならTechストーリーを作成。(POは編集できない)
    • Techストーリーの実施によってどのようなメリットがあるのか、POにきちんと説明する
    • POがTechストーリーの重要度を理解できるなら、判断してもらうのがベスト

うーん、盛りだくさんだー。(つづく)

超いまさらですが RubyKaigi2011 に1日だけ参加した感想です

超いまさらですが、下書きが発掘されたので。
今年の 7/16〜18に行われた RubyKaigi2011 に1日だけ参加しました。RubyKaigi にはずっと来たかったので、終わる前に来られてよかったです。
以下、個人的な感想ですが、メモがわりに残しておきます。

  • SIerのなかのRubyistが考えるべきこと 素晴らしい講演。グッときました。
  • アーロンさんの基調講演。境界についてのたくさんの問題提起。オープニングに相応しい引き込まれる内容でした。道場movieに大受け。
  • アジャイルサムライ」買えた!「7つの言語、7つの世界」も。matz さんのサイン一番乗り。
  • 地下の AgileUXD がとてもおもしろそうでした。試みも、作っているものも。
  • 闇RubyKaigi では勢いあまってLTドタ応募してしかも gdgd でごめんなさい。
  • 個人的にとても嬉しかったのは休憩時間にかくたにさんが 7月6日の DevLOVE の感想を述べてくださったことです。Rubyコミュニティにはああいった場は少ないから良かったと。ありがとうございます、励みになります。
  • IRCでの同時通訳がすごかった。本当にすごかった。
  • スタッフの皆様、お疲れ様でした。素敵なイベントを開催してくれてありがとうございました。

アジャイルサムライ読書会(湯島道場)に参加しました。

7月27日に湯島で行われた アジャイルサムライ読書会 湯島道場 に参加してきました。読書会の詳細については、リンク先にわかりやすい解説がありますのでぜひご覧ください。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

…といっても、当日は残り10分足らずという状況での駆け込み参加。道場の皆さん、バタバタしていてごめんなさい…。しかしそんな短い時間でも興味深いお話を聞けたので、メモしておきます。

みんな悩んでいる

こうした道場に来る方々ですから皆さんアジャイル開発に興味を持たれているわけですが、やはり共通の悩みとは「どうやって導入するか」のようでした。お客さんを巻き込めない、まわりが無関心…
しかし、そんな中でも悩みを一人で抱え込まず、こうした場で共有することで第一歩が踏み出せるだろう、というお話がありました。たしかに、一人で悩んでいても始まりません。
悩みを共有できる、読書会のような場は貴重だと改めて感じさせられました。

懇親会でのお話

懇親会でもいろいろといいお話があったのですが、思い出せる限りで書いてみます。

  • Manage It ! を並行して読むといい感じ。どちらも実戦系の内容だから
  • SIで元請けの下にいくつも下請けがいると牽制しあってチームがつくりづらい。ぶっちゃけ(チームづくりにその構造が)邪魔という話もあるが、プロジェクトの目的を共有することで足並みを揃えられるかも
  • アジャイル=PANDA(Poor And No Discipline Agile) ちゃんと理解しないままアジャイルという言葉がひとり歩きするのは怖い
  • スカイツリーを先端からも作れるのがソフトウェア開発(自由な発想!)
  • 勉強会にいるすごい人とそうでない人の一番の違いは、申込フォームの参加するボタンを押せるか否か

まとめ(になってないまとめ)

アジャイルサムライ、まだ7章までしか読めていませんがとても良い本です。ふつうの本ではなかなかお目にかかれない「プロジェクトのはじめ方」をはじめ、ソフトウェア開発の奥義をとってもわかりやすくかつ濃い内容で説明してくれます。実践したくなるヒントが多く詰まっている本だけに、読書会の存在は重要だと感じました。
開催してくれた @ShiroKappa さんをはじめとするスタッフの皆様、ありがとうございました。次回は定刻に来る or 早めキャンセルを心がけます (滝汗)。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

Manage It! 現場開発者のための達人式プロジェクトマネジメント