デスマーチについて考える(デスマーチ経験のエピローグ)

これは某サイトで書いた日記()の転載です。

私はテスタとして、必ず

  • バグの修正を「お願いします」と言う。
  • バグ修正確認時は、必ず直してないところも最低1箇所は触ってみる。(でよく落ちる)
  • バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。

を実践してゆきました。

ある日、一人のプログラマさんから相談を受けました

“デスマーチについて考える(デスマーチ経験のエピローグ)” の続きを読む

デスマーチについて考える前にデスマーチの経験を書く

これは某サイトで書いた日記()の転載です。

その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。

まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ! ということを頻繁に行った。
受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが(幸運にも!)教えてくれても、それが議事録に書かれることはなかった。
受けたプログラマもいいかげんだった。「この計算はどこのデータを見るんですか?」と質問したところ、SEは「うーん、とりあえずここだと思う」と言うので、それに対するエビデンスを残すことなく実装した。
そして、それらはだれかに検証されることなく現地に持ち込まれた。

そこに仕様のわからない私がやってきた。

“デスマーチについて考える前にデスマーチの経験を書く” の続きを読む