Shibuya.trac #13 - よりよい開発を目指して -

Shibuya.tracの第13回勉強会行ってきました。

立案企画の @tyobichiさん
発表者の @kanu_さん、@ikikkoさん、@kompiroさん
kompiroさんは遠路はるばるお疲れさまでした！
また、会場サポートスタッフの皆様、大変お世話になりました。

今回は、場所は日本橋のパソナエンジニアカフェさんをお借りしました。
あまりにおしゃれな建物で、しかも発表してる横に、
水耕栽培してるという、良い意味で面白く、凄い場所でしたw

目的として、よりよい開発を目指してと、かなりアバウトといえばアバウトなんですが
そこを目指すのがこのコミュニティなんで、それでいいかとも思います。
内容がタイトルに縛られないためか、おもしろいエントリがならんだのかなとか。

発表は

Scrumでやってみた
@kanu_さん

Jenkins実践入門の Next Step
@ikikkoさん

Kanban - お客さんの視点に立ったアジャイルなやり方 -
@kompiroさん

の三名でした。

LTで

パソナテック / エンジニアカフェのご紹介
パソナテック様

という4本だて2時間です。

開始が少し遅れて19:10からになってしまい
時間が押してしまったのが申し訳なかったです
（休憩時間をがっつりけずったり、総合QAを削ってるので
色々聞きたかった方は、Twitterとか使ってもらえるといいかなと思います）


Scrumやってみた

結論 : tracいらねぇんじゃねぇの？

というのも、ツール自体はあくまでツール
Trac.Lighningのデフォルトページにあるとおり、
Trac自体は最小限の干渉しかしないサポートツールで
開発者は、Tracにアクセスする作業が増大することで
開発に支障がでるようであれば、それは本末転倒かなぁと理解しました。

便利なプラグインは多くあるにしても、
Trac.Lightningに入っているプラグインは把握できてないし
汎用的に仕える物と、そもそも状況に応じて自分でいれて拡張することで
初めて力を発揮するのがtracかなと思いました。

開発とプロジェクト管理を両立させるのは、ますます無理だなとw
本当にtracを使って集計や方向性とかを決める材料にするのであれば
それに大して100%注力できる環境が必要なような気がします。

tracが管理のためのツールになり、第二第三のExcelにならないように
使い方をしっかりと考えて使うことが大切なのではと思いました。

「とうとうExcelがやられたか、しかし奴はBTSの中では最弱」

的な展開はしたくないところですw


Jenkins実践入門 の Next Step
（後日、発表資料公開があるらしい）

この発表は、JenkinsのTips集のような感じでした。

前半は、Jenkins本の紹介
積み本が増えてきたので、いまのものがあらかた片付いたら
読んでみようかなと思います。

後半はこうしたらいいよ！っていうTips
Jenkinsの？ボタンはほんと助かります。
いつも押す？ボタンは、スケジュールの設定のところのやつと
成果物の収集のところのやつです。お気に入りの？ボタン

高度な設定は、一通り使った後に、押してまわると面白いかなと思います。
中身は、やってみないと分からないものが多いと思うので
まずは使ってみてからの、ひと押し

実際、僕は本を読まずに、ネット + 素晴らしい先人たちが残してくれた
Jenkinsの環境設定を見ながら、Jenkinsを利用しています。
大体問題にぶち当たると、twitterで呟きつつ、自分の昔作った
プロジェクトを眺めて、あーでもねぇ、こーでもねぇとやってます。


Kanban - お客さんの視点に立ったアジャイルなやり方 -

発表時間が短くなってしまい、申し訳ありませんでした。

いつもの todo doing done のScrumボード（意味あってるのかな）じゃなく
Kanbanの仕組みと、用語の解説。
また、おもしろいサンプルケースとして、
タスクの完了期限を決めないことで、生産効率が上がった事例をお聞きしました。

Kanbanで優秀だなって思ったのは、流れが停止しないことだと単純に思ってます。
Todoは常に補充され、開発者は補充される物から順番にタスクを拾って処理していくため
機能追加が滞らない場合は、開発者はシームレスにタスクをこなすことになると。

気になるというか、辛そうだなと思うのは、まず終わりが見えずづらいこと。
TODOに入れる個数が制限されて、そこに入るタスクは、顧客側が管理するとなると
顧客のプロダクトバックログや、要求仕様を確認していかないと
プロジェクトの終了が見えないのかなと思いました。

あと、シームレスの弊害があると思って、ふりかえりや改善のタイミングは
どうやって図るのかなというのが、疑問として残りました。
これに関してはチームがここで振り返るよ！って言ったときに、
前回の振り返りからの完了タスクとかでやるのかなぁとか。

実際問題として、組み合わせちゃいけないというわけでもなく

プロジェクト管理をScrumボード タスク管理をKanbanで
とかでもいいのかなとか。
とりあえず勉強不足なので、この辺は戯れ言ですw


パソナテック / エンジニアカフェのご紹介

今回会場を提供していただいたパソナテック様のLTです。

いいね！ をするがいい！ という（ぉぃ


勉強会とかで会場提供して、交流を深めるのが真の目的だそうで
今度はHTML5とかゲーム開発のフレームワークの勉強会とか
結構ワクワクするような勉強会やってそうでした。

とりあえず、イイネはしてきた！

というわけで、皆様お疲れさまでした。

後日談

今回の勉強会では、司会をやらせていただきました。
時間調整で、お品書き削ったりとかしかしなかったんですが
発表者に大して、時間はあとこれぐらいで頼む！とかいうのも
有志の勉強会で、それはないなぁという意識から
そのまま流させていただきました。

おかげさまで、最後の総合QAと休憩時間を一個半削るという
暴挙をやらかしたのも反省点です・・・

とはいえ、お褒めの言葉もいただき嬉しい限りです。
また機会があれば、お手伝いしたいと思います。

司会業は、舞台度胸つけるのに結構いいんじゃないかなと
最近思ってます。あがり症なため、前にたつと
足がガクガクしてたりしますw