CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
スケジュールを作るプログラマが一番効率が良い。 - 山本大の日記のエントリに プログラマが作ったスケジュールはいつも壊される - @katzchang.contextsでトラックバックを頂いたので返答します。 すべてに返答差し上げたいところですが、長くなるので部分的に。 id:katzchangの言ってる状況は、昔僕もよく経験しましたし納得できますね。 僕の場合はそういった状況に陥らないために、自分がマネジメントをする立場になりたいと考えるようになり、現在はやばそうなプロジェクトに1SEとして入っても、そうそうトラブらなくなったので、ある程度の結果は出ていると思います。 好きなプログラミングの仕事に集中したいなら、プログラミングスキルと共にマネジメントスキルをツールとして持っておくことは大事だと思います。 とは言え「マネージャになれ」というのは解決策としては遠回り過ぎるので、もう少し現実的
プロジェクト管理のための代表的なソフトウェアと言えば、マイクロソフトProject 2007(以下、Project)です。Projectをインストールして最初に起動した時に表示されるのが、ガントチャート(バーチャート)です。 画面の左側には、WBS(Work Breakdown Structure)を構成するタスクを入力します。WBSとは、プロジェクトで実施する作業を細分化し、階層構造で示したものです。右側のカレンダーにタスクの開始と終了がバーで表示されます。あるタスクが終わらないと次のタスクが始められない場合は、タスクの依存関係を指定することもできます。依存関係が変わると、Projectは開始と終了を自動的に再計算してくれます。 例えばシステム開発のプロジェクトでは、「10月1日が本番稼働だから、4月が要件定義、5~6月が設計、7~8月が開発、9月がテストと移行準備…」等、大きなフェーズ
ITの地殻変動はどこで起きているのか?: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク(チケット)は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
品質の鍵は上流工程にあり SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON(ダンジョン)」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用!業務システムの開発ドキュメント標準化」(http://www.thinkit.co.jp/free/project/4/1/1.html)にて紹介したところ、大変好評でした。 その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、そ
9Arrows プロジェクトの成果物を細分化し、担当者割り振りやスケジュール・進捗状況の管理を行うWBS(Work Breakdown Structure:作業分解図)。 プロジェクトを管理する上で欠かせないこの手法を中心に、チームとしても個々としても作業を効率的に進められるようになるツールです。 WBSとは? WBS(Work Breakdown Structure:作業分解図)とは、一言でいうと「やる事リスト」です。 プロジェクトマネジメントで計画を立てる際に用いられる手法の一つで、プロジェクト全体を細かい作業に分割した構成図で「作業分割構成」「作業分解図」などとも呼ばれています。 プロジェクト管理に特化した機能ばかり 日々変化するプロジェクト進行を、効率的に進めるためだけの機能を取り揃えました。タスクの細分化、担当割り振りなどはもちろんのこと、自分のやるべき
個人的にはあまり好きではないのですが、Microsoft Projectはプロジェクト管理でよく使われているソフトウェアです。 別にソフトウェア自体がキライというよりは、すごーく小さいプロジェクトでも、何百もタスクを定義したプロジェクト計画を一生懸命作るという意味の無い作業をする人が増えたのはこのMS Projectのせいじゃないかと思ってるだけなんですが(私がプロジェクト計画を作るとスカスカになってしまうので、「お前のはマイルストーンじゃなくてマイルマウンテンだ」なんて言われたことがあります)。 Mac上でも大昔はMS Projectがあって、仕事でいやいや作ったプロジェクト計画を家で手直ししたりできたんですが、今はなかなかそうもいきません。で、この間発見したのがMS Projectのファイルを開くことができるというOpen Projectです。 まだベータで、ざっと見ただけですがそれな
「Excel Pro 工程表」は、「Microsoft Excel」(以下「Excel」)で日単位のガントチャートを作成して印刷できる「Excel」用マクロ。Windows上の「Excel」2000/2002/2003/2007に対応するフリーソフトで、編集部にてWindows XP上の「Excel」2003で動作確認した。作者のWebサイトからダウンロードできる。 作成できるガントチャートは、横軸で日数を、縦軸で項目を表示する形式。項目には担当者名と作業内容を記入でき、1つの項目に“予定日”“実績日”の2種類の帯を色つきで表示可能。1枚のガントチャートで表示できる期間は、日単位で31日間表示する“1カ月”のほか、1カ月を3等分して表示する“3カ月”“6カ月”“12カ月”の合計4種類が用意されている。専用ソフトを使わず、使い慣れた「Excel」上でガントチャートのスケジュール表を作成できる
2007/07/05 日本情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
プロジェクト開発などのスケジュール管理をExcelで簡単かつグラフィカルに作成するマイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機
朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する(なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい)。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物(ドキュメント)を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 (1)題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
情報処理推進機構(IPA)は1月22日、ソフトウエア開発プロジェクトに関する情報を自動で取得し、分析するための「ソフトウエア開発プロジェクト可視化ツール(EPM=Empirical Project Monitorツール)」を無償で提供することを明らかにした。3月に試行バージョン(ドラフト版)を公開し、2008年1月に正式版を提供する計画だ。 今回提供するEPMツールは、(1)作成あるいは削除したプログラム・コードの行数、(2)メールをやり取りした回数、(3)バグの件数などを自動で収集し、その結果をリアルタイムで図示するもの。開発者ごとに「ソース・コード規模の推移」を表示したり、「累積した未解決障害件数と平均障害滞留時間との関連」といったデータ同士の関連を参照することで、プロジェクトの状況を分析できる。プロジェクト・マネジャ(PM)が、プロジェクトでトラブルが発生していないかどうかを早期に把
先日9/29に開催したTRICHORDミニイベントの資料のひとつTRICHORDプラクティス大集合を公開しました。 この資料は、TRICHORDプロジェクトで日々実践している、または実践したプラクティスを各シーン(ブートストラップ、リリース、イテレーション、日々)毎に、「質より量」をモットーにして紹介しました。今回はどちらかというと目新しいものを中心にとりあげました。どれだけ他の現場で役に立つ内容があるかは別にして、この資料を見て「自分達にも取り入れたい」と思われたなら、それはとても嬉しいことです。 しかしもっと大切だと感じていることは、自分達で今まさにやっている開発をプラクティスという視点で見直して、まとめてみるという行為です。開発をプロセスという抽象的な形でまとめている組織はいくつもありますが、より具象的なプラクティスという形でまとめることにも意義があるのではないでしょうか。 プラクテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く