複雑なUMLの代わりにC4モデルが提案されている - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい - プログラマの思索
倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。 新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。 以下はラフなメモ書き。 【研修資料】 【参考】 アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索 アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change! ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change! アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change! ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは
WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる - プログラマの思索
WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。 【参考】 ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から 【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか？それとも機能単位に作った方がいいですか？」だ。 話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。 WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか？ (引用開始) さて、３つの機能モジュール×３段階の作業プロセスだから、合計９個のアクティビティからなるプロジェクトである。 これをＷＢＳに構成するとき、二種類の表現が考えられる（ＩＴ系の仕事になじみのない人は、「シス
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
第18回Redmine大阪の見所～「チケット管理システムによるソフトウェア開発支援と今後の課題～気象庁のRedmine利用事例報告」 - プログラマの思索
第18回Redmine大阪の見所～「チケット管理システムによるソフトウェア開発支援と今後の課題～気象庁のRedmine利用事例報告」 来年2月3日に開催予定の第66回 SEA関西プロセス分科会＆第18回 Redmine大阪の見所を書いておく。 【参考】 第66回 SEA関西プロセス分科会＆第18回 Redmine大阪 - connpass 気象庁の数値予報課におけるRedmine利用事例: プログラマの思索 【1】（引用開始） テーマ～「チケット管理システムによるソフトウェア開発支援と今後の課題」 今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。 気象庁｜数値予報課報告・別冊 第63号（平成28年度） 数値予報モデル開発のための基盤整備および開発管理 気象庁におけるソフトウェア開発プロセスの事例で興味深
Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしい - プログラマの思索
Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしいのでメモ。 WF型開発に固執した古い体質の現場で、Redmineをいかに使いやすくするか、という観点で読むと、とても参考になる。 【参考】 Redmineを受け入れて貰うためのプラグイン紹介 - Qiita 親チケットの詳細ページに表示される子チケットの一覧項目 - Google グループ 【1】(引用開始) Redmineは小規模なチームでも比較的簡単に導入できる、素晴らしいソフトウェアだと思います。 ただ、このようなツールを知らない人や絶対Excelマン達にとっては、得体の知れない面倒なモノと思われてしまうこともあります。 そういった人たちにも積極的に利用して貰うためには、日々の業務で感じるイライラを極力減らす努力が必要ではないでしょうか。 この記事では、Redmineを少しでも快適に使って貰うため、開発者にとって有用
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーの感想 #RDRAセミナー - プログラマの思索
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーに行ってきた。 要件定義の考え方がすごく参考になった。 感想をラフなメモ書き。 【元ネタ】 さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper 要件構造の見える化 #RDRAセミナー: ソフトウェアさかば リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索 【1】要件定義の問題。 いつまで経っても、システムの全体像が見えない。 大量のドキュメントばかりで、肝心のシステムが説明されない。 分析と言う名の転記作業ばかりで、要件定義が完了しない。 では、どうすればいい？ 要件定義、要件分析では、個人作業は非効率。 レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。 その場で皆で合意を積み上げて進める方がいい。 ステー
Redmine3.0.3をWindows7にインストール時はJRubyを使うと上手くいく - プログラマの思索
Redmine3.0をWindows7にインストールする手順をメモ。 【参考】 RedmineをWindowsにインストールする手順: 9th Ghost Windows の Ruby で native extension を使う - akishin999の日記 Azure Web Apps 上で JRuby を使って Redmine 3.0.3 を動かす - しばやん雑記 Redmine2.5をwar化してTomcatで動かしてみた~warbler | Scimpr Blog Redmine 3.0.0をJRubyで動かす→ダメだった… | u6k.log() akipiiさんはTwitterを使っています: "Windows のインストールはBitnami 以外はあきらめた方が良いです。RT @mzsm_j: Redmineのインストール方法を調べるたびに「面倒くさいしもういいや…」っ
ソースコードからモデルの絵を自動生成する - プログラマの思索
ソースコードからモデルの絵を自動生成するツール(Graphviz、PlantUML)についてメモ。 アイデアをラフなメモ書き。 【元ネタ】 Graphvizの簡単なサンプル Graphvizメモ(Hishidama's Graphviz Memo) AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo) PlantUML の使い方 | プログラマーズ雑記帳 PlantUML 【1】クラス図、あるいは単なるネットワーク図を手書きではなく、ツール上のGUIでもなく、ソースで書きたい時がある。 ちょうど僕は、「アイデアを組織に広めるための48のパターン」の本を読んでいて、その内容にすごく惹かれて、それらパターンの一覧であるナビゲーションマップが欲しくなった。 ナビゲーションマップがあれば、パターンの間でどのような関連があり、
なぜ超高速開発が話題になるのか～キーワードはビジネスルール管理システム(BRMS) - プログラマの思索
最近なぜ超高速開発が話題になるのか、何となく分かった気がした。 ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 超高速開発先進国、知られざる韓国企業の実態 - サムスン電子に見る「威力」：ITpro NC特集 - 「超高速開発」が日本を救う：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第3回 ビジネスの俊敏性を実現する：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第4回 スマートなシステムを生み出す：ITpro ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経 ビジネスルールとビジネスプロセス（その1） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その2） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その3） | 株式会社ＫＢマネジメント ビジネスルールと
Jenkinsビルド後の処理でRedmineにチケット登録ができるJenkinsプラグインredmine-posttask-plugin - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmine for ITILが解決するもの - プログラマの思索
ホロンテクノロジーという会社がRedmine for ITILというソリューションツールをPDFで公開していた。 とても参考になる資料だったので、システム運用保守におけるRedmineの解決方法について、考えたことをメモ書き。 ホロンテクノロジーが提供するOSSソリューションのご紹介 (PDF) Redmine for ITILの特長｜株式会社ホロンテクノロジー Redmine for IMSの特長｜株式会社ホロンテクノロジー Hinemos＋Redmine for ITILで運用保守を改善する: プログラマの思索 Redmine for ITIL: プログラマの思索 TiDDにITILの概念を持ち込む: プログラマの思索 チケット駆動開発の課題～ITILやDevOpsの適用方法: プログラマの思索 【1】システム運用保守の問題点 システムの新規開発案件ではなく、システムの運用保守では特有
RedmineはPC・サーバ資産管理に適用できるか？ - プログラマの思索
Redmineのチケット管理をPC・サーバ資産管理に適用するためのアイデアをメモ書き。 【事例１】 Twitter / akipii: 運用ルールが聞きたい RT @jun090309: PCのリース期限切れが近いものがあるので、誰が使ってるのか調べてください、みたいなメール来てた。新人にやらせてよ、というのもなんなので、前からやりたかったRedmineでの資源管理を個人的に導入。 Twitter / jun090309:@akipii 1/2: PC到着（リース会社の資産番号=A）→自社資産管理用番号を採番（=p）、Excelに記入。このExcelブックは、資産管理者しか持ってない、かつ、更新できない。 基本的にリース資産と人は1:1。席移動の際も、人と一緒に資産の場所も移動。 Twitter / jun090309:@akipii 2/2: 外注さんがいなくなると使用者不在となる。この
Redmineの初心者向け資料 - プログラマの思索
(引用開始) はじめてRedmineに触れる方向けに、Redmineとは何か、Redmineを使うと何が便利になるのかを紹介するスライドです。 (引用終了) ソフトウェア開発者以外の人にRedmineを使ってもらおうとする場合、IT技術者の立場を押し通すと多分使ってくれないだろう。 普通の人がイメージするタスク管理は、RememberTheMilkやGmail ToDoのイメージであり、Redmineは入力項目が多すぎるし、たくさんの機能があって理解しにくいようだ。 Redmineによるチケット駆動開発が障害管理ツールから発展した歴史を考えると、チケットは本来は障害報告票ゆえに、どうしても入力項目は多くなる。 でも、きちんとチケットに作業内容を記録してもらえれば、強力かつ多種多様なチケット集計機能によって、色んな観点でタスクの進捗状況を分析することができる。 特に、アジャイル開発で出てくる
Redmine1.4.0で待望のRuby1.9サポート - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmine のsubtaskingを使った画面part2 - プログラマの思索
Redmine本家にsubtaskingの説明があった。 更に、Redmine本家のデモサイトで、subtaskingを使ってチケットを利用できる！ 気付いた事をメモ。 【元ネタ1】 Redmine - What's new in trunk: Subtasking - Redmine Test CMS - Feature #16630: Create Pages Contoller - Redmine Demo subtasking を使うには「Manage subtasks」のユーザ権限が必要らしい。 そして、子チケットの優先度、開始・終了日、進捗率、予定工数、実績工数を自動的にロールアップして親チケットへ反映してくれる。 つまり、子チケットの属性のUnionを自動計算した値を親チケットへ反映する。 この機能によって、ストーリーカードとタスクカードの関係を容易に表現できるようになる。
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
プログラマの思索
Redmineのチケットとは一体何だろうか？ Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。 Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索 Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索 その他にも、Redmineでは、課題チケットという一つのインシデントという情報（データ）として意味を持たせていたのに、課題を解決する対策の作業手順（プロセス）もチケットとして登録される、というケースがよくある。 つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった - プログラマの思索