radioc@?

レディオキャットハテナ

【勉強会メモ】スクラム道関西 第104回オープン・ジャム

scrumdo-kansai.connpass.com

  • 日時:2018/05/09(水) 19:00 〜 21:00
  • 場所:TAM COWORKING OSAKA

スクラムマスターの存在価値を理解してもらうには

  • スクラムで開発してよかったと言える価値を追求する
    • 稼働率や生産性などの従来型と同じ土俵で評価することはあまり意味がない
    • チームのために奉仕しメンバーと一緒に問題に向き合う
  • スクラムマスターがタスクを握ってしまうのは良くないがチームを前進させるためにはコードを書くことがダメなわけではない
    • チームが把握できていない技術などは調べて試してみても良い
    • メンバーに良いやり方を示す
  • スクラムに対する思いが強い人がスクラムマスターをやるケースが多い(言い出しっぺとしてやらざるを得ない)
    • スクラムについては誰よりも詳しくなってチームを引っ張っていける方がよい
  • ビジネスサイドに対してはチームの成果を自分の手柄と言うぐらいのアピールをしても良いかも

少人数チームでのレビュー

フロントエンド担当、モバイルアプリ担当、バックエンド担当などの分業による少人数のチームで担当分野をレビューしてもらえない場合どうするか?

  • スクラム的には機能横断型チームが望ましい
    • メンバー自分の担当領域以外に関心が無くなる
    • 他人の領域をレビューして責任を負いたくない
  • 専門ではなくてもチームで互いにレビューできる環境のほうが良い
    • レビュー(品質対策)を担当者の問題ではなくチームの問題ととらえる
    • まさにスクラムをやるべき環境かもしれない
  • 最初はペアプロやモブプロのような形で自分の担当範囲の説明を聞いてもらう

デザイン思考とは

最近話題になったこの記事より

medium.com

そもそもデザイン思考とは?

調べてみた。

ferret-plus.com

デザインしたサービスやプロダクトの先にある ユーザーを理解し、仮説を立て、初期の段階では明らかにならなかった第二の戦略や代替する解決策を特定するために問題を再定義する、一連の問題解決の考え方のこと

5つの段階(共感、定義、概念化、試作、テスト)はUI/UX系の勉強会で何度か見たことがあるなぁと思いだした。

スクラム開発の実践より前段階でのPOやビジネスサイドが使うフレームワークの1つと言えそう。

下記の本がわかりやすいとのことで紹介していただいた。

まんがでわかるデザイン思考

まんがでわかるデザイン思考

自動化の取り組み

  • テストをどこまで書くか
  • 環境調達の問題
  • 静的解析の自動化はレビュー効率化や細かいレビュー指摘による関係悪化を回避できるメリット
  • 本番デプロイの自動化が誰でもできるのはやや不安はある
  • 自動化しすぎてJenkinsおじさん頼みになるつらみ
    • 体力がある会社にはビルド専門部隊がいる

社内LTの広めかた

  • 発表者と発表内容を事前に調整する
    • エンジニア以外の部署を巻き込む
    • 影響力のあるゲストを呼ぶ
      • ヴァル研究所さんの駅すぱあとの生みの親による勉強会の事例
  • 参加しやすい時間の考慮(昼休みなど)
  • みんなが興味のありそうなテーマを決める(各チームの障害事例共有など)
    • 自由に発表したい人にはテーマを決めずに任せるほうが発表してもらいやすい