Agile Project Management
Proven project management for successful teams With a shared view of team priorities, a process that fosters collaboration, and dynamic tools to analyze progress, your team will deliver more frequently and consistently. Better organization to get focused Keep your team on the rails. Tracker's shared backlog makes priorities clear so the team can stay organized. Easily visualize scope, focus your t
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
Tom's Planner - Gantt charts for the rest of us.
When project planning in spreadsheets is chaos, and when fancy project management software is overkill — try Tom's Planner. Try Tom's Planner for free: Create and share professional Gantt charts in minutes Break rules and plan your way — it's flexible Zoom in to see who's doing what and when Zoom out to see the overall picture you're missing Drag and drop to make changes on the fly No learning cur
Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」
Windows、Mac、Linuxのいずれでも動作が可能で、JRE1.5以上がインストールされていれば問題なく利用できるのがこの「OpenProj」。ガントチャート、ネットワークダイアグラム、WBSとRBSチャート、レポートの印刷とPDFによる出力、コスト計算などなど、プロジェクト管理に必要なほとんどの機能が備わっています。 また、Microsoft Projectのファイルを開いたり保存することも可能です。ただのビューワーではなく、実際に編集できるのでかなり便利。メニューなどはほとんど日本語化されており、抵抗なく使うことができます。 ダウンロードとインストール、実際の表示などは以下から。 Home | Serena Open Source and Hosted Project Management Software http://openproj.org/ 今回はWindows用を使うの
セレナビジネスマッシュアップについて
Knowing what has changed in a software environment is as critical today as it was in 1980 when Serena began. From the very first product Comparex, to the Release Management and Deployment Automation solutions, Serena focused on managing every facet of IT change. These products are depended upon daily by global organizations to develop and deliver their critical business systems so they can “move f
[B! PM] shozzyのブックマーク
タイトルは僕の造語です。 ビジネス・アーキテクツ代表取締役の森田さんが、下記雑誌の対談でこのような発言をされていました。 Web Site Expert #14 作者: WebSite Expert編集部出版社/メーカー: 技術評論社発売日: 2007/09/27メディア: 大型本 クリック: 5回この商品を含むブログ (6件) を見る 「正しく動いていることを担保してくれれば良いので、プロジェクト自体を開発するのは物事を作る仕事につながることです。PMPの資格を持っていますといっても、プロジェクトの開発、つまり案件化はできないですからね。じゃあ、どうやって僕たちはそれをできるようになったのかと言えば、これはまた別の難しい話ですけれどね｣ Webディレクションの世界でも僕のようなSIの世界でも、似たようなお悩みがあるんだなと思いました。 つまり、｢システムを作る・Webを作るマネジャーとモ
近況. - Backnumbers: Steps to Phantasien
とっくに明けてますがおめでとうございます. 親元には WiiFit がありました. また負けた. 悔しいので世の中にはニコニコ動画というのがあって... とまだまだ若いところがあるのを見せようとしたらアカウントがなくて, 仕方ないので金を払ってプレミアム会員になり, 猫鍋やらアホな料理を見ていたら年が明けていました. 最近読んだ本 前回は 8 月. 全然最近じゃない... オブジェクト志向設計入門 第2版 原則, コンセプト 古典ということで読んでおく. 厚い. 辛かった. 古さは感じるが, しっかりとした内容でそこそこ満足. 継承の話以外は. 1/3 くらいは継承の話で, そこは辛い. もう多重継承とかやめてよ... 継承付近のつじつまあわせで Effiel の言語仕様は やたらと面倒になっている気がする. 使うことはないからいいけれど. 基準, 規則, 原則の議論はよく引用されるだけあ
残業は会社にも優しくない - 書評 - 「残業ゼロ」の仕事力 : 404 Blog Not Found
2008年01月31日01:45 カテゴリ翻訳/紹介Art 残業は会社にも優しくない - 書評 - 「残業ゼロ」の仕事力 日本能率協会マネジメントセンター出版事業部坂田様より献本御礼。 「残業ゼロ」の仕事力 吉越浩一郎 勝間和代も 荘司雅彦も、働く側から「残業は損」と述べているが、それを「働いてもらう」側から述べているのが著者。著者の本はその点で首尾一貫しているのだが、その中で最も優れているのが本書だ。両方あわせて読んでおきたい。 本書〈「残業ゼロ」の仕事力〉は、トリンプ元社長として、従業員も増やさず残業も増やさず会社の売り上げを5倍、増収増益を19期連続で達成した著者が、それをどう成し遂げた、いや成し遂げられるように会社をしたのかを、一個人の立場から振り返って書いた本。同工異曲としては「デッドライン仕事術」があるのだが、本書の方がよく書けているのは、単価の違いばかりではないだろう。 目次
ウノウラボ Unoh Labs: デザイナの立場からの「デザイン依頼のコツ」
こんにちは。yamazakiです。 このブログをご覧になっているのはエンジニアの方が多いと思いますので、デザイナの方とのやりとりをされている方も結構いらっしゃるはず。 社内で「どういうふうに依頼されるのがデザイナとしてはいいもの出てきやすい？」というお話を振られたので今回はそれについて書いてみようと思います。 ※もちろんあくまでこれは私個人が思うところであり、全てのデザイナにあてはまるわけではないと思います。 ので、できればこれをご覧になったデザイナーの皆様も、「こういうふうに依頼してくれると力が発揮できる」というポイントなど書いていただけたら非常に嬉しいです。 また逆に、デザイナにはこういう点気をつけて欲しい、といった、エンジニア視点でのデザイナへのリクエストなどもいただけると嬉しいです。 ---- ビジョン、ゴールを共有するこれは複数の人間が関わるプロジェクトなら当たり前といえば
住みたいところに住める俺: 仕事は7.5時間で終わらせる
今のカナダの会社では5時にもなると半分以上の人間が帰る。 原則7.5時間働けばいいというルールなので、朝早く来る人は当然早く帰る。 7.5時間以上がんばっても評価される仕組みではないのだ。 評価はその時間でどれだけアウトプットが出せたかで決まる。 これは私がシリコンバレーにいたときの現地のメンバーも同じような感覚でやっていたので、北米的には普通なのかもしれない。 なので、時間内に何とか終わらせようという気持ちがそこここで感じられる。 この3ヶ月で見た感じだと、その工夫の一つにはミーティングへの時間の割き方が日本とは違う。 ・基本的には定例会議はない。 ・ミーティングは30分単位が基本。 ・重要かつ急ぎのプロジェクトの場合、毎朝進捗確認はやるが、15分程度。立っておこなう。 ・2-3人での、ちょっとした相談や、決断は担当者のキューブへ押しかけて行う。 ・その際も、異常に早口で、即決する傾向あ
WorldWideWeb: ハイパーテキストプロジェクトの提案(訳)
この文書は、1990年11月12日、最初のWebブラウザを開発したティム・バーナーズ・リー氏が、彼が所属する組織であるCERNの重役たちにむけて送った、メールによる提案書の日本語訳です。( 原文はここ: http://www.w3.org/Proposal ) この提案書が送られてから3ヶ月後に、当初の予定に遅れることなく、最初のWebブラウザ「WorldWideWeb」がリリースされることになりました。（スクリーンショット：http://www.w3.org/History/1994/WWW/Journals/CACM/screensnap2_24c.gif ） 私がこの文書に興味を持ったのは、Webの発展の歴史上、非常に重要な文書であるということだけではなく、この文書が、プロジェクトを成功させるために必 要な、高品質の提案書を作成するための非常に良いヒントを多く含んでいるからです。 プ
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
ブレインストーミングは死んだ！ ブレインストーミング万歳！ | Lifehacking.jp
LifeDev 経由で読んだのですが、「チームによるブレインストーミングはそれほど効率的な発想法ではない」という研究結果について紹介する記事がありました。 心理学者の研究によると、何人かの人を集めてブレインストーミングのセッションをしたのと、個々の人に一人で発想をさせてあとで持ち寄るのとで、有意な差は見られなかったという研究結果です。 「ええ？ そんな！ じゃあ今までブレインストーミングをやっていたのは無意味だったの？」と思われるかもしれませんが、答えは yes でもあり、no でもあると思います。 ブレインストーミングを殺す要素 非効率的なブレインストーミングならやらないほうがましという意味ではみんな意見が一致すると思います。英語版 Wikipedia の Brainstorming の項が非常に詳しいのですが、ここに書いてあることをまとめると、ブレインストーミング効率を下げてしまう要因
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flowdock: Group chat for teams. Integrates with GitHub, Jira, Trello.
Amazon.co.jp: Manage It! 現場開発者のための達人式プロジェクトマネジメント: Johanna Rothman (著), でびあんぐる (翻訳): 本
Amazon.co.jp: Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本: Dan Pilone (著), Russ Miles (著), 有限会社福龍興業 (翻訳), 木下哲也(監訳) (監修), 木下哲也(監訳) (読み手): 本
Amazon.co.jp: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~: Mike Cohn (著), マイクコーン (著), 安井力 (翻訳), 角谷信太郎 (翻訳): 本