Loading...

「H280」プロジェクト総括

2013/08/10

「H280」プロジェクト開発は終了した。苦しいことも悲しいことも嬉しいことも楽しいこともいっぱい詰まっている。従って、初めてSCRUM方式を利用した同プロジェクトの開発流れ・実績・改善必要点を見直す為、反省会を行った。反映会で、取得したもの以外、改善必要点も端的に示していた。以下はその反省会でまとめた情報である。

H280

「H280」概要サイズが1.5人月であり、Voicebookシステムをベースとして開発されたプロジェクトである。最も高い品質を提供することを目的として、とても小さいプロジェクトでも、いつも品質のことを一番中心した。開発担当チーム(JUDO)といえば、開発し始める時点(04/27)まではSCRUM方式を実習した期間が1ヵ月半になる。短い期間なのにH280開発に着手してから、SCRUM方式の開発標準をいろいろたてられた。 指数によって評価 以前、各プロジェクト評価の時には定量指数がなかったので、プロジェクト評価のことが難しかったが、SCRUM方式でプロジェクトを開発すると、具体的な定量数量により評価できる。 まずはVelocity(スピード)指数である。「ユーザのストーリポイント合計/1スプリント」という指数である。KAMEという実習プロジェクトでは19ポイントを取得したが、本プロジェクトでは約70ポイントを取得した。個人仕事質予想ためのものではないが、リリース計画を立てることの役に立つ指数である。 次の指数はBug Rate(バグレート)である。本プロジェクトでは2つのバグ/1スプリントになる。この結果により、SCRUM方式で品質を保証できると証明された。 3つ目 の指数はCode Converag(31,5%)である。全ソースコードの中で、テストされたソースコードの行数を計算する指数になる。というのは、本指数の値が高ければ高いほど品質が保証されるということである。31,5%だけに達成する原因が下記のようになると言われている。

● TDD(テスト駆動開発)実行をメインフローだけに中心したこと。

● TDDに関する知識力がまだベーシックレベルなので、難しい関数であれば、TDDを実行できなかった。

● 関数をTDD実行したが、その関数の中で1行だけテストしていないと、その関数テスト指数が0%だと見なす。

● 開発期間が短いので、TDDのすべてケース数を考えることができなかった。

最後の指数は顧客様の満足度というものである。完了版のリリース締切が延期されていたので、お客様はあまり嬉しくないと思われている。商品渡しを延期した理由は品質が一番高いものをお客様に提出したかったのである。

プロジェクト開発実績

◆ 技術実績CI(Continuos inter-grantion)、Selenium(Auto test)、Test fistなどような新しい技術を適用していた。
◆ 開発メンバースキル改善

新しい技術を利用することと共に、開発メンバーもこれらの技術に関する新しい知識を取得できた。それはTDD実行方法、Auto test書き方、Refractoring方法等である。デベロッパーQuyenLM(クエン)さんは「TDDを実行できると、不具合が激減になるが、勉強するのがとても難しい」共有した。JUDOチームはTDDを実行する時、厳しいルールを立てた。知識だけではなく、開発者習慣変更も問題になるからである。開発習慣とは開発者がコーディングだけ担当し、テスト仕事がテスター担当する考えである。TDDを適用するためには、その考えを消さなければならない。TDD実行に対して、開発者がコーディングだけではなく、テスト仕事も一部担当する。 開発者BinhCX(ビン)さんは数千ソース行を作成したが、TDDがまだ適用しなかったので、削除しなければならなかったという経験があった。 デベロッパーの勉強ほか、テスターLinhLT1(リン)がAuto testを勉強するのも大変だった。Auto test技術は以前のテストケース作成方法と全然違っているし、Auto test技術を把握している先輩がいないので、自分でAuto test研究並行、プロジェクトにすぐ適用しなければならなかった。また、Auto testの実行が難しい各ケースは、以前の作成方法を使った。 本プロジェクト開発には困難がたくさん有ったが、あきらめないで全員が一所懸命勉強しながら、開発した。メンバースキルが向上されて、品質が高い商品をお客様に提供できた。

◆開発プロセス
HAGENDATSUプロジェクトははじめてSCRUM方式及び新しいプロセスを実験するものである。そして、プロジェクト品質を具体的な指数で初めて測ることができた。又、SCRUMのフォーマットの通りに、PO、Scrum Master、開発チームような役割を割り当てることもできた。 改善必要点 SCRUM方式で開発した経験がまだないので、下記のいくつかの欠点が発生されたと言われている。

  • 改善活動はまだうまく行っていなかったこと。
  • PO(製品の総責任者)は開発チームからの各質問をはやく回答できなかったこと。
  • スクラムフレームワークを実装している際にはスクラムマスターでも解決できない問題がたくさん有ったこと。
  • 希望結果に達成できなかった要件があること。
  • 存在無駄を徹底に排除できなかったこと。

結論 JUDOチームがScrum方式を適用するのは成功になったと言われているが、今回の失敗したことを経験として今後のプロジェクト品質をもっと向上して、順調に開発できると希望している。 JUDOチームに続いて、MANGOチームは引続きスクラム方式をプロジェクト開発に適用する予定である。MangoチームもScrum方式を利用するのが成功になるように願っている。

 Mamut

 

 

一覧に戻る