アジャイルサムライ |
アジャイルサムライ読み終わった。テクニック以外の部分（いわゆる取り組み方）が重要なのは当然として、取り組み易い環境作りが大事。人は怠け者だから、取り組み易い環境がないとやっぱりうまくいかない。所詮は理想と思って取り組めなくなってしまう。
アジャイル開発をするのに重要な以下の4つ。
- ユニットテスト
- リファクタリング
- テスト駆動開発
- 継続的インテグレーション
どれも個人的な開発ではおざなりにしてまいがちな項目…。
これらの環境整備をまず行なっていきたい。
これらがひいては時間の節約をするための強力なツールになるので、事前に投資するべき。
プロジェクトの回し方については、アジャイルな見積りと計画作りに書かれていたように、イテレーションの中でベロシティ（チームの開発力）を計測しつづけて、チケットに当てられたポイントをベロシティxイテレーションで差し引くことでプロジェクト完了時期を算出するという方法だった。
それを根拠に期間を調整したり、リリース時期のほうが重要な場合は、機能のほうを削っていくなどで対応する。
完成してない機能に関しては、半分完了しているからといってその分を進捗報告に加えない。リリースできないものは加えてはならない。あくまでもリリース可能なソフトウェアの形を維持し続けることが大事。
アジャイルであるためには失敗を怖れてはならない。失敗は誰でもする。またプロジェクトの進み方が理想的でないにしても、それは失敗ではない。理想的でないというだけ。改善していけるところから改善していけばよい。
自分の言葉があんまりにもなかったので、自分の言葉で書いてみる。
たぶん管理手法としては、自分は付箋紙やホワイトボードを使うようなアナログな管理手法のほうが小規模チーム（顔を見渡せるくらいのサイズ）では向いていると思う。それをデジタルツールにも移すけれども、手で書いた方が早い場合のほうが多いんじゃないだろうか？ただ項目数が増えすぎるとアナログツールでは管理しにくいので、そこをデジタル化で管理したのがいいのかなと。
ユーザーストーリーから機能を掘り起こして、機能からテスト項目を掘り起こして、というツールがあって、それがある程度コードを自動的に生成するような仕組みがあったらよさげ。Railsのgenerateコマンドでもひな形は作ってくれるけれど、それをもう一つ踏込んだ形で、例えばチケットを発行したらそれに合うCucumberのテストが書かれるとか。
プロジェクトの見通しがよいようにするためには、管理することに重点を置く、のではなくて、自動的に管理されることに重点を置く方がいいのかなと思う。チケットに仮の名前を付けられるようにするとかできたらいいのになとか、時々思う。
チケット駆動開発が、自分的には理想型なんじゃないかと思っているのだが、これを徹底するのもまた難しかったりする。利便と不便の狭間があるのだが、なかなか落としどころがわからない。
あまり勉強をしない人には、なんでそんなことをするのか？ということを説明するのも大変だったりするので、アジャイル開発の勉強をする機会を社内で設けて知識の共有を図っていったほうがいいのだと思う。そうすれば自ずとスライドとかも蓄積されて新しく来るであろう人の教育にも使えるのであろうし。
ダラダラと書いてみたが、そういうのを企画していきたいと思う。
