「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理

チケット駆動開発における「チケット」を要求とみなした時、要求工学の品質特性の観点から考えると理解しやすいように思えた。 ラフなメモ書き。 【参考】 要求仕様 - Wikipedia 要求の旅は終わらない――開発と並走する「要求管理」 － ＠IT自分戦略研究所 要求仕様（要求工学：第3回） requirement-engineering 【1】ソフトウェアエンジニアリングの中で、要求定義の手順や要求事項を引き出す技法や概念を体系化し、整理したものが要求工学である。 ここで「要求」は「ソフトウェアやシステムを利用することで実現したいこと」、「要求仕様」（SRS：Software Requirements Specification）は「要求を実現するためのソフトウェアのインターフェイス、構造、機能」と呼ぶことにする。 要求を仕様化する時、どのように要求をまとめればよいのか？ この問題は古くから

いろんな議論が出てきた。 皆同じような問題を持っているのね、と共感している人も多かった。 僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。 顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。 トラッカー＝顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。 実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。 この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。 このアイデアは、第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理

日本のIT業界でも、日本のIT技術者も、アジャイル開発へ大きくシフトし始めているようだ。 IPAが公開したIT人材白書で気になった箇所を見つけたのでメモ。 【元ネタ】 情報処理推進機構：プレス発表：記事：「IT人材白書2013」のポイントを紹介　ITベンダーからユーザー企業へIT人材の流動が明らかに　～中途採用でユーザー企業のIT部門に配属された人のうち40.5%は直前の職場がITベンダー～ IPA 独立行政法人 情報処理推進機構：IT人材白書 IT人材白書2013　製本版・データ編は、アンケートに回答すればPDFを無料で取得できる。 6部あるうちの「IT人材白書2013～強みを活かし多様化の波に乗れ～グローバルIT人材、WEB人材に求められるスキルとは」(ITjinzai2013_Hires.pdf)の280ページ、288ページには、開発プロセス別のIT人材に対する興味深い調査内容が掲載

CCPM（Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント）の解説記事があったのでリンクをメモ。 【元ネタ】 CCPM とは：梅田弘之のプロジェクトマネジメント講座：【第６章】大型プロジェクトにはCCPMを取り入れよう サルでもわかるTOC/CCPM(第五回)｜ザ・プロジェクトマネジャーズ TOC流の開発型プロジェクト管理術「CCPM」（1）：なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（2）：PDCAサイクルに潜むプロジェクト管理の問題点 (1/3) - MONOist（モノイスト） TOC流の開発型プロジェクト管理術「CCPM」（3）：TOCのPMが本当に管理すべきポイ

ソフトウェア開発の「新」3種の神器に関する記事を見つけたのでメモ。 日経Systems2013年6月号に掲載されている。 【元ネタ】 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITpro 【1】興味深いのは、アンケート結果では、「「Microsoft Project」（MS Project）で48.7％、2位はオープンソースソフトウエア（OSS）の「Redmine」で40.4％、3位も同じくOSSの「Wiki」で32.4％だった」こと。 他に、TracやTFSも上位に上がっている。 日本でRedmineの人気は高いのが意外だった。 Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP B

「テスト駆動開発による組み込みプログラミング」を頂きました。 ありがとうございます。 既に色んな方が感想を書かれています。 【元ネタ】 「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook [書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com O'Reilly Japan - テスト駆動開発による組み込みプログラミング 書籍『テスト駆動開発による組み込みプログラミング』：柴田 芳樹 (Yoshiki Shibata)：So-netブログ "これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評 テスト駆動開発は設計技法である～組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索 C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモック

アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。 【元ネタ】 Twitter / z200: スクラムを例に取ると、リリース（および検収）と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。 【続報】ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ ソフトウェア開発の売上げ計上タイミング：むささびの視線：ITmedia オルタナティブ・ブログ 販売管理～売上の計上時期（売上計上基準） 【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。 作って納品しておしまい

InfoQにマージツールの記事があったのでメモ。 【元ネタ】 関数を理解するマージツール これは凄い。ソースコードを理解するマージツール「Semantic Merge」 | ソフトアンテナブログ 彼らの動機としては「優れたブランチは優れたマージから」という信念がある。 つまり、「タスクごとのブランチ」の考え方(トピックブランチ、フィーチャブランチなど)を強く支持しているが、結果的にブランチが乱発されてしまう弱点があり、もっと良いマージ機構が欲しかった、と。 だから、「マージ処理はコードを理解すべきである」という方針で、ツール自身がマージをサポートしてくれればいい、と。 Eclipseがリファクタリングをサポートしているように、ツールでもっと簡単にマージをサポートしたいのだろう。 彼らは、タスクごとにブランチ(Branch per Task)というブランチパターンを支持している。 つまり「イ