2.1アジャイルなプロジェクトはどこが違うのか- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

アジャイルなプロジェクトはどこが違うのか

アジャイルチームに見られる特徴は次の3つ

1. 役割分担がはっきりとは分かれていない
2. 開発工程が途切れることなく続く連続的な取り組みになる
3. チームが一丸となって成果責任を果たす

役割分担がはっきりとは分かれていない

プロジェクトの成功に寄与することならなんだって協力する

具体的には・・・

開発者もテストをやる


現在は開発担当・テスト担当といったようにプロジェクトメンバーの中で役割分担を分けるのではなく、開発もテストも担当するといった体制になっています。
次のステップとしては使い勝手・画面遷移などに対しても分担しないでも出来る体制になることかと考えています。（完全フラットというよりはUI・UXなどに対して意見の言いやすい環境づくりかなと考えています）

役割分担をはっきりわけないことで、自分の作業が終わったら終わりといった意識にならないようになったり、機能や操作性・画面遷移といったものに対して疑問を抱きながら開発することがなくなり、それらがよりよい製品づくりにつながるんじゃないでしょうか。

開発工程が途切れることなく続く連続的な取り組みになる

開発工程が他の工程から独立して行われることはない

具体的には・・・

1つのチケットに対して開発してテストしてリリースして完了


設計フェーズ・開発フェーズ・テストフェーズ・リリース。そういったプロジェクトの期間ごとのまとまりはなくなり、1つの機能（1つのチケット）ごとに対して設計・開発・テスト・リリースといった取り組みがなされることとなります。
アジャイルなプロジェクトだと、1つの機能に対して開発が終わってリリースされるまで（テストがまだのまま）しばらく寝かせて醸造することはありません。

チームが一丸となって成果責任を果たす

品質に責任を持つのはチームであり、品質保証部門ではない

具体的には・・・

誰かがテストしてくれるから大丈夫だろう、ここの担当は自分じゃないから気にしないといったことをなくす


確かな品質を達成するのはチームのメンバー各々の仕事。あらゆる作業が品質保証につながっている。

これはまだ達成できていないと思う。開発だけじゃなくプロジェクトに関わっているチーム全員にこの意識が必要になってくるんだと思います。自分の担当が終わったから終わり、ではなく一つの製品としてプロジェクトを見た時に果たしてまっとうなものに仕上がっているかといった観点で見られる視点を持たなければいけません。
そうしないとちぐはぐなものが出来上がってしまう。
そういったチームを作るのがプロマネの仕事。

きっとチームメンバーにリリース完了時の報告をするとかそういったことも大事になってくるんだと思います。


この章ではアジャイルなチームに関する3つの特徴が記載されていました。
意識の問題をいかにチームのフローとして落とし込んでいくかがプロマネとして問われている部分なのかなと思います。
最初の2つはある程度仕組みでカバーできそうなので、3つ目のチームとしての成果責任も仕組みに出来るんじゃないかなとは思いますが・・・

アジャイルサムライ－達人開発者への道－ 新品価格 ￥2,730から (2013/1/24 00:48時点)

外部のライブラリ追加が楽だね| Play Framework2.0 ここがいい！

libフォルダに色々追加する
classpathに追加する

そんな時期が私にもありました。
でも今は違う！Play Frameworkではそんな事する必要ありません。

project/Build.scala
に必要な記述を追加すれば、後は勝手に取ってきてくれます。

http://www.playframework-ja.org/documentation/2.0.4/SBTDependencies

STEP1

http://mvnrepository.com/

にアクセスして、自分がほしいライブラリを検索します。
次に自分が使いたいバージョンを選びます。

STEP2

http://mvnrepository.com/artifact/net.sourceforge.nekohtml/nekohtml/1.9.17

とかで「SBT」を選びます。

libraryDependencies += "net.sourceforge.nekohtml" % "nekohtml" % "1.9.17"

STEP3

書式を整えて project/Build.scala に追記します。

val appDependencies = Seq(
  "org.apache.derby" % "derby" % "10.4.1.3",
  "net.sourceforge.nekohtml"%"nekohtml" % "1.9.17"
)

みたいな感じですね。

1.4 ３つの真実- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

1. プロジェクトの開始時点にすべての要求を集めることは出来ない
2. 集めたところで、要求はどれも必ずといっていいほど変わる
3. やるべきことはいつだって、与えられた時間と資金よりも多い

