2010年2月17日水曜日

GitとCakePHPとRedmineでスーパーアジャイルな開発!!

釣りです

今職場実習生が来てるので、CakePHPで社内ツールのプロトタイプを作成してもらってます。

実習生の実力はというと、VB.NETとC#をやっていたということでオブジェクト指向OK!でも3年間のブランクありという僕より10歳くらい上の淑やかな女性です。

なぜいきなりGit?CakePHP?Redmine?

理由は至ってシンプルです。実習が終わった後に実習生が「何をしたかが言葉以外の情報でも見えるようにしたかったから」。どういうコードを書いたのかを知っておかないと、社内ツールとして採用された場合にメンテナンスをどうするかっていうことを考えれば、期間が短くてもやっておいて損はないと思います。そんなのやってる時間がねーよ!って会社ほどやるべきですね。でないとノウハウが貯まらない会社になってしまって、人が辞めるとそこでいろんなことが終わっちゃいますから。

RedmineとGitを採用しているのは会社に既に導入しているのと、Gitの方は導入実験も兼ねてですが、ブランチ開発をしてもらって、変更が追いやすい良質なコミットをしてもらうことと、一部CI的な要素も含んでます。CIについてはまだやらないので、良いコミットの仕方について何度か説明することになると思います。

CakePHPを採用した理由は、構造が分かっていればコードを追いやすいことと、CakePHPのルールに従って書いていれば、独特なコードがあまり生まれないということからです。社内ツールとして採用されれば、社内の人間がメンテナンスする日がくると思いますし、おそらく機能追加は必須です。そういった場合に、まずどういった作りになってるか調べて...という作業をせず、規約に沿っていることを前提に進める方が効率がいいと思います。また実習生に自社の独自のフレームワークについて教える場合は資料が必要ですが、CakePHPの場合はググって下さいと言えばOKです。ですが、ググっても分かりませんでしたと言われた時に、その問題を解決する手段を提示できることは大事です。

実はA4のしかも文字が羅列されてるだけのプロジェクトの概要と、目的、背景、目標と機能一覧みたいなものを描いた紙しか渡してません。口頭での説明もしましたが、自分で設計して実装して下さいと伝えました。なので実装の仕方は自由ですから、CakePHPを使うということを半強制的におしつけましたw

手書きの設計書からいきなりbake!

This is agile. とにかく動くものに仕上げてレビューをして、目的に合った使いやすいものにどんどん仕上げていくというポリシーで、画面設計に必要な項目を出してもらい、あとシステム上必要な項目を洗い出せば、画面設計とDB設計は完成です。もし詳しいドキュメントが欲しいとなれば、開発が終わった後にまとめる感じです。

アジャイルって設計書とかのドキュメント書かないんじゃないの?と思う人もいるかもしれませんが、そうではなく、最初にどういったもの作るかという使う側と作る側のコンセンサスを得るのは大事です。途中で大きな変更があってもプロジェクトが快活に進むなんてどんな開発手法であれほぼありえません。スコープをある程度明確にしておくことはアジャイルでも大事だと思います。

手書きが個人的に好きなのには理由があります。変更しやすいのと、誰でも鉛筆さえ持てば書き込めるからです。鳥頭なので会議の内容なんてすぐに忘れるので、紙に重要な点だけ書いておくというのは大事です。画面項目とその配置とかって、実際に絵にしてイメージを共有した方が早いし、資料として残るので後で整理しやすいです。画面を書いて、画面遷移も書きたくなってとなれば、手書きの方が絶対早い。お客さんも参加しやすいはずです。見やすいようにまとめるという作業はとにかく後回しにして、要点だけを抑えて、すぐに実装できるように持って行くことが大事だと思います。要求分析や業務分析や要件定義もこの中で全部やってしまって気づいたことはメモしときます。

必要な項目が分かって、項目の型も分かればテーブルを作って必要に応じてbakeします。もしくは、まだ項目に自信がもてない場合は自動のscaffoldを使って、使う側に項目の確認を実際に使ってみてもらって判断してもらえばいいかと思います。OKが出ればbakeして仕上げの作業に入ります。動くもののレビューをしては開発を進めるというイテレーションの繰り返しですね。社内の人間とは基本的に業務時間内であればいつでもコミュニケーションが取れるので、社内での開発はアジャイルが向いていると思います。

何かを達成して実習を終えてほしい

実は教わる側より教える側の方が学ぶ事が多いと思います。そして今回は社内ツール開発なので外目には触れません。じゃあ実習生は損ばかりかというと、経験が積めるからいいじゃないか!という話になると思うのですが、じゃあその経験の質をどうするかと考えると、本人が無意識に定めている以上の限界をこちらで設けて、それを達成できるよう持って行くのがいいんじゃないかと思っています。上から目線の生意気なクソガキが!とこれ見たら思われるかもしれないけどw

もう二日目にして、チケット駆動開発、DVCS、フレームワーク、ユニットテストと、その方が知らなかったワードがいっぱい出てきています。本人が大丈夫かなー?という心配に少しかられている様子です。教える側としても「順序組が下手でごめんなさい」とか思いますが、いずれ出てきたワードがいずれ芽吹いていくんじゃないかと思います。開発を進めるにあたって、どれも実際にやっていくので、その中のどれかがその方の未来で役に立つものがあれば嬉しいです。

成長できた気がします!とか本人が自覚している上でそう言われる、これに勝る喜びはないです。

my issues

うまく達成してもらうためには、教える側が指導の仕方を時間の合間をぬって工夫していかなきゃいけないところですが、今のところ全敗な気がするので、ちゃんとうまく説明できる人間になろうと思います。これをやってくれ、あれをやってくれは時間をかければある程度は説明ができるんですが、指示以外の部分でどう動くかという、動きが見えない部分の洞察力も必要だなーと感じます。将来部下を持った時に、その洞察力がないと、報連相がうまくいかない時に、それが開発効率のボトルネックになるのは防がないといけないと思うので。迷いは開発を鈍らせるので、迷いが発生する時にどうするかを見てみたいなとも。迷ったら聞きにきてという指示はもちろんありだと思うし言いますが、言ったからといって毎回そういう行動は取らないし、相手の事を考えて忙しいから聞くのを後にしようとか思うものだと思うので、何かうまいやり方というのがないのかなーと思います。100%は無理だし過干渉は良くないので、あれ?(妙に変だなー 某ラジオ番組出典)とすぐに気づけるぐらいになりたいです。上司の仕事の一つは、自分がいなくても仕事がまわるようにするだと思うので、latent observer パターン的上司を目指します!(笑)

0 件のコメント: