2. Disclaimer ● プロジェクトメンバー/プロジェクトマネージャの初心者向け資料です ● ハートビーツ社内勉強会向けに作りましたが公開できそうなので公開しちゃいま す ● ばば個人が知ってること、意識していることを書きました ○ 個人の見解です ○ プロジェクトマネジメントについてのインプットは実務+大学院での授業いく つか ○ 担当領域予算数百万円、工期〜1年程度の小規模プロジェクトを主に扱っ ています 4. プロジェクトとは 「独自の成果物、またはサービスを創出するための 期限のある活動」 (Project Management Institute定義) ・・・噛み砕くと ● 明確に定義された目標がある ○ 明確に＝計測・判定可能 ● 明確に定義された予算がある ○ (確保されるという意味ではなく定義されるという意味合い) ● 明確に定義された期限がある ○ 期限を決めずや
前から気になっていたプロジェクト管理ソリューションJIRAを試してみようと思います。プロジェクト管理と言えばRedmine等のBTSとかリポジトリ管理とかそんなかんじのものを思い浮かべますが、JIRAもそれと同じようなものであるようです。 しかも高機能な上に、他のプロジェクト管理ツールからチケットをインポートできる機能も併せ持つ今話題のプロジェクト管理ツールだということですから、これは見逃せません。しかも安い。 というわけで使ってみた。お試しということで体験版をダウンロードします。 # ダウンロード先 http://www.atlassian.com/ja/software/jira/download cd /usr/local/src/ wget http://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
Basecampでプロジェクト管理を行うには、プロジェクトを作成したら、何をおいてもまずマイルストーンを置くことです。 プロジェクトのゴールを考え、それに向かってマイルストーンをおいていく。 「この時点で、だいたいこういう状態になっていたいな」 というところを書いていきます。 たとえば、 ・開発環境構築完了 ・初期版の画面モック作成完了 といった感じ。 私もそうなのですが、マイルストーンがうまく置けないケースが出てきます。 マイルストーンがうまく置けないということは、そこからゴールまでの道筋が分かっていないということ。 なので、無理にマイルストーンを置かずに、「何が分かれば先のマイルストーンが置けるか」を考え、 プロジェクトがもう少し進んだところで、マイルストーンを置く作業を再度行います。 それから、マイルストーンはだいたい週単位でいくつかのマイルストーンがクリアされていくぐらいの粒度に落
Rick Freedman （Special to TechRepublic） 翻訳校正： 村上雅章 野崎裕子 2012-08-10 07:30 アジャイル開発の考え方と、従来から用いられているプロジェクトの計画手法や予算策定手法は真っ向から対立する場合がある。本記事では、こういった場合に行えることを3つ紹介する。 アジャイルな見積もり、およびプロジェクト計画やイテレーション計画といったロードマップの作成工程には、対立と誤解の種が数多く潜んでいる。クライアントや、事業の後ろだてとなってくれる人たち（スポンサー）、特に従来のプロジェクトマネジメント手法に精通している人たちは、ロードマップがプロジェクト見積もりを算出するためのものだという前提を置いているため、ロードマップの立案を終えた時点で一足飛びに「コストはどれだけかかるのか？」という難問の答えを求めようとする場合がしばしばある。 ではここ
29年ぶりに出たVisageのニューアルバムばかり麻薬のように聴いている、イノベーション・センター もりもとです。 ミクシィでは、会社・サービスのロゴをあしらったノベルティをしばしば制作します。 いままで、ルービック・キューブとか カラビナとか ただの紙じゃつまらないと、透明な素材を活かしたリクルートメントのパンフレットとか (巨人が夏みかんの皮を剥くのにも使えると思います) いろんなものを各部署で毎年作ったりしてきました。 さて、今年度は何をつくろうかな…… と思ってましたが、 Androidネイティブアプリを手がけているユニットがリファインメントをしている様子を見て、 「そうだ、これを作っちゃえ!」 上の写真でチームメンバーがお互いに出し合っているトランプのようなものは、プランニング・ポーカー (Planning Poker) と呼ばれるカードです。ゲーム感覚もあわせて、タスクの見積も
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
私は、Jiemamy Projectというオープンソースプロジェクトを運営している。 ある意味、一人で作っている頃は楽だった。Javaにおけるpublicというキーワードの重みも知らず、複数人によるコミュニケーションのオーバーヘッドも気にすることなく、それはそれは勝手気ままにひたすらコードを書くだけだった。 当初、Jiemamyは「そんなに難しいモンじゃないだろｗ さっさと作って便利にしようぜｗｗ」くらいのノリで作っていたのだが、作れば作るほど色々な問題点も浮上し、勉強すればするほど新しい機能も欲しくなった。人の欲とは恐ろしいものだ。一人じゃ、もう作れない、限界がすぐに訪れた。 Jiemamyは、（私の知る限り）今までにあまり無い考え方を打ち出したプロジェクトだ。ただ語られていなかっただけかもしれないが、「私はこうあるべきだと思う」という理想（Jiemamy開発プロセス）を打ち出し、それを
工事進行基準とEVM 今回から2回は、EVM(Earned Value Management)を活用した予算・実績管理に関する話題である。EVMそのものについては、PMBOKにおいてプロジェクト報告のためのツールの1つとして位置付けられていることから、読者諸兄にとっても耳になじみのある単語だろう。 本年4月から、受注ソフトウェア開発業についても、会計上の収益認識基準として工事進行基準の適用が原則義務化された。工事完成基準においては、いわゆる「どんぶり勘定」の計画でスタートして、完成時の収支計算で帳尻合わせを行うことが許容される世界だった。それが、計画段階から精緻に予算を積み上げて、それを基にした進捗管理を行わなければならなくなり、読者諸兄も自身の担当プロジェクトを、いかにして工事進行基準に合致させるか苦心されたのではないだろうか。 工事進行基準に対応するには、プロジェクトの進捗や作業のパフ
メンバーの力を引き出す効果的なチームマネジメント プロジェクト成功のカギは何か。周到なプロジェクト計画の策定、適切な人材のアサイン、組織的なプロジェクト管理支援等、様々な要素が挙げられる。いずれも重要であるが、それらが揃ったとしてもプロジェクトが成功するとは限らない。最終的にカギを握るのは、プロジェクト現場における一人ひとりのメンバーの活力である。 今回は、チームリーダーの立場を担う上で重要となる『メンバーの力を引き出す効果的なチームマネジメント』について、事例を取り混ぜつつ、5つのポイントに絞り、紹介していく。 メンバーの力を引き出す効果的なチームマネジメントのポイント ポイント1 : メンバー間における信頼関係の構築 - お互いを尊重しあう姿勢 チームが有効に機能するために重要なことは何か。まず基礎になるのはメンバー間の信頼関係である。一朝一夕に築き上げられるものではないが、お互いの立
スケジュールについてPMが知っていなければならない、絶対原則。 完了日を1点で見積もるのは絶対にムリだ、ということ このことはエンジニアがタイトル買い、著者買いすべき本 - Fight the Future じゅくのblogでも紹介した本から学んだ。 ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子出版社/メーカー: 日経BPソフトプレス発売日: 2006/10メディア: 単行本購入: 27人 クリック: 372回この商品を含むブログ (88件) を見る もしあなたがマネージャなら、最低でもマコネルの「ソフトウェア見積り」は読んでおいてほしい。 本に書いてあることをそのまま実践してほしいわけじゃない。 こうした英知をベースに見積もりやスケジュールを考えてみてほしいだけだ。 自分のプロジェクトに合わせてア
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Amazon EC2上で稼動しているRedmineからメールが送信したくなったので頑張ってみた話。 インターネット上でサービスを動かしている場合、何かしらのタイミングでメールを送りたくなる場合があるかと思います。 でも、やっぱりメールサーバの運用の難易度と言えばそりゃもう、、、なわけで、出来るだけ自分でメールサーバの運用だけは避けたいものですよね。 ということで、GmailのSMTPサービスを使ってみることにしました。 天下のGoogle様のサービスであるGmailについては、説明不要かと思いますが、Gmailは、ただのWebメールではなく、SMTPやPOP、IMAPなんかにも対応していたりします。 しかも、SMTP経由で送信したメールも、Gmail上で保管してくれるという優れものです！ で、Gmail使えるやん、ってことで設定しはじめたんですが、すんなりとはいかなかったので、以下、頑張っ
プロジェクト管理ツールの必要性 みなさんのプロジェクトは上手に運営できていますか？ プロジェクトメンバーのタスクの進捗管理はできていますか？ 問題・課題管理はスムーズに行えていますか？ ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか？ 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか？ ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか？ ソースコードはきちんと管理されていますか？ リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか？ プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
