Agile2017 Day 1

最近ほとんどSNSばかりでブログを書いておりませんが、今年も Agile Conference に参加しております。2009年からなのでもう8回も参加したらしいです。

Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

初日は基調講演から始まって90分の並行セッションが3つという構成です。

f:id:wayaguchi:20170807090104j:plain

オーガナイザーからの説明とか。

f:id:wayaguchi:20170807092209j:plain

リーダーシップに関する基調講演。潜水艦のマネジメントだった経験を踏まえて、マネジメント層の重要さとか、心理的安全とか自律性の話をしていました。

f:id:wayaguchi:20170808072135j:plain

基調講演の後は、アジャイルコーチのスコアカードの話に参加。メトリクスを取ろうという話でした。

f:id:wayaguchi:20170808073329j:plain

Productivity, Predictability, Responsiveness, Quality, Agile Maturity/Fluency, Business Outcome, Happiness という観点でメトリクスを出す。Rally(プロジェクト管理ツール)から取れるものと、アンケートやインタビューで。

f:id:wayaguchi:20170808073402j:plain

Productivity(生産性)の例。緑がストーリー数、黒がバグ対応数、青が合計。

カンバンとスクラムを混合してるのでサイズ見積もりはなく件数だけとってる

この例ではより安定してきてる。

f:id:wayaguchi:20170808073631j:plain

これはPredictability(予測性)の例。
下側の時は着手数の方が多い状態。上側は完了数が上回ってる状態。WIPを制御することで徐々に上になる。こうすることで、「タスクが山積みなんでいつ終わるかわかりません」状態を回避できるようになる。フローの効率化。

f:id:wayaguchi:20170808073746j:plain

ここで会場から質問。「Weって言うけど誰?誰のためにデータ取ってるの?コーチやコンサルタントのため?チームのため?」

どっちのためでもある、というような回答だったと思います。(メトリクス系のとき、この点がいつも焦点になる気がします。マネジメントに管理しやすい数値を渡したいだけなら、それチームのためじゃないじゃん説。いやマネジメントが管理しやすければチームもやりやすいでしょ、という立場はあると思いますが、チームとの信頼関係次第かな。業務知識のないマネージャーさんに操作しやすい数字をあげても、いい方向には使えなかったりするでしょうし。)

このあと質問ラッシュになってました。

Agile Fluency / Maturity つまりアジャイルがどれくらい出来てるか、はインタビューでトルっぽいです。ダイアナ・ラーセンとかがやってる、Agile Fluencyのモデルを参考にしている模様。

f:id:wayaguchi:20170808075004j:plain

f:id:wayaguchi:20170808075303j:plain

 

Jonathan Rasmusson : 7 Sources of Waste

アジャイルサムライ」の著者で今はSpotifyでエンジニアしているジョナサンのセッションに参加。Pragmatic Bookshelf から新しい本が出てます。

f:id:wayaguchi:20170808064603j:plain

テスト自動化の7つのムダ ... 3つは技術面、4つは文化面。

f:id:wayaguchi:20170808065232j:plain

 

#1 スローテスト
まず見つけるのが難しい
すべてのテストが暴動ではない 1000ms 100ms 1ms
スローテストは生産性キラー

 

#2 Flaky Test
100%の信頼性で動かないテスト。
つまりテストの結果が揺らぐのは辛いってこと。
これ1月にMicrosoft行ったときにBingのUIテスト自動化の人も同じことを言っていた。
なるべく各環境(ロケールとかブラウザとか)で揺らがないような書き方を探すんだそう。

Kent Beck はそんなテストは消せと言っている。

f:id:wayaguchi:20170808072714j:plain


#3 Premature Hardening

バグを取りきる前にUIテスト(自動化)に入ってはいけない。

f:id:wayaguchi:20170808065639j:plain

 

こっから文化

#4 Lack of Language and Framework
共通言語(結合テストがなにを意味するかとか)がないと辛い。テストのフレームワークが統一できてないと辛い

 

f:id:wayaguchi:20170808065927j:plain

f:id:wayaguchi:20170808065851j:plain

f:id:wayaguchi:20170808070008j:plain

#5 Lack of Skills

必要なスキルがないと辛い

f:id:wayaguchi:20170808070107j:plain

 

#6 Artificial Separation of concern

責任を変に分割してると辛い (開発者とQAとか)

f:id:wayaguchi:20170808070430j:plain

一つの作戦はテスト中の列をタスクボードから削除。

f:id:wayaguchi:20170808070332j:plain

 

#7 Lack of perspective

しかし観点は必要なのだ。

f:id:wayaguchi:20170808070242j:plain

f:id:wayaguchi:20170808070528j:plain

 

最後にSpotifyの話

f:id:wayaguchi:20170808070702j:plain

ダッシュボード作って常に見えるようにしている。テストコケてないかとか、各種メトリクス。

f:id:wayaguchi:20170808070740j:plain

チーム(Squad)によっては専任のテスト自動化のロールの人がいる。例えばクルマのメーカーとの共同プロジェクトですごい短い期間でクルマ(TeslaとかBMWって言ってた)でSpotifyの音楽を流せるようにしたんだけど、こういうテストは専門家がついた。

f:id:wayaguchi:20170808070831j:plain

生産性向上のための専任チームがいる。これはプロセス改善するという意味ではなくて、技術的に解決する人たちという意味だと思う。DevOpsとかツール整備とかそういう感じだろう。

f:id:wayaguchi:20170808071101j:plain

毎週リリース。これはきついけど守っている。ユーザーからフィードバックもらうためには必要なこと。毎週機能をリリースする。

f:id:wayaguchi:20170808071108j:plain

テストエンジニアの社内認定試験を作った。(このへんは How Google test に近いな)

f:id:wayaguchi:20170808070622j:plain

 

ということで、本を出したので読んでね。(日本語版は9月にオライリージャパンから出版予定だそうです。)

f:id:wayaguchi:20170808071440j:plain

よいまとめであり、かつSpotifyの話が聞けてすごく勉強になりました。

 

昼ごはん食べたときに「タフクエスチョン用意しといてね」と言われたので質問。

「こういう話って、非エンジニアの偉い人に説明するの大変じゃん?どうしたら良いと思う?」

答え「わかんね。カナダのエネルギー系のプロジェクトのときは、お金に換算して説明してた。Spotifyはファウンダーがエンジニアで、もともと技術的解決をする仕事をしてて、その3つの柱の一つがSpotifyだった...」

まあ、そういう時代かなーと思う。 

 

最後に日本人とパシャリ

f:id:wayaguchi:20170807151734j:plain

 

で、このつぎのセッションが David さんの非エンジニア向けにクリーンコードを説明する方法のセッションでした。熱く語っていた。

f:id:wayaguchi:20170807154739j:plain

 

Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5