開発評価に向けて 〜内容編２〜

また間が空いてしまいましたｗさーせんｗ

今日はレトロスペクティブについて触れます。
前回同様、飽くまでも私が経験した内容を
もとにしていますので、違和感を感じる方も
いらっしゃると思います。
どうかご容赦ください。

2週間のイテレーションを終えると
レトロスペクティブを行います。
内容はKPTについて。

言わずもがな
K・・・KEEP（継続したいこと）
P・・・PROBLEM（問題点・改善が必要なこと）
T・・・TRY（挑戦したいこと）
です。

毎回のように同じ意見が出るのですが、
どうにも進歩のないチームのようです。
参考程度に上げますと、
・朝昼夕のスタンドアップミーティングが有効（K）
・意見交換が活発にできた（K）
・テスト駆動ができてない（P）
・リファクタリングが不完全（P）
・レビューがされてない（P）
・バージョン管理でGitを使いたい（T）
などなど。

ちなみにワタシは管理に注力してましたので、
上記意見は開発を担当した入社１〜３年目社員のもの。
これが弊社若手社員の実力ですｗ

これらの意見を簡単に紐解きますと
・朝昼夕のスタンドアップミーティング
⇒全然報連相がないため、強制的に発言させる場
・意見交換が活発
⇒傍から見るとただの意見共有。やって当たり前なのでは・・・
・テスト駆動、リファクタリング
⇒何回言ってもやろうとしない。目の前の製造作業でアップアップ。
・レビューがされていない
⇒対面レビューの代わりに机上チェックをして
　フィードバック事項をリファクタリング手引きとして
　各担当者に展開。結果は上記のとおり。
・バージョン管理
⇒結局subversion止まり。引き受けた人間が勝手に導入を凍結。

うーむ。
毎回振り返り結果が同じというのも考え物。
それでも不思議と成果物だけは出来上がっていってしまった件。
ま、保守性・可読性がアレなんでしょうが・・・ｗ
品質は総合試験でシナリオをバンバン消化して
単体レベルのバグや結合レベルのバグをつぶす。
品質報告は絶対出来んなｗ

こんな感じでレトロスペクティブが進んでいきました。

今日はここまで。
次回はカットオーバー後の保守について書かせていただきます。

乱文にお付き合いいただきありがとうございました。