サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
www.marenijr.net
'01.03.09 自らの何を創造性と認めるの?と模索中。書き殴りとキーボードから出てくるインスピレーションと瞬発力を求めて「毎日」という継続性に縋り付くことにしよう。断片をかき集めればおのずと構築される体系。隠れた繋がりを探しつづけること。 最新 | 一覧 658 ウィルスバスターの冒険 スティーブ・チャン、ジェニー・チャン 657 闇の考古学 ミヒャエル・エンデ 656 マネジメント 基本と原則 P.F.ドラッカー 655 自閉症だったわたしへIII ドナ・ウィリアムズ 654 痛みと身体の心理学 藤見幸雄 653 宙返り(上) 大江健三郎 652 ソラリスの陽のもとに スタニワフ・レム 651 母なる夜 カート・ヴォネガット・ジュニア 650 二十歳のあとさき 出久根達郎 649 家守綺譚 梨木香歩 648 カウセリングを考える 河合隼雄 647 子どもの体と心の成長 カロリーネ・フ
Solution 受託開発の罠 プロジェクトを成功させたいのであれば「そこにいて、やることをやっている」者を選ぶことです。 つまり、あなたがすでに知っている、そして信頼している開発者を選ぶのです。 それだけのことなのです。ソフトウェア職人気質は、成果物に対する評判という土台の上に 確立された長期の信頼関係の上に築き上げられるものなのです。 受託開発を行う場合、大抵は、最終顧客と呼ばれる「顧客」と、 SIerと呼ばれる「発注元」と実際にプログラミングを行う「下請け会社」に分かれることが多い。 下請け会社は、「協力会社」と呼ばれることが常なのだが、ここでは「下請け」ということにしておく。 何故か?は、この記事を読めばわかる、と思う。 たとえば、顧客が何か社内システムを作ろう、と思い立ったとしよう。SIer=発注元に営業を受け、 「こんなシステムを作りませんか?」という形で製品の売り込み、そして
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ1ヶ月ほど、私的Webサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね~」と話していたのが、非常~に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数(アクティブな人)が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
Solution 役割分担型プロジェクト運営 ソフトウェアプロジェクトは、さまざまなカルチャーを持つメンバから構成されている、小さな生態系(エコシステム)を設定する。その生態系には以下のような要素がある。 バリアにあたる壁と、泉にあたるオープンスペース 相互作用する亜種としての役割を果たす専門職にいる人 生態系の働きを変える、強い個性を持った個人 概要 受託開発型の中規模から大規模プロジェクトで適用されている役割分担型のプロジェクト運営を考察する。基本的には初期設計段階においてプロジェクトは成功するという確信(あるいは期待)を以って、プロジェクトは進行していく。途中段階あるいは最終段階において、なぜ最初の予想が外れてしまうのかの原因を探り、既に予想が外れた時点(いわゆる火を吹いた状態)においてのフォローアップを考える。 目的 初期計画のずれ、見込み違い、それによる製作&試験期間圧縮による品
MyMy-MyCompany アジャイル開発手法(XP, SCRUM, FDD) ソフトウェア職人気質(教育、人間性、創造性) トム・デマルコ著「ピープルウェア」、「ゆとりの法則」 G.M.ワインバーグ『ソフトウェア文化を創る』シリーズ4巻、「スーパーエンジニアへの道」 オブジェクト指向 TOC制約理論&思考プロセス これらをキーワードにして、ソフトウェア開発&管理を行うためのソリューションを提供します。 HOME | mymy分室(blog) ReadMe 「ザ・ゴール」から「クリティカルチェーン」まで、「ゆとりの法則」から「熊とワルツを」まで、「知識創造企業」から「ナレッジ・イネーブリング」までをひっくるめて、私なりに、スループット会計と制約理論(TOC)というパラダムシフトから、デスマーチ、アジャイル開発手法、xUnit、または、ピープルウェアという考え方、プロジェクト管理という方法
2003/11/25 "what we do-is what you witsh to do." by AQUA
Solution デブサミ2005 レポート デベロッパーの復権 閉塞した状況を打ち破り、開発者が想像の力を取りもどすために、 デブサミは全てのIT技術者を対象に、新しい集いの場を提案します。 今年のデブサミ 去年のデブサミ2004は、トム・デマルコ氏の講演を聴きに行っただけだった。あれから、アジャイル関係の本を通読し続けて、どうやらプロジェクトマネージメント関係の本にも手を出さないといけないと思い始め、PMBOK や CMM の入門書を読んだ。デマルコ氏の言う「彼は天才的で、理論もすばらしいけれども、TOC をソフトウェアプロセスに組み込むということは、結局、個人の時間が犠牲になるだけなのだ」という言葉がずうっと頭に染み付いていた。この意見が、正であれ否であれ、考慮しなければいけないと直感的に思い、(大袈裟に言えば)一年間考え続けてきた。 アジャイルとは反対側にある PSP(パーソナル・
Solution 週40時間という見積もり 「変更です」そう言って、彼は説明を始めた。「『顧客は常に正しい』というのが、私の会社のモットーです。顧客が変更を求めるなら、反対はしまんせん。喜んで協力します。実は、変更は多ければ多いほどいいんです。そこまでの段階にいけば、顧客が別の業者に乗り換えることはありませんし、お金も払ってくれます。それもたくさん」テッドは、まるでトップ・シークレットを暴露してしまったかのように、こわばった表情をしている。 概要 週40hという見積もりを利用することによって、プロジェクトを80%の確率でスケジュール通りに終わらせるマネージメント手法を論じる。 内容 部分見積もりのセーフティを使わず、50%の確率で成功する見積もりを立てる。 (現在は80%の確率を考えているので、これらの部分をプロジェクト・バッファに移す) この見積もり時に、h数(時間単位)ではなくて、w数
Solution スループット会計とソフトウェア開発工程の関係 We are what we're supposed to be-illustions of your fantasy All dots and lines that speak and say-what we do-is what you wish to do We are the color symphony-we do the thins you want to see Frame by frame-to the extreme はじめに 設計・製作・試験という工程 ウォーターフォール方式再論 製作工程に注目 工場の生産ラインと比較 生産性をアップするということ フィードバックという考え方 設計工程のフィードバック 製作工程のフィードバック 試験工程のフィードバック サイクル式のソフトウェア開発工程 はじめに 既に「クリ
概要 トム・デマルコ氏の講演を聴きに行き、効率化によってゆとりがなくなり、自由で新しい発想が阻害されることを改めて感じた。他の企業との競争に打ち勝つためには、効率化を行い、人員を削減し、作業期間を短縮することによって短期納入と投資額の減少を求めようとする。 〈効率化〉により、私達(あるいは私自身)は何を求めているのか、また、〈効率化〉により、将来的に 何を得る(あるいは失う)ことになるのか、を再考する。 内容 まず、企業(あるいは個人)が効率化によって求める事柄を列記する。 「効率化することによって、何がよくなるのか?」 面倒で煩雑な作業から解放される 単純労働から解放される 自動化することによって人手による間違いが激減する 効率化すると、作業時間が減るので、短納期が達成しやすくなる 効率化すると、作業時間が減るので、人件費が減り、全体の金額が減る 効率化すると、作業時間が減るので、他に使
このページを最初にブックマークしてみませんか?
『marenijr's homepage』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く