上司の頭の中にある、テスト方法の考え方１ 単体のホワイトボックステスト：今もこの考え、使えるかも - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０代後半、３０代前半の人の中には、上司のいう話が、「何考えてるの？」という人たちがいるのではないだろうか？ 全部コーディングが終わってからテストしろとか、すぐに修正するなとか。。。 で、「昔はよかった」といいだす。。。 たぶん、宇宙人に近い？発想に聞こえるかもしれない。しかし、実は、現場の大きな流れは、その時代の考え方で流れている。なので、その時代の考え方を理解しないと、上の人間との溝ができて永遠に埋まらないだけでなく、開発の中に矛盾を生じる（やりたくない仕事ばかりしている）。。。のだが、それについて、語る人はいない。。。ので、ウィリアムのいたずらが語ってあげよう！というこの企画。その第一回目は、テストについて。 上司の時代、今の５０台、４０台の人、COBOL文化の人は、だいた
スクラムは現実解 (arclamp.jp アークランプ)
アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
