2012年12月15日土曜日

PHPのunit testをやってみる (基礎編1)

前回の内容

http://masatonave.blogspot.com/2012/12/macphpunit-test.html

今回の内容

目的

単体テストの書き方を覚える。

方法

PHP Unitのマニュアルの第4章を写経し、自分の理解を記録に残す。

テストの書き方


  1. テストはテストクラスを作って実行する。
    • テストクラスのクラス名は "テスト対象クラス名"+ "Test"
    • テストクラスはPHPUnit_Framework_TestCaseを継承して作る
  2. テスト項目1つに対して1つテストメソッドを実装する。
    • メソッドの名前はtestで始まる
    • テストメソッドはクラスメソッドで、アクセス制御はpublic
  3. テストメソッド
    • アサーションメソッドを使って、値の比較など検証を実施する。
      • 例 : assertEqual($val1, $val2);  → $val1と$val2が等しいことを検証
    • 1つのテストメソッド内ではテストしたいことだけ、検証する
  4. 実行順序など、テスト間に依存関係がある場合は@dependsアノテーションを付ける

実践

コード

PHP Unit 公式の例4.2
http://www.phpunit.de/manual/current/ja/writing-tests-for-phpunit.html

<?php
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testEmpty()
    {
        $stack = array();
        $this->assertEmpty($stack);
 
        return $stack;
    }
 
    /**
     * @depends testEmpty
     */
    public function testPush(array $stack)
    {
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertNotEmpty($stack);
 
        return $stack;
    }
 
    /**
     * @depends testPush
     */
    public function testPop(array $stack)
    {
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEmpty($stack);
    }
}
?>
エディタで書いて、stack_test_case.phpとして保存。

実行結果

$ phpunit stack_test_case.php 
PHPUnit 3.7.10 by Sebastian Bergmann.

...

Time: 1 second, Memory: 4.50Mb

OK (3 tests, 5 assertions)

テストコードがやっていること

この例題は、スタックのpushとpopを検証する。

testEmpty()メソッド
スタックの生成と検証の2つの役割を持っている。空の配列を作り、assertEmptyで空であることを検証し、フィクスチャとしてその配列を返す。 フィクスチャ(fixture)とは、テストしたい状況。

testPush()メソッド
ここでテストしているのは「スタックにpushできるか」ということ。依存関係としてtestEmpty()メソッドを指定しており、testEmpty()が用意した空のスタックを受け取ってarray_push()の実行結果に対して検証している。また、要素が1つ積まれたスタックというフィクスチャを用意する役目も持っている。

testPop()メソッド
「スタックからpopできるか」を検証している。依存関係としてtestPush()メソッドを指定し、要素が1つあるスタックを受け取って、array_pop()の実行結果に対して検証している。

補足: プロデューサとコンシューマ

  • プロデューサ:テスト対象(フィクスチャ)を用意するテストメソッド。 
    • testEmpty()は空のスタックを生成するプロデューサ
    • testPush()は要素に'foo'が1つ積まれたスタックを生成するプロデューサ
  • コンシューマ:プロデューサの生成したインスタンスに依存するテストメソッド
    • testPush()はtestEmpty()に依存するコンシューマ
    • testPop()はtestPush()に依存するコンシューマ

テストを書く上で大事なこと


1つの要件が変わったときに、すべてのテストメソッドを書き直すようでは、テストが開発の負担になってしまう。

テストメソッド間の独立性をできるだけ上げること。

具体的には、フィクスチャと依存関係を上手に使い、テストする対象の生成はメソッド内に書かない。

2012年12月13日木曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (後編)

読書の目的

前回のエントリに引き続き、プロジェクトマネジメントを知り、エンジニアとして参画するときにいつ何をすればよいのかを読み取る。


プロジェクト詳細設計(続き)

タイムマネジメント

WBSの最小単位はワークパッケージ。ワークパッケージをさらに細かく作業単位に落し込み、スケジュールを作成する。

アクティビティ

作業単位。 ソフトウェア開発で言えば、「プログラム作成」がワークパッケージで、プログラムを構成する「モジュール作成」がアクティビティに該当する。

アクティビティの依存関係
  1. 強制依存 : 「☓☓が終わらないと、〇〇は開始できない」
  2. 任意依存 : 「この順序で進めると無駄がなく効率的」
  3. 外部依存 : プロジェクトのアクティビティそのものではない

マイルストーン

アクティビティを実行していく過程で訪れる節目。 プロジェクトが目標を達成しているか検証し、必要であれば修正を行うタイミング。
例)「デザイン承認」「システムリリースの見極め」




→ 作業には順序と依存関係がある。 どこの作業で遅延が生じやすいか、遅延が後の工程に響く部分であるかを把握し、プロジェクト進行での時間見積もりの際に共有する。またスケジュールは変更されるので、スケジュールの書式は変更管理を前提にする。


プロジェクト運用

プロジェクトの発足

プロジェクトチーム育成の責任

マネージャはプロジェクト目標を達成するためにチームを特定し、形成し、維持し、動機付けし、リードし、奮起させる。

ソフトスキル = マネージャに要求される人間関係スキル。メンバーについて、その感情を理解し、行動を予測し、関心ごとを認識し課題を追跡することで問題を最小限にし、連携を強化できる。

プロジェクトチームの形成活動

チーム環境を作るうえで最も重要なスキルのひとつは、プロジェクトチームの問題をチームの課題として取り扱い、話し合えること。

プロジェクトマネージャが担う役割
  • トップマネジメントの指示やチームメンバーの積極的な参加を取り付けること
  • 表彰と報酬
  • チームアイデンティティの形成
  • 衝突のマネジメント
  • チームメンバー間の信頼とオープンなコミュニケーション促進

キックオフミーティング

プロジェクトの「これまで」と「現状」を共有し、リスクを検討する。
アジェンダ
  • 自己紹介 : 所属・役割を紹介
  • 制作者の提案・プロジェクトの経緯 
  • 進め方 : タスクが誰から発生し、誰へ引き継がれるか、どの段階で確認をとるか。
  • 想定されるリスク : 主たるリスクは時間不足とコミュニケーション
  • 体制の確認
  • コミュニケーションルール
  • 会議体とその参加者
  • 質疑応答
  • 次のアクションについて : とりかかること、調べて再度連絡すること

変更管理シート

「手を動かす」段階になると、考慮漏れが表面化する。
規模が小さなプロジェクトや突貫工事のようなプロジェクトでは、トラブル発生時など「いざ」というときに経緯を失念していることがあるので、品質管理はデータ化する。

参照性の高いドキュメントフォーマット

政策の前提が書かれた資料はプロジェクトにおいて頻繁に流用・転用される。
適切なファイル命名規則を定めておくことでファイルの数が増えても管理ができる。

→ エンジニアはマネージャの意図を汲み、コミュニケーションにおいてはプロジェクト目標の達成を第一に考える。口を開く前に、その情報が「チームの課題を解決できる」、「チーム間の信頼向上につながる」など、チームにとって役に立つかという判断基準でチェックし、適切に発言する。個人的な感情は抑え、チームメンバーとして求められる振る舞いを意識する。

制作ディレククションとプロジェクトマネジメント

品質 = 「本来備わっている特性がひとつにまとまって、その結果、どの程度要求事項を満たしているかの度合い」。欠陥のなさ、扱いやすいさ。 機能数などは「等級」であり、品質とイメージは似ているが、意味は同一ではない。


マネージャはプロジェクトの品質と成果物の品質を監視・管理する

→ 成果物が納期に間に合うだけでなく、そのプロジェクト自体がどう進んだかもマネージャの関心事項。 エンジニアは状態が芳しくないときこそ、遠慮無くマネージャへ報告・連絡・相談する。

計画の変更とその手順

変更 = 要件定義の段階で定めた成果物かスコープが代わること。

多くのWeb制作プロジェクトは期間が短い。 見積もりに割ける時間が短く、「やりながらわかる」ことが多い。完全にプロジェクト計画通りになるプロジェクトはない。重要なのは変更の必要が生じたとき、マネージャが誰かのスキルやリソースの「せい」にしないこと。

変更の種類
  • 成果物 (数量)
  • スコープ (仕様、メンバー、予算、期日、ToDo)
  • 変更計画および変更の手順
  • 変更管理の対象 
  • 担当者
  • 連絡体制
  • 見直しの頻度
  • 会議体

→ エンジニアはプロジェクトの変更は不可避であることを理解し、変更が必要になるときに変更内容となぜその変更が必要なのかをマネージャへ伝える。

制作フェーズにおけるヒトのマネジメント

マネージャはプロジェクト実行フェーズでは
  • プロジェクトチーム育成およびトレーニング
  • 経営企画、人事、財務おいった機能部門との調整
  • コンフリクトの解決
