BETA

昨日TDD&モブプロを初めてしたエンジニアがTech-on MeetUp#03「Agile for Developers ~やってみよう!お作法だけじゃないアジャイルレシピ~」に参加してきた[20181113] #TechOn東京

投稿日:2018-11-13
最終更新:2018-11-13

11/12のtddyyχに参加して、初めてTDDとモブプロを実体験した私が、
次の日のTech-on MeetUp#03「Agile for Developers ~やってみよう!お作法だけじゃないアジャイルレシピ~」 に参加したので、
とりあえずメモったことを書いていきます。


「テスト苦労開発、あるいはTDDの夢」

https://speakerdeck.com/yattom/tesutoku-lao-kai-fa-aruihatddfalsemeng @yattomさん

  • テストは自分のため
    自動テストゼロよりもあるだけマシ
    ない状態からの最初の一歩としてやりやすいところから作っていく

    人の尻拭いのためではなく、書いた自分が死なないため、 責任と自信を持てるためにテストをする。
    言われたから、必要だからではなく「自分のため」

  • 小さい時に最初にテストも作っておく 高速でレガシー化していくコードに対して、自動化テストをしたいモチベ→実装に
    最初のテストを作離始めるはいいが途中脱落しやすい(サービス間等の壁が存在する)
    途中からテストを作るより、最初にテストを作る方が楽
    何を作ればいいのか手探り、状況では価値のあるテストを書くのは困難。
    小さい時に最初にテストも作っておき、一緒に大きくしていくが重要
    正常パターンを1つ作っておくだけでも違う
    モデルだけとか単機能から徐々にDBやフロントを巻き込んで大きくしていく

テストも技術的負債になり得るので、プロダクトに求められていることと品質を考慮しながら、開発者は考えていこう


「SkyWayの開発現場 いつの間にか最高のアジャイルチームになっていた件について」

[email protected] Com
https://www.slideshare.net/iwashi86/skyway-122781277

  • プロセス
    • キャパシティプランニング 各メンバの予定から使える時間の算出する(曜日ごととか)
    • 見積もり
      • Plannning Poker
      • Reference Task これまでのタスクを評価するためにポイントにするにして明確に
    • プロダクト・スプリントバックログ管理
      • Trello
      • Huboard
      • Taiga
    • スプリントレトロスペクト(スプリント振り返り)
      • Google Slides 曜日でコピペ
      • KPTの問題 Problem/Tryが出にくくなる
        1. タイムラインを全員で作成
        2. 各個人の重要な出来事を書く
        3. 他のメンバがアイディア、コメントを追記する
        4. 投票が多いものを深堀、アクションの抽出を行う
      • デイリースクラム の前にプロダクト全体のトピックの共有・相談をして、優先度などに反映する
  • 技術
    • TDD
    • ペアプロ,モブプロ
      • 結構、「やったー」は重要。笑ったりでも心理的安全性は上がる
    • リファクタリング
    • CI/CD
    • ベストプラクティスを選択する
  • 人・チーム スクラムの3本柱
    • 透明性
      • 現状、問題の見える化で共通理解ができる
    • 検査
      • 現状や問題がないかを確認する
    • 適応
      • 問題があった時に改善策を考えて対処する

透明性の高め方

  • チームビルディング合宿
    • 汎用的なものが少ないため、探しても出て来ない
    • 普段と違う場所でモチベ(自分探し?)の共有
    • 「半年、1年後に何をやりたいのか?」
      • その人のモチベの最大化につながる
    • アンカンファレンスで自由に
    • ポエムを書く
      「なぜ、今この仕事を?」を書く
      • コストはかかるけど、重要
    • 自己開示 <ー> 心理的安全性 ニワタマ問題
      誰かが先陣を切る&強制をしない → 自分が先陣を
  • 開発合宿

    • POやDevRelも参加して交流をもつ
    • 開発テーマは自由
  • なぜ、できたか?
    ステークホルダーからの理解

  • 上司、上長が采配権限をもつ → 彼らからの理解が必要
    権利と責任をセットでくれるような人を擁護者にする

  • それでも無理なら


「モブプロを導入してみた話」

 佐野 友則さん@KDDI

モブプロの導入によって出てきた問題

  • 自分の時間がなくてしんどい
    • 程度が人によって異なる
  • 学習は効果的
    • Android <-> iOS 「できるようになった気がするだけで一人でできるか不安」
  • 先生、生徒役が分かれる
  • 全員で作業がなれると、全員がいないと決定できない

  • モブプロのせいだけでなく、ファシリテートの部分もある。
    モブプロは混乱期、統一期が一番活躍するが、
    形成期で導入して成功体験がないと、ものができないなどで不安がおおきくなるため、辛い時期を過ごすことになる

モブプロとペア、ソロプロの区分が必要

  • モブプロが早いかどうかは微妙 小さく作れるけど、納得できるものがでてくる = チームの集約できる
  • ペアプロやソロ 暗黙知は増えてくるが、軽快な対応が可能

  • 準備期間でチーム力を上げるためにモブプロ 1 day 模擬案件

  • 受託、契約がとれたら、ペアやソロ 1week スプリント

チームがこういう状況で、こういう案件だから
-> モブプロで、 or ペア、ソロで
を区分できるようにチームが判断できるようになるのがベスト

時間、労力、コストがかかるけれども、チームを維持し続けるのは大事

チームを勝手に解散するのはやめて!!!


「超アジャイルの基本(仮)」

Start with WHY

  • なぜ、ここにいる?
  • なぜ、アジャイルに興味を持っているのか?

  • 解決するベクトルが重要 Why -> How -> what
    どんな問題があるから→どんな手段をとって→どうなったか
    のHowに注目しがちだが、現場が→に流れていくそのベクトルが重要

なぜ、ボトルネックになるのか、もっといい方法がないかを探す。
次々に出てくるWhyに向き合い、解決していく。

思い込みから抜け出す

  • 分担する=生産性が高い という思い込み
    求められていることとチームの状況で使い分けることが重要

  • 営業に向けてのプログラム研修

    • 最強の研修
      • 実際の仕事に近い
      • ベストだと思うことをやる
      • 研修する側が受けたい内容にする

間違いじゃないけど、もっとうまくできるのではないか?

学んでいないことの強み

  • 吸収できる
  • こういうものっていう思い込みがない

Nextアジャイル

  • モブプロ
  • スプリント期間
  • Unlearnを戦略的に、学び直すことをチームに取り入れる

今、正しいことがずっと正しいわけではない 正しいことも、よりもっといい方法があるのでは、と新しくアップデートしていく

あと、名前は大事

新卒にプログラミング研修をした話

ついていけない人を発生させないように、みんながわかって初めてDoneにする。 あとで、どうかを実際に聞いてみることも必要。 勉強は教材をみんなで解いてた感じ
初心者をドライバーにしてあげて、わからないところはストップする

  • みんなで教える
  • ストップしてもOKな心理的安全性を保つ必要性
Unlrean
  • 学びほぐす
  • 学んだこと、知ったことの振り返り以外に自分を振り返る

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@taktstockの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう