ユースケース駆動開発実践ガイド - プログラマの思索
「ユースケース駆動開発実践ガイド」を読んで、この手法がまさにRUPなんだな、とようやく気づいた。 理解した内容をまとめてみる。 ＃一部はメモなので論理的整合性は無視。 【1】ドメインモデルはプロジェクトの用語集 「ユースケース駆動開発実践ガイド」では、プロジェクトで実際に使われている単語を全て収録した「生きている」辞書だ。 単なるプロジェクトの用語集よりもはるかに優れている。 それぞれの単語間の関係がグラフィカルに表現されているから。 【2】ユースケースは叙述的に書く 「ユースケース駆動開発実践ガイド」では、ユースケースに「～しなければならない」という命令形が混じる時がある。 機能要求は「～しなければならない」のように指示的に書かれた要求。 機能要求を分離してユースケースに割り当てなければならない。 ユースケースに機能要求が混在している時は、ユースケースが良くない兆候。 ユースケースは要求
Pivotal Trackerとredmineの違い - プログラマの思索
Rxtstudyで@kuranukiさんが「RedmineからPivotal Trackerへ乗り換えた」話をしてくれた。 考えたことをラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 Pivotal Tracker - Simple, Effective Agile Project Management & Team Collaboration, from Pivotal Labs Pivotal Tracker: はじめかた Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile Twitter / @minitau: ICEBOX -> BACKLOGに移動して、BACKLOGでステータスをいじる #RxTstudy Twitter / @sousoumt: @@kuranuki さんに補足：Pivotal Tracker
バーンダウンチャートのパターン集 - プログラマの思索
バーンダウンチャートを見れば、チームの進捗だけでなく、チームの成熟度やその後の予測もある程度可能だ。 良い記事があったのでメモ。 【元ネタ】 InfoQ: バーンダウンチャートを解読する 理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索 最初に、3パターンが紹介されている。 一つ目は、スプリント終了時に残作業量がゼロにならなかったケース。 例えば、スプリント後半にバグが頻発して、計画通りに作業が進まず、重大なバグを解決できずにリリースできなかった状況があるだろう。 二つ目は、スプリント前半は残作業がかなり残って遅延していたが、スプリント中盤からいきなり急角度で残作業が減っていき、最終的にゼロになったケース。 結果オーライかもしれないが、記事では次のように解説している。 「おそらく彼らは積極的に数字を更新することをしなかったことを示す
プログラマにコミュニケーションが足りないと言われる時 - プログラマの思索
IT業界で働く技術者は営業マンでないのに、コミュニケーション能力が必要とよく言われる。 特に、プログラマのプログラミング能力が優れていても、実力を発揮できないとき、君はコミュニケーション能力が足りない、とよく言われる。 その理由について考えたことをラフなメモ書き。 【1】営業マンにコミュニケーション能力が必要と言われるのは、初対面の顧客へモノを売りつける必要があるから。 いかに信頼して買ってもらえるか、人間関係の構築作りに力を入れる。 だが、IT技術者に必要とされるコミュニケーション能力は、営業マンのそれとは全く違うと経験的に思う。 自分よりも上位職の人へ働きかける政治力をすごく要求されるのだ。 特にプロジェクトリーダー、そしてプロジェクトマネージャのように上位の管理職になるほど、自分よりも上位職の力を借りて組織を動かす能力が必要とされる。 以下、どんな状況でそのようなコミュニケーション能
チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する - プログラマの思索
Redmine・Trac・Mantisによるチケット駆動開発を4年間やってきて、いつも新しい観点を発見している。 最初はRedmineプロジェクトへ組織構造をマッピングする件について考えたことをメモ。 全3回の予定。 【0】最初は小規模プロジェクトでRedmineを運用し始めて、じきに保守ブランチが必要になったり、メンバーが増えて複数チームになったり、現行ソースを他の顧客へカスタマイズして販売する派生開発になったりすると、複数プロジェクト機能を使わざるを得なくなる。 あるいは、一つの組織でいきなり全てのプロジェクトへRedmineを導入して運用しようとすると、Redmineプロジェクトの構造をどのように決めるか、考えなくてはならない。 自分が過去に運用したり、周囲を見聞きしてきて、下記の3パターンでまとめられるように思う。 それぞれについて解説してみる。 (1)派生プロジェクト (2)保守
redmine_chartsプラグインでバーンダウンチャートは表示可能 - プログラマの思索
下記プラグインをインストールしてみたら、バーンダウンチャートの表示が可能だけでなく、機能が豊富でとても素晴らしかった。 以下メモ書き。 【redmine_charts】 Redmine - PluginCharts - Redmine mszczytowski's redmine_charts at master - GitHub pullmonkey's open_flash_chart at master - GitHub ruby on railsでグラフを作成する。Open Flash Chart編←【2009/11/18 追記】 【インストール方法】 $redmine/vendor/plugins へredmine_charts、open_flash_chartのフォルダを解凍して配置する ※open_flash_chartフォルダがないと、redmine_chartsが動作しな
Redmineの集計プラグイン、statSVN諸々 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
SVNのコミットログの書き方 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する - プログラマの思索
最近は、yuguiさんや色んな人のつぶやきに触れて、励まされたり、ハッとしたりする時が多い。 「Redmineによるタスクマネジメント実践技法」を出版してから、チケット駆動開発が今後進むべき道について再考してみた。 ラフなメモ書き。 【元ネタ】 Twitter / Yugui (Yuki Sonoda): redmineがtracの劣化クローンだった時代など最早信じられないな。機能も著しく向上し、実装も改良され、更にはいろんな先進的なプロジェクト管理の試みをするひとたちが集まるコミュニティを得た。 Twitter / Yugui (Yuki Sonoda): 一読しただけでは微妙に未消化でその時が来たらもう一度読まねばならないけど、『Redmineによるタスクマネジメント実践技法』は良い本だ。Redmineという特定の製品に依存した話はそんなに多くなくて、むしろTiDDの背景解説とパターン
RedmineとHudsonやTestLinkを連携させるプラグイン - プログラマの思索
RedmineとHudsonやTestLinkを連携させるプラグインが最近色々でてきたのでメモ。 【元ネタ1】 Twitter / やのつとむ: Hudson Email Extension Pluginで、hudsonの発行するエラーメールをredmineに対応させて、エラーメールを即タスクとして登録するテク #hudsonstudy Twitter / Naoki Nishiguchi: Hudson Email Redmine Plugin でテスト失敗時にRedmine にチケット登録かー。凄い Twitter / akipii: @haru_iida なるほど。うまいやり方ですね。ソフトウェアあんどんをビルド通知メールだけでなくビルド失敗チケットにしてしまうわけですね。 プラグインのリンク先が無いので分からないが、Redmineの各機能から眺めたチケット駆動開発の課題: プログラ
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