プロジェクトの開始時点にすべての要求を集めることは出来ない

要求とは発見されるものであり、全てで揃うまで進めないと言うことではない

具体的には・・・

要件定義を完璧にしても必ず漏れが出る


実際に開発に入ってからそういえばあれって・・・なんてことはよくあることです。

集めたところで、要求はどれも必ずといっていいほど変わる

 変化とは恐れるものでも避けるものでもなく、起きるもの。

具体的には・・・

変化するものという気持ちでいれば、仕様変更もえーっと思うことがなくなります。

必要に応じて計画を変更していくようにします。

計画の変更をしないまま要求を受け入れようとするので避けたいと思ってしまうのかもしれませんが。。。

やるべきことはいつだって、与えられた時間と資金よりも多い

優先順位をつけて優先度の高いものからこなしていく

具体的には・・・

必ず必要な機能、開発中に見つかった不具合などまず対応すべき事項から「完了」にしていきます。

一度に全部を並行して進めようとすると、結局プロダクト的には何も進んでいない状態になってしまいます。

優先度の高いものから「完了」にしていくことで、動くソフトウェアを提供できるようになります。

1.3「完了」とは完了のことだ- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

第2回。

完了の定義

アジャイル開発でフィーチャーを届けるというのは、コードをリリース可能にするために必要な作業をすべて終えていることを意味します。

設計、コーディング、テスト全てが完了していることを意味しています。

蓋を開けてみるまで、リリース可能かどうか不明であれば、その作業は完了とはいえません。

具体的には・・・

チケット管理システムでチケットを管理しているのであれば、そのチケットの内容がリリースできる状態になっていなければ「完了」ではありません。

開発が終わった段階ではまだ「完了」とはいえません。この段階では開発者的には完了かもしれませんが、プロダクト的には完了ではありません。

レビュー・フィードバック、テストを行なってようやく「完了」に出来るようになります。

よくある、開発者の進捗90％問題は完了していません。せっかく作ったものを「完了」にするためにすぐにレビューやテストを実施する必要があります。

アジャイルサムライ－達人開発者への道－ 新品価格 ￥2,730から (2013/1/24 00:48時点)

まずは大事な６つのこと- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

まずは最初に気になったところから。 
アジャイルに取り組むために6つの大事なことがあるようです。

1. 大きな問題は小さくする
2. 本当に大事なことに集中して、それ以外のことは忘れる。
3. ちゃんと動くソフトウェアを届ける
4. フィードバックを求める
5. 必要とあらば進路を変える
6. 成果責任を果たす

 1.大きな問題は小さくする

アジャイルでは定期的に価値あるものをリリースすることが大事とされています。
そのためには1サイクルで終わるレベルに問題を小さくシンプルにする必要があります。

具体的には・・・

チケットの単位を最大数時間単位として、その粒度でチケットを作成する。

大規模プロジェクトだと難しいかもしれませんが、一定のサイクルでリリース可能なものを作り上げるには、なんとしてもその日のうちに終わる分量のチケットにする必要があると考えています。
そのためにはチケット作成時の粒度として最大で◯時間と決めてチケットを作る必要があります。
もちろん1機能が大きい（ように見える）場合もありますが、その場合は機能の中で満たすべき要件を洗い出して、処理の中身をステップに分けてそれに応じてチケットを分割します。
そうすることで、1機能丸々作り終えてから実は仕様と違ったと言った際のさし戻りが小さく出来ますし、少しずつレビューができるので、チェックする側も楽になりますし、開発する側も直ぐに修正ができるようになります。

2.本当に大事なことに集中して、それ以外のことは忘れる。

本当に大事なのは、動くソフトウェアを提供することであり、ドキュメントはあくまでもその補佐的な役割になります。

具体的には・・・

ソフトウェアをリリースできる状態にしておくことを一番に考える。

ドキュメントだけでなく、ムダを省く必要があります。ソフトウェアにバグが有ることがわかっているのであれば、新しい機能の開発はやめて、そのバグの修正に全力を尽くさなければいけません。

3.ちゃんと動くソフトウェアを届ける

お客さんに価値を届けるということは、常にテストされて動くことが担保された状態にしておく必要があります。テストだけは疎かにしてはいけません。

具体的には・・・