をおこなう。


コンフリクトのパターン
  • プロジェクトチームのメンバー同士
  • メンバーとプロジェクトマネージャ
  • 制作者と外部パートナー
  • 制作者と発注者
  • 制作者と発注者側のステークホルダー
  • 発注者と発注者側のステークホルダー

コロケーション  = チームとしての実行能力を高めるために、プロジェクト、チーム、メンバーの大部分または全員を同じ場所に集めて仕事にあたること。 面と向かって速やかに問題解決を行えることがメリット。

スキルとパフォーマンスの見極め

「スキル」と「パフォーマンス」、「モチベーション」はプロジェクトの進行によっへのどうするため、マネージャはメンバーのアサインが妥当であるか、常に確認する。 

スキルとパフォーマンスを混同しないこと。
スキル = 技量。
パフォーマンス = 性能、成績。

スケジュールにしわ寄せが着て、あるメンバーにタスクが集中した場合、そのメンバーのパフォーマンスは落ちる。


チェックイン = 近況や心境をフリートークで話す。メンバーの様子を把握するファシリテーション技術のひとつ。 

対立の芽を摘む

Webサイト制作が分業制で、全体のスコープや進捗を把握できるメンバーが限られている以上、すべてのメンバーにすべての情報が与えられているとは限らない。

マネージャはスケジュールと優先度を睨みつつ、対立の芽を先見的に摘んでいく。

→ マネージャは士気をあげようといろいろな施策を打つ。 エンジニアはその施策が何を目的としているのか、意図を理解し、妨げないようにする。


制作フェーズにおけるコミュニケーションのマネジメント

コミュニケーションモデルとノイズ

コミュニケーションの要素
  • 発信者
  • 受信者
  • メッセージ
コミュニケーションの手順
  1. エンコード :発信者は伝えたい事柄を、伝達可能なメッセージに変換する
  2. 伝達 : メッセージをメディアを介して受信者に届ける
  3. デコード : 受信者は発信者からのメッセージを、読み取り、理解する。
伝達やデコードの段階で「ノイズ」が入り、受信者の理解が妨げられる場合がある。

ノイズ
  • 発信者と受信者の距離
  • 文化や経験などバックグラウンドの違い
  • 受信者の気分

ステークホルダーの期待のマネジメント

  • プロジェクトの便益とリスクを明確に理解してもらい、適切な支援を得る
  • プロジェクトの成果物の受け入れ(承認や検収)の可能性を高める
  • 潜在的なリスク、懸案事項を早期に発見し、対処する


制作ディレクションは、ひとつひとつの判断や確認を短時間で済ませることの連続で、非常に負荷が高い。しかも、プロジェクトマネージャは、メンバーの誰もが追い込まれている状況でコンタクトを取る。

プロジェクトマネジメントにおけるコミュニケーションスキル = 主観なき情報伝達の交通整理

コミュニケーションは「無駄を省く」観点で見直す。 

→ エンジニアは「チームメンバーが理解できる表現」を心がける。 客観的に、誤解をまねかない平易な言葉で。 専門用語、カタカナ語は極力使わない。同じものに対して、2つ以上の呼称を混在させない。

制作フェーズにおける品質保証とテスト


品質管理 = 品質の基準と計画を取り決め、実施すること。

「発注者が喜ぶと思ってデザインに磨きをかけた」、「とりあえず形にした/とにかく納期に間に合わせるためやっつけた」などの対処的行動は、PMBOK本来の「品質」の基準と関係がない。納品物に求めれるのは「取り決めた品質の基準に適合しているか」。


品質管理計画と立てるとリスクを発見したり、成果物をチェックしているときにバグが見つかって納期を圧迫するなど、品質管理とリスクマネジメントは密接な関係。

Web制作におけるリスクマネジメント手法

前提条件のテスト:定性的なリスク分析。WBSやファイルリストから、「たられば」で状況を想定して、対処方法を検討する。

コンティジェンシー計画:「不測の事態」(=コンティジェンシー)が発生したさいにどのように対処するかを前もって決めておく。この計画がうまくいかなければ、さらに代案を検討する。

品質管理の観点

よいプロジェクトは 「発注者のニーズに応える」と「納品品質を満たしている」が均衡する。 発注者は人であり、満足度は感覚的・定性的。 納品物はソフトやモノであり、数値的・定量的である。

