議事録を書くときに意識すべきこと - Be Happyman!!
開発現場であってもそうでなくても議事録を書く機会は多いのですが、意外に役にたつ議事録を書くのは難しいものです。ということで、以下自著『プロジェクトを成功させる現場リーダーの技術』より議事録の書き方をまるっと引用。キーワードは「目的・課題・アクション！」です。 会議は避けられない 一口に会議といっても、あらかじめ計画されている定例的なものから、突発的に発生する小さなプロジェクト内ミーティングにいたるまで色々ですが、プロジェクトがさまざまな人との協調作業であり、プロジェクトの生み出す価値がたくさんの利害関係者の合意によって成り立つ以上、会議は必要かつ重要な活動です。実際、大規模プロジェクトでは、プロジェクトの計画段階でコミュニケーション計画として会議体が定義されます。世の中無駄な会議が多すぎると嘆かれながらも、実際問題として、プロジェクトは会議によって進んでいるというのも事実です。 現場リーダ
アウトプットする、ということ。 - Be Happyman!!
オブジェクト倶楽部のイベントに参加いただいたid:u_1rohさんの感覚は、私にも良く分かります。 今はもう、平鍋さんとは直接お会いするようになり、気さくで人間味のある「ふつうにスゴイ人」として接するようになった。これはもちろん、僕の中で平鍋さんの地位が下がったというわけでは、断じてない。なんていうか、きちんと人物に「焦点が合った」感じ。自分の視野に、自分の被写界深度に、きちんと対象を捉えられた感覚。 この感覚を得て以来、僕は以前よりも自然体でいられるようになった気がしている。 この業界にいると、意外に身近に「ふつうにスゴイ」人たちがいることに気がつかされます。ブログや紙面でしか接点がない人と、実際に話せる機会がとても多いのです。オブジェクト倶楽部のイベントも、実はそんな場になっているな、と感じます。スタッフの立場でワールドカフェで楽しそうに会話する人たちを見ると、すごく楽しい気持ちになる
JRubyでJUDE CRUD-APIを試す - Be Happyman!!
JUDE-CRUD-API JUDE5でCRUD図がサポートされ、さらにAPIも公開されました。さっそく試してみましょう。題材は、おなじみファンクションポイント測定アプリです。さらに今回はJRubyも使い、JUDE-APIとJRubyの相性も体感します。 仕様 仕様は基本的に前回と同じで、計測結果も前回と同じになるはずです。 使い方はユースケースとER図を描いて、ユースケースとエンティティそれぞれの「タグ付き値」にDET/RETなどの見積りに必要な情報を入力します。（DET/RETの詳細は前回のエントリを参照してください） 前回との仕様の違いは次の通りです。 ユースケースとER図を使う 前回は、ユースケースとクラスを使っていましたが、JUDEのCRUD図は、ER図が必要です。ということでデータのモデルはER図で表現します。（ちなみにERモデルとクラスのモデルは相互に変換できます） CRUD
(続)テストを書かないと品質はやっぱり下がる - 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ページを開く
