チケット駆動開発を上手に運用するためのポイント - プログラマの思索
倉貫さんがチケット駆動開発を上手に運用するためのポイントを公開されていたのでメモ。 実際の経験に裏打ちされているだけあって、とても参考になる。 【元ネタ】 チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change! 高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change! 【1】役割分担 (引用開始) Pivotal Trackerを使う役割はざっくり分けると２つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。 (引用終了) 倉貫さんの指摘では、顧客がプロダクトーナーの役割を持つので、経営戦略から仕様を決定できるストラテジスト、
コミットの粒度 - プログラマの思索
コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。 【元ネタ】 git commit するまえに考えるべき10のこと | Act as Professional - hiroki.jp by HIROCASTER 「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組 GitやMercurialがCVSやSVNよりも優れている点は、ブランチ管理の容易さと豊富なマージコマンド。 特に、ローカルにブランチを作り、プライベートなブランチとして開発者は好き放題にコミットすればいい。 そして、masterに最終的にコミットする時、必要なパッチのみまとめて送ればいい。 コミット履歴を改変する必要があるのは、masterのコミット履歴を綺麗にする場合だろう。 ローカルのブランチは自分だけが好きなようにコミットしてもいいが、masterのコミット
Redmine CSV Import Pluginの使い方 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
データベース設計で派生関係は難しい - プログラマの思索
@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向
TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。 【参考】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。 それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。 例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。 大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
韓国SIがIT技術を日本に逆輸出 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineの最新動向 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ドキュメントも構成管理すべきだ - プログラマの思索
SVNで構成管理する時の良い記事が公開されたのでメモ。 【元ネタ】 Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 SVNの使い方の記事はネット上にいくらでもある。 しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。 CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。 この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。 つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。 構成管理が変更管理と密接に関係する理由は、上記のような
1回のリリースは100回のレビューに勝る - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プロジェクト管理サーバーとは - プログラマの思索
僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。 【プロジェクト管理サーバーのイメージ】 そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。 基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。 タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。 RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。 つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。 バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。 バージョン管
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
チケット駆動開発を開発プロセスへ理論化できるか？ - プログラマの思索
下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。 【元ネタ】 実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記 まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。 僕が考えるプロジェクト管理サーバーのイメージは下記の通り。 RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。 Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。 更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。 Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。 TestLinkで受入テストを効率化する。 VMWareでテスト環境、本番環境を
All In One Redmineを見つけた - プログラマの思索
WAMP(LAMP)環境でRedmineをワンクリックインストールできるツールを見つけた。 下記のインストーラーを使えば、Redmineの最新バージョン0.8.3をわずか5分でインストールできる。 【元ネタ】 BitNami :: Redmine 上記ツールの環境は下記の通り。 これだけあれば十分だろう。 Redmine 0.8.3 Apache 2.2.11 ImageMagick 6.4.7 MySQL 5.1.30 Subversion 1.4.6 Ruby 1.8.6 Rails 2.1.1 RubyGems 1.2.0 【追記】 インストール手順は、かおるんさんのBlogを参照。 画像付きなので非常に分かりやすい。 BitNami::Redmine をインストールしてみた - かおるんダイアリー Windowsの場合、ApacheやSVNなどのプロセスはWindowsサービスの一
マネージャ層の技術が遅れている - プログラマの思索
下記のBlogを読んで、最近の技術のトレンドにプログラマよりもマネージャ層が遅れているような気がしてきた。 【元ネタ1】 脱Excelのための… - Talking Nonstop 『ずっと受けたかったソフトウェアエンジニアリングの新人研修』続き - 思っているよりもずっとずっと人生は短い。 「ずっと受けたかったソフトウェアエンジニアリングの新人研修」を実際に本屋で立ち読みしてみて、すぐに飽きた。 この本の内容を覚えたとしても、実際の業務では正直役に立たないだろう。 少なくともプログラミングには役立たない。 業務システムの開発でも、定型化されたプロジェクトならまだしも、昨今のように短納期・大規模なプロジェクトでは、業務モデリングすら間に合わないだろう。 今までのSW開発の技術の進歩から外れている。 上記のBlogにあるように、大手SIerが下請けに下流工程を投げるための技術の一つに過ぎない
システム開発から属人性を排除しようとして失敗する - プログラマの思索
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
業界から見たIT技術の変遷 - プログラマの思索
IT技術の変遷について考えてみると、業界の変遷と照合すると分かりやすくなる。 最新のIT技術が必要とされる業界が、流れとして、鉱工業や金融から、小売などの商業やマーケティング系へ移りつつある。 昔は、工場や銀行のようなミッションクリティカルな業務システムに、メインフレーム＋Cobolで構築していた。 昨今は、メインフレーム＋Cobolを、Java/.NET＋オープン系システムへリプレースする案件が非常に多い。 それらの案件は大抵、大規模案件で、いつもデスマーチになる。 技術者としても、部品ばかり作って、システムの全体像が見えず、楽しくない。 昨今の小売などのネット注文Webシステム、SNSなどは、Java/PHP/Perl/Ruby＋Unixで構築することが多い。 例えば、Amazon、楽天、mixiなど。 それらの案件は中小規模だが、いつも最新のWeb技術を試すし、技術革新のスピードが猛
ITの地殻変動はどこで起きているのか？～SeasarとRuby、そしてPF - プログラマの思索
2008年になってみて、ITの地殻変動がどこに起こっているのか？を考えてみる。 ※以下は殴り書き。後でロジカルにまとめる。 【1】XPからPF(プロジェクトファシリテーション)へ ウォーターフォール型開発はメインフレーム＋Cobolの時代の開発プロセス。今となっては古い。 RUPは、業務向けオブジェクト指向開発を基盤とした開発プロセス。 馬鹿でかい。皆こなしきれない。 ウォータフォール型開発に、各フェーズでインクリメンタル型を取り入れただけ。 XPは、Webシステムを基盤とした開発プロセス。 XPは、ここ10年の経験に裏打ちされた開発プロセスの革命。 ソフトウェア工学にも新しい知見を生み出した。 XPでは、プログラマは、コーディングするパンチャーではなく、システムの品質に対する最終責任者。 ドキュメントよりも動くプログラム重視。 プロトタイプ重視。 ソース共有、コーディング規約、常時ビルド
プログラマの思索: 日本のパッケージベンダーが駄目な理由
ひがさんのBlogを読んで、日本のパッケージベンダーが駄目な理由が垣間見えた気がした。 スルガ銀行のIBM提訴にみるパッケージビジネスの難しさ SIerが自動車産業をまねしようとするのはいい加減やめなさい 日本のパッケージベンダーが駄目な理由は2つある。 一つは、パッケージそのものが変化に対応しきれないこと。 もう一つは、分業化しすぎて技術力そのものが劣化していること。 金融系の勘定系システムは、大手SIベンダーのメインフレーム上のパッケージ製品が多い。 だが、それは余りにも大きすぎて、誰も仕様も技術も全部は分からない。 パラメータTblに顧客ごとの値を設定してカスタマイズすれば、すぐにできると宣伝するが、実際は、顧客の要求に合わせていくうちに、元々のパッケージと似て似つかぬシステムになる。 品質も保守性もボロボロになるのがいつものパターン。 ソフトウェアプロダクトラインの発想が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
