XP本読書会13回目のふりかえりのふりかえり
By 管理人
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
スコープの管理
ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。
数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。
すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。
いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。
テスト：早めに、こまめに、自動化
あとでまとめてテストしようとすると、テスト自体にとてもコストがかかるのと、どうしても欠陥が残ってしまうということ。さらに欠陥を取り除こうとしてもコストが増えるばかり。逆に、こまめにテストを実施していれば、欠陥も起こりにくいしそれほどコストもかからない。あと、プログラマー目線でのテストと、顧客目線でのテストによるダブルチェックが重要というお話。ダブルチェックといっても、テストの工程を分けるんじゃなくて、まとめてテストできるように自動化が必要、という感じでしょうか。