アジャイル開発って、スキルではないのでどうすればアジャイル開発かと言うと定義が難しい。
強いて言うならば
・プロセスやツールより人と人同士の相互作用を重視する。
・包括的なドキュメントより動作するソフトウェアを重視する。
・契約上の交渉よりも顧客との協調を重視する。
・計画に従うことよりも変化に対応することを重視する。
を守ってるものだろうか？
まぁ、まぁ、僕がやってるものもこれを守ってるからアジャイル開発と言っていいと思うが。。。
デブサミで聞いたり、どこかの教科書っぽい文献を読むとXPやらスクラムやらが主流で色々書かれてるけど・・・。
これって本当に実践できるのだろうか？
と思う。
なんていうか、アジャイルで決められた事（プラクティス）を守ると結局のところマニュアルに決められた事を行う事になるかと思っていて、、、アジャイルってマニュアル通りにやってて出来るのだろうか？
僕がやって見て思ったのが、とてもマニュアル通りには出来ないと感じた。
特に「人同士の相互作用」や「顧客との協調」なんてマニュアル通りではとても出来ない。僕がやってて思うのが、アジャイル開発って随分
属人性にかかっている
のでは、と思うのだ。
言い方が悪いが、誰にでも出来るものではないと思うし他の人と同じ方法では出来ないと思うのだ。
誰かのを参考にして、自分なりのオリジナルを作る事は出来るかもしれないがコピーは出来ないと思うのだ。
で、僕のやり方だが・・・
僕は基本的に一週間でイテレーションを回している。
その理由としては、Railsで開発すると１機能のスパンが１～３日程度だからだ。ならば、週の定例として作った機能のお披露目と次のタスクを受ける形にすれば良いかと思って週１でやっている。
もちろん、この理由はほかにもある。自社サービスを作っているためお客さんが自社のためである。（これが遠方のお客さんだったら毎週はきついだろうな・・・。）
さらに、僕は情報集約型でアジャイルを回している。
すなわち、僕に全ての情報を集めて他の人は自分の作業に集中する形だ。他の人が何をしているかはおぼろげながら知っていても、週の終りまでは自分の作業以外は知らない状態が続く。（他の人とコミュニケーションが必要な場合は僕がMTGを設ける。また、そのタイミングも僕がハンドリングしている。）
そして、週の最後に一日かけてコードレビューを行う。これは基本的にみんな参加である。
コードレビューが終われば、次の日に定例でお披露目と言うスパンが続く。
纏めると・・・
金曜：今週行った事のお披露目と次週のタスクを貰う。
月曜～水曜：とにかくコーディング。（水曜日は定時退社日）
木曜：コードレビューで情報共有
金曜・・・
こんな感じで約半年回してきたが、開発速度とクオリティはかなり良いものが出来た。（今まで何度も失敗してきたプロジェクトなので、この短期間でこれだけのものが出来る事に感嘆された。）
さて、この方法は世の中の方法とは違うのだろうか？
ちなみに、利点と欠点がある。
【利点】
・僕がハンドリングをしているため、最終的に意見が割れて仕事が進まない事は無い。僕の責任の範囲で判断を下すため何をすべきかをメンバーが迷う事が無い。
・僕が全ての状況把握しているため、コアな打ち合わせは僕とお客さんだけで進める事が出来る。（すなわち、詳細が分からないからメンバーを参加させるようなメンバーのリソースを喰う事が無い。）
・当然だが、フットワークが軽い。
※トップダウンっぽいが、ボトムアップの意見も取り入れている。KPTもそうだが、僕は理論がしっかりしている意見は極力取り入れるようにしている。その結果スケジュールが遅れても後で必要な場合はボトムアップの意見を優先する。
【欠点】
・僕がいないと回らなくなる。しばらくは平気だが、長期にかけて居なくなると僕の代わりを務める人を育てるのに非常に時間がかかる。トラックナンバーが１の状態のため僕は容易には休めない。
・僕の作業が入ると一気に回らなくなる。（僕はフレームワーク等のコアコードも作成しているため、そこでバグが出るときつい状況に陥る。バグが無ければテストコードをしこしこ書いてるんだけどねぇ～。）
・僕の意見が揺れると、メンバーも揺れる。（前に言ってた事と違う事を言ったりすると大変。）
メンバー主導型だとどうなるんだろうか？
情報の集約やお客さんによって上手くリソースがとれなかったりするのではないだろうか？
これは僕の友達とも話したのだが、お互いメンバー主導型をしっかり実践できてないのでいまいちわからないのだ。
有識者の意見求む！