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時点)