フロントエンドのテストツールとか気になっているやつ
テストツールというかサービス中心なんだけど、書籍情報も。
- WebGUIのテストIDE Katalon Studio
- JavaScriptのテスティングフレームワーク
- iOS Appiumで並列テスト
- AIでテストをやるっていう話
- テスト戦略書籍まとめ
Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた
2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。
カンファレンスのイベントページに書いたセッションの概要はつぎです。
ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。
私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。
このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。
背景とかこのチーム(基盤チーム)でわかったこととか
世界最高の製品開発チームとは何かを追求する実験場が基盤チームと言われればそうなんですが、単純にこのチームで仕事をするのが楽しいし、いろいろやっていることがどうも他の人と違うらしいってことはわかってきているので、事例紹介してフィードバックもらったり、誰かの参考になればいいかなぁと。
まぁ普通に考えて頭悪いとは思うんですけど、このチームを通してわかったのはマイクロマネジメントこそ最高である。っていうところですかね。以前の自分と比較して、プロジェクトマネジメントでマイクロマネジメントできないのは才能が足りないんだろうなって思うようになった。マネジメントはあらゆるリソースの使い方を考えて最高の成果を出すということが目的かなぁと思っていて、解像度が低い状態でしか判断できないって辛いよねっていうかね。高解像度かつ大画面なモニターがいいように、マネジメントもそのほうがよっぽどうまく違和感に気づけるのになーみたいな。
この発表は誰かに強制するものでもないし、ある状況ではこういったやり方や考え方もあるということを話しているだけな感じです。 ので、僕も例えば全く別のチームにいったり転職したりしたら、きっと違うことを考えるんだろうなぁとは思います。
Scrumの破であるという理由は、Scrumの3本柱である透明性、検査、適応は変えていなくって、この3つを重要視することは変えずにそれら以外は瑣末なルールだと解釈してScrum Guideを基盤チームオリジナルにどんどん変えていっているっていう感じです。
あぁ、そういう意味だとScrum GuideもGitHubにあると基盤チームでforkして公開するとかできて楽しそうですね。なによりチーム的にもわかりやすいかもしれない。
今までにいただいたフィードバックとか
- 控えめに言ってクレイジー
- 理想はこれなんですよねー
- ちゃんと聞くと当たり前のことを突き詰めているだけなのがすごい
- Extreme Scrum なんだよな
- もうScrumとかどうでもよくね
- kyon_mmは今後何年たっても「僕たちはまだScrumを忠実にやっているだけなんですよ」とかいいそうだよね。
- タイムトラベラーやな kyon_mmさんはタイムトラベラー
- そろそろ何周かしてしまっていて、勘違いしている人と話があっちゃいそう
今後とか現在とか
現在も形を変えてこのチームとして仕事をしていて、非常にたのしくやっています。できれば2017年の成果もどこかで話せたらいいなぁと考えています。 例えば、 #RSGT2018 (日本最大のScrumのカンファレンス 2018/1/11 - 1/12)とか。ただ、まだ公募に出していないので、ここでVoteしてね!って言えないんですが。 僕の話もいいわけですが、もしScrumとか製品開発に関わっているのであれば、これを読んでくださっている方はきっと #RSGT2018 で発表する素質がある気がするのでみなさんも公募を出してみてはどうでしょうか? 採用されなくても別に恥ずかしいとかはないと思いますし、去年は非採用のセッションをひたすら発表する別イベントがたっていたりしましたし、まず考えをまとめてみるだけでも、とても有意義かと思います。
次のサイトで 画面右側の + Propose Sessionボタンを押せば登録できます。
全体のことが書いてあるページはこっち
Regional Scrum Gathering Tokyo 2018 - Tokyo, Japan | ConfEngine - Conference Management Platform
まぁなんにせよ、ソフトウェア開発組織としての知見共有とか悩み共有して次の一歩を踏み出すという場はとてもよいと思っているので、その1つとして自分も貢献できたらなって思っています。
参考書籍
アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (21件) を見る
- 作者: KentBeck,CynthiaAndres
- 出版社/メーカー: オーム社
- 発売日: 2017/07/14
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: マイケル・アブラショフ
- 出版社/メーカー: 三笠書房
- 発売日: 2015/06/24
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: マイケル A ウェスト,下山晴彦,高橋美保
- 出版社/メーカー: 東京大学出版会
- 発売日: 2014/05/12
- メディア: 単行本
- この商品を含むブログ (1件) を見る
お気に入りの生産性あげるための工夫(アプリとかブラウザ拡張とか)
オススメのものを列挙するよー。
1日の過ごし方
大切にしているコンセプトは「もっているものを最大に使いこなす」ということで、手を使える時間はプログラミングとか、たまにしか手を使えない時間は電子書籍か動画、耳しか使えない時間は音声ってつかいわけています。なので、手が空いているときはできるだけものを作るようにシフトして生活している。
- 起床したら気になる記事をInoReaderとかはてなブックマークから検索して、Pocketに共有。
- シャワーあびたり身支度する時間、通勤で歩いている時間、などはPocketで共有した記事を音声読み上げで聞く。
- 音声読み上げできなかった記事は、空き時間に目視で確認。(大抵は業務時間の隙間とか)
- 気になったソースコードはPCのChromeでSourcegraph for GitHubを使って確認して、必要そうだったらcloneする。
- 手が動かせる時間ができたら、いろんなものを動かしてみる。
InoReader
いろんなブログとかRSSで購読するためのWebサイト、スマートフォンアプリ。 スマートフォンで見て気になったらSlackとかPocketとかはてなブックマークに共有しています。 PCブラウザで見るときはショートカットキーが使えて便利。
Webページをまるっとスクレイピングして保存できるWebサイト、スマートフォンアプリ。 Androidで音声読み上げを入れれば、記事を読み上げることができる。 これで、シャンプーしながらとか歯を磨きながらでも勉強できるようになりました。神ツールだと思った。
Sourcegraph for GitHub
GitHubのコードをブラウザ上でIDE的に見ることができる。 なんとコードジャンプもできてまぢ便利。神ツールだと思った。
ポモドーロテクニック
25分毎に1度休憩するというテクニック。 で、これはお手製ツールを使ってやっています。25分過ぎると、アプリが全画面表示になって作業を強制的にストップするようにしています。 結構便利です。集中して仕事したいときはかならずポモドーロテクニック使っていますねー。
Chrome拡張で便利なのはStrict Workflowっていうプラグインかな。25minの間はTwitterとかが見れなくなります。(どのサイトを見れないようにするかはカスタマイズできます)
ブラウザ上で英単語翻訳
ブラウザで表示している画面で、ダブルクリックした英単語とか選択した英単語を日本語に翻訳してくれる拡張をつかっています。 いろいろあるんですが、最近は、速訳!英辞郎®英和辞書っていうやつを使っています。 ページの翻訳はChromeでそもそもできるんでね。
スクラムとかアジャイルのワークショップ 2017.05 版
毎月スクラムに関する勉強会を開催していて、そこでワークショップをやることがあります。 また社内で勉強会をやることもあります。 そこでいままで実施したワークショップの一覧があるといいなぁとおもったのでまとめておきます。 yattomさん、みほらぶさん、角さん、たかえすさん、川口さんありがとう!!!
カンバンゲーム
www.slideshare.net
www.slideshare.net
バルンガ
www.slideshare.net
紙ヒコーキ
振り返り
↑の中で次の5つを実施 * +/Δ * Circle of Question * Value Stream Map * KPT * SMART Goal
プロダクトオーナーの意思共有
フィアレスジャーニー
www.slideshare.net
スプリント期間と見積もり
プログラミング言語雑感 2017春
まえおき
kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。
Groovy
こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。
GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。
WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。
C#
Visual Studioと.NET Frameworkから離れなければとりあえず安定している。いつも不満なのは、Visual Studioで出来る操作をMSBuildでやるにはどうしたらいいのか調べるのに苦労しています。誰かサクサク知る方法を教えてください。
async/awaitの変換回りはかなり気色悪い(褒めている)とかあるんですが、(LangExt っていうライブラリをつかえば)そこそこつかえるかなぁとはおもっています。 いつも不満なのは、ASP.NETとかADO.NETとかそういうやつですよ。(あれー)
F#
.NET Frameworkでアプリケーションつくるときの第一候補とする言語。C# とかいう言語では最近REPLができたそうですが、F# は古来からありますよ! みんなでレッツF# !
F# はアクティブパターンがつかいやすくてマヂ神! ってかんじですかね。タイププロバイダーとかいうおもしろ機能はいろいろ使いこみたいんですが、まだ使いこなせていないです。 あ、あと弊社? で開発している FQC っていうコンパイラの後ろ部分(IL生成部分)があるので、こいつへのPullReqとかおまちしております。
ほかの言語
よくわからん。とりあえず、言語仕様書とGetting Startよめばなんとかなるだろという雑な扱い。 Javaは最新の言語仕様書読めていないし、C++はそもそもたいしてしらないです。言語仕様書がうすい言語は勉強しやすくてよいですね。(そうだろうか。。。)
Erlang
最近勉強しているのは、CoqからErlangの生成とかできるのではーと妄想して調べていたら、PPLでそんな話があったとかで、やっぱりそうなるよねー!っていう話をステーキたべながらしていた。 Erlangカッコイイなーってあこがれこそあれど、なかなかたくさんのコードを書こうとすると、なれがたりていないです。。。(静的型検査がないやつで、たくさんのコードを書くことにそもそもなれていないってだけです)
JavaScript
JavaScriptは僕にはむずかしいので、Vue.js でいいかんじにやっておしまいです。Vuejsの日本語ドキュメントすばらしい。課金したい。 一時期は、AltJSで生成すればなんとかなるとかおもっていましたが、JavaScript書くほうが楽な場面そこそこあるなーっておもっていました。 それもWebAssemblyでなんとかなるのかもーっていう夢がひろがってよいですね。
Java
Groovyを実行する基盤のやつ。ヴァルハラ〜。各プログラミング言語とかビルドツールがJava9にスムーズに対応できるのか不安。
OCaml
なごやで公用語のやつ。プログラミングの基礎っていう書籍でつかわれているしね。
いまだに自分はプロダクトにしろツールにしろ仕事でつかったことがないので、いつかつかってみたいとおもって幾年ってかんじです。 Emacs以外でいいかんじにつかえるIDEがほしいです。JetBrainsさんつくってくれませんかね。
Scala
東京で定番化?流行?しているらしい。個人的にはGatlingつかわないWeb企業ほぼないとおもっているので、Scala書いたことないWeb系の人いるほうが希少なのではーくらいにおもっている。
VDM++
形式的な仕様に憧れてさわってみたりしているものの、「おれがつくったほうがもっといいDSLつくれそう」というサイクルをとおして振り出しにもどる系の言語です。もう最近はVDM++でいいんじゃないだろうか。。。っていう気がしなくもないですが、B-Methodとどっちにすればいいんだーってなやんじゃいます。
ふりかえり
JetBrainsさんがいないと生きていけないです。