品質チェックのフロー
制作 → 内部チェック → 発注者確認 → 修正 → 発注者承認 → 確定

チェックの留意事項
  • 計画することが目的化していないか
  • チェック者が「やっつけ」「流れ作業」に陥る手段やプロセスになっていないか
  • チェック結果は後に取りこぼしを生まぬよう、整理されているか
テスト計画で決めること
  • テストの種別と目的
  • テスト手法とタスク
  • テスト要員

チェック = 中間生成物に瑕疵がないか、要件に適っているか。
テスト = 要件を満たしているか、バグなく稼働するか。
発注者レビュー = チェックやテストとは別個で発注者に依頼し、承認を得る


チェックは「他人の間違いをあげつらう」のではなく、「検収をするまでのプロセスを残す、責任をもって制作し品質管理を実施したという根拠を残す」。

→ エンジニアとしては品質の数量化・定量化を行い、品質が確認できるようにする。  
人力によるチェックを計画する際はチェック実施時の「めんどくささ」を考慮し、「やっつけ」を防ぐ。ソフトウェアモジュールなら単体テストがGREENになった件数などで定量的に品質が評価でき、自動化も可能。


読み終えて

品質に対する考え方、士気に対する考え方は改める必要性を強く感じた。
凝り性を抑えて実装する方法、コミュ障が士気を下げないようにする方法など、自分用の指針は別途考えないといけない。



2012年12月9日日曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (中編)

読書の目的

前回のエントリに引き続き、プロジェクトマネジメントを知り、エンジニアとして参画するときにいつ何をすればよいのかを読み取る。


特にプロジェクトがうまくいかなくなるのを未然に防いだり、立て直すためのコミュニケーションの方策を知りたい。

詳細見積もり

WBS (Work Breakdown Structure)

プロジェクトの作業と要素成果物を細かく定義する。
ボトムアップによる見積もりにつかう手法。

WBS作成のポイントと留意事項

ポイント
  • 必ず一度、実施項目を書き出す
  • 完璧を目指さない
  • レビューを通じて無理や破綻をつぶす
留意事項
WBS作成者は制作のワークフローや要領がわかり、各工程に慣れていることが前提。
不正確なWBSは重要なタスクを見落としたり、不必要なタスクを実行するなど失敗の元凶となる。

WBSは修正がされることを前提に、メンテナンスのしやすさとバージョン管理を考慮する。

見積もりの認識がズレがちなポイント

  • スコープ
  • 金額そのもの
  • 数量と単位の認識
  • 制限や制約

→ エンジニアとしてできることは、実現不可能な見積もりにNOを言うこと。技術的な制限や制約などを非エンジニアにわかりやすく、誤解のない表現にすること。 プロジェクト開始後に変更されそうなポイントの指摘、対策。

プロジェクト立ち上げ時の計画

PMBOKの計画プロセス群

  • プロジェクト総合マネジメント
  • プロジェクトスコープマネジメント
  • プロジェクトタイムマネジメント
  • プロジェクトコストマネジメント
  • プロジェクト品質マネジメント
  • プロジェクト人的資源マネジメント
  • プロジェクトコミュニケーションマネジメント
  • プロジェクトリスクマネジメント
  • プロジェクト調達マネジメント
マネジメント対象はリソース(ヒト、モノ、カネ)、スケジュール、アウトプット(スコープ、品質、リスク)、そしてプロジェクト自体の制御やコミュニケーション。

人的資源マネジメント

プロジェクトを推進する「人」の役割の明確化。
「ステークホルダー全員を、プロジェクト達成のために効率的に活かす」体制づくりがおろそかにされがち。

RACI (Responsible Accountable Consulted Informed) 

責任分担のマトリクス。どのタスクに対してどのような役割を果たすのかを示す。
R : Responsible 実行責任者。
A : Accountable 説明責任者。
C : Consulted 協業先
I : Informed 報告先
「誰を説得するか」「どこまでフォローするか」といったコミュニケーションの道筋がはっきりする。

リスクマネジメント

プロジェクト開始前にあらかじめありえるリスクを予想し、対処法を決めておく。

特性要因図 (fish-born chart)

リスクをリストアップして、リスクの程度と頻度、対応策を計画に落としこむ。
特性:現象や結果などのよくないこと。
要因:特性に影響する要素。 要因の抽象度(粒度)でレベル分けする。


調達マネジメント