開発が終わったらすぐテストを行う。

プログラマの言う「開発がほぼ終わった」やチケットの進捗90%、は何も終わっていません。

プロジェクトマネージャーの視点で言えば、いや、プロダクトとして言えば、何も終わっていません。テストを行なってリリースできる状態になればようやく完了となります。

ここがプログラマとプロマネの意識の違いになるので、プログラマからプロマネになる時の難しい点でもあります。

チケット管理システムをプロダクトのためのツールとして使うのであれば、進捗は0か100かだけで事足ります。

リリースできるか出来ないか、それだけです。

Redmineには進捗のパーセンテージを登録できる機能がありますが、消しました。

開発が終わったらすぐにテストに入るのも重要です。あとでためてからやると、テストも大変になりますし、バグが出た時にどれが原因か分かりにくくなるので大変です。
開発が終わってテストまで終えてチケットを完了にしてから帰るのがベストですね。
テストが終わってないのは何も終わってないのと同じ！

4.フィードバックを求める

狙い通りに進んでいるのを確認するためにも定期的にお客さんにフィードバックを得よう。

具体的には・・・

見せられる状態になったらすぐに見せる。

せっかく定期的にお客さんに価値を届けているはずなのに 、全部が完成するまでフィードバックを得られない。それは定期的に価値を届けてないということになってしまうので、せっかく見せられる環境があるんだったらどんどん見せて意見をもらいましょう。

意見を全部吸い上げていたらスケジュールに間に合わない、というのであれば、やるもの・やらないものを決める交渉を行うことが必要です。

どちらかと言うと最後にまとめてフィードバックをもらって、DB構造から作り直しだよ・・・。デスマ確定。というケースのほうが多いんじゃないだろうか。このようにならないように、定期的に実際に動いているものを触ってみてもらって確認してもらう必要があります。

頑張ってモック作っても「これってエラーの処理とかは実際の画面遷移じゃないんでしょ？」と言われて結局触られないことが多いので、動くものを見せましょう。

5.必要とあらば進路を変える

計画を変える。現実を変えるんじゃない。

具体的には・・・

計画は変わるものだと認識する。

例えばYahoo APIを使った連携をする計画を立てていたとするが、開発中に有料APIになるアナウンスがあったにもかかわらず、そのまま何も考えずに突き進む前に、本当にそのAPIを使うのか、別に乗り換えるのかを考える必要があります。

計画はあくまでもその計画を立てた当時の計画であり、流動的に対応をしていく必要があります。

6.成果責任を果たす

質・スケジュール・期待・資金のコントロールを行う。

具体的には・・・

決められたスケジュール内でお客さんの期待するものをリリースする。

ファイルを作る順番に暗黙の制約がある | Play Framework2.0 ここがんばれ！

https://twitter.com/kamekoopa/status/288872473091526656
でもつぶやかれていますが、まさにそのとおりなんです。

僕の今までの開発スタイル

1. 最初にルーティングを決める
2. 次はControllerを作る
3. 最後にViewを作る

以上。

ただざんねんながら、Play Frameworkではこの順で開発を進めようと思うと、途中のステップで止まることは許されません。

ルーティングを決める

routesにはURLのルーティングとそれに対応するメソッドを記述します。

となると、記述されるControllerとその中のメソッド（ detail()とか）を作らないとコンパイルできません。

Controllerを作る

Controllerでは、最後に出力するviewをimportする必要があります。そのため、先にviewを作る必要が出てきます。

Viewを作る

じゃあ先にviewを作るか、ということで作り始めるとまずぶち当たるのが、引数の問題です。大体ModelやFormなどを渡すことが多いのですが、これらも先に定義されてないと渡しようがありません。

ああ、この画面に引き渡すModelなり何が必要になるか、Viewを元に考えることになるのか、とふと思うのです。

そしてViewが出来たらようやくControllerです。Viewを先にコンパイルしてないとEclipseで警告が出まくるので注意が必要です。

それにうっかりView側にこの引数も渡さないとだ、と思って引数を1つController側とView側とで追加すると、またEclipseでエラーに。同じViewを複数箇所で呼んでいるとホントは引数追加しなくちゃいけないのに、引数が足りない方はEclipseのエラーが出ず、追加した方はEclipseのエラーが出てしまうというちょっと開発の順番が悩ましいことに。。。

