アジャイルジャパン富山サテライト地方セッション予告：「その一方で、ウォーターフォールの現場にて開発者が出来ること」 - @katzchang.contexts
4/15（金）に予定しているアジャイルジャパン富山サテライトで、地方セッションということで一つお話をさせて頂くことになりました。 情報・参加申し込みはアジャイルジャパン2011サテライトin富山 : ATNDからどうぞ。 内容予告 タイトル 「その一方で、ウォーターフォールの現場にて開発者が出来ること」 概要 アジャイルアジャイル言ったところで来週の自分の現場がどうなるものか！！と思わないでもない昨今が続いていますが、皆様いかがお過ごしでしょうか？ それにしてもキラキラ輝いて見えるアジャイル文化/アジャイルプラクティスを参考に、目の前にそびえ立つ（もしくは切り立つ）ウォーターフォールの現場をどうにか出来るか出来ないかについて探っていきます。奮闘してきた経験を交えつつ。 スピーカー情報 katzchang いわゆる”二次請け”業務系SEとして、要求定義から運用支援まで、ユーザ対応からプログラ
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
チーム立ち上げのプラクティス「病気自慢」 - @katzchang.contexts
開発チームの立ち上げの際、互いに自己紹介しあうのは大事です。社内だとしても、同じチームで仕事しない限りはあまり交流がなかったりするのは弊社だけじゃないはず。 で、その場で名前とか開発経験とかを言い合うわけだけど、合わせて「今までの仕事で、一番ヤバかったこと」を言う。これが「病気自慢」というプラクティスなのです！（ﾊﾞｰﾝ 仕事ではまった経験はトラウマになり、その人の判断基準に強く影響する。しかも、厄介なことに、無意識に行われることも多い。トラウマを避けるということは、ディフェンシブな開発スタイルに慣れきったオレらにとって重要な位置をしめているはず。互いを理解し判断を尊重することが出来れば、悪習慣を避けるように方向を付けられる。こんな効果が期待されます。 というかまぁ、単に盛り上がるのでオススメです。 夢を語るのは営業でもできる！クソ現場を語るのは開発チームの特権だろ！ これ、30分前に命名
TDD Boot Camp 北陸 事前アンケート中間発表 - @katzchang.contexts
自由回答欄がいい感じにいい感じなので、だーっとコピペします。 引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。 アンケートは => http://bit.ly/6ToL7W イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。 あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。 TDDを既に実践している テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。 スローテスト。 テストしにくいもののテスト。JavaScript や GUI など。 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明して
Redmineサーバを止めた理由 - @katzchang.contexts
元請けから切り出された3人編成の要件定義チームなので、 意思疎通は対面で十分に出来る 課題管理の形式が元請けから指定されているので、二重管理になって混乱する。 進捗管理の形式が元請けから指定されているので、二重管理になって混乱する。 MSProjectとの連携プラグインとかあったら使ってみたい…。 要件定義中なので大小の課題が乱立するが、入力に手間がかかる その点、excelはコピペが強く効くので便利。○○予定日とか完了日とか、ダー！って入れたいもんね！！ 慣れの問題もなくはないし、こなれた設定方針を打ち出せれば…というのはあるかも。 どのレベル/種類の課題を投入すべきか、みたいな運用を決める必要があるのかな。 ということで、結局使わなくなってます。 小規模編成ほど、オーバヘッドが気になるというか。継続する保守案件とか、開発案件なら15人規模（=5人編成を3グループ）以上であれば導入すべき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
