ハイブリッドマン・・・立つ！

ウォーターフォールによる開発が一段落しました。
内製とはいえ、相変わらず納期厳守のPJにつき、
やっぱりあちこちでほころびが。

其の一：各工程の開発審査が雑
審査をすべき上司がなかなか時間が取れずに、
審査が伸び伸びに。
これが終わらなきゃ次工程に入れないはずなのに、
便宜上という形で次工程に進んでいた。

其の二：製造・試験工程のレビューが不十分
アジャイルで散々文句を言っていた若造どもが
いざWFで開発して、設計書を見ながら製造しているはずなのに
生産性がちっとも上がらない。
期間ギリギリになって、レビューの依頼をしてくるので、
結局机上チェック・フィードバックの形で済ませる。
レビューアの手間がかかってるっつーの。

其の三：試験の精度が低い
開発規模に対して、試験密度がやや低い。
コピペコピペで作った試験項目なので、
特定の観点について、全モジュールで漏れている模様。
後工程でバグって摘出はできたが・・・

ま、思っていた通り、WFに執拗こだわるやつほど
WFも満足にできないという仮説は正しかったようです。
何でもかんでも手取り足取り教えてもらって
その通りにやれば完璧にできると思い込んでいる
おめでたい輩は最低限の仕事すらできないわけです。
指示したとおりにしか動かないんだったら
SES契約の協力会社に頼むってｗ

そんなこんなで2ヶ月が過ぎ、
ふたたびアジャイルによる開発が始まろうとしています。
当然XP・スクラムといったピュアアジャイルは無理でしょう。
WF：アジャイル比が7:3あるいは8:2くらいのハイブリッドで
なんとかやっていこうと思います。

アジャイルな開発手法の妥当性・商用開発への適用可否を
見極めようとしているのに、こんなやり方でいいのやら。。。
過去の記憶を思い返しながら、また2ヶ月足らずの短い期間で
開発をしていきます。

ウォータフォーラーへ・・・（笑）

結局ウォータフォールでの開発が始まりました。
ガチガチのウォーターフォールで。
Webシステムで規模はおそらく6〜7Kstep。
これまた期限ありきらしく、7月いっぱいでカットオーバー。
つまり2ヶ月であの滝を実現しろ、と。

○要件定義⇒これは完了。
○外部設計(ED)⇒内部レビュー・外部レビュー・品質判定を含めて7人日。
　ちなみに実施要領の作成や設計書のフォーマット作成を含む。
○内部設計(ID)⇒EDと同じ。期間は10人日。
○製造・単体試験(C/UT)⇒上に同じく。期間も同じく10人日。
○結合試験⇒相変わらず同じｗ期間は5人日。
○総合試験⇒同じ。期間は3人日。
○リリース準備・リリース⇒同じ。期間は2人日。

1日だけ予備日があります。

まぁ規模が小さめですが、メンバはアジャイルの時と同じで3名。
途中参加になるメンバもいます。
ワタシの職責は進捗管理や品質管理(各種レビュー)がメイン。
エクセル方眼紙を駆使して、担当者の進度をウォッチする日々が・・・

しかも各担当者にウォーターフォールのなんたるかを
理解させながら開発を進めるという。。。
ウチの会社は学校か何かか！？
そんなもの自分で勉強するのが筋だろ！？
そんな叫びもむなしく、不毛な2ヶ月が始まりました。

不毛にならないように努力しなきゃなぁ。
そう思って開発の基本的な書籍

ずっと受けたかったソフトウェアエンジニアリングの授業(1)

を読み始めましたが・・・
なかなか手ごわい。
分かってたつもりでいたことが意外とうろ覚えだったり、
実はPJ特有のスタイルであったりと
結局WFの亜種みたいなやり方だったんだなと今更気づく。

はてさてどうやってアプローチしようかな。
大事なのはゴールをどう定めるか、じゃないかと。

こ、これが手戻り！？

ナニを書こうか迷っているうちに
間が空いてしまいましたｗ

先の開発にて仕上げたシステム。
改善要望がたくさんありました。
維持もアジャイルにやろうか迷いましたが、
聞き分けのない後輩たちを困らせてやろうと思い、
「お前たちが好きにやれ」と言い放つ。

・・・すでにアジャイルじゃなくなってました。
ワタシはおろかスクラムマスターまで蚊帳の外。
結局商用故障を出してました。
しかもまたこそっと直して終了。
リリース判定なんてどこ吹く風。
ここまで徹底して報連相をしない若手って
他社ではありうるのでしょうか。

上司に相談して話し合ったところ、
6月からの開発はウォータフォールに。
まずはウォーターフォールを経験してもらおうなんて
話の流れに。

うーむ。
初のアジャイル開発ってことで
至らない点は多々ありましたが、
まさかここまで退化(？)するとは・・・

ガチガチのウォーターフォールになるのか
多少なりともアジャイルなプラクティスが是とされるか
未定ですが、まだまだ前途多難な感じ。

もうね、これはね、やり方云々じゃなくて
コイツらにアジャイルは合わないって結論でいいと思います。
自分自身がもっとアジャイル手法について学びたいのに
ここまで足を引っ張られると・・・

これは諦めではなくて妥協点。落としどころです。
そう言い聞かせて次なるアジャイルな手法に
チャレンジしたいと思います。

なんという愚痴ｗｗｗ

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

いやっはっは
また間が空いてしまったｗ
週１くらいで書こうと思っているのですが、
すぐに忘れます。

気を取り直して、
今日は維持フェーズについて触れていきます。

無事にカットオーバーをしましたが、
アジャイルで開発をしている以上、
インクリメンタルかつイテレーティブに
維持をしていく必要があると思います。

つまりは上がってくる要望に、
いかにフレキシブルに対応していくか、ということです。

