2011-12-09
■[アジャイル][JIRA]スクラムをJIRA+GreenHopperではじめる
JIRA Advent Calender 2011 - http://atnd.org/events/22899
@j5ik2o さんから紹介を受けました。
ブログなんて2年ぶりくらいですね...。このAdventCalender終わったら俺ブログ執筆業復活させるんだ...。
さてさて、JIRAは今働いているチームでバリバリ業務で使っています。
理由はアジャイル開発のスタイルの一つであるスクラムを試してみたかったからで、
GreenHopperというプラグインがいいぞと聞いたのではじめた感じです。
GreenHopperは有名すぎるプラグインなんじゃないかと思うのですが、
意外とまだ誰も紹介されていないので、ざっくりとどういうものか紹介してみます。
そもそもスクラムとJIRAについて
誤解なきよう最初に述べておくと、スクラムを行うのにJIRAなど必要ありません。
腕利きのスクラムマスター(スクラムで食えるかもしれないスクラム専門家のこと)はホワイトボードを抱えて
その身一つでプロジェクトに飛び込むとか飛び込まないとか。
ということで、逆に言うとJIRA+GreenHopperを導入したからと言ってスクラムが出来るわけではないという
至極当たり前のことを言いたかったのです。ツールはやはりただのツールであります。
ちなみにかくいう私もまだうまくスクラムを組めた感じはしていません。
最近も評価面談で上司にまだまだ成果が見えにくいねなんて言われたところです。
まあ、継続が力だと思うので、真のアジャイラー目指してのんびり精進していこうと思う次第です。
さて、スクラムについては興味ある方は知っているし、興味ない方は知らないので、
このエントリでとりたてて体系だてて説明をするつもりはないのです(けしてめんどくさいわけでは...)。
が、興味あるけど知らない方は、とりあえずスクラム道という素晴らしいイベントが精力的に続けられているので
足を運ばれてみるのがよいかと思います。またスクラムに限らず、アジャイルで一冊本を選べと言われたら（多分私以外の人も）
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」という本をオススメします。
アジャイルに興味ある方は是非読んでみてください。
このエントリでは一応頑張ってスクラムを知らない人でも何となくわかるように書くつもりですが、
ほどよく内容が適当なのをご了承ください。
スプリント計画、バックログの作成
アジャイル開発にはタイムボックス(一定の期間)をきめて、それを繰り返すことで
開発の計画や進行の精度を上げるという方法論があります。
スクラムにおいてはこのタイムボックスはスプリントと呼ばれています。
通常２週間くらいを想定するようで、２週間のち動く成果物をリリースして一区切りつきます。
時間あるようで時間ない位の期間で、リリースを目指してチーム一丸となって全力疾走するところから
「スプリント」という短距離走を思わせる名前がついているようです。
そのスプリントのはじめにチームが集まって計画を立てます。これがスプリント計画で、ここが頑張りどころです。
スプリント計画ではタスクを２週間分洗いだしていきますが、ここでのタスクは
「ユーザーストーリー」というかたちで書き出していくのがいいとされています。
何を言ってるのか分からねーとおもいますが、ユーザーストーリーというのは
「ユーザーはなになにすることが出来る」といった形でタスクを考えるということです。
たとえばブログを作るとして、ブログを見るところを開発しようとするなら、
「ユーザーはブログを閲覧することが出来る」
というのがユーザーストーリーになります。
いつものタスク分けだと「ブログ閲覧画面を作成する」になったり、もしかすると
「カレンダーの該当の該当日付のリンクを押下時に遷移する」みたいな押下ってなんやねんみたいな、
読み方わからんわ「おしげ」か「おすか」か？みたいなタスクからになったりするかもしれません。
それを考えると、このユーザーストーリーは何をしたいかというところで一発で機能を言い表せるので
案外いい方法であるということが分かります。
それで話を元に戻すと、このユーザーストーリーを洗いざらい出した後に、ストーリーポイントなるものをみんなで振っていきます。
これをフィボナッチ数列でつけていくのがイケてるらしいです。
フィボナッチ数列は0,1,1,2,3,5,8,13,21...って感じですが、何を言ってるのか分からねーと思いますが、
2は1のタスクの2倍、3は3倍という感じで、だいたいこのタスクはこのタスクの何倍くらい大変なのかということを
見積もっていくのがストーリーポイントでやりたいことです。
その何倍みたいなのもそこそこいい塩梅の取り決めでやりたいので、フィボナッチ数列が出てきます。
本当にプログラマーってやつはfib好きなんだな...。
こうすると1hとか2dとかで積み上げてって人月単価で80万で、買う側は見えない残業時間を入れるし、
売る側はバッファを入れて水増しするし、その間でやっぱりデスマな俺は辞めさせてもらうわ
みたいな時間見積もりな世界とオサラバし、規模感で見積もることができるようになります。
規模感で見積もるとどういったいいことかがあるか。
相対的なスケールになるので属人性を排除できたり、タスクの粒度を揃えたりできます。
そうすると次に成果についての定量的な観測が可能になります。定量はスーツの人たちも含めてみんな大好きです。
そうは言っても私のタスクは53倍ですみたいな感じでテキトーになるんじゃないのということを避けるために、
他者の目を介することが大事です。
そこで、みんなで相談するやり方として、ストーリーポイントを書いたカードを「いっせのせーっ」で見せ合うのが
若干恥ずかしいという心があるためまだちゃんと挑戦したことないのですが、そのうちやってみたいなと思っています。
こうして、スプリント計画ではそのスプリントに必要なユーザーストーリーを書き出し、
ストーリーポイントを振っていくということをチームみんなでやります。
その結果できたものをスクラムでは「スプリントバックログ」と言います。
とどのつまり、やることリストのことです。これを最初にみんなできっちり作ろうぜということです。
GreenHopperはこのスプリントやユーザーストーリー、ストーリーポイントみたいなものを取り扱えます。
JIRAではよくあるチケット発行によるタスク管理が行えるのですが、
チケットのフォーマットとしてユーザーストーリーがあるのでこれを使います。
使い方はGreenHopperをインストールした状態でプロジェクトページを見ると「アジャイル」メニューが追加されています。
ここから「プランボード」を選択します。
すると画面右上に「＋新規カード」が現れるので、ここからユーザーストーリーを入力できます。
その上の「＋課題の作成」からも作成は出来るのですが、通常のチケット管理における課題の起票となってしまうので、
入力項目が大分多いです。ですので「＋新規カード」からユーザーストーリーを作成するのが気軽でおすすめです。
それではストーリーを作成しましょう。といっても簡単で、要約を書いてストーリーポイントを振るだけです。
試しに先の「ユーザーはブログを閲覧することが出来る」というユーザーストーリーを追加します。
ここではストーリーポイントを3振っていますが、あとからプランボードで振ったり更新することができますので、
ここでまだ振らなくてもいいかもしれません。
また、JIRAは基本的にだいたいのUIがAJAXになっているので、
「作成してクローズ」を選ばずに「作成」を選ぶことで画面の切り替えなしにどんどん作成できます。
とてもストレスレスに、こまけえこたぁいいんだよ方式でどんどんタスクを作成していけます。
また、作成したストーリーにはサブタスクが追加できます。
プランボードで作成したストーリーの一番左のアイコンをクリックするとメニューがでてきますので
「サブタスクの追加」を選択し、ユーザーストーリーと同じような要領でタスクを作成します。
私のチームではユーザーストーリーは「ユーザー(主語)は〜出来る」というストーリー表現で統一し、
サブタスクではタスク口調でどんどん書いていくというスタイルを取っています。
大きくタスクを漏れなく区切っていくというやり方としてユーザーストーリーは有益ですが、
実際のタスクはそれでは書きづらいからです。
作成したユーザーストーリーとサブタスクはツリーで表示され、プランボードから画面遷移なしで編集可能です。
例えば要約(タイトル)を編集する場合はそこをクリックすれば入力欄に変わるといった具合です。
だいたい感じが伝わりましたでしょうか。
タスクカンバンでのTODO管理
アジャイルでのタスクワークフローではよく「カンバン」という手法が併用されるようです。
カンバン=看板は日本語ですが、トヨタの生産管理で考案され特許がとられているので
日本初ということで海外でもこの名前になっているようです。
カンバンを現実的にやるにはツールも少ないのでホワイトボードを用意して
ポストイットなどを利用する光景をよくこれまでも見かけました。
GreenHopperではこのカンバンの手法をワークフローとしてデフォルトで提供しています。
カンバンを見るには「アジャイル」メニューから「タスクボード」を選択します。
タスクボードを選択すると先ほど作成したユーザーストーリーがカンバンにすでに配置されています。
あとは使い方は簡単で、着手したタスクに関しては進行中=WIP(WorkInProgress)にドラッグアンドドロップし、
完了したタスクに関しては完了=Doneに同じくドラッグアンドドロップするだけです。
完了時に色々と作業時間などの情報を書き足すこともできます。
サブタスクを全て完了にしたユーザーストーリーは最後に右上の「Open」をクリックすることで
「Close」や「Resolve」の状態に変えることができます。
余談ですが、このクロージングの作業だけ設定で権限を変えたりも出来ますので、
ワークフローを細かく制御したいといったこともできます。
このタスクカンバンもJIRAのAJAXによる画面遷移なしのUIによって、非常に直感的で使いやすくなっています。
私のチームでは作業時間を細かくは見ないようにしていますので、
基本的にはドラッグアンドドロップしてもらうだけという形で
作業記録をメンバーに付けてもらったりしています。
タスク管理は入力の煩雑さに負けてだんだんグダグダになっていくというのはよくある光景だと思いますが、
これだと続きそうではないでしょうか。
バーンダウンチャートをみる
ストーリーポイントのところで説明しましたが、相対的な規模感の見積もりによってストーリーの大きさというのは
スプリントにおいては一貫している、つまり粒が揃っていると言えます。ですのでだいたい定量的に扱えます。
これを利用して、アジャイルにはタスクの進行度合いを見える化するために「バーンダウンチャート」というグラフ作成手法があります。
「バーンダウン」ときくと人によっては厨二病的に必殺技名のように感じられたり、
僕のようにトーキングヘッズというバンドの「バーニング・ダウン・ザ・ハウス(家を焼き払え)」という曲が
脳内で再生されたりするかもしれませんが、
平たく言うと単純に「下がっていく」グラフだということを言ってるようです。
言葉で説明するとややこしいので実物を見てもらうのが一番いいです。
これはGreenHopperで「アジャイル」メニューから選択した「グラフボード」から「課題バーンダウングラフ」を選択したものです。
このグラフでは縦スケールがサブタスクの数の積み上げになっていて、横スケールが日付です。日付は開始日からリリース日までです。
そして真ん中の綺麗にななめってる赤線が理想線で、機械的にサブタスクをやっつけてったら終わる線になっています。
この線に対してその上にある緑線が実際の残りサブタスク数です。
図では理想線より上にあるので、進捗は「ヤバイ」ということになります。
この緑線を下げていくのが「バーンダウン」するということのようです。
逆にサブタスクを忘れてて後から追加するとどんどん上に上がってしまうのは「バーンアップ」と言ったりもします。
これによりスプリントの進捗状況がだいたい分かるというわけです。
ちなみにアジャイル的にはスプリントを繰り返すうちに見積の精度もふりかえりで上がっていくものなので、
最初のうちはこのバーンダウンチャートが最後らへんで崖みたいになってるグラフになったり、
最後になってストーリー自体を次のスプリントにごそっと移動させたりすることもあります。
バーンダウンチャートがうまく理想線あたりを上下するようなグラフになれば
アジャイルな計画つくりも上手くなってきたと言えるのではないでしょうか。
ということで
スクラムをやってみた私視点からJIRA+GreenHopperを使った一例を紹介してみました。
まだまだ上手い使い方もあると思いますのでコメントなどで教えていただけると大変嬉しいです！
それではいいアジャイルを！
明日のJIRA Advent Calender 2011は...
決まってなかったw
Permalink | コメント(0) | トラックバック(0) | 15:00
2009-09-18
■[PHP][mobile]jpegのヘッダのコメントを書き換える軽量なやつ書いた。
ここのところ転職したり、入院したり、冠婚葬祭の波に見舞われたりして更新してなかったので、
カッとなって書いたシリーズです。コードを載せたかったというのもあります。
ええと、こいつはアレです。携帯で画像を著作権保護したいときとかの、jpegのコメントを書き換えたい用途のものです。
ImageMagickだとか、そのPHPバインディングだとか、外人さんの古げなライブラリとかはイマイチ使いたくないのです。
なぜなら、サクッと呼び出せて、軽快に動作して、後腐れのないものが欲しいからです。
錆び付いて回ってない車輪*1なら書き直しちまえ！！
JpegHeaderCommentクラス*2
class JpegHeaderComment{
public static function &write($file, $comment){
$buf = '';
$com = "\xFF\xFE" . pack('n*', strlen($comment)+2) . $comment ;
$skip = false;
$skip_count = 0;
$fh = @fopen($file, 'rb');
if(!$fh) return false;
while(!feof($fh)){
$byte = fread($fh, 1);
if ($skip){
$skip_count--;
if($skip_count < 0){
if (preg_match("/[\xE0-\xEF]/", $byte) == 0) {
$buf .= $com;
}
$skip_count = 0;
$skip = false ;
}
}elseif ($byte=="\xFF"){
$byte .= fread($fh, 1) ;
if (preg_match("/[\xE0-\xEF]/", $byte) != 0) {
$app_length_part = fread($fh, 2);
$byte .= $app_length_part ;
$unpack = unpack('n*', $app_length_part);
$skip_count = $unpack[1] - 2;
$skip = true ;
}
}
$buf .= $byte;
}
fclose($fh);
return $buf;
}
}
- ファイルパスとコメント文字列を与えたら、コメント付記されたjpeg画像を返します。
- 名前空間とか、クラスの使い勝手とかは今書き上げたばかりなのであんまり考えてないです。
- アルゴリズムもなるべくメモリを使わんように、オーダー少ないように書いたつもりですが、所詮PHPなのでベスト・エフォートのつもりです。
- URL指定してリモートのファイルでもいけるかどうかは試してません。あくまで同ドメインの画像ファイルを読み込む用途です。
- エラーハンドリングも例外クラスとか作る気今のところ無いです。失敗したらfalse返すだけ。
呼び出しもとのコード例
file_put_contents('piyo.jpg', JpegHeaderComment::write('hoge.jpg', 'piyopiyo'));
証拠
参考
module.jp - PNGとGIFとJPEGにコメントを埋め込むという2004年に書かれた記事で紹介されてるアルゴリズムを鵜呑みにして実装しました。*3
有り難うございました。
感想
- バイナリいじるのは楽しくて日が暮れた
- 根気があれば誰でも１日未満で出来る
- もっとファイルフォーマットとかやりたいし知りたい
- そもそもbyteというものに愛着が湧いた
今後
こういう携帯関係のツールを山ほど書いているので、ニーズが有ろうと無かろうと勝手にgithubとかにその内奇麗にしたものを上げるつもりです。
Permalink | コメント(0) | トラックバック(0) | 05:26
2009-09-02
■[OpenSocial][mixi]mixiアプリ説明会【技術】に行ってきた。
第20回のmixiアプリの説明会に行ってきました。
仕事絡みなんですが、めもをはてな記法で書いてしまったのと、コンフィデンシャルな内容ではないので、こちらに載せます。
ちなみに「でゔせん」って言ってるのはDeveloperCenterの略です。
その中でも、「ドキュメント」を見れば詳しい情報は集約されてるのですが、
あくまで現在の概観と、入門としてお読みください。
紹介
mixi platform構想
- 運営者ー利用者というSNSの関係性
- 利用者間のつながり = ソーシャルグラフと呼ぶ
- これを公開すること = OpenSocialの概念
- mixi platformはこの関係性に開発者をプラスする
- 2つの軸
- mixi アプリ
- 個人でやってる開発者にもオープンする。今日はこっちがメイン
- mixi connect
- mixi アプリ
mixi アプリ
- 「mixiの画面の中で動く」というイメージ
- 今までの導線上でユーザが使用できる
- mobileもやるが、一般への公開はまだ
- アクティビティ
- 行動の結果がfeedとして配信できる
- 所謂「アクティビティストリーム」ってやつ
- 他のユーザに通知させることが出来る
- 画像は3枚まで
- 提供側がアピールする場はここ
mixiアプリの仕組み(技術より)
- OpenSocialに準拠(v0.8.1)
- 基本的には？他のSNSサービスに持ってける
- 難色？？
- 独自APIとバージョン間整合性が難点か
- OpenSocial
- PC -> OpenSocial JavaScript API
- mobile -> OpenSocial RESTful Protocol
- owner & viewerの概念
PC版
アーキテクチャ
- 例
- newFetchPersonRequest メソッド
- Viewerを指定してる
- それでほげほげしてプロフィールを取得してる
- newFetchPersonRequest メソッド
- USER_ID
- 起点となるユーザ
- 取得したいユーザとの関係をGROUP_ID
- 距離をNETWORK_DISTANCEで指定
- 起点となるユーザ
- GROUP_ID="FRIENDS" NETWORK_DISTANCE="1"
- gadgets
- makeRequest メソッド
- URLを指定
- feedをパースしたJavaScriptのオブジェクトで返してくれる
- makeRequest メソッド
- OpenSocial Dev App
- ちょっと試せるmixiアプリ環境
- トライ&エラーここでしる
- 気にして動作確認しないでローカルで開発したいとき
mobile版
- mobile <-> mixiServer <-> (proxy) <-> server
- 公開
- 追加GETパラメータ
- opensocial_app_id
- opensocial_owner_id
- ownerユーザのid
- 追加ヘッダ
質問
- Flashってどこまでやれんの？
- インタラクティヴならできる
- 全画面で
- インラインはNO!!!
- インタラクティヴならできる
- なんでJavaScript中心の実装縛りにしたの？
- FaceBookとOpensocialどっちにのるか？の政治的判断
私の質問
- OpenSocialのバージョン
- 0.9x
- 一気に移行は現実的に無理
- 0.8X
- APIをフォローしていく段階的に
- すでに0.9xの一部をalbumとかで取り入れてたり
- 対応状況はDevelopperCenterのニュースで知らせていきます
- 0.9x
- アプリの申請ガイドラインと審査について
- でゔせんに３つあるので読むべし
- 公開申請用のガイドラインを満たしているか？がポイント
- 掲載内容を逸脱しているかどうか？
- 文書解釈を各社、独自にすべし
- あのほげほげ事件は申請が通ったって事なのか。
感想
やはり課金APIが気になります。ついでに言うとモバゲーの出方も気になります。みな様子見してるのでしょうか？
技術的には、OpenSocialに対応して、日本の携帯事情に合わせるためAPIを整備して、独自のも用意して、バージョンもetc…
という開発者さま方の苦労がしみじみと伝わりました…。
Permalink | コメント(0) | トラックバック(4) | 15:51
2009-06-29
■[PHP][勉強会]PHP勉強会でlimonadeの事について喋ってきた！
会場ご提供頂いたトライコーン株式会社様（Redmineの時もお世話になりました！）もとい、主催者、参加者の皆様、お疲れさまでした！＆有り難うございました！
相変わらずのゆったりとした会場かつ設備で、PHPコミュニティの本拠地というイメージです、感謝！ ＞ トライコーン株式会社様
プレゼン
- ゆっくり喋った。うまく伝わっただろうか…
- 大分資料に引き摺られずに喋れるようになってきた
- ちゃんとPHPへの尊敬の念は込めたつもりだったけど、嫌な印象を与えてたらどうしよう
- 蛇足と誤解上等で書くと、Sinatraが一種のRubyのPHP化だとすると、Rubyの良いとこをフィードバックして「あるべきPHP」化させたのがlimonade
- 使い物になるんだったら使いたい。使えないなら使いたい人がコミットすればいい
感想
- sabelの作者さんがいらっしゃっていた。懇親会に行かんかったので、話せず無念…
- PHPでPofEAAなORM組むのってどんな感じなのか聞いてみたかった
- id:yandodさんのオランダのPHPカンファレンスの紹介（実は行ってない）の温度感が面白かった。I Love PHPか。その気持ち… わからねー。
- 萩原さんのPHP on GAE/j。ホットデプロイには対応している、との突っ込みが入った。あと、スタックが深すぎると駄目なのでCakePHP動かないとか
- NEKOGETさんのCunit？の話。
- しかしPHPのフレームワークはめちゃくちゃ多いな
- rhaco使ってるという人も
- pieceはいなかったか
- 個人的には食い足りなかった…。やっぱ参加型じゃないと盛り上がりに欠ける気がする
最後に
- 一緒に仕事を戦い抜いた、symfonyならこの人！って言うくらいのスキルの弊社の女性エンジニアを紹介した。
- 社内に埋もれるには勿体ない人だったので、是非勉強会とかで凄腕が知れ渡ってくれたら嬉しいなあ。と思いきや、大きなお世話なのかなと思ったり。
Permalink | コメント(0) | トラックバック(0) | 23:08
2009-06-26
■[Sinatra][万葉][勉強会]株式会社万葉にてSinatra勉強会をやりました！
会場ご提供頂いた万葉株式会社の皆様もとい、参加者の皆様、本当にお疲れさまでした＆有り難うございました！！
初めての所謂、まともな技術勉強会の主催をやらせて頂きました。
正直、Sinatraのことよりは開催に精一杯で、めまぐるしく過ぎ去った感じです。
見えた景色も、一介のスピーカーや、OOPJogとはまた違いました。本当に良い経験をさせて頂き、まことに感謝いたします。
プレゼンです。
雑感
- ustにチャレンジした。自分のハンディカムを持っていた。絵もまあまあ撮れた。しかし録画をクリックするのを忘れた。
- ビア・バッシュをやった。ビールの権威、id:hyoshiokさんの素晴らしいエントリ通りにやった。非常にうまくいった。
- 前半は私のプレゼンによる、所謂セミナー形式。だが、参加者の方々がえらい豪華だった（なんとid:t-wadaさんが！！）ので、少し協力を仰いだ。そうすると色々と助けて頂き、深みが増した。
- 勉強会に講師なんて必要ない。声が大きくて、シナリオを書けたら十分回る。
- 後半はjugyoさんによるライブコーディングと実際の運用アプリ説明の２本立て。これも実学的な方向から完全に前半の私の机上の蘊蓄と補完関係にあり、パーフェクトに機能した。
- 残念なのはビアバッシュの用意で、自分がほとんどその内容を聞けなかったところだが…
- ビア・バッシュ。技術話はそこそこに、尊敬するTDDのカリスマ・ギークのid:t-wadaさんと、Schemeの師匠？id:yad-ELさんと、親密なトーク（ただの悪ノリ）をできたことが嬉しかった。
- 男と女の間にはかくも深き闇と、そして希望が横たわっている。女性エンジニアは私たちに優しく接するべきだ。
日本Sinatraの会
- 会長は私です。
- 今日発足しました。
- もしかして…解散？
忘れてたけど大切なレオさんの言ってた事
- コードリーディングはテストから読むべし。
Permalink | コメント(0) | トラックバック(2) | 01:49
