わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。
アジャイルの前のほうが楽だった？
「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。
- http://kaorun55.hatenablog.jp/entry/2012/04/17/001312
- 第5回TFSUG WFからAgileへの変革 - Speaker Deck 34スライド目と37スライド目
他にも似たような情報があるかと思って調べてみると、興味深い記事も。
確かに、アジャイル開発は全ての人に向いている方法では無い。
短い期間で結果をだし続けなければいけないのは想像以上に大きなプレッシャーだと思う。
ウォーターフォールだと期間も長いから少しずつリカバリしていくことが出来た。理論上は。
実際には問題はどんどん積み上っていくばかりだったけど。アジャイルはその問題を先に見せて、場合によっては毎週のように怒られるのだろう。
それはやだなぁ。
パブリックなメモ : 『アジャイルサムライ』を読んだ
それはいやだ。
日本でよく言われるのが、「期日までに使わない(と思われる)機能も全部作れ、契約だから」とか。限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまう。このような状況が続けば焼畑農業のようにチームには何も残らなくなる。
ゴールを決め過ぎてしまうことによって陥る罠 | Ryuzee.com
開発プロセスの変化で何が変わったのか
アジャイル開発が、従来型(?)のウォーターフォール型・計画駆動型の開発プロセスと変わった点はなんだろうか。思いつく限り列挙してみる。
- リリースサイクルが短くなり、常に本番のプレッシャーにさらされる。
- 常に顧客の近くにいることになる。
- 実際には週に１回会議でしか会わないとか、間にちゃんとPMが入って緩衝材となる場合も多いようだが。
- オンサイト（いわゆる常駐型）なのかにもよるか。
- 数日といった短いサイクルで設計、プログラミング、テストの作業を行う。短い期間でさまざまなアクティビティを行う。
- コミュニケーション重視。
- あとでゆっくり確認するとか、時間をかけて考えるタイプの人にはストレスかもしれない。
- 自分の作業が終わったらすぐにオープンにする。
- 手元において、数日の間を置いておくといった行動はしにくい。
- 毎日成果が求められる。
- 別に非アジャイル開発でも成果は必要なんだけど、「今日の成果」を毎日求められるようになるのは強いプレッシャーかもしれない。
- 業務時間内の学習がしにくい。
- 実際にはそんなことはないと思うけれども、毎日の作業プレッシャー下でどうどうと学習や研究をするのは憚られるような気がする。
- マイクロマネジメント風。
- これも実際は違うのかもしれないけど、毎日「自分の作業について語ったり」「人の作業にコメントする」のは一種のコマンドコントロール型マネジメントと似ている側面もある気がする。言う人がマネージャーから同僚に変っているけど。
- 放っといてくれタイプの人はむかない？
前述の通り不確実性の高い状況下において「達成」に関する約束をすることは難しいが、一方で個人による努力ではなくチーム全員が同じゴールに向かって最大限努力することは約束できるだろう。誤解して欲しくない点として、これは長時間労働や休日出勤をするという意味ではないということだ。アジャイルな開発の特徴は、リソースと時間を先に固定し、その範囲内で最大のビジネス価値を実現するものである。固定された時間の中で成果を出さねばならない。そしてその努力の中には、自分達がより良い成果を早く出せるようになるために、チームで継続的に改善を行うことも含まれるのである。
コミットメントとは何か？ | Ryuzee.com
常に最大限努力はつらい。
