アジャイル開発のためのプロジェクト管理·Agilo MOONGIFT
アジャイル開発にとって重要なのは、スクラムを組み、一気通貫で開発してしまう勢いだ。手間のかかるタスクの登録やステータスの更新その他諸々の面倒ごとをやっていたら時間はあっと言う間に過ぎ去ってしまう。 タイムライン 例えばTracは素晴らしいプロジェクト管理だが、少々画面が素っ気ない。そこでもっと便利に使えるAgiloを紹介しよう。 今回紹介するオープンソース・ソフトウェアはAgilo、アジャイル開発を進めるためのプロジェクト管理だ。 Agiloはアジャイル開発を基本としたプロジェクト管理だ。VMWareのアピアランスも提供されているので、すぐに試すことができる。また、Tracのプラグインとしても提供されている。Wiki、タイムライン、ロードマップ、チケット、検索といった一般向けの機能に加え、チーム管理、グラフといった管理機能がある。 グラフ 何よりインタフェースがボタンを中心になっている。こ
Excelのプロジェクト管理は何故良くないのか - プログラマの思索
XP祭り関西2010のTiDDセッションの感想を読んでメモ。 【元ネタ】 [TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば 2010-02-07 - winplusの日記 XP祭り関西2010に参加してきた - Basic XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style 【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。 (前略) それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。 この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。 倉貫さんの Excelならダ
トヨタが気前よくカイゼンを教える本当の理由（1/3） ― ＠IT MONOist
工場の現場改善を定量化する科学的アプローチを可能にする手法を学習する本連載。第11回は、無駄を減らし生産プロセスを最適化することが可能な「工程仕掛かり分析」と「製品在庫分析」について説明します。
要件管理はチケット駆動開発で実装できるか？ - プログラマの思索
要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。 【元ネタ】 チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索 RedmineへScrumのアイデアを注入: プログラマの思索 まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。 TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。 * チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。 * 要件定義な
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
News Improvement
以前紹介した書籍ですが、本書の項目45「News Improvement」では、開発現場での悪いニュースが上層部へ伝わっていく過程で、それほど悪くないニュース、さらには問題はないという具合に良くなっていくという話が書かれています。 このNews Improvementは、色々な所で発生していると思います。「マネジャーはプロジェクトの現状をつかむことができない？」でも述べたように、開発の現場の状況をきちんと知るのは難しかったりします。 開発現場で問題が発生した場合には当然その問題を解決するのですが、その場合に、同様な問題が発生しないようにするための再発防止策を検討して実施することが重要です。「問題が発生しましたが、もう解決しました」と報告された際に、報告を受けた側は、問題の本質は何であるかもちろんのこと再発防止策まで突っ込んで聞く必要があります。 報告を受ける側が、そのように突っ込んで聞くこ
トヨタが気前よくカイゼンを教える本当の理由（1/3） ― ＠IT MONOist
工場の現場改善を定量化する科学的アプローチを可能にする手法を学習する本連載。第11回は、無駄を減らし生産プロセスを最適化することが可能な「工程仕掛かり分析」と「製品在庫分析」について説明します。
ガントチャート（がんとちゃーと）
プロジェクト管理や生産管理などで使われる、作業計画およびスケジュールを横型棒グラフで示した工程管理図のこと。またはその表記法をいう。 縦軸（行）に作業（タスク、アクティビティ）ないし資源（リソース）を置き、横軸に期間（時間）を取って、各作業／資源の所要期間をそれに比例した長さの横棒で示した図である。 各作業（または資源使用期間）がいつ始まり、いつ終わるのかが一目瞭然であるため、作業担当者にとってスケジュールの把握がしやすい。また作業実績を逐次記入すれば、計画に対する作業実施状況が即座に分かるため、作業管理者にとっても極めて有効な進ちょく管理表となる。 土木・建築や製造業の工程管理では広く一般に用いられており、横線式工程表、横線工程表と呼ばれる。ITプロジェクトの世界でも利用されており、バーチャート、線表（せんぴょう）ともいう。 ただし、多数の作業が複雑に入り組んだ工程を計画・管理しようとす
「Excelでプロジェクト管理」が圧倒的多数、しかし満足度は低め
昨今、システムの開発はより複雑化、多様化しており、開発者には成果物の品質向上や短納期、低コストをはじめとするさまざまな課題がのしかかっている。その中でも、現場の人間が最も問題だと感じているのはどの部分なのだろうか。 また、プロジェクトを成功させるためには「品質・コスト・納期」という3要素のバランスを取ることが不可欠となる。その実現をサポートするものの1つとしてプロジェクト管理ツールが挙げられるが、現場で求められている機能とはどのようなものか。本当に使いたい機能、使える機能とは何か？ そこで今回、TechTargetジャパンでは、プロジェクト管理に関する課題やプロジェクト管理ツールの利用状況を調査するため、会員を対象に「プロジェクト管理ツールの利用状況に関するアンケート」を実施した。656件の有効回答から見えてきた現状を読み解いていく。 関連ホワイトペーパー Excel | 工事進行基準 |
あるＳＥのつぶやき: フリーで使えるプロジェクト管理ツールまとめ
フリーで使えるプロジェクト管理ツールをまとめておきます。 ■ガントチャート 開発マイルストーン ガントチャートでプロジェクト管理できるExcelツール フリーとは思えないほど高機能 ガントチャートforExcel・・・シェアウェアになりました こちらもガントチャートでプロジェクト管理できるExcelツール スケジュールの表示期間を切り替えられるのが便利 OpenProj Java ベースでガントチャートでプロジェクト管理ができるツール Microsoft Project のフリーのビューワーとしても利用可能 フリーの高機能プロジェクト管理ソフト「OpenProj」を試してみました TaskLine Excelのアドインとして動作するプロジェクト管理ツール（saramiさん情報） Microsoft Projectのファイル(XML形式)をExcelで表示するProjectViewerもある
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
「ITゼネコンをぶっつぶせ」レポート
日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれました。 この稿ではそのうち「ITゼネコンをぶっつぶせ」というBOFについてレポートおよび考察となります。 講演者はSeasarの開発者として著名なひがやすを氏。会場は立ち見が出るほどの盛況ぶりでした(100人以上はいたと思われる)。 ITゼネコンをぶっつぶせ - ひがやすをblog ITゼネコンを倒す方法をみんなで考えよう - ひがやすをblog プログラミングファースト開発 - ひがやすをblog セッション資料はそのうち公開されるのではないかと思います。 本セッションはITゼネコンの問題点をまず挙げ、ひがやすを氏の考える打開案であるところの 「プログラミングファースト開発」についてのプレゼンといった流れ。 残念なのはひがやすを氏が契約の部分に対して解をもっていなかったという点ですね。
ITゼネコンは永遠に不滅、か？ - andalusiaの日記
日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれます。その中で私も「ITゼネコンをぶっつぶせ」というテーマでBOFをやるので、興味のある方はぜひおいでください。 ITゼネコンをぶっつぶせ - ひがやすを blog 東京なのでいけないのが残念ですが、面白そうなBOFだと思います。やろうとしていることには非常に賛同します。 ただ、非常に難しいだろうな、と思います。 そんな難しいことじゃない。プログラミングを教えるコストは、もちろんかかるけど、そのおかげで、プログラム設計書を書かなくてもすむようになるなら、十分すぎるほど元が取れると思う。 プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを blog こういうことが、現実には非常に難しいからです。 まず、システム管理基準に、こんな記述があります。 ３．プログラ
6000人が作ったシステムは必ず動く：ITpro
最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開
Java製の高性能プロジェクト管理システム·Project Dune MOONGIFT
プロジェクト管理は、開発規模の大小に関わらず必要だ。ただし、小規模なら工数を少なめに済むように簡易に、大規模なら権限管理も含めてしっかりと行わなければならない。その際にはプロジェクト管理ソフトウェアが役立つだろう。 不具合登録画面 だがそのソフトウェアの種類も多く、様々に存在する。どんなシステムを選択すれば良いだろうか。Java開発であれば、こちらはいかがだろう。 今回紹介するオープンソース・ソフトウェアはProject Dune、Java製のWebベースプロジェクト管理システムだ。 Project DuneはTomcatなどで動作するソフトウェアだが、インストーラーがdone.warを生成するというちょっと変わった作りになっている。Project Duneはロール管理が多彩で、規模が若干大きめのプロジェクトに向いているかも知れない。データ管理にはMySQLまたはPostgreSQLが利用
第1回 Tracをオススメする，これだけの理由：ITpro
Tracの便利さに惹かれるが，インストールに煩わしさを感じ，Tracを簡単にインストールできるTrac Lightning（旧Trac月）の開発を行う。また，日本のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として，プロジェクト管理ツールのTracが注目を集めています。Tracは，Ruby on RailsやSpring IDEなどでも利用されています。本連載では，開発現場を交通整理するために，Tracを利用したプロジェクト管理の効率化を，Tracの基礎から紹介していきます。 ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。 ま
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
システム開発から属人性を排除しようとして失敗する - プログラマの思索
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
小さなチームのためのプロジェクト管理ツール | Teamsteam
Microsoft 365 help & learning