Redmineの親子チケットの功罪 - プログラマの思索
RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。 Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。 考えたことをラフなメモ書き。 【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。 彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。 Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。 そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。 OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。 特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。 つまり、Redmineのメリット
Redmineに関する課題と展望 - プログラマの思索
RxtStudyやshinagawa.redmineで見聞したことを思い出しながらメモ書き。 間違っていたら後で直す。 【1】プライベートチケットの使い方 プライベートチケットはVer1.2から追加された新機能。 プライベートチケットに設定すると、初期設定されたロール以外の人からチケットが見えなくなる。 Redmine 1.2.0 released！: プログラマの思索 Redmineの大規模化の壁: プログラマの思索 プライベートチケットの使い道が最初は分かっていなかったが、@g_maedaさんから、Redmine本体の運用から生まれた機能であると聞いた。 例えば、redmine.orgへRedmine自体のセキュリティに関するバグチケットが登録された場合、そのチケットの情報が公開されることでRedmine本体に悪影響を与える可能性があるため、サイト管理者がプライベートチケットで隠してし
チケット駆動開発の3種の神器 #itsjp #tidd - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Hinemos＋Redmine for ITILで運用保守を改善する - プログラマの思索
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はメールを送信
TestLinkのFAQ - プログラマの思索
TestLinkを運用する時のFAQをまとめたみた。 TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。 【元ネタ】 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索 簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社 TestLinkCnvMacro 【テスト計画】 【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？ 【回答】 TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。 TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業
TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス - プログラマの思索
TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス 僕はテスト技法を体系的に知らないが、TestLinkを過去1年間実践してみて、テスト戦略やテストケースの作成方法について、ノウハウは色々溜めてきた。 TEF関西のNakaさんからテスト技法の専門用語を教えてもらい、そのノウハウに専門用語が付けられているのを知ったので、まとめてみる。 【元ネタ】 JSTQBテスト技術者資格認定-シラバス（学習事項）・用語集- ソフトウェアテスト標準用語集 日本語版Ver 1.3 【1】みなしバグとブロッキングバグ TestLinkのテストケースには「ブロック」という状態がある。 ソフトウェアテスト標準用語集 日本語版Ver 1.3 によれば、ブロックとは「事前条件を満足できないため、実行不能のテストケ－ス」を指す。 つまり、失敗したテストケース
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
システム開発に必要な役割 - プログラマの思索
プログラマやテスターの能力に関して考えたことをメモ。 【元ネタ】 小野和俊のブログ:1・10・100、それぞれの力 小野和俊のブログ:プログラマー風林火山 プログラマと呼ぶ時、すぐにイメージするのはGoogleのように独創的なプログラムを書く人をイメージする。 しかし、実際の現場では、色んな役割の人達が必要になってくる。 新規顧客の新規開発の場合、初めてのフレームワークを元に、スクラッチで作っていく。 最初に必要な人は、何も無い所から動くものをまず作る役割。 このタイプは、新しい技術の飲み込みが早く、試行錯誤するのが好き。 新しいフレームワーク、新しい言語を使う場合、独特のプログラミングの書き方がある。 その作法に慣れるまでに、普通の開発者は時間がかかる。 だから、最初は、新物好きの技術者にプロトタイプを作ってもらい、そのサンプルを真似ながら、普通の開発者は作っていく。 そして、システムに
アジャイル開発はツールに依存している～SW構成管理を再考しよう - プログラマの思索
アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。 【元ネタ1】 Kent Beck VSTSのホワイトペーパーの日本語訳 (前略) アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。 (中略) アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。 (中略) アジャイル開発は既に開発ツールに影響を与えています。 (中略) 今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。 以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用
TestLinkを運用して気付いたことpart7～要件カバレッジは難しい - プログラマの思索
TestLinkの要件カバレッジを振り返って気付いたことをメモ。 TestLinkを約1年使ってみて、そして過去のテスト実績を分析しながら、特に結合～受入テストの難しさを改めて痛感している。 TestLinkでテストの進捗管理はやりやすくなるが、やはり一番大事なのは、テストケースそのものの品質だ。 テストケースの粒度が殆ど同じで、テスターがすぐに理解できる内容にする必要がある。 そして、テストケース作成で最重要な点は、要件カバレッジ。 テストケースが要件を全てカバーしていないならば、そこからテスト漏れ、引いてはバグになる。 実際のテストでは、この要件は単体テストで保証済み、とか、この要件は最後のシステムテストで確認するから保留、などのように、テストすべき要件を間引いて、最小のテストケース数でもってテストしていく。 TestLinkでは、要件とテストケースが相互リンクしているので、要件がどの
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発はツールによる改善か、プロセスによる改善なのか - プログラマの思索
チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？ それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の
紙やExcelによる管理が残っている工程 - プログラマの思索
2007年頃のバグ管理の資料があったのでメモ。 【元ネタ】 [Think IT] 第3回：取材お断り！の裏事情 (2/3) ・現状は、半分以上が紙もしくはExcel ・今後は、Bugzilla、Visual Studio 2005 Team Foundation ServerなどのBTSを使いたい人が多い 以前、バグをExcelで管理していた時、バグ管理IDは特別なExcelシートで採番するやり方で運用されていた。 そこでユニークなバグ管理IDを採番した後、その障害管理票を紙に印刷して運用していた。 その紙には、判子の欄があった。 判子の欄には、開発者、テスト担当者、プロジェクトリーダーの3つの欄があった。 それは、他の人の作業した結果を認めたら、各人が判子を押していく運用フローになっていた。 つまり、ワークフローと言う概念が当時の開発者だった僕の頭にはなかったけれど、たとえアナログであろ
チケット駆動開発の運用例 - プログラマの思索
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
Redmineの唯一の弱点～工数管理 - プログラマの思索
僕は、Redmineは現在、世界中で一番優れたBTSだと思っている。 何と言ってもプロジェクト管理機能が強力で、このおかげでチケット管理を更に活用できる。 しかし、唯一の弱点があると思う。 それは、工数管理。 Redmineチケットには、予定工数と実績工数を入力できる。 その実績工数は、レポート欄でログ検索のように検索できる。 しかし、使い勝手は正直悪い。 実績工数を単に表示するだけでは面白くないからだ。 また、Redmineの実績工数には作業分類という属性があり、デフォルトでは「デザイン作業」「開発作業」がある。 これは、Redmineでは作業トラッキング(タイムトラッキング)と呼ばれている。 つまり、実績工数を更新するたびに、実績工数を色づけできるから、後で、作業分類ごとに工数集計できる。 しかし、この作業分類を上手に使って集計する機能がない。 結局、MySQLへ直接SQLを発行して、
TestLinkをユーザ企業が使う時の注意点 - プログラマの思索
下記の記事を読んで、TestLinkは本来、ユーザ企業が発注した業務システムを、ユーザ企業自身が受入テストで使うべきだと思った。 以下メモ書き。 【元ネタ】 TestLink を使ってみた - hokorobiの日記 TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 僕は、TestLinkをテスト工程のうち、結合～システムテストで運用している。 実際は、単体テスト完了したモジュールをリリースする前に、開発部隊が自分たちで業務シナリオベースのテストケースを作り、それでもってテストしている。 つまり、リリース前の品質保持のためにTestLinkを使っている。 でも本来は、ユーザ企業自身がTestLinkを使って、発注した業務システムを受入テストで使うべきなのだ。 理由は、ユーザ企業も受入テストというテスト工程を自身が関与しなければ、システム開発は
RedmineとTracの機能比較part2～ポータビリティ、プラグインなど - プログラマの思索
あるTracユーザの話を聞いて、RedmineとTracの機能の違いを感じたので、考えたことをメモ。 【1】ポータビリティ(環境の持ち運び)はTracが勝る TracLightningでは、SQLLite＋SVNが一つのフォルダに存在するから、バックアップが簡単。 Tracはそもそも１プロジェクトしか扱えないので、1プロジェクトのTracDB(SQLLite)を持ち運んで同期を取ればいい。 しかし、Redmineでは、DBはMySQLが普通だから、バックアップや持ち運びはOracleのような操作が必要になる。 また、複数プロジェクトを扱っているから、1個のプロジェクトだけ持ち運んでも同期がとりにくい。 特に、客先と自社で受託開発のタスク管理をする場合、USBメモリでSQLLiteのDBを持ち運びできればすごく簡単だなと思った。 RedmineでもSQLLiteを扱うことはできるが、チケット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認定スクラムプロダクトオーナー研修の感想 - プログラマの思索
事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき - プログラマの思索