もちろんメンテナンス的な突発作業も入ってくるので、
システムについては熟知している必要があります。

残念ながら今回の開発は
縦割りでリファクタリングも不十分なので
改造するにも該当箇所の担当者のみが適任に。
ほかの人間ではソースの解読等に
時間がかかってしまうかもしれないのです。

これを避けたくてリファクタリングと
Javadocコメントを充実させたかったのですが、
各担当者がワタシの意図を理解できなかったようです。
「アジャイルである」ことにこだわるつもりは
なかったのですが、その分で別の形でフォローを
していきたかったんですけどね。

データ補正等の作業については手順書を取りまとめ
単純作業に落とし込んでいきます。
手順にどんな情報をどの程度盛り込むかがカギになります。
過剰な情報はノイズになって
作業者をミスリードする恐れがあるので。。。
この辺はワタシが担当し、若いメンバは開発に注力してもらいます。
もはや返済困難な技術的負債にまみれていますが、
若い力で乗り切ってもらいたいと考えています。
（指示通りに作業してればこんなことにならなかったんだよ、くそが）
という心の声はとどめておきますｗ

そして新年度から次の開発が始まります。
再びScrumによる開発です。
今回の経験を活かして、
さらにいいモノづくりをしていきたいと考えています。

次の目標は
・アジャイルな見積りと計画づくり
・管理よりも自主性
・ルールの確立と遵守

この辺でしょうか。
与えられた環境で最高のパフォーマンスを発揮するための
努力をしていきたいですね。

本日もお付き合いいただきありがとうございました。
次は何を書こうかな・・・ｗ

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

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

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

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

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

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

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

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

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

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

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

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

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

ちょっと間が空きましたが、
棚卸の方も進んできたので、また筆を執ります。
※キーボード叩いてんだろって突っ込みはなしでｗ

最初に留意いただきたいのは、
初めてのアジャイル開発で右も左もわからないメンバなので、
一般的な進め方と若干違うところがあります。
アジャイルサムライのマスターセンセイも仰っている通り
「アジャイルであることが目的ではない」のだと
割り切って読んでいただけると助かります。

開発開始にあたって
まずはプロダクトオーナー（以下PO）が
ユーザから聞き取り調査を行い
プロダクトバックログを作成しました。

一番最初のミーティングで
取りまとめた内容について展開をします。

チームのメンバはこれを受けて
チーム内でスプリント計画ミーティングを実施。
まずはデジタルモックの作成に着手しました。
デジタルモックといってもほとんど紙芝居。
年末にかけてのスケジュールの都合上、
最初のイテレーションは1週間程度しか
時間を確保できませんでした。。。

以降のイテレーションは2週間刻み。
営業日で換算したら10営業日ですね。
うちの会社は7.5h/dayなので75時間。
内訳は
スプリント計画ミーティング・・・0.5day
開発・・・8.5day
レトロスペクティブ（振り返り）・・・1day
なんというざっくり感ｗｗｗ

開発期間中に
製造・単体試験・リファクタリングを
実施しています。
ちなみに若手社員が製造を実施しているため
品質面で不安があったので、
対面レビューではありませんが、
机上でソースチェックをしました。
修正点等を「リファクタリング手引き」の名のもとに
ドキュメント化し、横並びで修正させています。

あ、さらにちなむと、
スプリント計画ミーティングの段階で
各担当者のスキルに合わせて
担当箇所を予め割り振っています。
そしてワタシは製造には参加せず、
環境構築やらRedmineを用いた管理に注力。
いかんせん「多能工」なアジャイルチームでは
ありませんで・・・

jenkinsによる継続的インテグレーション（以下CI）は
ワタシのスキルが及ばず、いったん導入は凍結。
開発期間ギリギリで各機能が出来上がってくるので、
総合試験も手作業かつ不十分。

とりあえず完成したものをリリース。
といっても商用環境ではなく開発環境へ。
エンドユーザに触って評価してもらうのではなく
POとスクラムマスター（以下SM）に
操作感やインタフェースを確認してもらいます。

ここでの評価結果をもとに
レトロスペクティブに入ります。

今日はこの辺にしておきます。
次回はレトロスペクティブでの「KPT」について
お話させていただこうと思います。

拙い文章にお付き合いいただきありがとうございました。
厳しいご指摘等あるかもしれませんが、
「ありのままの事実」を書き上げていこうと思います。

開発評価に向けて

つい先日、開発を手掛けていたシステムがカットオーバーを迎えました。
ちなみに開発手法は我が社では初のアジャイル（Scrum）。
有識者がいない状況下で、プロダクトオーナー・スクラムマスター・チームの各役割をアサインし、
「やりながら覚えていこう」的なノリで
進んでいきました。

ワタシは1年目、2年目、3年目社員とともに「チーム」の構成員。
図らずもリーダ的な立ち位置での仕事となりました。
※アジャイルチームにリーダなんていないんじゃないの？
　という突っ込みはなしでｗ
ＷＦの知識もままならない若手を率いるということで、
かなり苦労しましたが、どうにかこうにかアジャイルっぽい
開発はできたかなぁ、と。

以下、概要です。

【構築したシステム】
運用管理システム
（ＩＴＩＬでいうところの「インシデント管理」や「問題管理」
を取り扱うシステム）

【言語】
Java

【ＤＢ】
MySQL

【Ｗｅｂサーバ】
Apache

【サーバＯＳ】
Windows2008 R2

【その他開発支援ツール】
Eclipse、Subversion、Git(挫折)、Jenkins(挫折)、Redmine

【フレームワーク】
Struts2、Spring(挫折)、Hibernate(挫折)

こんなとこかな。
細かい内容についてはボチボチ書いていきます。