「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしい - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
アジャイル開発をERP構築に適用するには - プログラマの思索
InfoQにアジャイル開発をERP構築に適用する記事があったのでメモ。 【元ネタ】 Twitter / @akipii: アジャイル開発の利点は小規模リリースだけでなくプロダクトオーナーを含む体制にあると最近は強く感じる RT @bengkarita: アジャイルはERP構築失敗を防げるか http://bit.ly/sm3DEz #yam InfoQ: アジャイルはERP構築失敗を防げるか 【1】ERPの特徴はいくつかある。 一つ目は、とても大規模で複雑なシステムであること。 ERPはその名の通り、1企業の基幹業務システムのパッケージ製品だ。 企業の業務で、製造や販売から会計までの全てをシステム化するから、大規模で複雑になりがち。 それゆえに、設計だけでなくプロジェクトの体制そのものも複雑化しやすい。 ERPに関しては、BPR、EA、SOAなどのバズワードがたくさん言われては消えていった
Mantisの記事 - プログラマの思索
Mantisの記事を見つけたのでメモ。 僕のBlogの記事を参考にしているそうです。 【元ネタ】 Mantisについてのメモ - watawata日記 Mantisの使い方: プログラマの思索 TracやMantisによるチケット駆動開発の運用方法: プログラマの思索 Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索 Togetter - 「Mantisメモ」 MantisはおそらくTracやRedmineよりも使っている開発チームは実際は多いと思うけれども、ネット上に情報がないのが残念。 Redmine、Trac、Mantisを使ってみて、３種類のBTS共に、下記の４つのルールによるチケット駆動開発の運用は可能だと経験している。 (1)Issue Tracking Systemとして拡張して、チケットをXPのタスクカードのように扱う (2)SVNコミット
ソフトウェアテスト技法ドリルの感想 - プログラマの思索
秋山さんが執筆された「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」を読んでみた。 テストケース作成技法がとても実践的で、しかもフリーのツールを色々説明していて役立ちそうな感触を持った。 感想をメモ。 【元ネタ1】 【感想】ソフトウェアテスト技法ドリル／秋山浩一 - Software Quality Topics. ソフトウェアテストの勉強室: ソフトウェアテスト 本棚３ 「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」は、テストケース作成技法を初心者～中級者レベルに向けて書かれていると思われる。 同値分析、境界値分析の使い方から原因結果グラフ、HAYST法、ペアワイズ法など各種の技法が説明されている。 僕が興味を惹いたのは、原因結果グラフからデシジョンテーブルを生成するツールCEGTestと、ペアワイズ法によって組み合わせを生成するツールPictMasterの説明がと
販売管理システムで学ぶモデリング講座 - プログラマの思索
渡辺幸三さん著の「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」を一通り読んだ。 内容はとても奥深い。 最初に断っておくが、前提知識としてデータモデリングだけでなく簿記3級程度の知識も知っておかないと、この本の凄さは分からないと思う。 本の内容は、卸売業の販売管理システムを渡辺さん作成のツールで作ったリファレンスモデルで解説している。 販売管理システムの業務を、仕入・受払・売上の3種類で説明している。 仕入と売上は実際の業務をイメージしやすいが、受払という在庫管理の業務はなかなかイメージしにくいが、簿記の知識があれば腑に落ちる。 在庫管理では、庫入れ・庫出しで商品の単価が変わる。 その流れは商品有高帳という補助簿で追跡できる。 在庫にある商品の単価は、先入先出法や移動平均法などで計算されるが、昨今のようにIT化されているなら、移動平均法が普通だろう。
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
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フレームワーク | エンタープライズ | マイ
ERPの落とし穴part2～業務の裏には会計あり - プログラマの思索
ERPの落とし穴part1～SW開発ではない。要求開発だ！の続き。 「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を非常に参考にしているので、全てが僕のオリジナルの考えではないので注意。 【1】業務の裏には会計あり。業務データは必ず仕訳データに連携される。 業務システムの裏には必ず会計システムがある。 Webで作っていても、メインフレームで動く会計システムと連携できなければ、ただの箱に過ぎない。 会計システムと連動できて初めて、業務コストや売上が計算出来るし、更には売掛金管理や請求管理で経理担当者の仕事もサポートできる。 例えば、「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、販売業務では、受注→出荷→売上→請求→入金のような業務フローがあるだろう。 業務データの裏には、仕訳デー
アジャイル開発と要件管理 - プログラマの思索
要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、
Excelのプロジェクト管理は何故良くないのか - プログラマの思索
XP祭り関西2010のTiDDセッションの感想を読んでメモ。 【元ネタ】 [TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば 2010-02-07 - winplusの日記 XP祭り関西2010に参加してきた - Basic XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style 【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。 (前略) それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。 この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。 倉貫さんの Excelならダ
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
何故チケット駆動開発はタスクやイテレーションの変更に強いのか？ - プログラマの思索
Redmine.JP | Redmine on Twitterを見ていて、下記の質問は、「何故、チケット駆動開発はアジャイル開発に使えるのか？」「何故、チケット駆動開発はタスクやイテレーションの変更に強いのか？」を示唆するヒントだと直感した。 考えた事をメモ。 #下記はあくまでも一つの参考意見。 【元ネタ】 Twitter / EG: Redmineとかtracとかで「ちょっと気になって ... Redmineとかtracとかで「ちょっと気になってること→対応すべきこと」というレベルアップや「○○バグの修正」と「ソースの全般的な修正」のような規模の違うものをどう扱うのがいいのだろう 上記の質問に対する回答としては、二つあると思う。 一つ目は、タスクの内容に応じてワークフロー(トラッカー)を変えて管理する。 チケット駆動開発の基本ルールは「チケットファースト」。 プロジェクト内部の作業はチケ
クラウドではソフトウェアの品質が課金の差として出てくる - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
要件管理が必要な理由 - プログラマの思索
要件管理が必要な理由についてメモ書き。 ＃後でまとめる。 要件管理の機能で最も重要と思われる成果物は、要件と機能のトレーサビリティマトリクス(TM)だ。 イメージは、下記の記事の図3 トレーサビリティマトリクス（追跡可能性マトリクス）に相当する。 ＠IT：みんなが悩む要求管理（8）要求管理ツールの賢い使い方 イメージとしては、上位要件を行、下位要件を列にしたマトリクスを作り、上位要件に紐づく下位要件がある場合、そのセルに印を付ける。 このマトリクスがトレーサビリティマトリクス(TM：追跡可能マトリクス)であり、このTMがあれば、要件に変更が生じた場合、下位要件、更にはそれに紐づくテストケースの影響範囲が一目瞭然になる。 上記の図にある「サスペクトリンク」は、そういう機能だ。 実際の開発では、要求仕様と基本仕様、基本仕様と機能仕様のように、隣り合う要件ドキュメント(フェースタイプテーブTbl
派生開発プロセスXDDPの講演メモ - プログラマの思索
SQIP2009で清水吉男さんのXDDPの講演を聞く機会があった。 アジャイル開発や並行開発、要求仕様と機能仕様の違いについて、とても勉強になったので、メモを公開しておく。 なお、メモ書きなので、分かりにくい部分は、下記の著書を読んで理解してください。 【講演メモ】 ◆派生開発の特徴と問題点 保守開発 JISで定義されている 派生開発とは似ているが異なる 例：携帯電話は、電話以外の機能が次々と追加されている 保守ではない →是正保守プロセスで改良保守を行うと問題が発生する 派生開発特有の混乱が生じている まずい作業で品質が劣化する 派生開発にはアーキテクチャ設計がなくても開発できる 仕様は設計しないと出てこない 衝突は仕様レベルで出る 派生開発は新規開発よりも複雑 追加機能と変更は異なる 機能追加は、新しい機能の仕様やレビューしかない 追加と変更の2本立てにしなければならない ソースも移植
XDDPと言う派生開発 - プログラマの思索
初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。 本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。 以下、メモ書き。 【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。 ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。 駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。 影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。 清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。 人体でも、風邪を引いた場合、抗生剤を飲む。 しかし、抗生剤は人によっては免疫機能が
レビューはペア作業であるべき - プログラマの思索
SW開発でいつもボトルネックと感じる工程がレビュー。 僕が経験した過去のどのプロジェクトも、レビュー工程は効果的と思えなかった。 少なくとも、開発者の立場では、レビューは嫌なもの。 自分の成果物にケチをつけられ、何度も直しては叩かれる。 今、管理者の立場でレビューに携わっているが、レビューが成果物の品質Upになっているとはとても言えない。 設計レビューは、設計の元ネタとなる要件定義と化している。 レビューアーにひたすら質問しまくって、本来の仕様を聞き出す。 ソースレビューは、コーディングルールの徹底と化している。 CheckStyleで十分なのに、レビューワーは業務ロジックまで分からないから、ただ直すだけ。 いつも思うのは、レビューはペアプロ、ペア作業であるべきだ。 レビューワーが、レビューイーの席の隣に座り、レビューイーのPCで成果物を見ながら、間違っている箇所はその時その場で即修正する
ソフトウェア構成管理に至るまでの道のり - プログラマの思索
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
