Life is beautiful: 私のとっておきのプログラミングスタイル
少し前の記事だけど反応。
- スタードダッシュでできるだけはやくめどをつける
私もどちらというとスタートダッシュ型。単に心配性なので先に問題になりそうところを潰しておきたいという思いのほうが強いのだけど。
ただ、チーム作業だと自分だけがこうやって頑張っても限界があるので、同じような考え方の人が一緒だと生産性は上がるはず。もし自分以外にそういうタイプの人がいなさそうな場合は、先に課題や問題点、過去の失敗事例をたくさん指摘しておいて「ああ、いろいろやっとかないと後からまずいことになるな」と思わせるのが良い。
早い話が、相手の不安を軽く煽る。
一度でも過去の仕事で痛い目にあった経験があると、理解してくれやすいのだけどね...。
（どのみち設計変更はするので、あまり先のことまで綿密に計画を立てるのは時間の無駄）
これも結構賛成なのだけど、システム屋をやっているとスケジュールは作らないといけないからなぁ。PMBOK系でもWBSからスケジュール引くことが推奨されているしね。これは善し悪しなんだろうけど。
私の場合はずっと仕様変更や割り込みの多いプロジェクトをやってきていることもあって、プロジェクトの序盤にあまり細かいスケジュールを引くのには消極的。もちろん当初計画時点で時間的、人的リソースに不足があるかどうかなどを見るには線を引いてみるのだけど。数日するとまたリスケしたり作業工数を再見積することになることが多いので、リスケする工数自体バカにならなかったり。
すでに判明している開発タスクを見込み工数とともに洗い出しておき、各メンバーに対して1つか2つを割り当ててあとはプールしておく。手持ちのアイテムが終わったメンバーからプールしているタスクを割り当てていく、随時アサインのほうが上手く回るケースも私の周りでは多いかな。
「たぶん動くだろうけど、バグがあったらテスターが見つけてくれるからいいや」という考えでチェックインするのは犯罪行為。
これはけっこう耳が痛い。
評価チームがある程度いるプロジェクトだと「プログラマは作って軽く動かしてみるだけ、あとはテスターが」という考えに陥りがち。スケジュールに追われるというのもあるし、コーディングが好きでもテストは面倒、嫌いという人が多いからだろう。
コードを書いたあと、Excelで単体テスト仕様書をシコシコと作り、それにそってテストする。テストのほうが時間がかかるというようなやり方だとテストが嫌いになるかもね...。かといってTDDは浸透しないし、手動テストでもテストコードによるものでも「テストにかかる時間」を嫌う傾向が強いのが問題。
結局、テスターが単体テストレベルのバグを見つけ、「なんでこんなバグが残っているモジュールをテストに回すんだ」とクレームが来ることになる。またテスターから見るとバグだらけのモジュールを渡されて、バグ票を起票する作業でテスト計画が大幅に狂うという悪循環が起こってプロジェクトが破綻の道を進み始めるので、開発側は軽い気持ちでテストを怠ったらダメだな。
