アジャイル開発は受託開発の方が向いている - プログラマの思索
ある人と話して気付いたこと。 アジャイル開発は受託開発の方が向いている。 組込系の製品開発やパッケージ製品開発では、マーケティングやビジネス上の要請から、既に要件が殆ど決められていることが多い。 だから、ウォーターフォール型開発で進めやすい。 受託開発では、おおまかな要件は決まっているが、あくまでも方針だけ。 顧客のためにカスタマイズしていく間に要件が絞られて、具現化していく。 ガチガチのウォーターフォール型開発で進めると、度重なる仕様変更を制御できずに、コストや納期がオーバーしやすい。 だから、小刻みにリリースしながら、顧客のフィードバックをイテレーション単位で取り込んで、システムをブラッシュアップしていく。 コストと納期は厳守しながらも、スコープ(要件)を変化させることで、顧客満足を稼ぐ。 でも、アジャイル開発だからといって、設計書は不要、とか、計画は不要、というわけではない。 要件の
Redmineの唯一の弱点～工数管理 - プログラマの思索
僕は、Redmineは現在、世界中で一番優れたBTSだと思っている。 何と言ってもプロジェクト管理機能が強力で、このおかげでチケット管理を更に活用できる。 しかし、唯一の弱点があると思う。 それは、工数管理。 Redmineチケットには、予定工数と実績工数を入力できる。 その実績工数は、レポート欄でログ検索のように検索できる。 しかし、使い勝手は正直悪い。 実績工数を単に表示するだけでは面白くないからだ。 また、Redmineの実績工数には作業分類という属性があり、デフォルトでは「デザイン作業」「開発作業」がある。 これは、Redmineでは作業トラッキング(タイムトラッキング)と呼ばれている。 つまり、実績工数を更新するたびに、実績工数を色づけできるから、後で、作業分類ごとに工数集計できる。 しかし、この作業分類を上手に使って集計する機能がない。 結局、MySQLへ直接SQLを発行して、
TestLinkをユーザ企業が使う時の注意点 - プログラマの思索
下記の記事を読んで、TestLinkは本来、ユーザ企業が発注した業務システムを、ユーザ企業自身が受入テストで使うべきだと思った。 以下メモ書き。 【元ネタ】 TestLink を使ってみた - hokorobiの日記 TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 僕は、TestLinkをテスト工程のうち、結合～システムテストで運用している。 実際は、単体テスト完了したモジュールをリリースする前に、開発部隊が自分たちで業務シナリオベースのテストケースを作り、それでもってテストしている。 つまり、リリース前の品質保持のためにTestLinkを使っている。 でも本来は、ユーザ企業自身がTestLinkを使って、発注した業務システムを受入テストで使うべきなのだ。 理由は、ユーザ企業も受入テストというテスト工程を自身が関与しなければ、システム開発は
TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念 - プログラマの思索
TestLinkのテストケースの概念についてのメモ書き。 【元ネタ】 TestLink 実戦投入 - かおるんダイアリー TestLinkの「テストケース」も「テスト計画」と同様に、「ビルド」(回帰テストの実施結果)と1対多の関係になる。 「テストケース」の状態遷移図を考えると、下記のようなフローになる。 アサイン前→未実行→成功 or 失敗 or ブロック 「アサイン前」の「テストケース」は「テスト仕様」にあるが「テスト計画」にアサインされていない状態。 つまり、イテレーション計画に組み込まれていないので、TestLinkへただ貯めている状態になる。 「未実行」の「テストケース」は「テスト計画」にアサインされて、いつでもテストを開始できる状態。 テスターは担当の「テストケース」をフィルタリングして、どんどんテストをこなしていく。 テストケースがいつも「成功」ならば良いが、やはり「失敗」す
継続的インテグレーションをクラウド化する - プログラマの思索
Hudson作成者の川口さんのBlogを読みながら、継続的インテグレーションはクラウド化と相性が良いという指摘に関するメモ。 【元ネタ】 Hudson EC2 プラグイン - 川口耕介の日記 Hudson PXE plugin - 川口耕介の日記 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 HudsonクラスタをHadoopクラスタに - 川口耕介の日記 Hudson PXE plugin - かおるんダイアリー 【既存の問題】 XPを代表とするアジャイル開発におけるコード共同所有やテスト駆動開発などのプラクティスで、いわゆる下流工程の生産性を大幅Upできる。 しかしながら、自動テストや回帰テストを行う継続的インテグレーションは、システムが大規模化するにつれてビルド時間が膨大になるので、生産性が低くなっている。 その
時代はO-Rマッピングからkey-valueストアへ: プログラマの思索
Apache CouchDBに関するメモ書き。 ＃理解が不完全なので、後で正しく書く。 【元ネタ】 Apache CouchDB: The CouchDB Project Web 時代の非リレーショナルデータベース: 第 1 回 Apache CouchDB の概要とインストール Web 時代の非リレーショナルデータベース: 第 2 回 Apache CouchDB と Ruby on Rails を使って wiki アプリケーションを作成する Web 時代の非リレーショナルデータベース: 第 3 回 Apache CouchDB で MapReduce フレームワークに基づく問いあわせを行う MOONGIFT: ? Web2.0時代のニュータイプDB「CouchDb」:オープンソースを毎日紹介 CouchDBはこのように説明されている。 CouchDB を探る CouchDB はオープン
SaaSはアジャイル開発に向いている - プログラマの思索
XPJUG代表の倉貫さんが開発されているRuby on Rails製SNS「SKIP」について、アジャイル開発の運用例と、アジャイル開発とSaaSの相性の良さが書かれた記事を見つけたのでメモ。 ＃アジャイル開発の特長を生かしやすいビジネスモデルについて、経験談も含めて非常に良く分析できている。 ＃きちんと理解して、後で内容をまとめる。 【元ネタと抜粋】 【1】[Think IT] 第1回：少人数によるアジャイル開発の事例 （1/3） アジャイル開発を適用しやすいビジネスモデルは、納品型のビジネスではなくサービス提供型のビジネスである。 SaaSはアジャイル開発を適用しやすいビジネス。 【2】[Think IT] 第2回：チームによるアジャイルの事例 （2/3） タスクについては、Redmineを活用して管理を行った。 Redmineは、Ruby on Railsで作られたオープンソースの課
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サービスの一
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
チケット駆動開発を開発プロセスへ理論化できるか？ - プログラマの思索
下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。 【元ネタ】 実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記 まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。 僕が考えるプロジェクト管理サーバーのイメージは下記の通り。 RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。 Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。 更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。 Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。 TestLinkで受入テストを効率化する。 VMWareでテスト環境、本番環境を
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
要件定義をロジカルシンキングで解析する - プログラマの思索
「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。 要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。 【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。 元々の要件が顧客の認識とずれていたら話にならない。 しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の本来の要求が何だったのか、が分からない時はすごく多い。 だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。 特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。 だが、そういうリスキー
RedmineのTicketGrouping機能 - プログラマの思索
Redmineのリビジョン 2711 についにチケットをグループ化する機能が追加された。 似たようなプラグインも開発者の有志からパッチが提供されている。 【チケット一覧にグループ機能】 Redmine - Feature #2679: Ticket grouping Redmine - リビジョン 2711 Features: * Issues/Ticket grouping * Introduced queries categories, and grouping by them in sidebar * Queries in sidebar now shows count of issues in they * Group saving in queries 【チケットをグループ化するプラグイン】 Redmine - Ticket grouping plugin 上記の機能を見ると、右
Antリファクタリングカタログ - プログラマの思索
「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本を読んで興味深くかつすぐに使えそうな箇所は「Antビルドファイルのリファクタリング」だった。 以下メモ書き。 【1】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の1章に「ビジネスソフトウェアの「ラストマイル」を解決する」という章がある。 長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。 XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。 しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。 理由は、3つある。 一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は
Mercurialメモ - プログラマの思索
分散バージョン管理は、ソース管理だけでなくテキスト管理に使うべき。 自分のノートPCにあるWordやExcel、テキストファイル、画像、音楽ファイルなど全ても、分散バージョン管理の方が楽だ。 理由は、ノートPCではオフラインで作業する時が多いから。 ネットワークに遮断された状況で自分の作業ファイルの履歴管理をしたい。 「ファイル名_yyyyMMdd.xls」「ファイル名_yyyyMMdd.ppt」「ファイル名_yyyyMMdd.jpg」というファイルを作っている時点でバージョン管理が必要なのだ。 ファイルのRedo、Undoができるだけでなく、変更履歴や差分も追跡できるのがバージョン管理の大きな利点。 その意味では、PC上で作業する人は全員、バージョン管理に慣れる必要があるだろう。 プログラマだけでなく、SEもPMも、デザイナーも、事務員も、社長も。 Subversionがこれだけ普及した
最近の技術のトレンド～分散バージョン管理と関数型言語 - プログラマの思索
「はじめてのGit」「key-value ストア」が読みたくて、WEB+DB PRESS Vol.50を初めて買った。 すごくイイ！ 【WEB+DB PRESS Vol.50の気になる章】 特集2 ブランチもマージも簡単な分散型バージョン管理システム はじめてのGit 特集3 Webアプリのパフォーマンス向上の一策 ［旬のライブラリ大集合］key-valueストア入門 Java＋RDBの技術だけで、IT業界で一生飯は食っていけると思っていた。 でも、Webの世界では、特にGoogleの技術が世界中を席巻しているといっていい。 自分の技術が時代から少しずつ遅れてきている気がしてきた。 オブジェクト指向はもう古い。 MapReduce、レコメンドエンジン、Cookie Session Storeなどのように、リストやハッシュでデータを保持して比較計算する処理技術の方が重要になりつつある。 これ
金曜にバグを発生させるコミットが多い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Javaから関数型言語へ - プログラマの思索
ジョエルのWikiはいつ読んでも面白い。 JavaよりもScheme、Haskellなどの関数型言語の習得が何故必要なのか、を説明している。 【元ネタ1】 Javaスクールの危険 - The Joel on Software Translation Project (前略) 関数プログラミングを理解していなければ、GoogleをあれほどスケーラブルにしているアルゴリズムであるMapReduceは発明できない。 MapとReduceという用語はLispと関数プログラミングから来ている。 純関数プログラムは副作用がなく容易に並列化できるということを6.001に相当するプログラミングの授業で聞いて覚えている人には、MapReduceは容易に理解できる。 GoogleがMapReduceを発明し、Microsoftが発明しなかったという事実は、Microsoftが基本的な検索機能についてキャッチア
変更管理の基盤は構成管理が支えている - プログラマの思索
SW開発には、たくさんの落とし穴や地雷がある。 地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。 アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。 仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。 顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。 以下メモ書き。 【1】顧客要求を安易に受けてしまう人の良いSE－ ＠IT自分戦略研究所 スコープのずれがコスト増にすぐにつながる。 アジャイル開発の肝はスコープ管理だ。 スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。 スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがあ
アート・オブ・プロジェクトマネジメント - プログラマの思索
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」は、色んなPM本の中でもベスト3に入ると思っている。 全て目を通したけれど、全て理解できてない。 自分が理解できた文章を中心にメモ書き。 【1】私の一番好きな単語は「How」(どのように)です 「はじめに」の冒頭にこの文章がある。 僕はこのフレーズが好きだ。 IT技術者は、システム化がお仕事であって、コンサルタントでもないし、営業でもないし、経営者でもない。 きちんとした要件定義書があったとしても、それをシステム化するには、設計もプログラミングもサーバー運用技術も必要とする。 それらは、全て「どのように実現するか？」という問題そのもの。 プログラムに落とせない仕様は、Howが突き詰め切れていないだけ。 【2】スケジュールとは確率なり 「アジャイルな見積もりと計画づくり」に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
