纏め読み：開発プロセス再入門

＠ITから、開発プロセス再入門

回帰テストについての調べ物で辿り着いたシリーズ。読んでおく価値がありそうです。単独のインデックスが付いていないのが少々追い掛けにくいところです。

第1回 だれも書かなかった反復型開発のホントの姿

初回は前振り、下流工程の実際にコードを作っていくフェーズ限定とことわっています。最近 、開発プロセスと云うと上流工程に注目するものが多いための注意書きかも知れません。

第2回 反復開発の“反復”とは何をどのように反復するのか

第二回はビルドとリリースの定義。概念的には開発チームと評価チームとが分かれていて開発チームでビルドを繰り返し、一定の品質に達した（開発者的にですね）ものがリリースになって評価チームに渡されるイメージです。

第3回 ビルドはどのような要件を満たすべきか

ビルドが満たすべき要件の規定です。が、メインはリリースされるビルドの方、提供するバイナリイメージと付属文書といったところでしょうか。ビルドという概念自体、バイナリ提供されるものに固有のもので、ソース提供されるものだとバージョンだけで充分なようでづ。ソース提供だとユーザーサイドでコンフィギュレーションいじったりすることが前提になりますからね。

第4回 反復計画のたて方

それぞれの反復で何を実装し、何をテストするという計画の建て方の解説。反復系の開発プロセスでは最初からすべての機能を実装することはありえません。小規模なコアからスタートして機能を追加実装していく形になりますが、それぞれの反復をどのように規定していくかという話です。

第5回 チーム開発に向けたビルド環境の構築

ビルドのための環境構築の話。ここで専用のマシンを用意するといいと言っていますが、昔はなかったのですが、最近は自動更新でOSやらライブラリやらが更新されることがあるので、その点については少々頭が痛いですね。昔は更新されたシステムライブラリの所為で動きが変わるというのは結構目撃しましたが（なので開発機では自動更新止めていました）、最近はどうしているのでしょう。

第6回 ビルドの位置付けとリリースの順序

見かけるソフトがやたらと大きい所為でしょうか、OSやミドル系のアプリなんかでは延々とビルド、リリースが繰り返されるイメージがあります。そういえばRCまでいってからその先に進まずに後ろの番号がどんどん増えていったこともありました。

第7回 テスト計画の立案

まあ、テストはそれだけで本が一冊書けてしまいますからね。筆者氏の筆も勢いを増しているように思えました。個人的には少量のテスト項目で済むユースーケースベースのテストが好みではありますが、自分用のプログラムならそれで済んでもお仕事のプログラムとなるとそうは行きませんからね。いつでも頭の痛い作業です。

第8回 ソフトウェアの不具合を追跡するには

不具合報告書は、まあ公式にはQA担当と開発担当との間で交わされるものではありますが、個人的には何であれメモを取って欲しいですね。自分でも同じミスを繰り返すことがありますし、他の開発者の助けにもなりますし、回帰テストでバグが見つかった時なんかの手助けにもなりますから。無論、正しいフォーマットのなんかを作ってはいられないでしょうから、紙に書きなぐりで充分です。昔、ちょっと大きなプログラム（Xサーバね）を移植した時のそういう作業メモ、最終的には８センチバインダー一杯になりました。無論公式のQAシートとは別に、です。結構同じようなバグを繰り返すので仲々に役に立ちました。

第9回 不具合追跡でよくある間違い

問題は再現性、再現手順ですよね。個人的なモットーとしては「再現できるバグは必ず直せる」のですが、再現しないバグばかりは手の出しようがありません。昔の仕事でQA担当が100％再現するといってきたバグ、開発側では数十人が一週間かけてもまったく再現しないことがありました。まあ、マルチタスクのタイミング関係のバグなんかは難しいものがあります。そういうケースではむしろ設計文書を見直した方が早く原因が見つかったりするものですが。ブラックボックステストになるとそういうことも出来ませんからね。

第10回 課題駆動型開発を提案します！

課題駆動型開発という言葉というかモノを提案していますが、反復で機能と課題（issueという英語の方が意味が通じそう）を片付けていくイメージですよね。初期想定されたマイルストーンと発生した課題に対するマイルストーンとをターゲットにする動的なマイルストーン管理とも言えそうです。実際、課題のなかには不具合によるものだけでなく、仕様の更新やフィードバックによるもののあるわけで、反復でそういうのを潰していくというのは成果が目に見える分テンションが上がりそうです。