読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

第10回 TFSUG に参加しました

勉強会

7月13日 第10回 TFSUG:ざっくりわかるScrum and Team Foundation Server #tfsug(東京都)
19:00-21:00 日本マイクロソフト品川本社

「ざっくりわかる SCRUM AND TEAM FOUNDATION SERVER

講師は @ryuzee さんです。スライドに書いてないトークを中心にメモしたので公開します。後でスライドも公開されるそうです。

  • アジャイルの適用領域
    • ビジネスが速くなった!
    • 新しいことにチャレンジする必要が出てきた!
    • 不確実性に対応する
  • ウォーターフォールの適用領域
    • 対象のドメインが変化しない
    • やったことのある領域
  • アジャイルの考え方
    • スコープとリソースを総量規制する。
    • 優先順位は状況によって変わる。
    • 無駄なものを作ってはいけない。
    • 頻繁に確認と調整を行うので、無駄なものを作らない。
    • 開発チームはメンバーが揃えば製品を作る能力が揃う。
      • DBチーム、基盤チームみたいにレイヤーでチームを分けるのはアンチパターン
    • 会社の上下関係をチーム内に持ち込んではいけない。
    • 最良のやり方を自分たちで決める。
      • 言われたことを言われた通りにやっていればよい人は向かない。
    • 会社の規則に縛られない。
    • 一定のリズム(スプリント)で意思決定と確認を行う。
      • 問題を長時間放置しないため。
    • スプリントごとに計画会議を行う。
    • 出荷可能な製品を作る。
    • 完了を定義する。やらなきゃいけないことを決める。
    • ものを作るのはチームの責任。連帯責任。助け合う。
    • デイリースクラムで進捗状況を確認する。
    • スクラムマスターはチームへの妨害を排除する。
  • プラクティス
    • ソフトウェア開発に自動テストは必須。
      • 自動化しないとテスト工数の占める割合が増加して、価値への投資が相対的に減少する。
      • ビジネスの流れに開発がついていけなくなる。
    • チームの能力によって開発スピードが決まる。
    • プランニングポーカーで相対見積もり。
      • 絶対見積もりは難しく、精度は高くない。
    • We love TFS and Excel.
    • プロダクトバックログをインデックスカードに印刷するといいらしい。
      • 壁に貼っておくと何かと便利だよね。激しく同意。
    • タスクに着手する時に自分でサインアップする。
      • タスクの計画時に人を割り当てない。自分のタスクしか興味がなくなってしまうから。
    • タスクがあと何時間で終わるかを管理する。
      • 何時間かけたかは管理しない。
    • ツールがあっても対面のミーティングを重視する。
    • データを抽出して振り返りに活用しよう。
  • 振り返り
    • あなたの目的は何?
    • Scrumはビジネス価値を実現するための手段の一つ。銀の弾丸じゃないよ。
  • 質疑応答タイム
    • チームメンバーのスキルレベルがある時の計画は?
      • 最初の計画はスキルのある人だけでやってもいい。
      • できる人に仕事を集中させるより、チーム全体を育てる方が楽になる。
    • TFSのタスクボードは無味乾燥ですがご感想を。緊急対応を表現したい。
      • 何とかして欲しいなぁ…MSさん(笑)
      • 色付け、レーンのカスタマイズ、順序づけ等ができると嬉しい。
    • 相対見積もりの基準は?
      • 例えば、最も小さなタスクを1ポイントとするとか。
      • 1st スプリントで開発の速さ(ベロシティ)が分かる。
      • エンピリカルアプローチ(経験主義)
    • 全体の開発が終わる見積もりは?
      • スプリントを繰り返すごとに予測精度が上がる。
      • リリース日とチームの人数を固定して、チームの速さを計測しよう。
      • 作ったものの64%は実は使われなかったというレポートもある。
    • どういう契約形態が向いているのか?
      • 一般には準委任契約が向いている。
      • 顧客はチームのベロシティに不満があれば契約を切ってもよい。チームは頑張るインセンティブがある。
      • 一括請負と非常に相性が悪い。スコープ可変、金額固定の契約にするなど。
      • お客様、マネージャや営業を変えよう。
    • 最適な人数は?
      • 最初から大規模なScrumに取り組んではいけない。
      • 1チーム5人程度から始めるのがおすすめ。
      • みんな設計や実装やテストやインフラ構築ができれば3〜4人でもできなくはない。
  • https://tfspreview.com で試しにTFSを使ってみよう!

変なところがあったら教えてください。質疑応答はヒアリング&タイピング能力の壁を感じましたw

ここでエンピリカルアプローチという言葉が聞けたのは意外でした。アジャイルプロジェクトの定量分析はフィードバックのインプットになるし、研究に対する需要もあると思うんだけどなぁ。いつかそういう仕事をしたい。