11/30にXPJUG関西主催の「スタートアップXP！」で「プログラミング以外にも使えるペアプロ」というタイトルの講演をしてきた。 その時の講演内容について、もう一度振り返ってみる。 【1】でも、ペアで作業する時は多い 実際の現場で、ペアプロの経験は僕はない。 でも、ペアで作業する時は実は多い。 本番リリース作業では、オペレーションを行う人と、チェックリストを見ながら監視する人のペアが多い。 同じく本番DBのメンテナンス作業も同じ。 本番システムでは、作業ミスは許されない。 他スタッフの話を聞くと、開発工程(プログラミング)だけでなく、設計やスケジュール作成でも、ペアで作業する時があると聞いた。 つまり、工程に応じて、ペアの呼び名が違うのかもしれない。 a. 設計→ペアプランニング b. 開発→ペア作業(ペアプロ) 業務系でも、Web系でも、組み込み系でも、ペアで作業しているシチュエーショ

マネージャになるほど膨大な量のメールを処理するのが主な仕事になってくる。 また、SEの仕事の殆どは、顧客やメンバーからのメールや添付されたExcelを元に、設計書をどんどんブラッシュアップしていくことだ。 倉貫さんのつぶやきを読んで、同感すると共に、果たしてそれが本当に良いことなのかラフなメモ。 【元ネタ】 Twitter / @kuranuki: メールで5人とかに送って、ひとりtypoとかで届かなかったときの残念さったらない。もう一度5人に送り直すか、その人だけに送り直すか。前者は他の人にはウザいし、後者はこれからの返信に漏れるし。もう複数人でのメールやだ。 Twitter / @kuranuki: メールでは手紙で出来ること以上のことをやっちゃいけないんだよ。 Twitter / @kuranuki: メールのccにいつまで偉い人を入れておくのか判断が難しい。遠慮なく入れた方が良いの

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

Eclipseの使い方を一覧で分かりやすく説明しているＨＰがあったので、メモ。 特にリファクタリングの手順が分かりやすい。 Eclipseリファクタリング Eclipseのリファクタリングは非常に使いやすいのに、何故か皆、使ってない。 ファウラーのリファクタリング本を読んでないのだろうか？ Javaプログラマにとって、綺麗なプログラムを書くための技術が全て詰まっている良書なのに。 【リファクタリングの目的】 最近、ソースインスペクションをする立場になってみて、仕様を理解せずに長々と書いている下品なプログラムを見ると、すぐにカチンと来てしまう(-_-;) Fatなメソッド、Fatなクラスは、不吉な匂いがする。 女性と(だけじゃなくて男性も)同じく、太ったクラスはダイエットすべき。 リファクタリングする真の目的は、誰でも理解できるプログラムにして保守性を高めることにある。 特に、プログラマは派

TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ

普通は、MS Projectをどれだけ使いこなしているか、でプロマネのスキルが分かる。 ラフなメモ書き。 【元ネタ】 MSプロジェクトは使いこなすな！ - メイクミラクル　～大逆転～ タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない MS-Projectとかイナズマ線とか | kozawa のたまに気になること Microsoft Office : これならわかる!! Microsoft Office Project 2003 【MS Projectの代替ソフト】 プロジェクト管理の選び方と使い方＆プロジェクト管理×15 at Cool Coding Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」 - GIGAZINE 開発マイルストーン OpenProjを使ってみた:

応用情報技術者試験で、インシデント管理をExcelの障害記録票と障害管理簿で2重管理していた問題が出ていた。 この手の不手際がよくありそうなのでメモ。 以下ラフなメモ書き。 【元ネタ】 平成22年度春期試験　応用情報技術者試験（AP）午後問題 平成22年度春期試験　　応用情報技術者試験（AP）午後問題解答 上記の問11にITILのサービスサポートのインシデント管理の問題がある。 問題の詳細は省略。 その事件として、まずかった点は二つある。 問合せ管理簿で、他の問合せの最新状況が反映されていなかったために、過去直近の問合せと原因は同じと判断を誤ったこと。 もう一つは、問合せ管理簿に、プログラム改修の要否や改修予定日などが書かれていなかったために、ユーザに正しい情報を即答できなかったこと。 ITの運用保守業務では、インシデント管理ではまず障害の暫定措置や早期復旧を最優先にして、根本原因の解決は

チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S

「ＯＯエンジニアの輪！　第 40 回 関 将俊 さんの巻」で、関さんが興味深い発言をしている。 (引用始まり) --- XP やアジャイルを試みてからずっと継続的にやってるんですか？ 7 年くらい。でも、多分やってる人は XP でやってると思ってないと思います。そういう話はしてないです。はじめに入った時からそれしか知らないから、他と違うことを知らない人が多いのかもしれないです。 --- エリートですね(笑) 。どのようなプラクティスを重視してますか？ うちが一番注意しているのは計画ゲームとか、ストーリーカード・・・他のやつは、普通のプログラミングテクニックですよね？ 計画ゲームが無いと XP としての意味がないというか・・・ (snip) --- XP、アジャイルとの出会いはいつくらいですか？ Kent Beck の白い本が出始めた頃ですか？ 多分 2001 年ぐらいだと思う。出る前くらい

Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回　Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