マイクロソフトのAgileの事例の記事を見つけたのでメモ。 【元ネタ】 マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey Visual Studio 2005では当初の予定24ヶ月を大きくオーバーして39ヶ月もかかったらしい。 そこで、Visual Studio 2008の開発プロセスを根本的に変えたとのこと。 Redmineによるチケット駆動開発の経験から類推すると、下記のように置き換えられると思う。 フィーチャー単位の開発は、ユーザストーリー単位の開発と同じ。 進捗はタスクの達成率ではなく達成したユーザーストーリーの規模で測定するのは、ストーリーポイントと似ている。 「「クオリティゲート」を通過したもの以外、アクティブなブランチに統合してはならない」とは、メインラインモデルによる構成管理。 Yellow/Red Gameは、チケットの取捨選択。 進

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

「アジャイル開発の本質とスケールアップ」で「アーキテクチャ助走路」というプラクティスがあったので考えたことをメモ。 ＃ラフなメモ書き。 【1】「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」にもあるように、アジャイラーとアーキテクトの間には緊張関係がある。 小規模リリースとアーキテクチャの作り込みは、多分組み合わせが良くない。 アジャイラーとアーキテクトの緊張関係: プログラマの思索 アジャイル開発とソフトウェアアーキテクチャの緊張関係: プログラマの思索 WF、XP、RUPではアーキテクチャの考え方が違う。 WFでは、アーキテクチャは計画される。 XPでは、アーキテクチャは出現する。 RUPでは、アーキテクチャは成長する。 XPでは、「アジャイル開発の本質とスケールアップ」によると、最初のイ

DOAの体系的方法を知るために「実践的データモデリング入門 (DB magazine selection)」を読んでいる。 IDEF1の説明から、ビジネスロジックからER図への落し込み、データモデルパターン、データモデルの物理的配置の方法まで、全ての情報を網羅しているので読みやすい。 「実践的データモデリング入門 (DB magazine selection)」を解説しているHPがあったのでメモ。 以下は、「実践的データモデリング入門」から僕が理解できた内容を抜き出している。 詳細は「実践的データモデリング入門」を参照してください。 【元ネタ】 履歴モデル サブタイプ構造の明確化 サブタイプ分割されたエンティティから関連付けるエンティティ 取引モデル 関連が隠蔽されているモデル 同一主キーでの別エンティティ化の基準 代理キーによる複合キーの抑制 【1】「実践的データモデリング入門 (DB

データパターンの組み合わせからテストケースを自動生成するツールAssistAllpairが使い易かったのでメモ。 ラフなメモ書き。 【元ネタ】 デシジョン・テーブルを活用する AssistAllpairの詳細情報 : Vector ソフトを探す！ つれづれなる技術屋日記: 「AssistAllpair」がPICT生成も対応 組み合わせテストをオールペア法でスピーディに！：第2回　PICTの基本的な使い方｜gihyo.jp … 技術評論社 テストケースの作り方: プログラマの思索 PICTで出力したテストケースをTestLinkへ取り込む: プログラマの思索 テストケースを作る場合、システムの状態遷移を元にテストケースを作る時が多い。 モデルを書けば、大抵、システムの状態遷移図も書いている。 状態遷移図は状態遷移表と同値だから、デシジョンテーブルへ落とし込める。 又、データパターンに基づいて

信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。 【元ネタ】 Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ！スーパーエンジニア どこでテストをやめるのか？ 日本電気株式会社 川村真弥さん オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用 成長曲線（ゴンペルツ曲線とロジスティック曲線） つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOist プログラムバグの成長曲線とプログラム品質の判定 テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索 信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。 つまり、テストの止め時は、信頼度成

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

アジャイラーとアーキテクトの緊張関係を示唆する記事をリンクしておく。 【元ネタ】 ＠IT：ITアーキテクト宣言！ OOエンジニアの輪！ ～ 第 27 回 榊原 彰さんの巻 ～ 「職業としてのソフトウェアアーキテクト (Software Architecture Series)」という本では、建築学をヒントにアーキテクトについて書いているらしい。 但し、絶版なので手に入れて読めないので、ネット上で調べてみた。 下記のBlogに、痛烈な批判が書かれている。 アーキテクトはユーザとエンジニアの間にいる -- INOCCU ※注意：ずっと保守モードで読めない。Googleのキャッシュで読むことは可能。 (前略) 世の中でアーキテクトという仕事について様々な説明が為されているが、2006年当時に感じた違和感と同じものを、また感じている。 その違和感というのは、アーキテクトが技術の親分であるというよう

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

Hinemos＋Redmine for ITILのセミナーが東京であるみたい。 【元ネタ】 セミナー「コスト削減できる！監視運用業務の効率化」　～コストを抑えてITILに準拠した統合運用管理を始めましょう！～ - イベント情報 - ZDNet Japan Redmine for ITILの特長｜ホロンテクノロジー[Holon Technology]--サービス＆ソリューション-- Redmine for ITIL: プログラマの思索 Hinemosと言えば、OSSの統合監視ツール。 サーバーのジョブ管理、サーバー監視機能を持つ。 IBMのTivoliみたいなもの。 Hinemos＋Redmine for ITILのイメージは、Hinemosで検知した障害(インシデント)をRedmine上で追跡できるようにし、そのワークローはITILで運用するということだろう。 Redmineはメールを送信

大前研一が、英語・IT・財務がサラリーマンの三種の神器と言っている。 特に財務について、考えたことをラフなメモ書き。 ＃初歩的な内容なので注意。 【元ネタ】 はじめての財務管理 決算診断情報：決算診断「第１４回　損益計算書のカンタンな見方(3)」 決算診断情報：決算診断「第３３回　経営分析解説―生産性（１）」 付加価値 付加価値のつかみ方（分析ポイント講座⑦）: salon tamaken N's spirit　損益分岐点とは　損益分岐点分析とは　CVP分析とは IT技術者ならば、英語とITは日頃からたぶん慣れている。 でも、財務だけは取っつきにくい。 財務とは業務知識の元ネタであり、簿記を知らなければ理解できないだろう。 普通は、簿記3級程度の知識は必須であり、簿記2級の商業簿記まで理解しなければ、実際の株式会社の業務フローは、最終的にモデリングできないだろうと思う。 簿記を習得した後、

ドメイン駆動設計に関する良い資料があったのでメモ。 InfoQにログインすれば、概要をダウンロードできる。 【元ネタ】 InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 無料で読めるDomain Driven Designの概要 上記は「Domain-Driven Design: Tackling Complexity in the Heart of Software」に関する概要資料。 「はじめに: なぜドメイン駆動設計なのか」の節でなるほど、と思った。 マーチン・ファウラー の「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」によれば、オブジェクト指向による実装は本来、テーブルモジュールでもなく、トランザクションスクリプトでもなく、ドメインモデルにある。 つまり、OOA

「ビジネスパターンによるモデル駆動設計」を立ち読みした時の感想をメモ。 ラフなメモ書き。 【元ネタ】 第3回 分析やビジネスモデリングのためのソフトウエアパターン | Think IT REAとビジネスパターン入門(1) - 要求開発アライアンスのビジネス・モデリング道場：ITpro REAとビジネスパターン入門(2) - 要求開発アライアンスのビジネス・モデリング道場：ITpro REAとビジネスパターン入門(3) - 要求開発アライアンスのビジネス・モデリング道場：ITpro REAとビジネスパターン入門(4) - 要求開発アライアンスのビジネス・モデリング道場：ITpro OOAと言えばドメイン分析。 概念モデルをクラス図で書きながら、ビジネスを分析していくスタイルが王道。 僕もいろんな本を読んできたけれど、結局使いこなせていない。 「ビジネスパターンによるモデル駆動設計」にあるパタ

「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。 ラフなメモ書き。 【元ネタ】 「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮) 「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮) 【12章 リーダーシップが信頼に基づく理由】 「表明」とはコミットメント、約束を意味する。 メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。 チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。 プロジェクトで発生する全ての作業は、チケットに起票してから開始する。 WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。 そのチケットには、開始日と終了日、

アジャイル開発が銀の弾丸ではない。 むしろアジャイル開発を実践すると、ソフトウェア開発特有の難しさがはっきり出てくるように思う。 ラフなメモ書き。 【元ネタ】 InfoQ: アジャイルプロジェクトが遅れる理由 InfoQ: アジャイルにおけるプロジェクトマネジャーの役割 Agile2.0は何を解決しようとしているのか？: プログラマの思索 第二期アジャイルムーブメント ～ アジャイル開発の商業的取り組み と Agile2.0 ないし 「２週目の世界」 について - kawaguti の日記　(id:wayaguchi) 今は「Agile2.0」「2週目のアジャイル」と呼ばれる時期に到達している。 初期のアジャイル開発で克服できなかった課題、アジャイル開発のアンチパターンなど、各種の知識も増えてきた。 Agile2.0では、Scrumのようにプロジェクトマネジメントを強化する方向もあれば、チ

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

興味深いTwitterがあったのでメモ。 【元ネタ】 Twitter / kashisan: 最近行った #Redmine を使いこなせてチームに対するアドバイス。「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」、「各トラッカーのステータスがどういう状況を表すか定義する」「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 Redmineを有効に運用出来ていないチームに対するポイントは3点ある。 １・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」 ２・「各トラッカーのステータスがどういう状況を表すか定義する」 ３・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」 ポイント1は、チケットファーストの原則。 プロジェクトにある全ての作業はチケットから始まる。 そのためには、チケットは成果物単位、つまりWB

「派生開発カンファレンス2010」の講演資料が公開されたのでメモ。 ラフなメモ書き。 【元ネタ】 「派生開発カンファレンス2010」開催案内 XDDPとUSDMでプロジェクトの課題解決 ソフトウェアの改造で悩んでいませんか？　～派生開発の品質と効率の向上を目指して～ 派生開発は、既に運用されているソフトウェア製品に対し、保守したり、機能追加したり、それを移植して別製品を作ったりするアプローチ。 日本の携帯電話が、カメラ、着うた、オサイフケータイ、Edyなど次々に機能追加していく様は、まさに保守ではなく派生開発だ。 派生開発は組込製品やパッケージ製品でよく発生し、その難しさは以前から知られていた。 特に大規模プロジェクトほど、再利用可能な部品を作る設計にしておかないと、似たような部品を作っているのに、別チームで開発してしまって、工数やコストをかけすぎてしまいがち。 更に、似たような機能やソー