heavy weight processな改修方法

Other

id:yousukeharaさんとオフラインで議論してて、いろいろと認識を改める機会がありました。特に、GTDを前提に開発プロセスを考え直した場合、思っていたよりきれいにステージが細分化できるし、ロールが明確になりそうな感じです。
heavy weightっていうと嫌われる時代なのですが、light weightでもheavy weightでもこなすべき内容の総量に違いはなく、それがいかに早く回転できるかって言うことだと思います。そういう視点で、プロセスの作業エッセンスを分析中。
特に重視しているのが、各ロールにおける問題の捉え方。あとステージング。

  1. どこで起こったのか: エンドユーザの視点 (which, where, when)
  2. 何が起こったのか: テスタの視点 (what)
  3. なぜ起こったのか: レビュアの視点 (why)
  4. どのように直したのか: プログラマの視点 (how)

これがまともに整理できたら、Computer Aided Engeneeringの視点を入れたいと思います。

一般ユーザ

  1. プロダクトを利用する
  2. プロダクトに問題が発生した場合
    1. IssueとしてITSに問題(which/where/when)を登録
    2. Issueを「報告済み」のステージへに移行

マネージャ(テスタ)

  1. ITSを眺める
  2. Issueが発生していた場合
    1. Issueに対して再現ToDoをToDo管理システムに登録。このとき、Issueとのrelationがあることを記録する
    2. Issueを「確認中」のステージに移行

テスタ

  1. ToDo管理システムを眺める
  2. 再現ToDoが発生していた場合
    1. 再現ToDoの内容を実行し、再現する
    2. 再現手順と、現象(what)を再現ToDoとrelationalなIssueに書く
    3. Issueを「確認済み」のステージに移行

マネージャ(レビュア)

  1. ITSを眺める
  2. Issue(>= 確認済み)が発生していた場合
    1. Issueに対して分析ToDoをToDo管理システムに登録。このとき、Issueとのrelationがあることを記録する
    2. Issueを「分析中」のステージに移行

レビュア

  1. ToDo管理システムを眺める
  2. 分析ToDoが発生していた場合
    1. 分析ToDoの内容を、関連する再現ToDoの結果を利用して再現
    2. 原因(why)を分析ToDoとrelationalなIssueに書く
    3. Issueを「分析済み」のステージに移行

マネージャ(プログラマ)

  1. ITSを眺める
  2. Issue(>= 分析済み)が発生していた場合
    1. Issueに対して改修ToDoをToDo管理システムに登録。このとき、Issueとのrelationがあることを記録する
    2. Issueを「改修中」のステージに移行

プログラマ

  1. ToDo管理システムを眺める
  2. 改修ToDoが発生していた場合
    1. 改修ToDoの内容を、実施
    2. 実績(how)を改修ToDoとrelationalなIssueに書く
    3. Issueを「改修済み」のステージに移行

その後

たぶんこのあとに、改修内容の確認とかも発生する。