最初の設計が重要、ということですね。

Modelの中に色々かけてしまう | Play Framework2.0 ここんがんばれ！

ざっくりし過ぎていて駄目なタイトルではありますが、つまり私が言いたいのは
メソッド名の付け方に気をつけろ！ってことです。
後これは正直Play Frameworkとか関係ない気がします。

例えばユーザーのモデルに性別を追加したとします。

public string gender;

みたいなのを用意してここに
男性：M,女性：Fをデータとして入れるとしましょう。

DB的にはF,Mでいいですが、表示の際には男性、女性とか男、女とか表示をします。
その場合に

public string getGender(){
if(gender.equals("M")){
 return "男";
else{
 return "女";
}
}

みたいな感じに書いてしまったらもう駄目ですね。
テンプレート側で

user.gender

した時にデータの取得どっちでするの？的な厄介な問題になってしまうので、せめて
getGender()をgetGenderString()にでもしておく必要がありますね。

100ファイル程度になるとHotDeployができなくなる| Play Framework2.0 ここんがんばれ！

Play Frameworkの特長として、ホットデプロイがあげられることがあります。
確かにファイル数が少ないうちはサーバを再起動しなくてもホットデプロイできてしまいます。

もともとPHPを使っていた身としては、ようやく追いついたか、位にしか感じていませんが。。。Slim3もホットデプロイを謳っていますね。

ただファイル数が増えてくるとホットデプロイができなくなりStackOverFlowのエラーが発生します。
そうなってしまったらもういっかい

play clean

でクリーンしてコンパイルし直さなければいけません。
経験上、大体Javaのファイル100ファイル、Scalaテンプレートのファイル100ファイルくらいで限界値が来ています。
一般的なWebアプリケーションではすぐに到達するファイル数だと思いますので、 この程度で結局コンパイルを手作業でしなおさないといけ無いとなると、あまりホットデプロイの恩恵をうけることができなくなります。

ちなみに複数のGmailを受信してパースしてゴニョゴニョして1つのメールにまとめて送信する簡単なプログラムを作るにはPlay Frameworkは実に簡単に出来ます。

セッション共有に頭を悩ませる必要がない | Play Framework2.0 ここがいい！

あんまりPlay Frameworkの気になるところばかりを書いていてもあれなので、いいところも書いてみたいと思います。

Play Frameworkはポートを変えて複数起動するのが簡単に行えます。
そのため、フロントエンドをApacheにし、Proxyの設定で複数のPlay Frameworkに振り分けを行う設定ができます。

Play FrameworkもやはりJavaの子、再起動には多少時間がかかります。アプリケーションの規模にも寄ると思いますが1分くらい起動にかかるので、果たしてこれが瞬断といえるか、というとまあ言えないですね。

そんなときにリバースプロキシとしての Apacheを上手く使ってあげて、
1つのアプリを起動している間に、別のポートで立ち上げていたもう1つのアプリ側に振り分ける。
それが終わったら今度は逆に振り分けを行う、といった設定をしてあげます。

詳しくは
http://www.playframework-ja.org/documentation/2.0.4/HTTPServer
に載っています。

ちなみに待機系を指定する status=+H オプションはApacheのバージョンによっては使用できないため注意が必要です。

そこでこのURLに書いてあるとおり、セッション共有に頭を悩ませることはないということだそうです。

ただ実はPlayでSessionと呼んでいるものは実際にはCookieのことなので､サーブレットでいうSessionに近いものはCacheとなり、これは別ポートで立ち上げたアプリごと別になります。
つまり、Cacheにログイン情報とかを入れてると共有できなくなってしまいます。（当然といえば当然ですが・・・）

メンテナンス等を行う場合はApache側でメンテナンス画面を返すようにするとか一瞬のセッショ切れも、ログイン画面へ転送されるものとして割り切るかという判断になるかと思います。

大規模対応のためDBにセッションデータを入れるなんてプラグインすでにあるのだろうか・・・

SSLを使おうとするとApacheが必要になる | Play Framework2.0 ここんがんばれ！

SSLをPlay Framework2で使いたい、でしたらApacheを使いましょう！枯れたもとい安定した技術、お勧めです！

http://www.playframework-ja.org/documentation/2.0.4/HTTPServer

Webアプリケーションを作ったもののSSLを使って公開したいなあ、そんな時もあるでしょう。わかります。僕も人の子です。
Play Framework2.0.4ではSSL非対応です。
将来対応する、なんて話をどこかで耳にした記憶があります。
来るべき将来に備えて、まず今はApacheを使いましょう。
Apacheじゃなくてもいいですが。

SSLを使いたい場合はApache側でSSLの設定をしてProxy通すようにしてあげましょう。上記リンク先にある設定みたいに443ポートに対してProxyの設定を下記みたいな感じで設定してあげましょう。

<VirtualHost *:443>
  ProxyPreserveHost On
  ServerName www.loadbalancedapp.com
  ProxyPass  /excluded !
  ProxyPass / http://127.0.0.1:9000/
  ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>

SSL接続の時、asettsがどうなるか、僕は知りません。
Apacheを使ってしまうんだったら、Apacheで静的ファイルは返してしまえばいいんじゃないか、そう思います。

残念ながら今のPlay Frameworkでは単体で全てをまかなえるレベルにまでなっていません。そこまで行けば取り扱いが大分楽になると思うのですが。

bootstrapをAndroid2.3系で使えるようにするためにはApacheが必要になる | Play Framework2.0 ここんがんばれ！

bootstrap、よく使いますよね。

Play Frameworkではassertかassetsか何かを使ってNettyサーバ経由で画像やJavascriptを返すようになっています。（おそらくそういうことなんだろうと思ってます）

さて、通常のブラウザを使うぶんには何ら問題ないのですが、以下の組み合わせでモーダルダイアログが表示されないなどの現象が発生しました。

Play Framework 2.0.4
bootstrap
Android2.3

なかなかニッチな環境かもしれませんが、Android2.3系はまだバリバリ現役なので、注意が必要です。
http://www.playframework-ja.org/documentation/2.0.2/Assets

Play 2.0 には、公開アセットを提供する組み込みのコントローラが付属しています。デフォルトでは、このコントローラは、キャッシュ機能、ETag、gzip圧縮、JavaScript minify のサポートが提供されます。

とあるので、ここらへんが影響してる可能性がありそうですね。

Apache経由で静的ファイルを返すようにすることで回避できましたが、Play Frameworkはそれ単体だけでは完結できないのに、Tomcat用にwarファイルを作るのもできない（Play Framework1系では対応していたようですが、2系からはプラグインでの対応！？になったようです）のでちょっと残念です。

Modelが自動生成されない | Play Framework2.0 ここんがんばれ！

PHPのフレームワークである、SymfonyやGAEのフレームワークであるSlim3を触ってきた経験から、Play FrameworkにはモデルやServiceの自動生成がないのが非常に残念に感じます。

Symfonyはかなり律儀なやつで、ymlからモデルの自動生成をやってくれていました。（Play Frameworkも1系の頃にはそんなのもあったようだと聞きました。）
ymlにルールを記述して自動生成すると、ymlの定義に従ったBaseとなるModelが生成されます。そしてそれをオーバーライドする形でもう一つModelが生成され、通常はこちらにアクセスをするようになっていました。
また、Modelとは別に、Listの取得などを行うPeerと呼ばれるファイルも自動生成されいました。（Slim3で言うところのSeviceに当たりますね。）

今までの経験からPlay Frameworkの場合は以下が自動生成されてくれるようになるとより使い勝手が良く、複数人で開発をする場合も統一性が取れるのではないかと考えています。

• DBの構造と完全に1対1で対応している基底となるModelクラス（自動生成のため、手作業による変更は行わない）
• 基底クラスをオーバーライドするModelのクラス（例えば住所をつなげたものを返すなどのメソッドの追加などはこちらで行う。）
• 基底クラスをオーバーライドするJson用のModelのクラス
• save,deleteなどのモデルに対する操作を行うクラス
• list等のモデルのデータ取得を行うクラス

Play Framework2.0 でSQLを出力する方法

Play FrameworkのJava版ではORMにEbeanが使えるのですが、どんなSQLが発行されているか、確認をしたいケースがあります。

そんな時には、application.confに以下のように追記することで、コンソールおよびログファイルに実際に発行されているSQLが出力されるようになります。

db.default.logStatements=true
logger.com.jolbox=DEBUG

Stackoverflowに載ってました。
http://stackoverflow.com/questions/9719601/play-framework-2-0-and-ebean-sql-logging