「今回のプロジェクトでは、何を狙いとしてやるべきか?そのためには何が必要でどう取り寄せるか?」

対象はヒト(人員)・モノ(什器、ネットワーク)・カネ(予算、費用)・コト(手配、契約行為)。またプロジェクト終了後の返却や破棄・処分も計画する。


品質マネジメント

品質 = 「プロジェクトのステークホルダーが、プロジェクトに何を期待するか?」を満たすこと。

品質マネジメントの分類
  • 評価に関する作業 
    • 品質の維持するためのテスト計画、テスト実施
  • 予防に関する作業 (事前対応)
    • 欠陥を予防し、結果として欠陥対応にかかるコストを削減するための作業
  • 失敗に関する作業 (事後対応)
    • 成果に瑕疵やミスがあったときに、改修やクレーム対応を行う
→ エンジニアとしては、欠陥が発生したときの被害の大きさ、起こりやすさを把握し、計画段階で説明する。説明する範囲は責任分担マトリクスに従う。

コミュニケーション計画

プロジェクトは人が進めるもので、メンバーの作業と行為によって成し遂げられる。メンバー同士の意思疎通がうまくいかない状態や、想定の食い違いを放置していればプロジェクトは失敗する。

プロジェクト管理におけるコミュニケーション

コミュニケーションの分類
  • 情報配布 : 必要な情報をタイムリーに提供する
  • ステークホルダーへの期待のマネジメント : 関係者のニーズに応え、課題を解決し、プロジェクト破綻を防ぐ
  • 実績報告 : 実際のプロジェクト進捗とベースラインの差異を明らかにする。

プロジェクトの実行時はルールを元にコミュニケーションを図る。
ルールは堅すぎず流動的すぎず運用する(状況が変わればルールは変更する)。

コミュニケーションマネジメントに用いるドキュメント
  • プロジェクトマネジメント計画書
  • ステークホルダー登記簿
  • 課題や変更のログ : 課題管理票もしくはサービス(Excel,JIRA,Redmine,Backlog)
  • 実績報告書

コミュニケーションマネジメント計画書

記載項目例
  • ステークホルダーは誰か、どんな情報を必要としているか
  • コミュニケーションの手段、書式
  • コミュニケーション手段ごとの頻度
  • コミュニケーションの発信者、受信者、責任者
  • コミュニケーションマネジメント計画書の変更手続き
  • プロジェクトでの用語、コミュニケーション様式、書式関連の用語と説明

コミュニケーションの実践

コミュニケーションについて計画を立て、実行する目的は
  • 作業を効率化(タイムロスを減らす)
  • 混乱を起きにくくする、起きても早々に収束する
  • 各メンバーのストレスを減らし、作業に集中する
無駄を排し、意思疎通をしやすくするためにルールがある。
ルールに従う時やルールそのものを作ったり変えるときには
「プロジェクト推進の全体最適化」
「その情報伝達の先に何が控えているか」
「トラブルが発生したときに、どこを参照すればよいか」
などを考慮する。

コミュニケーションには感情が入り込むため、規格化とルール化でコミュニケーションの品質を担保する。
コミュニケーションが円滑であることは、必ずしも仲良しである、意見が一致しやすいといったこととは同じではない。

コミュニケーション計画で決めておくこと

  1. 決裁ルートと連絡体系
    • 「ものごとを取り決める」ために、誰が誰に相談し、誰が決めるか。
    • 「責任の所在」を含めた「取り決めの道筋」を事前に用意しておく。
    • 決裁ルートの「往路(打診)」と「復路(返答)」を押さえる。
      • 特に復路に不備があると、認識漏れが生じる
    • 決裁要件は「現象」、「プラン」、「どうして欲しいか」、「期限」
  2. 会議体
    • 種類、頻度、曜日と時間帯、所要時間、参加者、場所、司会、議事録
  3. 手段
    • 打ち合わせ、会議、メール、グループウェア、ファイル

コミュニケーションについての心づもり

  • 自分ができることは何か : 権限上可能なこと、状況として可能なこと
  • 主観を疑う : メンバーからのフィードバックを受ける
  • コミュニケーションツールの変更を想定する

 すべての情報を記憶し追うことは不可能。参照不可能な情報は存在しない。

→ エンジニアは、ルールに従い、感情の影響をした品質の高いコミュニケーションを心がける。 マネージャーが想定したコミュニケーションルールの問題に気づいたとき、その状況と改善方法を提案する。



