アジャイルアカデミー の研修に参加したよ
TRANSCRIPT
@toshi0383
アジャイルアカデミーの研修に参加したよ
1
2015/05/12
❖ 鈴木 俊裕
❖ ジャズ、ドラム、凧揚げ
❖ GWはずっとReact.js 触ってました
3/5 Scrum Boot Camp(西村直人さん)
3/6 リーダブルコード(須藤功平さん他)
3/10 TDD(t-wadaさん他)
に参加しました。
参加の動機
❖ もっといい仕事のやり方を学んで、現場に生かしたいという思い
❖ 純粋に触れて体感してみたかった
今日話すこと
5
❖ スクラムについて所感
❖ リーダブルコードの実践方法
❖ TDDの敷居が下がる話
スクラムについて所感
スクラムって？
7
❖ アジャイル？
❖ イテレーションを回して？
❖ 朝会とかやって？
❖ みんな楽しそう、みたいな？
私もまだよくわからないのですが、 ありのまま当日の様子をお話しします。
とはいえ当日やったことといえば本の表紙がプリントされた紙を切り刻んでシャッフル
元どおりにテープでくっつける
切り刻まなければよかったのにと後悔する
教訓
❖ 山からどうやって見つけ出すか？
❖ テープでくっつけるのが意外と難しい（技術力必要）
❖ 完了の定義は？
他のアジャイルとどう違うん？
覚えることが少ないので導入しやすいって言ってた
❖ ３つのロール（役割）
❖ ４つの会議体
❖ ３つの成果物
❖ ちょっとした専門用語
ワークをやってみて、いいと思ったこと
❖ 常にラストスパート
❖ フィードバックの連続
❖ 見積もりの精度があがってゆく
❖ 振り返りの意義
常にラストスパート
❖ 締め切りが頻繁にやってくるので、毎日がリリース間際のテンション。
❖ ぼーっとしてる暇がないので効率が上がる + 達成感。
フィードバックの連続
チームが学びを得る仕組み
❖ デイリースクラム aka 朝会（毎日）
❖ 振り返り（イテレーションごと）
見積もりの精度が上がっていく
よくあるやつ
機能1~5の開発
チームの実力
2ヶ月先の締め切り
終わると思ったんだけど。。
スクラムだと！
機能1
締め切り
機能2 機能3
締め切り
締め切り
だんだん見積りが正確になる！（イメージ）
※初めて導入する場合、勉強期間は当然必要。
振り返りの意義
振り返りの意義
❖ いいところをもっと伸ばす
❖ 仕事のやり方を見直す
振り返りの意義
0
25
50
75
100
n月 n + 1 月 n + 2 月 n + 3 月
コード量 開発スピード
振り返り
なるほど、スクラムやると仕事のやり方が改善できそうだぞ
よし、明日からスクラムやるぞ！
なにからはじめれば。。
導入の障壁
❖ スクラムに詳しい人がいなくて不安なんですけど。。
❖ スマホチームとサーバチームが別会社なので全部スクラムではできない気が。。
詳しい人にお願いして来てもらいましょう
スマホチームだけスクラムでできないか検討しましょう（苦い顔）
実際に講師に聞いてみました。
つづきまして
リーダブルコード実践
当日の様子❖ Rubyのコミッタの方々が講師
❖ OSSでの開発はリモートでのやりとりが多い
❖ 自然とひとのコードを読んで意図を汲み取ろうとする
❖ 書く方も読まれると思うので読みやすいように気をつかう
❖ 多くの現場では、ひとのコードを読む時間が圧倒的に足りていない！という問題提起
❖ なるほど
当日やったこと
❖ レシピを出力するアプリをそれぞれで作る
❖ パートナーのリポジトリをフォークする
❖ いいと思った点を書き出す
いいと思ったこと❖ Checkstyleいれたり、コーディング規約を設けて徹底するよりは、各自の気づきを生む文化の方がよっぽど大事（指摘しなくて済む方が効率的ですよね？という考え方）
❖ 1行変えたらプッシュする(差分が少ない方が読む気になる)
❖ つまり、
リーダブルなんて当たり前にやりましょうよってこと。
とはいえ、モチベーションはチームメンバーそれぞれで違いますよね
なにを言ってもひどいコードを書いてくるチームメンバーがいる（としたら！）。どうした
らいい？
リーダブルを実践する方法❖ まずは、みんながコードを読める仕組みを作るところから（コミットをメールやチャットの通知）
❖ ちょっと変更したらすぐコミットしてプッシュを徹底する
チームみんながお互いのコードを読む習慣をつける
朝会で「今日のリーダブル」を共有する
ここまでで話したこと
❖ スクラムをやると仕事がうまく回りそう
❖ リーダブルコードを意識するとなお良さそう
つづきまして
TDDの敷居が下がる話
TDDとは
❖ 機能のテストを書く
❖ 最初はテストが失敗するのでレッドになる
❖ 機能を実装してテストをグリーンにする
❖ リファクタする
❖ これを非常に小さい単位でぐるぐる回していく開発手法
以前自分だけでやってみたTDDもどき
❖ テストと機能を一気に実装する
❖ テスト通らん！（複数箇所）
❖ テストが通るように実装を直す
❖ テスト通る
❖ テストの間違いに気づく
❖ テストと実装を一緒に直す このテスト大丈夫かな。。
なんかテスト書く方にばっかり時間取られてる気がする。。
❖ あ、やっぱりこの機能いらんかったわ orz
❖ あーもうアプリ作ってるのかテスト作ってるのか。。TDDとかしらんわー
研修でやったTDD❖ テストを書く（実装はスタブ）
❖ テストがこける
❖ 実装を直してグリーンにする（最短距離）
❖ リファクタリング
❖ テストを書く
❖ 最短距離の実装なのでちょっとひねっただけでテストがこける
❖ 実装を直してグリーンにする（最短距離）
❖ リファクタリング
❖ テストを書く
❖ 最短距離の実装なのでちょっとひねっただけでテストがこける
ポイント
❖ Test First（1サイクルは5分以内に完結させる）
❖ 不安なことはテストにして解消
❖ テスト自体もリファクタリングの対象
❖ TDDで書いたテスト ≠ 単体テスト
demo❖ メトロノームアプリ
❖ TODO❖ テンポを表すクラスを作る
❖ テンポの最小値でプログラムを扱うテンポを制限する
❖ テンポの最大値でプログラムを扱うテンポを制限する
TDDでいいと思った点
❖ 安心感
❖ リファクタリングが捗る→リーダブルになる！
❖ しょーもないバグは減りそう
ということは！
TDDについてまとめ❖ スクラム
❖ リーダブルコード実践
❖ TDD
❖ 実践すればコードも綺麗で納期も守れてバグも出なくなる！
❖ 夢にまで見た理想郷はもうあなたの手の中。
と、思うだろ？
TDDの懸念点
❖ 開発コスト増
❖ テストのメンテコスト増
❖ DB,ネットワークの試験のためにスタブとかダミーデータとか作ってメンテするのはダルい
❖ UIをTDDで作るのはあまりメリットがないってt-wadaさんが言ってた
スクラムの懸念点
❖ 導入コストどうする？
❖ スクラムすることが目的になりそう
総括（TDD）
❖ 不慣れな技術を扱うときには向いている
❖ 時間かかりすぎるので開発すべてをTDDでやろうとしない方がよさげ
❖ ペアプロは、不慣れなコードを修正するときとか、新人を教育を扱う時には有効
総括（リーダブル）「読む人が
読みやすければ
リーダブル」講師
メンテしやすければそれでよし。
今日から実践しましょう。
総括（スクラム）❖ スクラムは、チームの仕事がうまく回ることを保証する仕組み
❖ あくまで1つの手法なので、導入すれば必ず効果が出るというものではない
❖ いいものを作っていこう、いい仕事をしよう、という文化を醸成するための仕組みと考えたほうがいいかも
一連の研修に参加してみて雑感❖ 有料研修って高いなーと思いましたが、無料より有料の研修の方が「お金払ったんだから絶対身につけてやる」という気になると思った。
❖ 講師の方がその道の第一人者ばかりだったので、達人から直伝で奥義を授かった気分になりお得な体験だった。
❖ スクラムやってみたくなった
❖ Keynoteやべえ
thank you