この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

スコープの管理

ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。

数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。

すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。

いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。

テスト：早めに、こまめに、自動化

あとでまとめてテストしようとすると、テスト自体にとてもコストがかかるのと、どうしても欠陥が残ってしまうということ。さらに欠陥を取り除こうとしてもコストが増えるばかり。逆に、こまめにテストを実施していれば、欠陥も起こりにくいしそれほどコストもかからない。あと、プログラマー目線でのテストと、顧客目線でのテストによるダブルチェックが重要というお話。ダブルチェックといっても、テストの工程を分けるんじゃなくて、まとめてテストできるように自動化が必要、という感じでしょうか。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

単一のコードベース

読書会のときは、以前に手掛けたAndroidのカメラアプリが頭の中にあって、機種依存で苦労したことを考えていたのですが、今思えば他の仕事（ウェブサイト）でも派生させてそのままになっているコードも存在していて、このあたり一つに集約する努力が足りていないなぁとあらためて反省。

今、この記事を書きながら考えているのですが、共通部分を派生させて使いまわすのではなくて、共通部分を完全に分離して、汎用的に使えるように作り込めば良いはず。今、すでに複数のプラグインでメンテナンスが必要になっている部分を切り出して汎用化する方向で検討してみます。

交渉によるスコープ契約

新規案件だと、過去の習慣もあってひとかたまりで見積もってしまいがち。部分的にリリースして、その状況で次のステップに進めるように、契約を分けておくと良さそうです。一つ一つの機能の価値を確認しながら進めていく感じですかね。

（余談）読書会とは別の Code Kata について

先月、GDCRを松山で実施したことがきっかけとなって、この1月ほど Codewars で Kata の練習をしています。（参考：最近の勉強ツールあれこれ）

レベルはまだ 6kyu で、問題も 7kyu の Fundamentals を中心に練習しているのですが、問題によっては解いているうちにプロパティやメソッド、変数の状態など強制的に使わされる感じのものがあったり、あるいは問題を解くと、他の人のコード例も見えるので、そこで自分のコードの拙さに愕然としたりという状況ですが、まぁとにかくとても良いトレーニングになっています。

日常の仕事の中だとスキルアップに時間を費やすのはなかなか難しいかもしれません。ですが、適切なコードを書けるかどうかで効率とか品質は全然違ってくると思います。そのためには日常のトレーニングが重要。あまり難しい問題だと、続かないかもしれないので、比較的簡単な問題を様々な言語で引き続き進めてみようと思います。