2017年6月16日金曜日

Java kücheに登壇してきました。

Java kücheに登壇してきました。


6/3(土)に開催されたJava kücheに登壇してきました。
沖縄ベイサイドセンター(サンエーコンベンションシティの隣)の1階のカフェを貸し切りにして、40人くらいの県内エンジニアさんが講演を聞きに来ていました。
僕は去年のenPiTに参加していて、アジャイル開発を経験したということで、その経験を紹介してくださいとの要望で登壇しました。
なお、僕はJava kücheは初参加、初登壇です。終始ビクビクしてました(笑)。

Java kücheとは

Java Kücheのページより
Java Kücheは沖縄における数少ないプログラマコミュニティとして、沖縄でのJavaの普及、 Java技術者の育成、また、Javaに限定しないプログラマのコミュニケーションの場を提供する目的で、 2006年7月21日に設立されました。
ということらしいです。全然Javaの話はしませんでしたが(笑)。

何を話したのか

enPiTではどんなアジャイル開発をしたのか、どう考えてどう判断したのか、終わってからの学びをお話ししました。
講演後に、何人かのエンジニアさんが「興味深い話でした」との感想をいただけたので、言いたいことは伝わったのかなーと思います。
資料はslide shareにあるので載せときます。

もしかしたら、伝わらなかったこと

講演では以下の3つの話をしました。
1. タスクの粒度やバックログの重み見積もりについて、開発速度について
2. 文化の違い、コミュニケーションの方法、ワークフローの違い
3. 個人間でのアジャイル理解、スクラム理解の差

説明の仕方がだいぶ下手な上に、先の資料は当日に作りましたので、伝わらないかもしれないと思って、ここに言いたかったことを書きます。

1について

タスクって細分化するのが難しいです。なぜなら、細分化しすぎると何の作業だかわからないし、大きすぎると具体性を失います。良い方法があればいいのですが...という話です。
僕の結論は、他のメンバーのタスクとロックすることない、依存関係のない細分化がされていれば良い、ということです。この話で重要なのは、チームが能動的に動きたいのに、タスクのせいで動けなくなってしまうことがある、ということです。素早く開発するアジャイルでは損です。
ロックするかしないかはチームによって異なります。なぜなら、毎日顔をあわせるチームならその場でコミュニケーションを取れば、ロックしているタスクの進行状況がわかるからです。逆に、全員リモートのチームはチャットでのコミュニケーションになるので、即レスするというわけにはいかなくなります。つまり、チームによってロックするかどうか変わります。そのため、タスクの最適な粒度はチームによって異なります。そして、その最適かどうかという判断は、タスク間の依存関係の有無で判断します、というお話でした。

バックログの重み見積もりもタスクと同様に難しい問題です。開発経験が浅いとどうしても正確に重みを見積もることができません。だから、実際の重みと異なることが多いです。そのせいで、その後のベロシティ計算に影響が出ることもしばしばあります。つまり、うまく見積もれないので、次回のスプリントでどれだけの容量をこなせるのか計算できず、開発スピードが微妙に上がらない、という問題です。
僕の結論は、最初は見積もりを失敗するためのもので、後で振り返ってみるのが良い、ということです。おとなしく見積もって開発経験を積めば見積もれる、という話です。要は慣れ。どうしても判断に迷ったら、今のスキルセットと比較してどうか、という判断ができるかと思います。例えば、調査を要するのならば5とか。皆目見当もつかない実装なら8以上、という具合です。

開発速度については、余談でした。今思うと、いらなかった。

2について

社会人でIT触ってれば当たり前の話ですね。人によって学んでいることが違いますから。あと、当たり前になっている用語を新人に伝えられるか考えてみると、チームが円滑に進む気がします。

3について


アジャイルに対する理解って個人で違います。当たり前ですよね。でも、チーム間ではその理解を共有していないと開発に影響がでてきたりします。
例えば、デイリースクラムやらない問題です。僕たちは昼休み中、slackに「今日やったこと・これからやること・今困っていること」を書きます。これを何らかの理由でやらない人がいます。後で聞いてみると、寝てた・何も進捗がないからやらなかった、という理由らしいですが、そういうときにこそやって欲しいのです。なぜなら、リスクを小さいうちに潰しておくことがデイリースクラムの目的だから。
僕の結論では、どれだけアジャイルの目的を理解しているのか、チーム間でたまに共有してみることをオススメします。みんな人間なので、たまに忘れます(笑)。だから、思い出しみる作業をするのです。

おわりに

という感じでしょうか。文章化したら伝わるかも、と思って書いてます。
今後もコミュニティ活動にコミットできればなと考えています。
できれば、僕は人と話してエネルギーを得る人ではないので(逆に放出してしまって元気がなくなるタイプ)、懇親会でビール飲むよりも、その後に映画とか見ながらご飯を食べたい。

2017年6月13日火曜日

Vimはじめました。


vimを初めて見ました。

MacVimを導入します。CLIからも使えるようにします。
インストール手順とか、参考になればどうぞ。どちらかというと寄り道多めです。
あと、環境はMac OS X Elcapitanです。

なんで今更?

きっかけは、達人プログラマーです。
Tips22に次のことが書いてあります。
一つのエディタを熟知すること
複数のエディタを使うよりも一つを熟知したほうが恩恵がでかいです。
以後、小鳥のさえずりのようにキーボードをカタカタします。

インストールする前に、やり方を探してみた。

先人が一応やっているのですが、ちょっと古いので更新してみます。

(ちなみに、lua版というのがあるらしいです。luaはneocompleteを使うために必要らしい。macvimはlua付きかどうかはわからない。要調査。)

インストールすっぞ。

MacVimを落とす。dmgファイルがあるはず。

ちなみにVimにはいろいろ種類がある。MacVimはgithubで管理されているので、READMEを読めば大抵は完結する。

dmgを展開するとアプリが入っている。
入れたら気づくけど、GUIアプリケーションだ。僕はCLIでも使いたい。

githubのFAQにはmvimというCLIが/Applications/MacVim.app/Contents/bin/mvimにあるらしい。

というわけで、bashrcかzshrcに以下を書き込む。

#Vim
export PATH="/Applications/MacVim.app/Contents/bin:$PATH"
#Alias
alias gvim='/Applications/MacVim.app/Contents/MacOS/Vim -g'
alias vim='mvim -v'

というわけで、vimで呼び出せるようになりました。めざせvimmer!!
Vimmerになるために覚えるコマンド集