まだまだあるので後編に続く




2012年12月8日土曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (前編)

読書の目的

自分の興味があることはプロジェクトにおいてどのようなタスクがあり、どのような役割分担がされているかということ。

上司やチームメンバーへの報告、連絡、相談は、どのような事柄について、どのようなタイミングで、どのような粒度で行えばよいのかを明らかにする。


プロジェクトとは

  • プロジェクト = “独自”のプロダクト を“創造”する“有期性”の業務
  • 監視コントロールによって“計画”と“実行”を繰り返す
  • 要求 (作りたいもの) と資源 (ヒト + モノ + カネ + 時間 )のトレードオフ
→ まず計画段階ではどのくらいの資源が必要になるか、見積もりを行う必要がある。エンジニアがマネージャへ情報を伝える際には精度を伝える必要がある。
実行において見積もりが外れた場合、マネージャは要求を変更するか、資源を追加するかを判断する。

PMBOKの9つの知識エリア

  • 総合マネジメント 
  • スコープマネジメント (実施すること)
  • タイムマネジメント (スケジュール、何をいつまでにやるか)
  • コストマネジメント
  • 品質マネジメント
  • コミュニケーションマネジメント
  • 人的資源マネジメント (チームの編成・育成・管理)
  • リスクマネジメント (リスクの予測と対処)
  • 調達マネジメント 
→  これらの計画と実行結果異なっていれば、報告する。
成果物がスコープと異なる、納期に間に合わない、費用がかかる、品質が不十分、障害など予期せぬ悪影響が発生する

見積の種類

見積もりは「ざっくり」から「概算」を経て、「確定」へと進化させていく。

ざっくりとした見積もり 

提案書作成段階まで に行う見積もり。  過去の蓄積と比較し、だいたいこのぐらいという相場を提示する。

概算見積 もり

受注確定前までに行う見積もり。金額はまだ確定しない。与件や提案内容をもとにタスクやリソースなどの項目を洗い出す。

確定見積もり

プロジェクト終盤 で発注者に請求する段階での見積もり。プロジェクトの途中で成果、期日、使用リソースが変動したものを加味して確定する。

→ エンジニアは「ざっくり」と「概算」の見積もりにおいて、求められる情報の粒度が異なること理解し、伝えるべき情報の取捨選択する。
特に私の場合、情報をすべて(広範囲に、詳細まで)伝えようとするので、マネージャがそれを噛み砕いて状況を整理し、判断するコストが高い。


要件定義と詳細見積もり

心構え

  • 要件定義とは、与件や要望を実現するためにまとめ、明文化すること
  • 要件を作らなくてもプロジェクトはスタートできるが、逐次決定ではスタート以降のコントロール能力とスピードが低下する
  • 詳細見積もりは「正解を出す」よりも「あいまいさをなくす」


スコープ

「何を」「どう作るか」という「範囲」。それがそろってはじめて「いくらかかるか」がわかる。


Web制作のスコープ = 「プロジェクトのスコープ」 +  「成果物のスコープ」
プロジェクトのスコープ =  「成果物を提供するための作業」
プロジェクトのスコープ定義 =「その作業範囲を限定すること」
成果物のスコープ = 「何を制作し、何を納品するか」
成果物のスコープ定義 = 「要素成果物の洗い出し」

ベースライン

発注者と制作者で握り合った「基準」。成果物スコープ、プロジェクトスコープ、コストにおいて設定する。

コストコントロール


プロジェクト実行時に予算に変更をおよぼす要因を明らかにし、必要性を決定し、変更をコントロールするプロセス。


要件定義の作業

  1. 情報収集
    • 掘り下げ不足のチェック、メモ適切に使ってヒアリング
  2. 整理・分析
    • 優先順位をつける(ROIと重要度でクロス分析)
    • 大目的、目的、目標、今回のスコープを決定
  3. 文書化

デスマーチが起こる要因

デスマーチ = 制作メンバーが対応しきれる以上の負荷がかかり続ける状態。起こる要因は主として、スケジュールと作業量の見誤り。また要件定義と詳細見積もりのミスに起因。

不確定要素が発生したときの対処フロー

不確定要素が
致命的でない → 棄却/制作者内部で共有。
致命的 → メールや打ち合わせで確定させる。

致命的かどうかの判定

  • それについて決定しないと次のタスクに進めない
  • それについて決定を誤ると制作者と発注者の双方が不利益を被る


