テキストベースのシンプルなプロジェクト管理·Projector MOONGIFT
Projectorはテキストファイルベース、HTMLファイルの存在有無でタスクのステータスを管理するプロジェクト管理です。 プロジェクト管理の肝はタスク管理にあります。タスクのステータスさえ適切に管理できれば問題はないとさえ言えます。 プライオリティの優先度によって3つのタブに分かれて表示されています。 クリックで指定されたURLが開きます。 他のプライオリティにもアクセスできます。 こちらが設定ファイル。 ファイルの有無によってプライオリティが変わっているようです。デザイン状況などを管理するのに良さそうです。設定ファイルには単にタスクを並べておくだけなので簡単に使えます。更新はファイルベースなので手間もなくすぐに使えるようになるでしょう。 ProjectorはHTML/JavaScript製のオープンソース・ソフトウェア（Apache License 2.0）です。 MOONGIFTはこ
大型プロジェクトにも対応する時間管理機能付きプロジェクト管理·todoyu MOONGIFT
todoyuはタスク、時間管理、カレンダーといった機能が備わったWebベースのプロジェクト管理ソフトウェアです。 企業においては複数のプロジェクトが同時に進行するなんてのはざらです。そして一人が複数のプロジェクトにまたがって活動しているケースも多々あります。そこで使ってみたいのが大型なプロジェクト管理、todoyuです。 管理者としてログインしています。 プロジェクト詳細です。 カレンダー（月表示）です。 連絡先です。 帳票管理です。 こちらはメンバーとしてログインしています。Todoやタイムトラッキングが表示されているのが特徴です。 タイムトラッキングはその場で修正できます。 フィードバックの一覧です。 主な機能はプロジェクト管理、タイムトラッキング、カレンダー、レポート、請求書、タスク管理、コンタクト管理となっています。UIが特徴的なので最初に慣れるまでは時間がかかるかも知れません。管
みんなはどんなテスト技法を使っているの？ JaSST'12 Tokyo
先週、1月25日と26日に都内で行われたソフトウェアテストに関するシンポジウム「ソフトウェアテストシンポジウム JaSST'12 Tokyo」。会場には、参加者が自分の知っているテストの種類を付箋に書いて、自由に貼ることができるポスターが掲示されていました。 独自のテストの種類を貼っていく ポスターの下地になったのが「テスト技法ポジショニングマップ」です。さまざまなテスト技法が表示されています。 この上に、さらに自由にテスト技法、テスト手法の名前が付箋で貼られました。例えば、右上には「ZERO テスト（テストしない）」、右下の方には「血みどろテスト」、中央下には「書いてあるとおりテスト」、左下には「がまの油いぶり出しテスト」、左上には「カン」（勘ですね）、図のど真ん中には「たぬきの皮算用テスト」などなど。名前だけではどんな内容のテストなのか分かりませんけれど……
オープンで民主的なプロジェクト管理·BetterMeans MOONGIFT
BetterMeansはフラットな組織におけるアジャイルに似たプロジェクトの進め方を推進するプロジェクト管理です。 BetterMeansは従来のトップダウン型のプロジェクト進行ではなく、民主的な手法を全員が一律にプロジェクトを進めていく方法を実現するプロジェクト管理システムです。 トップページです。オープンソースの他、Webサービスも提供しています。 ダッシュボードです。早速新しいプロジェクトを開始します。 新しいワークストリームを作成します。 作成しました。左がオープン、右が作業中のタスクになります。 タスクを追加しました。 タスクの詳細です。 タスクはドラッグアンドドロップで移動します。作業中になりました。 完了時にはコメントを登録します。 完了の枠が追加されました。 チームメンバー一覧です。 掲示板です。 普通にリプライできます。 Wikiもあります。 日本語も使えます。 Wiki
規模の大きなプロジェクトで使いたいプロジェクト管理·NavalPlan MOONGIFT
NavalPlanはエンタープライズクラスに向いたのJava製のプロジェクト管理システム。 NavalPlanはJava製/Webベースのオープンソース・ソフトウェア。企業規模によってプロジェクト管理に求めるものは変わってくる。小規模な組織であれば個人の裁量が大きく、コミュニケーションも活発なのでWeb上でまとめる情報はそれほど多くなくても良いかも知れない。 ガントチャート しかし何百人とプロジェクトに関わる人が増えてくるとそうも言っていられない。適切に管理を進めなければいざという時に大変なことになってしまう。そこで使えるのは大規模プロジェクト向けのNavalPlanだ。 NavalPlanはガントチャートが基本になるプロジェクト管理だ。WebベースなのでWebブラウザさえあれば誰でも見られるのが利点だ。一つのプロジェクトだけでなく、複数のプロジェクトを全体的に見ることができる。各人員のリ
アジャイル開発を習得したいなら。スクラム開発対応のプロジェクト管理·ScrumDo MOONGIFT
ScrumDoはアジャイル、スクラム開発に対応したプロジェクト管理。Django/Python製。 ScrumDoはPython/Django製のオープンソース・ソフトウェア。アジャイル開発が徐々に使われるようになっている（社内開発中心だが）。アジャイル開発では、ユースケースをストーリーという単位にして管理する。一つのイテレーションの中で一つまたは複数のストーリーをこなす形だ。 ストーリー作成 一つのイテレーションを終わった段階で複数の機能が開発、テスト、結合されているのでそのままリリースすることさえできる。それを繰り返して開発を進めることで徐々に機能や品質が高まっていく。そんな開発を実現するためのプロジェクト管理がScrumDoだ。 ScrumDoではストーリーを作成し、その中にタスクを追加する。そしてそれをイテレーションの中に組み込んでいく。イテレーションを行った結果はバックログとして
bufferings, SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間が...
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ：DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチェ
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと１対１に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容（内部の処理の実装方法）の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
