カンバンはステータス名が大事 - プログラマの思索
「カンバン仕事術」を読んで、気づいたことをメモ。 【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか？ カンバンはチケット管理と相性が良い。 なぜなら、カンバンのステータスはチケットのステータスと同じだから。 チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。 では、カンバンのステータスはどんな観点で作るべきなのだろうか？ 一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。 チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。 たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。 たいていの場合、SIの開発
Redmineの直近の課題～競合ツールGitlabに対抗できるか - プログラマの思索
2018年4月現在、Redmineの今後の課題について考えてみる。 以下はラフなメモ書き。 【1】Redmine大阪や東京Redmine勉強会にスタッフとして活動してきた中、参加者も大幅に増えて、参加者層も初心者から経験者まで広がり、業種もIT業界だけでなく特に製造業にも広がっている印象を持っている。 たぶん、RedmineはRailsアプリ、そしてチケット管理ツールの中で、日本で最も普及したアプリの一つだろう、と思う。 しかし、技術革新の流れが早い中、Redmineにも課題がチラホラ見えてきたように思う。 僕は、Redmineの直近の課題は、Redmineのシングルページアプリケーション化、Redmineのコンテナ化、Git連携の強化だろうと思う。 【2】1つ目は、RedmineのUIが古臭いと言われる問題意識だ。 たとえば、スマホに慣れていると、Redmineのように画面更新のたびにリ
rebaseのイメージ - プログラマの思索
@yusuke_kokuboさんのつぶやきでrebaseのイメージがようやく分かったのでメモ。 【元ネタ】 Twitter / @akipii: とても分かりやすい RT @yusuke_kokubo: ブランチのmergeは2つのブランチが合流するのに対して、 rebaseは一方のブランチがもう一方のブランチに(分岐元から派生した分を)吸収するようなイメージをしてる Rebaseとトピックブランチ: プログラマの思索 mergeは衝突がなければ、派生ブランチをtrunkへ取り込んでくれるが、衝突があれば、マージしてくれない。 rebaseは、trunkへ派生ブランチで育てたパッチを合流するように取り込んでくれる。 つまり、rebaseはtrunkの履歴を壊さず、その履歴の上に派生ブランチの履歴を取り込んでくれる。 「入門Git」にもrebaseについて詳しく解説されている。 trunkに
Redmine1.4.0で待望のRuby1.9サポート - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineのユーザインターフェイスは使いやすい - プログラマの思索
MantisやTestLinkなどのPHPアプリを触っていると、ユーザインターフェイスが古いなあ、と思う時がある。 Webアプリであっても、デスクトップアプリのようにマウスクリックする回数を減らすとか、オートコンプリートのような機能が欲しい。 チェックボックスをたくさんチェックしてボタンを押して初めて一括編集できるユーザインターフェイスは、やはり使いづらい。 Redmineは、Railsアプリなのでユーザインターフェイスが他のBTSに比べるとはるかに使いやすいことに改めて気づく。 僕が便利と思う機能をメモ。 【1】Redmineの気がつきにくい機能 | Redmine.JP Blog チケット一覧画面で複数のチケットを選択後、右クリックするとコンテキストメニューが表示されて一括編集できるようになる。 この機能はとても便利。 最新バージョンでは、ブラウザに関係なく動作する。 ＃古いバージョン
Redmineに入れたプラグイン一覧part2 - プログラマの思索
Redmineの最新版1.1.2にプラグインを入れてみた。 随分変わったので、インストールと注意点をメモ。 【参考】 Redmineに入れたプラグイン一覧: プログラマの思索 【Redmineのインストール】 Redmine(v1.1.2)を解凍して、DBも作っておく。 ↓ gem install rails -v=2.3.5 gem install rack -v=1.0.1 gem install i18n -v=0.4.2 ↓ rake generate_session_store rake db:migrate RAILS_ENV=production ↓ ruby script/server -e production ↓ "http://localhost:3000/"へアクセスし、login : admin、password : adminでログインする 【@daiprese
レガシープログラマかどうかを判断する基準 - プログラマの思索
レガシープログラマかどうかを判断する良い記事があったのでメモ。 【元ネタ】 2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目 【公開】XP祭り関西2011講演資料「Agile開発のスケールアップ～Agile2.0を支えるチケット駆動開発」 #xpjugkansai: プログラマの思索 (引用開始) 【レガシープログラマの判断項目】 * 使われるローカル変数をすべてメソッドの最初に宣言する。 * ローカル変数の宣言時に空文字("")や新しいオブジェクト(new Xxx())で初期化する。その後にすぐ別の値をセットする。 * メソッドの戻り値がすべて成功・失敗を表す 0 か -1 になっている。 * 複数のデータをまとめて扱う際は毎回配列を使う。配列の上限数はありえなさそうな数を指定する(1000とか)。 * 基本データ型(stringやint)と配列だけで
基幹系バッチ処理をHadoopで高速化 - プログラマの思索
基幹系バッチ処理をHadoopで高速化する記事を見つけたのでメモ。 以下ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 プレスリリース｜2011年2月9日 |ウルシステムズ、業界初、基幹バッチ用のHadoopフレームワーク「Asakusa」 を開発、オープンソース化して提供開始 | ウルシステムズ株式会社 | UL Systems, Inc. ウルシステムズ、基幹バッチ用HadoopフレームワークをOSS化 - ニュース：ITpro 基幹バッチが超高速化する？｜HATのブログ 業務システムは、日中のフロントエンドのリアルタイム処理と夜間の大量データを集計するバッチ処理の2パターンを組み合わせたアーキテクチャが多い。 フロント側はVisualBasic→CGI→Java→RailsやHTML5と次々に技術革新が起きているのに、バッチ側は昔のCobolで作った資産が残っていて、そこから
Mercurialで独立並行リリース管理 - プログラマの思索
「Mercurialで独立並行リリース管理」という良い記事があったのでメモ。 【元ネタ】 Computing Memo of 2008/02/26 パッチを作った場合、そのパッチを取り込む方法はCVS・SVN・Mercurialで違いがある。 例えば、コードラインAのリビジョン修正2にコードライン3のリビジョン修正3を取り込む場合、下記のようになる。 cvs up -j 修正2 -j 修正3 svn merge -r r修正2:r修正3 (A側) hg transplant -s (A')修正3 (前略) むっちゃ簡単! 「どのパッチを取り込む」かを指定するので指定には 「修正3」 とか一個だけでなく何個でも書け，「修正x:修正y」のようにコロンで区切って範囲指定もできる。 そして，既に適用したパッチかどうかはチェンジセットIDで確実に判別してくれるから，リバースパッチなんていうアホな自体
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
Redmineを使って気づいたことpart4～チケットの状態管理 - プログラマの思索
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
TortoiseHgもRedmineチケットへの接続をサポート - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
【告知】「Redmineによるタスクマネジメント実践技法」を出版します #TiDD - プログラマの思索
さかばさんと共著で「Redmineによるタスクマネジメント実践技法」を2010/10/13に出版します。 世界初のチケット駆動開発の本になります。 【元ネタ】 [TiDD] 速報！史上初の「チケット駆動開発」の本が出版に: ソフトウェアさかば 過去３年間、RedmineやTestLinkなど各種ツールを駆使して、チケット駆動開発という開発プロセスの上でAgile開発をいかに運用するか、をテーマにして、試行錯誤した経験と今まで思索してきた内容を全て書きました。 そのため、350ページ近くまで膨れ上がりました(笑) 最初に断っておきますが、RedmineやTestLinkのインストール方法には特に触れていません。 XPなどのAgile開発の文脈の上で、チケット駆動開発という開発プロセスを世界で初めて定義して、その応用分野や今後の課題についてひたすら書いています。 読者層は、BTSに不満がある人
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
TortoiseHgでExcelの差分を見る方法 - プログラマの思索
TortoiseHgでExcelの差分を見る方法を見つけたのでメモ。 【元ネタ】 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) WinMerge 日本語版 xdocdiff WinMerge Plugin -Word、Excel、PowerPoint、pdfの比較・差分を見る- TortoiseHgで差分表示ツールにWinMergeを指定し、xdocdiff WinMerge Pluginを入れると、Word、Excel、PowerPoint、pdfをテキスト化した後に比較・差分表示してくれる。 このおかげで、TortoiseSVNと同様に、分散バージョン管理ツールTortoiseHgでも、ExcelやWordの仕様書の差分比較ができる。 実に素晴らしい。 最近思うの
Redmineのプラグインが充実している - プログラマの思索
昨年に比べると、Redmineのプラグインがすごく充実している。 いろいろ試してみてメモ。 【コードレビュー】 r-labs - Code Review - Redmine Redmineリポジトリ画面からコードレビューのチケットを発行できる。 UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。 それぐらい素晴らしいプラグイン。 【Hudson】 r-labs - Hudson - Redmine RedmineからHudsonと連携できる。 以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。 Hudsonを使っているなら、このプラグインは必須。 このプラグインのおかげで、ビルド管理をチケット駆動開発に含
Windowsエクスプローラーが不安定になる原因の一つはTorotiseSVNか？ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: 日本のパッケージベンダーが駄目な理由
ひがさんのBlogを読んで、日本のパッケージベンダーが駄目な理由が垣間見えた気がした。 スルガ銀行のIBM提訴にみるパッケージビジネスの難しさ SIerが自動車産業をまねしようとするのはいい加減やめなさい 日本のパッケージベンダーが駄目な理由は2つある。 一つは、パッケージそのものが変化に対応しきれないこと。 もう一つは、分業化しすぎて技術力そのものが劣化していること。 金融系の勘定系システムは、大手SIベンダーのメインフレーム上のパッケージ製品が多い。 だが、それは余りにも大きすぎて、誰も仕様も技術も全部は分からない。 パラメータTblに顧客ごとの値を設定してカスタマイズすれば、すぐにできると宣伝するが、実際は、顧客の要求に合わせていくうちに、元々のパッケージと似て似つかぬシステムになる。 品質も保守性もボロボロになるのがいつものパターン。 ソフトウェアプロダクトラインの発想が
プログラマの思索: Webベースのプロジェクト管理
最近、プロジェクト管理の手法が急激に変化しつつあるのを感じる。 以前は、ExcelやMS Projectで進捗管理や要件管理をプロジェクトリーダーが取り仕切り、メンバーに節目ごとに展開していた。 そこでよく出る症状として、プロジェクト全体の進捗や各メンバーの役割がメンバーに見えにくいことがあった。 だから、「見える化」と称して、XPやPFの手法が使われた。 最近は、Trac(Python)やRedmine(Ruby on Rails)のようにWikiベースのFreeのプロジェクト管理ツールを導入するケースが多くなった。 その特徴や感想について書いてみる。 【1】TracやRedmineの特徴は下記があるように思う。 １・Wikiに、技術上のアイデア、開発環境の構築方法、リリース作業手順、日報などを書き込み、皆で情報共有する ２・カレンダーにプロジェクトのマイルストーン、各自の作業納期を書き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
redmine.tokyo10周年を祝う会でふりかえりしました #redmineT - プログラマの思索