→  エンジニアとして要件定義に参加する場合、与件や要望を最小限満たすためにどのような解決策があるか、甚大な失敗をしやすい箇所はあるのかという情報に絞って、マネージャへ伝達する。また要件定義なしで着手した場合、後の工程でどのようなリスクがあるかを理解する。

詳細見積もりの手法とレビュー方法

手法
  • トップダウン見積もり
    • スコープから規模算出し、作業量(単価、工数)と合わせて計算する
    • 開発コスト = 規模×作業量 + 予備費
    • 規模の想定が正しければ、客観的。弱点は想定外タスクや取りこぼし。
  • ボトムアップ見積もり
    • 作業項目など全タスクを洗い出し、作業費(単価×工数)算出
    • 開発コスト = 開発作業費 +  モノ + 変動費 + 予備費
    • タスクをもれなく列挙するので、粒度が高い。弱点は見積もりにかかる時間と工数設定に主観が入りがちなこと。

見積もりの精度を上げるにはレビューをする。
技術的な観点から
  • 「その実装方法は技術的な要件を満たしているか」
  • 「物理的な制約と矛盾していないか」
などをチェック。
  

長くなってしまったので、残りは別の機会に。

MacでPHPのunit testをやってみる (準備編)

動機


  • もう回帰テストを人力でやりたくありません。
  • リファクタリングのためには、テスト自動化。

自分Python使いなのになんでPHPなのよ?


人を増やすときに「Python使ったことないです。PHPならできます。」という状況で泣きをみたくないです。

環境構築

マシン

MacBookPro、OSはMountain Lion


PEARをインストール

コマンドを叩く
sudo php /usr/lib/php/install-pear-nozlib.phar
実行結果
No log handling enabled - using stderr logging
Created directory: /var/db/net-snmp
Created directory: /var/db/net-snmp/mib_indexes
[PEAR] Archive_Tar    - installed: 1.3.7
[PEAR] Console_Getopt - installed: 1.3.0
[PEAR] Structures_Graph- installed: 1.0.4
[PEAR] XML_Util       - installed: 1.2.1
[PEAR] PEAR           - installed: 1.9.4
Wrote PEAR system config file at: /private/etc/pear.conf
You may want to add: /usr/lib/php/pear to your php.ini include_path

参考 http://memorandum9.blogspot.jp/2012/11/macos-x-mountain-lionpear.html

PHP Unitをインストール

コマンドを叩く
pear config-set auto_discover 1
実行結果
config-set succeeded

もう一つ叩く
pear install pear.phpunit.de/PHPUnit
実行結果
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "pear.phpunit.de", adding to registry
unknown channel "pear.phpunit.de" in "pear.phpunit.de/PHPUnit"
invalid package name/package file "pear.phpunit.de/PHPUnit"
install failed
 エラーったので、sudoる

