時代に咲いた徒花: 『プログラマのジレンマ 夢と現実の狭間』 @ val it: α → α = fun
プログラマーのジレンマ 夢と現実の狭間 同僚に教えてもらって読んだのだが、とても良かった。プログラマは必読だが、それ以外の人にもおすすめしたい。 Chandlerという鳴り物入りで始まったオープンソースプロジェクトについて、およそ3年にわたって追いかけた失敗の記録。といって「ああ、デスマの本ですか」と一括りにしてしまうともったいない。確かにソフトウェアプロジェクトの失敗の話なんてありふれているし、デスマーチの本なんて他にいくらでもある。この本が面白いのはたぶん、そういうありがちな問題がまるでないプロジェクトだったにもかかわらず失敗する、ということを報告しているからだ。 デスマーチはない。納期に追われて徹夜するやつはいない。勤務時間は自由であり、オフィスには愛犬を連れてきてもいいし、在宅勤務もオーケー。資金的にも問題ない。スポンサーが変なことを言い出して仕様変更になったりしない。リーダーはロ
TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない - プログラマの思索
ITS(Issue Tracking System：課題管理システム)の導入がうまくいっていない状況があったという記事があったのでメモ。 とても参考になります。 【元ネタ】 なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド Agile開発の肝はイテレーションにあり: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 (前略) 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんてITS使ってる人には常識
Webベースのプロジェクト管理サービス探訪
で。 残念ながら参加する人間の関係上、英語インターフェイスしかないものは却下Google Docs は Office 文書の共有しかできない。まさか Excel で管理とか常識的に無理Backlog は非公開プロジェクトを無料では作れない残りは Zoho Projects と fixdap Zoho Projectsこれは本格的なプロジェクト管理ツールで、しかも無料で非公開で使える。（ただし、作れるプロジェクトは一つまで。） OpenID 対応Google ID などでログインできる。一見地味だけど、後に挙げる「外部メンバー」のところで効いてきそう。 概念の階層が Trac より一つ多いプロジェクト マイルストーン タスクリスト タスク慣れもあるけどタスクリストはちょっと邪魔かなぁ。 外部メンバー、内部メンバーこれは面白い。社外の顧客と情報共有をしつつ、内部リリース（非公開）用のマイルスト
プロジェクトの進捗遅れはなくせる
「システム開発プロジェクトで、進捗をきちんと守ることなんて到底無理ですよ。いいシステムを作ろうと思うほど、進捗が遅れるんですから。雑誌作りだって同じでしょう？」。 日経SYSTEMS 2010年8月号で「進捗遅れをなくそう」という特集を担当するにあたり、懇意にしているITエンジニアのAさんに相談したところ、特集の意義を真っ向から否定された。 記者は言葉に窮した。自分で言うのも何だが、記者は進捗（締め切り）遅れの常習犯である。自分のことを棚に上げて、システム開発プロジェクトの進捗遅れに意見する資格はない。 それでも、一点思うところがあったので指摘した。経験的に言って、進捗を遅らせたほうがいい記事になるとは限らない、ということだ。むしろ進捗通りに進んだときのほうが、記事の出来はよいように思う。 記者の指摘に対し、Aさんは「システム開発でも同じかもしれない」と答えた。単純な話、進捗を守ると余裕期
プロジェクト単位で、メンバーや書類やタスクを管理できる「Manymoon」 | ライフハッカー・ジャパン
Googleサービスを、プロジェクトごとに管理したい人へ。 日付毎、メール毎、タスク毎、書類毎、ゴトゴトと管理方法は数多あれど、プロジェクト毎にはビミョーに管理しにくいGoogleサービス。その難点をすっきりさせてくれるのが、「Manymoon」です。過去記事、「Google Apps Marketplace」でオススメのアプリTop10でも、3位にランクインしている､定評のあるフリーAppです。 初回のログイン時はチュートリアルモードで、シンプルな画面の指示に沿っていくと、プロジェクトが1つできあがります。 プロジェクトを単位として、メンバー（同じドメインのメンバーやGoogleの連絡先から簡単に登録できます）、添付ファイル、Googleドキュメント、URL、イベント（日時指定・期間指定）などを一元的にまとめられます。 上の画面から、Googleドキュメントを作成するのも、既存のドキュメ
障害管理の泥沼から脱出するには - プログラマの思索
リンク先から下記の記事を見つけたので、考えたことをメモ。 【元ネタ】 こんにちは。 ソフトウェアの不具合管理をしているのですが、現在はエクセルファイルを複数社で メール添付で行っています。 この方法だと、 ・どれが最新かわからなくなる.. - 人力検索はてな 不具合管理(障害管理)はソフトウェア開発の中で最も重要で、そしてコントロールが難しいマネジメントだ。 ウォーターフォール型開発で設計、開発、単体テストと順調に進んでも、結合テストや受入テストに入ると、バグが多発してしまって品質がボロボロになってしまうケースは数多い。 ソフトウェア開発が製造業など他の産業の工程と異なる箇所は、結合テスト以降の障害管理だと思う。 各種のモジュールを初めて結合して、インターフェイスが違っていたり、仕様通り作っていても性能が出なかったりする症状が分かる。 いわゆるビッグバン結合で頻発する。 上記の質問を読むと
むむむ » OpenProjとGanttProjectを使ってみた
今ちょうど仕事で新しいプロジェクトを立ち上げて、折角の機会なので何か使ったことのないツールを使おうと思ってみたり。 で、以下の2つをチョイス。 OpenProj GanttProject どちらも総評として言えることが一つ。 人の引いた線を勝手に動かすバグだけは頼むから直してくれ 手戻り多すぎて泣けたよママン。 細かな評価は以下の通り。 OpenProj タスクの管理はやりやすい。0.5日とかのタスクもすいすい作れる。 複数のタスクに一括でリソースの割り当てが可能なのも良い。 WBSやRBSもすぐに作れるのも便利。 開始日を変更すると前後のタスク日付もずれるバグがあり、タスク数が多いほど泣きを見る。 印刷機能は期待すんな。GanttProjectと比べると印刷項目が選択できるのが利点。primoPDFなどのPDF出力ソフトを使用し、A3サイズ出力してからA4にするとかしないと
IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構：ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ
DevOps - mizzy.org - Trac
DevOps: Why Silos Suck And How To Break Them というエントリをたまたま目にして、「DevOps」という見なれない言葉が出てきたので、気になって調べてみたところ、自分が何となくやっていたことや、今までもやもやと考えていたことに一定の方向性が与えらえた気がしたので、整理してみることにします。 DevOps とは？ 簡単に言ってしまうと「開発者と運用者の間の壁を取り払うためのベストクラクティス」と言えそうです。 開発者と運用者の間の壁？ Flickr の中の人による 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr という Velocity 2009 でのプレゼンスライドには「Devs versus Ops」という章があり、以下のような言葉が載っていました。 "It's not my mach
スケジュールが遅れる理由について - suVeneのアレ
プロジェクト管理の中のひとつ、スケジュール管理、或いは進捗管理についての考え方。 その中でも特に、「納期」について。 はじめにプロジェクトを遂行していると、必ずといっていいほど「遅れ」が出てくるものである。それは何故なのか。どうすればよいのか。を、個人的な観点で、今の考えを整理。主にソフトウェア開発。 スケジュール管理についてスケジュールは遅れるものであるまず、スケジュールが遅れるのはなぜか。 納期・計画がそもそも無理度重なる仕様変更が抑えきれない立ち上げが遅く、各フェーズ開始時には、既に○ヶ月遅れだったなどなど。 このなかで、一番最初の「納期・計画がそもそも無理」は、個人の努力ではなかなか改善しようがない部分が多いが、「ある程度バッファがある」と思っていたプロジェクトですら、いつの間にか「遅れ」が出てくるものである。 これは何故なのか。 それは、従属関係にあるタスクというのは、そのタスク
ハタさんのブログ : Javascriptによる大規模開発の覚え書き
未だに半年前のエントリにブクマされるみたいなので、もう少しjavascriptについて書いてみる。 今回は大規模化開発におけるJavascriptの注意点とかそういうの。当てはまらない環境の方もいます。(しかも基本的な事だらけで大したことは書いてないです) ほぼリッチクライアントを主目的としたjavascripterとコードを対象とします。 どちらかというと、ライブラリを提供する側の視点から 1.ログを出力せよ あなたが書いたコードは遅い、と必ず言われます。なので言われる前から、自分の書いたコードの処理時間をログするようにしましょう。 次のような処理時間を計測するロガーを作ります。 var TraceLog = function (){ this.startTime = -1; var outer = document.getElementById('_outer'); if(oute
FP法で業務モデルを計測する - プログラマの思索
児玉公信さんの本「システム開発の見積りのための実践ファンクションポイント法」を読んで、ファンクションポイント法を業務モデルの計測に使えないか、考えてことをメモ。 ＃まとまっていないので、あくまでもメモ書き。 ファンクションポイント法(FP法)は、機能の規模の見積もりとして古くから知られている。 しかし、計算が複雑で、見積もりの根拠となるモデルが曖昧なため、普及しているとはいえない。 「システム開発の見積りのための実践ファンクションポイント法」で興味深いと思った点は下記の通り。 【1】業務設計やシステム提案という早い段階で、概算の工数見積もりを出す道具として、FP法を使うこと。 FP法を使うタイミングとしては、RFPによる提案やシステム化構想、業務設計など、プロジェクト計画書を作る段階を想定している。 実際の業務設計では、顧客の現行業務と新業務の二つのモデルを作り、システム化の利点をアピール
TestLinkのベストプラクティス集 - プログラマの思索
TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。 あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所 TestLinkのFAQ: プログラマの思索 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】ブロック テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッ
社内Wikiや社内SNSや社内リポジトリがある : インフラエンジニアに成る
情報共有ってテーマが社内で叫ばれるこんにち。 グループウェアだ！って時代があったように せっかくITツールがいろいろあるんだから 試そうぜって風潮が企業にあっように思う。 社内ブログとか社内SNSとかWikiとか。 でも、これってトップダウンでやらないと なかなか浸透はしない。 たとえ、Wikiであっても難しい。 基本的には全員を巻き込んで参加させないと 全く意味がないからだ。 一人でも面倒くさがったら終わり。 成り立たない。 前社で体験したWikiの活用方法の話。 ちゃんとやっているところはきれいに情報が整理されていた。 もちろん、全員参加。 Wikiのメリットを生かした情報共有をしていて 使わなければいけないと徹底していた結果成り立っていた。 うまくいっていないところは参加者がまばら。 未整理な情報が適当にWikiに並べられる。 そのうちまばらな参加者もWikiを使わなくなる。 結局、
はてなブログ | 無料ブログを作成しよう
セメントドリンク、ブラウン管、吊るされた収納、OMORIカフェ、くり抜き、どや顔の初音ミク パチミラ福岡に出演する縁で博多に行きました。 楽しかったのでその時の写真をアップロードします。 博多駅のハートポスト 手描きのグリッチ カニの丸揚げ(おいしかった) フレッシュセメント という名前の飲み物(おいしかった)ごま+バナナスムージーっぽかった？ 泡系…
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
Sun は Oracle に買収されますが - Blog by Sadayuki Furuhashi
Oracle Buys Sun Overview and Frequently Asked Questions OpenSolaris.orgで進められている数々のプロジェクトは、ぜひ継続して欲しいものです。 "Sun" を偲びつつ。 Hadoop Live CD 仮想サーバー（Solaris Zone）を立ち上げて3ノードのHadoopクラスタを構築する Live CD。もちろんOSはOpenSolaris。 Hadoopを使ったアプリケーションの開発を始めるのにちょうど良さそうです。 Live CD と言えば、知る人ぞ知るBusyboxと同等のものをOpenSolarisでも実装しようというプロジェクトがあるようです： OpenSolaris Busybox OpenSolaris Squashfs Open High Availability Cluster Linuxで言うところの
そろそろバグ管理についてひとこと言っておくか - 平凡なエンジニアの独り言 はてなブログ出張所
ひとことどころか、バグ管理について367ページにわたって書いてしまいました。「実践バグ管理」です。なでしこなどで有名なid:kujirahandさん（クジラ飛行机さんのブログ）との共著です。 実践バグ管理―プロジェクトを成功に導くための 作者: クジラ飛行机,あかさた出版社/メーカー: ソシム発売日: 2009/03メディア: 単行本購入: 6人 クリック: 148回この商品を含むブログ (21件) を見る 本書の特徴 本書の特徴を伝えることには非常に苦労しています。「バグ管理なんて何について書くの？」とかよく言われるわけです。バグ管理のやり方なんてあたりまえ・・・なのかもしれませんが、大抵のプロジェクトに参加すると以下のような現象に遭遇するものです。 Tracなどの運用を始めると、「バグレポートに何を書けばいいのか？」と質問される バグレポートに書かれている内容が意味不明 とある案件では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitとSVNに対応可能なプロジェクト管理ツール「Springloops」 | Web活メモ帳
Home | Serena Open Source and Hosted Project Management Software