ガントチャートの光と影 - プログラマの思索
プロジェクト管理といえば、ガントチャート。 ガントチャートの良い部分と悪い部分についてメモ。 【参考】 下記の連載記事は、初心者向けのガントチャートの記事で読みやすい。 初めてのガントチャート（1）：ガントチャートって何ですか？ - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (1/2) - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (2/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (1/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (2/2) - ＠IT 【1】ガントチャートは、作業が予測
WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
WordやExcelから直接SVNにコミットできるアドオンmsofficesvn - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
スクラムを大規模組織へ導入した事例 - プログラマの思索
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - delirious thoughts (引用開始) 組織の課題としては、増え続けるサービスの品質を担保したい、そして中央集権的な管理から自律的なチームにすることで改善スピードをどんどん上げていきたい、ということがありました。 そこで出てきたのが、「スクラム」という言葉です。 この頃には役員陣も興味を持ち始めてくれるようになり、ブログで「ハッカーと画家」とか「アジャイルサムライ」といった本を読んだことを書いたりしていて、アジャイル開発を議論できる空気になってきました。 (引用終了) 社長のような経営トップがアジャイル開発に興味を持ってくれるとすごく導入しやすい。 アジャイル開発とは何か、アジャイル開発を入れるとどんな利点があるか、を逐一説明する手間を省ける。 アジャイル開発を自社に入れる場合
長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい～プルリクエストはJiraにあってRedmineにない機能 - プログラマの思索
長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい～プルリクエストはJiraにあってRedmineにない機能 長沢さんのモダンなチーム開発環境のフリー利用可能な資料が素晴らしいと思った。 長沢さんのJira資料を読むと、RedmineよりもJiraの方がチケット管理の環境が一歩進んでいる印象を持った。 その理由を書いてみる。 【元ネタ】 モダンなチーム開発環境のフリー利用可能な資料を公開 Atlassian製品による「No Ticket, No fork!」: プログラマの思索 GreenHopper を使用した Bamboo と Bitbucket の自動化 | Atlassian Japan Stash 3.3: タスク機能を利用してプルリクエストの進捗状況を追跡 | Atlassian Japan RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRe
Jenkinsをバッチ監視ツールとして運用する事例 - プログラマの思索
@akiko_pusuさんが公開されたJenkinsによる運用事例の資料が素晴らしいのでリンクしておく。 Jenkinsはたった一つのツールに過ぎないが、たくさんの可能性を秘めていると思う。 【皆のつぶやき】 Twitter / 検索 - 20121019-jenkins-akiko_pusu.pdf Twitter / udzura: 凄く心に響きました…… / “20121019-jenkins-akiko_pusu.pdf” http://htn.to/m5MjUJ Jenkinsの元々の目的は、ソースのビルド管理だろう。 だが、「高機能なCron」という隠れた機能がある。 この機能を使って、Unixのパイプラインのように、定型的な処理をバッチ処理のジョブでつなげる。 すると、定期的に決まった日や時間帯に動くバッチ処理になる。 この発想は、日々のバックアップ処理や、サーバー間のデータ
Jenkinsで静的コード解析を常時自動化する - プログラマの思索
Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。 これは使い道があると思う。 【元ネタ】 Twitter / akipii: テスト自動化ができなくても静的コード解析を回帰テストのように使うのは効果的という指摘。ガラクタのレガシー資産プロジェクトで有効かもしれない。Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 http://goo.gl/rpTq7 Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 Twitter / akipii: Antのbuild.xmlをSonarが読み込んでソースの各種メトリクスを出力し、更にJenkinsと連携してCronのように使う手法。SonarがMavenだけでなくAntも使えると便利。Ant,Jenkins,Sonarの導入手順 http://goo.gl/wXJ
チケット管理は商品管理のモデルと同等なのか - プログラマの思索
RedmineでWebショップの商品管理を実現した記事を見つけたのでメモ。 【元ネタ】 Redmine でWEBショップの商品管理をしてみる | まったり覚書 (引用開始) $REDMINE_HOME/config/locales/ja.ymの文言をそれっぽく修正します。 プロジェクト→ショップ チケット→商品 作業時間、時間→売上 トラッカー→商品種別 バージョン、ロードマップ→納品計画 ワークフロー→商品の流れ 開始日→納品日 期日→回収日 題名→商品名 予定工数→売上目標 時間を記録→売上(税込) 報告したチケット→登録した商品 (中略) 1. 作業時間を金額として利用する場合に、そのままだと1000までしか入力できないので、桁数のチッェクを外します。 2. 時間表示部分を金額表示に変更します。 (中略) ステータス(商品の状態)とワークフローを商品管理っぽく設定します。 使いそうな
GnuCashの使い方 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
構成管理のアンチパターン～TiDD初心者が陥りやすい罠 #tidd - プログラマの思索
Redmine上でイテレーションを理解してもらうのが結構難しい。 その理由について考えたことをメモ。 【1】Redmineを運用してもらうと、Redmineプロジェクトやチケットの使い方はすぐに慣れてくれる。 プロジェクトの階層化は組織構造をマッピングしてくれればいいし、チケットの階層化もMS ProjectでWBSを作っていた人にとってはとても自然。 だが、Redmineバージョンがイテレーションに相当することを理解してもらうのはとても難しい。 ロードマップがリリース計画になると何度言っても、すぐに理解してくれないし、運用してくれない。 Redmineのバージョンを作らないし、チケットの属性であるバージョンに値をセットしてくれない。 ロードマップを見ながらスコープ管理しろと何度も言っているのに、チケット一覧で数百枚のチケットを平気で一生懸命フィルタリングして、チケットを1個ずつ精査してい
Scrumの謎をRedmine Backlogsプラグインで解く - プログラマの思索
先日行われたScrum Boot Campに参加した方から、Scrumの謎が解けた、というつぶやきがあったのでメモ。 僕はScrum研修を受講した経験がなく、書籍による理解しかないことを先に断っておく。 【元ネタ】 Scrum Boot Camp 横浜に参加してきた - Diary of absj31（2011/07/01から移行します：→http://d.hatena.ne.jp/shinyaa31/） Twitter / @frerudev: @hideo_sa 私はScrum Boot Camp終了後、Redmine Backlogプラグインの使い方がようやく理解できました。ずーっつスッキリしなかったScrumの謎がかなり解けた感じです。行ってよかったです。 Twitter / @akipii: @frerudev Scrumの謎はどこにあったのでしょうか？ よろしければ教えて下さい
プロダクトバックログとスプリントバックログの違い～要求マネジメント - プログラマの思索
「成功する要求仕様 失敗する要求仕様」の最後に、要求マネジメントに関するクイックレシピがある。 その方法が、Scrumのプロダクトバックログとスプリントバックログを上手に使い分けるのと同じように思えたのでメモ。 【1】あるシステムを作るために、要件定義をしているとしよう。 その時、「成功する要求仕様 失敗する要求仕様」のクイックレシピによると、以下の手順が必要になる。 1.ブレーンストーミングで要求をまず洗い出す。 要求の実現性は問わない。 要求の優先度や重要度も洗い出す。 2.ブレーンストーミングで洗い出した要求リストから、要求か否かを決定する。 実現できる要求のトリアージを行い、要求の候補を決定する。 但し、この段階では、コストやスケジュールは未決定。 3.リリース計画を作る。 実現可能なスケジュールと予算を作り、リリース計画へ入れる要求を足していく。 但し、作成中のリリース計画では不
TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト - プログラマの思索
TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト Nakaさんからテスト手法について聞いたのでメモ。 以下メモ書き。 【参考】 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkのベストプラクティス集: プログラマの思索 TestLinkのアンチパターン: プログラマの思索 TestLinkのFAQ: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】お試しテスト お試しテストとは、テスト対象モジュール・テストケース・テスト実施者などを対象として、本格的なテストを実
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
Mercurial以前と以後のチケット駆動開発 - プログラマの思索
Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。 【元ネタ】 Re:Re:mercurialでチケット駆動開発 - ろじぼ Mercurialによるチケット駆動開発は強力だ！: プログラマの思索 ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索 【Mercruial以前のTiDD】 「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。 基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。 理由は、コードラインの品質を維持したいからだ。 リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。 そし
コードレビューは緩いペアプログラミング - プログラマの思索
記事は古いけど、気付いたことをメモ。 【元ネタ】 【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro (前略) 開発もなるべく小さな単位で行う。「設計しつつ実装，こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ，デバッグしやすさのために重要」（鵜飼氏）。 既にあるコードを利用して，新たに作らないことも重要だ。「何を作らなくていいか，利用できるか，把握する。持ち駒が多ければ多いほどいい」（鵜飼氏）。 Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが，コードレビューならいつでもどこでもできる」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