sudo pear install pear.phpunit.de/PHPUnit
実行結果
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "pear.phpunit.de", adding to registry
unknown channel "pear.phpunit.de" in "pear.phpunit.de/PHPUnit"
invalid package name/package file "pear.phpunit.de/PHPUnit"
install failed
watanabe-shouhito-no-MacBook-Pro:php_unit_test watanabemasato$ sudo pear install pear.phpunit.de/PHPUnit
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "phpunit", adding to registry
Attempting to discover channel "pear.symfony.com"...
downloading channel.xml ...
Starting to download channel.xml (811 bytes)
...done: 811 bytes
Auto-discovered channel "pear.symfony.com", alias "symfony2", adding to registry
Did not download optional dependencies: phpunit/PHP_Invoker, use --alldeps to download automatically
phpunit/PHPUnit can optionally use package "phpunit/PHP_Invoker" (version >= 1.1.0)
phpunit/PHP_CodeCoverage can optionally use PHP extension "xdebug" (version >= 2.0.5)
downloading PHPUnit-3.7.10.tgz ...
Starting to download PHPUnit-3.7.10.tgz (117,079 bytes)
...done: 117,079 bytes
downloading File_Iterator-1.3.3.tgz ...
Starting to download File_Iterator-1.3.3.tgz (5,152 bytes)
...done: 5,152 bytes
downloading Text_Template-1.1.4.tgz ...
Starting to download Text_Template-1.1.4.tgz (3,701 bytes)
...done: 3,701 bytes
downloading PHP_CodeCoverage-1.2.7.tgz ...
Starting to download PHP_CodeCoverage-1.2.7.tgz (157,806 bytes)
...done: 157,806 bytes
downloading PHP_Timer-1.0.4.tgz ...
Starting to download PHP_Timer-1.0.4.tgz (3,694 bytes)
...done: 3,694 bytes
downloading PHPUnit_MockObject-1.2.2.tgz ...
Starting to download PHPUnit_MockObject-1.2.2.tgz (20,347 bytes)
...done: 20,347 bytes
downloading Yaml-2.1.4.tgz ...
Starting to download Yaml-2.1.4.tgz (38,574 bytes)
...done: 38,574 bytes
downloading PHP_TokenStream-1.1.5.tgz ...
Starting to download PHP_TokenStream-1.1.5.tgz (9,859 bytes)
...done: 9,859 bytes
install ok: channel://pear.phpunit.de/File_Iterator-1.3.3
install ok: channel://pear.phpunit.de/Text_Template-1.1.4
install ok: channel://pear.phpunit.de/PHP_Timer-1.0.4
install ok: channel://pear.symfony.com/Yaml-2.1.4
install ok: channel://pear.phpunit.de/PHP_TokenStream-1.1.5
install ok: channel://pear.phpunit.de/PHP_CodeCoverage-1.2.7
install ok: channel://pear.phpunit.de/PHPUnit_MockObject-1.2.2
install ok: channel://pear.phpunit.de/PHPUnit-3.7.10
うまくいっているらしい。コマンド叩いて確認
phpunit --version
実行結果
 PHPUnit 3.7.10 by Sebastian Bergmann.


最初のテスト

テストコードを書く
vim sample_test_case.php
動くかどうかを知りたいので、中身は公式からコピペ
<?php
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testPushAndPop()
    {
        $stack = array();
        $this->assertEquals(0, count($stack));
 
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertEquals(1, count($stack));
 
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEquals(0, count($stack));
    }
}
?> 
参考 http://www.phpunit.de/manual/current/ja/writing-tests-for-phpunit.html

実行する
phpunit sample_test_case.php
結果
PHPUnit 3.7.10 by Sebastian Bergmann.

.

Time: 0 seconds, Memory: 4.50Mb

OK (1 test, 5 assertions)
大丈夫らしい。










2012年12月1日土曜日

これから勉強したいこと

背景と動機

一言でいえば、自分の力不足でチームに迷惑がかかることを実感したから。

ソフトウェアは学生時代からつくっていたが、自分の好きなやり方で開発してきた。
作るソフトウェアの規模も一人で十分に把握できる範囲であり、また開発速度が優先され、他の人が保守することが考えられていなかった。

チームでの開発では他の人と仕様を共有したり、さらにはエンジニア以外の人に仕様を技術用語なしに平易な言葉で説明する必要がある。だからチーム開発を円滑にするためのスキルを強化する。

何を身につけたいか

  • 開発マネジメント
    • なにをやるか・やらないか
    • やるべきことをどんな順番でやるか
    • 状況の変化に対してどのように対処するか
  • コミュニケーション
    • 必要なときに必要な情報を必要な量だけ共有する判断力
    • 説明する言葉の選び方と話し方
    • ドキュメント作成

どうやって学ぶか

既存のうまいやりかたに倣うのがいちばん手っ取り早い。 それを試してみて、自分に合わなければ自分なりにアレンジをすればよい。

会社の先輩に聞く

幸運なことにMobile Web開発については百戦錬磨の先輩方がたくさんいる環境にいる。まずは自分がどのような状態にいるのか、何をすべきなのかを相談する。

本を読む・社外の勉強会に参加する

受託が中心の会社であるので自社サービス開発の進め方については、自分で勉強しておく必要がありそう。

今のところ読む予定なのは
  • 失敗しないWeb制作 プロジェクト監理のタテマエと実践
  • Webプロジェクトマネジメント標準 PMBOK(R)でワンランク上のWebディレクションを目指す
  • アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法

開発全体でどのような工程があり、どのような意思決定がされ、どのような分担をすればよいのか、基本知識を仕入れたい。

学んだこと、実践したことを見える形で残す

これまでは溜め込んだ知識は自分の中にしかなかった。脳には限界があり、しばらく経つと忘れてしまう。同じことを学びなおすことになるのは避けたい。
自分のためにも、そして自分が学んだことを他の人にも役立てるためにもblogに残していく。