続・書評『アジャイルな見積りと計画づくり』 - Be Happyman!!
先日の書評ではもの足りない気がしたので、もう少し書いちゃいます。 アジャイルのチャンスとTo-Beの前にある壁 私も厳しい状況を肌身で感じていますが、不景気は中小ソフトハウスのチャンスになりうるとも感じています。 小さい企業は間接費が小さい分もともと低コストです。そして、さらに短納期を実現する仕組みを持つことによって、今までは喰い込めなかったお客様に食い込めるチャンスが生まれます。 そのための武器にアジャイルを。って話はTo-Beの形としてはよく語られますが、アジャイル（アジャイルプロセス）それ自体はお客様の嬉しさに直接訴求しにくく、ここに大きな壁があります。ブレークスルーするためには、既存のお客様の既存のやり方や仕組みとしばらく付き合っていく必要はあります。 As-Isに横たわる大きな課題 現在の中小ソフトハウスの主戦場では、 一括契約 機能ベースの事前コミットメント 指定される開発プロ
(続)テストを書かないと品質はやっぱり下がる - Be Happyman!!
前回のエントリにはたくさんのブックマークをいただきました。やっぱり品質と、それを実現するユニットテストやTDDに関する関心は高いですね。そこでもう少しだけ補足することにします。 ユニットテストとレビューは補完的 まず、 r-westさんより頂いた質問に対する回答です。 ・xUnit有無で、単体バグは３倍の差が付いた。 → xUnitは単体バグを相当削減できる。 ・しかしxUnitを単に実施しただけでは、単体バグは受け入れテストまで相当数残ってしまった。 → xUnitも実施するだけでは単体バグの漏れは相当でる。 と言うことでしょうか。 質問に対する回答としては、「はい。xUnitを単に実施しているだけでは漏れるケースがたくさんあります。」となるでしょうか。 では、Actionレイヤを原因とする、「漏れてしまった単体バグ」15件の内の一部をお見せしましょう。（内容は公開用に多少書き直してます
テストを書かないと品質はやっぱり下がる - Be Happyman!!
私は今だにxUnitに代表される自動テストツールの効果が今ひとつ腑に落ちていなかったのですが、プロジェクトメンバーがその効果を調査・分析・見える化してくれたおかげですっきりしました。私の中だけに留めておくのはもったいないのでエッセンスを公開します。*1 対象プロジェクトに関する情報は以下の通りです。 業務系 画面数は60程度 帳票数は15程度 Java(Seasar2/S2Struts/S2Dao),Web系 クラス数は750程度 開発期間は約半年 最終的には総じて高い品質を実現した テストツールとしては、JUnit/EZmock/S2TestCaseを使っていて、それぞれ対象となるレイヤは、Actionクラス/Serviceクラス/Daoクラスです。画面のテストにはSeleniumも使いましたが、今回の調査の対象外としています。 目的 テストで重要なのは、要はそれぞれの工程で適切な粒度・
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
