Project Management as Code with Graphviz
tl;dr My team and I have been using graphviz and git to perform project management tasks. It has numerous benefits, including: Asynchronous project updates (ie fewer meetings) Improved updates for users Visualisation of complexity of project for stakeholders and team Assumptions challenged. Progress can be measured using git itself (eg log) HackerNews Discussion here Background Recently I’ve had t
Kanboard - カンバンをベースとしたプロジェクト管理
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました プロジェクト管理ソフトウェアにおいてカンバンは欠かせない存在になってきています。特にアジャイルでスプリント管理しているケースは重宝するでしょう。さらに開発以外のタスクについてもカンバンは便利です。 そんなカンバンをベースとして発展しているプロジェクト管理システムがkanboardです。 kanboardの使い方 ダッシュボードです。まずプロジェクトを作ります。 プロジェクトの詳細画面です。 タスクを作ります。期限やステータスなどもあります。 カンバンです。 ガントチャート表示もできます。 さらにカレンダー表示も。 一覧もあります。 タスクの詳細です。 ステータスを確認できます。 グラフによる可視化も。 Kanboardはカンバン機能が軸になっていますが、表示方法が多彩でプロジェクト
関係が泥沼化、京都市が7億5000万円請求するもIT企業は支払い拒否
京都市が進めていたシステム刷新の稼働が遅延している件で、京都市とシステム開発を受託したシステムズ（東京・品川）の関係が泥沼化している。京都市は開発遅延の責任を巡って2017年10月12日、システムズに対して10月27日までに約7億5000万円の損害賠償を支払うことを求めていた。ところがシステムズはこの支払いに応じなかったことが、日経コンピュータの取材で分かった。京都市とシステムズともに、訴訟に発展する可能性を否定していない。 京都市の情報システム部門に相当する総合企画局情報化推進室は2014年から81億円を投じて、基幹系システムの刷新プロジェクトを進めてきた。この基幹系システムは、国民健康保険や介護保険といった福祉系のほか、徴税、住民基本台帳の管理など18業務を担うもの。NEC製メインフレーム上にCOBOLプログラムで構築したシステムで、稼働後約30年が経過している。 福祉系のオンラインシ
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
iandeth. - エンジニアが陥りやすい「バーンアウト症候群」
@IT自分戦略研究所の記事より 日本語でいうと「燃え尽き症候群」。熱意持って仕事に取り組んでいたエンジニアが、ある日突然すべての事柄に対する意欲を失ってしまう現象の事。 バーンアウトを一言で説明すると「ある日突然、意欲が燃え尽きてしまうこと」である。元気で働いている人ほど、バーンアウトに陥りやすく、これまでの意欲まんまんの様子と、その後の落ち込みの落差が非常に激しいという特徴がある。 （1）消耗感または疲労 バーンアウトに陥った際に最も典型とされる症状。例えると弾力のあったゴムが疲弊し伸びきったような、単に体が疲れ果てたということにとどまらず、もう何もする気力がなくなったという意味で情緒的な消耗感である。 （2）人と距離を置く姿勢 上記のような消耗感から自分を守るために人との接触を制限し、場合によっては突き放すような態度を取ったりする。個人を十把ひとからげにし、人をモノのように扱う。一方、
敗戦処理をする : SEの残業しない仕事術
2007年12月23日22:18 敗戦処理をする カテゴリプロジェクトマネジメント gaseidou2 Comment(0)Trackback(0) プロジェクトの失敗を、 １００％避けることはできません。 かならず、 いくらかの割合で、 失敗します。 ときに、 もう失敗が決まっているプロジェクトの、 残務処理をしなくてはならない場合があります。 比較的できるリーダーが、 アサインされることが多いでしょう。 楽しい仕事ではありません。 顧客は怒っているでしょうし、 メンバのモチベーションも最悪でしょう。 しかし、 ここでどれだけ学ぶことができるかが、 リーダーとしての勘、経験を左右します。 失敗プロジェクトは、 見方を変えれば、 こうするとこんなことになる または、 これをやらないとこんなことになる という事例の宝庫です。 失敗は学ぼうと思って学べるものではありません。 めったにないチャン
Github IssuesをExcelに出力する - Qiita
はじめに Quadでは開発フェーズでのタスク管理や運用フェーズでの障害管理にGithub Issueを使っています。 最初は何が良いのかよくわからないけど、一度Issueに慣れてしまうと他の方法でやりたくなくなるぐらいの魅力を持ったサービスですね。 ただ受託案件の場合、クライアントとの課題一覧のやりとりにIssueを見せるわけにもいかず、課題管理表をExcelで作ることが多いです。2重管理だし手間かかりますよね。 今回はIssueをExcelに書き出してみました。 GitHubからIssuesを取得する 前回GitHubからAPIを利用してデータを取得したので、これを利用します。 http://qiita.com/segawa/items/8c97e626326b68d5750a Issue APIの詳細は下記を参照してください。 https://developer.github.com/
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
プロジェクト管理のエモいはなし - Qiita
前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー
Tracに足りない4つの機能 - プログラマーの脳みそ
ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
「計画的にやれ」が悲しいほどメンバーに通じない理由 − PG時代と何が違う？ 新任PMがついやってしまうNG集 − ＠IT自分戦略研究所
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 お悩みのPM諸君、ついこんなこと言っていませんか 同じ「プロジェクト」に関わるにしても、PM（プロジェクトマネージャ）になる前と後では大違いです。プログラマの1人として働いている時は、自分の作業に専念していればよかったのに、PMになった途端「顧客から新しい要望が来た」「○○さんの作業が遅れている」といってはフォローに追われる日々。「何で皆、ちゃんと動いてくれないんだ！」とストレスをためるPMも多いはずです。 ですが、「自分が動くこと」と「人に動いてもらうこと」が違うのは当然のこと。ですが、ついそのことを忘れて、こんなことを言ってしまうPMは多いのではないでしょうか。 これらはPMの発言としては“NG”です。いくら口をすっぱくして注
［進捗管理編］工数をうのみにしてはいけない
工程表を作成する方法はいくつかある。システム開発プロジェクトではWBSを用いてガントチャートを作成する方法が一般的である。このWBSを分解しワークパッケージ単位まで落とし込む際に，各担当SEやプログラマに概算工数を算出させるプロジェクト・マネージャ（PM）は少なくない。 各担当者は，PMからの要請に従い，自分が行う作業工数を見積もって報告する。PMは，各担当者から報告された工数をベースにWBSをガントチャートに割り当ててゆくのである。事実，筆者もワークパッケージを1～2週間単位の粒度まで細分化していく場合，担当者やその作業に見識のある技術者に当該成果物がどのくらいの工数で作成できるのかを聞く機会は多い。 こうして作成した工程表を基にプロジェクトを推進しようとすると，往々にして予定していた工数を超過してしまう。では，いったいなぜ各担当者からの見積もりに基づく工数が超過してしまうのだろうか。一
情報システム開発プロジェクトの成功率は75% - Footprints
日経コンピュータ誌10月16日号の特集で興味深いデータを見つけた。 26頁以下のアンケート結果によれば，「当初予定していた品質・予算・納期（QCD)を遵守できた」新規システムの導入・開発プロジェクトの成功率は何割かということを，ベンダ，ユーザ双方に聞いたところ，開発期間によって多少の差があるものの，単純平均すると，75%が成功だったという回答だったという（回答数は2000以上）。 （出典：日経コンピュータ2014年10月16日号26頁） これは正直驚いた。というのも，同種のアンケートが日経コンピュータ2008年12月1日号にて公表されているが，そのときの回答では，成功率は31.1%（800社に対する調査）であり*1，劇的に改善されていたからだ。 実際，私も，雑誌の解説や，講演などで，「システム開発プロジェクトは失敗が多いですよね。2008年のアンケートですが，3割しか成功しないという結果も
要求管理(要件管理)ツール RaQuest
お知らせ RaQuest バージョン ビルドをリリース致しました。 製品版はサポートユーザ ダウンロードページからダウンロードしてください。 評価版は評価版のダウンロードページからダウンロードしてください。 2023年11月28日 RaQuest バージョン6.0 についてのページを公開致しました。 バージョン6.0について はじめに 昨今のソフトウェア開発において、ソフトウェアに対する要求（要望・要件）は増加・複雑化しています。このような状況においては、ソフトウェアに対する適切な要求を開発・定義することが重要です。それに加え、開発・定義した要求を適切に管理(マネジメント)することがより重要です。また、ソフトウェアの開発中には環境の変化など、様々な要因から要求が変更されることが多くあります。要求が変更された場合、発生した変更に対して、適切に対応することも重要です。こうした状況では、要求を正
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『開発が遅れる原因：プログラマー社長のブログ：オルタナティブ・ブログ』へのコメント
タスク管理でチームの効率アップ｜MeisterTask
【雑記】失敗事例から学ぶシステム開発 - 循環論法
https://www.ipa.go.jp/files/000005381.pdf
トレーサビリティ支援ツールで開発費用を削減