最近ほとんどSNSばかりでブログを書いておりませんが、今年も Agile Conference に参加しております。2009年からなのでもう８回も参加したらしいです。
※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5
初日は基調講演から始まって90分の並行セッションが３つという構成です。
オーガナイザーからの説明とか。
リーダーシップに関する基調講演。潜水艦のマネジメントだった経験を踏まえて、マネジメント層の重要さとか、心理的安全とか自律性の話をしていました。
基調講演の後は、アジャイルコーチのスコアカードの話に参加。メトリクスを取ろうという話でした。
Productivity, Predictability, Responsiveness, Quality, Agile Maturity/Fluency, Business Outcome, Happiness という観点でメトリクスを出す。Rally(プロジェクト管理ツール)から取れるものと、アンケートやインタビューで。
Productivity(生産性)の例。緑がストーリー数、黒がバグ対応数、青が合計。
カンバンとスクラムを混合してるのでサイズ見積もりはなく件数だけとってる
この例ではより安定してきてる。
これはPredictability(予測性)の例。
下側の時は着手数の方が多い状態。上側は完了数が上回ってる状態。WIPを制御することで徐々に上になる。こうすることで、「タスクが山積みなんでいつ終わるかわかりません」状態を回避できるようになる。フローの効率化。
ここで会場から質問。「Weって言うけど誰？誰のためにデータ取ってるの？コーチやコンサルタントのため？チームのため？」
どっちのためでもある、というような回答だったと思います。（メトリクス系のとき、この点がいつも焦点になる気がします。マネジメントに管理しやすい数値を渡したいだけなら、それチームのためじゃないじゃん説。いやマネジメントが管理しやすければチームもやりやすいでしょ、という立場はあると思いますが、チームとの信頼関係次第かな。業務知識のないマネージャーさんに操作しやすい数字をあげても、いい方向には使えなかったりするでしょうし。）
このあと質問ラッシュになってました。
Agile Fluency / Maturity つまりアジャイルがどれくらい出来てるか、はインタビューでトルっぽいです。ダイアナ・ラーセンとかがやってる、Agile Fluencyのモデルを参考にしている模様。
Jonathan Rasmusson : 7 Sources of Waste
「アジャイルサムライ」の著者で今はSpotifyでエンジニアしているジョナサンのセッションに参加。Pragmatic Bookshelf から新しい本が出てます。
テスト自動化の７つのムダ ... ３つは技術面、４つは文化面。
#1 スローテスト
まず見つけるのが難しい
すべてのテストが暴動ではない 1000ms 100ms 1ms
スローテストは生産性キラー
#2 Flaky Test
100%の信頼性で動かないテスト。
つまりテストの結果が揺らぐのは辛いってこと。
これ1月にMicrosoft行ったときにBingのUIテスト自動化の人も同じことを言っていた。
なるべく各環境(ロケールとかブラウザとか)で揺らがないような書き方を探すんだそう。
Kent Beck はそんなテストは消せと言っている。
#3 Premature Hardening
バグを取りきる前にUIテスト(自動化)に入ってはいけない。
こっから文化
#4 Lack of Language and Framework
共通言語(結合テストがなにを意味するかとか)がないと辛い。テストのフレームワークが統一できてないと辛い
#5 Lack of Skills
必要なスキルがないと辛い
#6 Artificial Separation of concern
責任を変に分割してると辛い (開発者とQAとか)
一つの作戦はテスト中の列をタスクボードから削除。
#7 Lack of perspective
しかし観点は必要なのだ。
最後にSpotifyの話
ダッシュボード作って常に見えるようにしている。テストコケてないかとか、各種メトリクス。
チーム(Squad)によっては専任のテスト自動化のロールの人がいる。例えばクルマのメーカーとの共同プロジェクトですごい短い期間でクルマ(TeslaとかBMWって言ってた)でSpotifyの音楽を流せるようにしたんだけど、こういうテストは専門家がついた。
生産性向上のための専任チームがいる。これはプロセス改善するという意味ではなくて、技術的に解決する人たちという意味だと思う。DevOpsとかツール整備とかそういう感じだろう。
毎週リリース。これはきついけど守っている。ユーザーからフィードバックもらうためには必要なこと。毎週機能をリリースする。
テストエンジニアの社内認定試験を作った。(このへんは How Google test に近いな)
ということで、本を出したので読んでね。(日本語版は９月にオライリージャパンから出版予定だそうです。)
よいまとめであり、かつSpotifyの話が聞けてすごく勉強になりました。
昼ごはん食べたときに「タフクエスチョン用意しといてね」と言われたので質問。
「こういう話って、非エンジニアの偉い人に説明するの大変じゃん？どうしたら良いと思う？」
答え「わかんね。カナダのエネルギー系のプロジェクトのときは、お金に換算して説明してた。Spotifyはファウンダーがエンジニアで、もともと技術的解決をする仕事をしてて、その３つの柱の一つがSpotifyだった...」
まあ、そういう時代かなーと思う。
最後に日本人とパシャリ
で、このつぎのセッションが David さんの非エンジニア向けにクリーンコードを説明する方法のセッションでした。熱く語っていた。
※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5
