タグ

pmに関するkataのブックマーク (40)

  • へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog(ブログ)

    2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Googleエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Googleプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同

    kata
    kata 2007/06/07
  • Martin Fowler's Bliki in Japanese - 朝会のパターン:立ってるだけじゃないよ

    朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく

  • Geekなぺーじ:こんなプロジェクトは嫌だ

    プログラマとしての立場で、どんな開発プロジェクトが嫌か考えてみました。 個人的な偏見満載で、とりとめもなく羅列してしまいました。 なお、フィクションですのでご注意下さい。 書いてから自分で見直すと結構酷いかも知れないと思い始めました。 あらかじめ、言っておきます。ごめんなさい。

    kata
    kata 2007/01/19
  • いいアジャイルと悪いアジャイル

    スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

    kata
    kata 2006/10/19
  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、

  • プロジェクト管理機能付きグループウェア「TUTOS」 - GIGAZINE

    オープンソースで開発されている日語化済みのプロジェクト管理機能付きグループウェア。バグトラッカーも付いてます。メイン画面はカレンダーベースで、アドレス帳、ToDo、タスク、請求書作成、タイムトラッキングなどが可能。 実際に試用できるデモが以下のアドレスにあり、日語化されている状態でログイン可能なので試してみるのがオススメです。 TUTOS Homepage / Status http://www.tutos.org/homepage/status.html 画面は以下のような感じ。大体何ができるか把握できます。 動作環境はPHP4か5。データベースはPostgreSQLMySQLOracle、Borland Interbase 5のうちから1つ選びます。 公式サイトは以下。 TUTOS Homepage http://www.tutos.org/homepage/index.htm

    プロジェクト管理機能付きグループウェア「TUTOS」 - GIGAZINE
  • Bridge Word

    This shop will be powered by Are you the store owner? Log in here

  • 道具箱の整理

    はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ1ヶ月ほど、私的Webサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね~」と話していたのが、非常~に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数(アクティブな人)が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、

  • http://mozaic.lolipop.jp/archives/000370.html

  • KPTを使ったプロセス改善(2):An Agile Way:オルタナティブ・ブログ

    Issue … Problem質化。問題を見つめ、質的「課題」としたもの。「5回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK(ケプターク)と言う名前でKPTの拡張として、Alistairに提案したところ、「日人はカイゼン慣れしてるな~」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl

    KPTを使ったプロセス改善(2):An Agile Way:オルタナティブ・ブログ
  • マイルドなアジャイル開発手法 AMOP | オブジェクトの広場

    今回は, アジャイルモデリングを実践するためのベースとなるアジャイル開発手法として筆者らが考案したAMOP (Agile Method for Ordinary Projects) [1] という開発手法を紹介します. AMOP は, 既存の開発のやり方に慣れた開発者や管理者に受け入れられやすいものであることを目指したアジャイル開発手法です. 今回の記事では, まずスクラム [2] の短所や難しい点を説明し, 次いでそれらを XP (eXtreme Programming) [3] のプラクティスでどのように補おうとしたかについて説明します. さらに, AMOP を2つのプロジェクトに適用した結果を紹介します. 1. スクラムの短所や難しさ 前回の記事では, もっともシンプルで取り入れやすいと筆者が考えるアジャイル開発手法スクラムを紹介しました. その記事では, スクラムの長所を中心に説明

    マイルドなアジャイル開発手法 AMOP | オブジェクトの広場
    kata
    kata 2005/10/23
  • アジャイルなソフトウェア開発とは | オブジェクトの広場

    同僚の協力もあり 2002 年にアジャイルモデリング ( AM ) 日語リソースサイト [1] を開設し, 2003 年に AM [2] を刊行して以降, 筆者にとって「 AM の適用事例を作る 」ことが大きな課題として残されていました. 幸いにも, 2003 年から社内開発でアジャイルなソフトウェア開発を適用する機会を得るとともに, 2004 年にはお客様からアジャイルなソフトウェア開発のプロジェクトのお手伝いを依頼されたり, 社内開発で AM を実践する機会を得ることができました. 読者の皆さんが AM を学ぶ際の参考となることを目指して, 今回から数回の連載で AM を実践するために筆者が勉強したり, 考えたり, 実践したことを紹介させて頂こうと考えています. とりあえず, 今回は AM の土台となるアジャイルなソフトウェア開発について説明します. 1. アジャイルなソフトウェ

    アジャイルなソフトウェア開発とは | オブジェクトの広場
    kata
    kata 2005/10/23
  • スクラム組んで開発しよう! | オブジェクトの広場

    今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.

    スクラム組んで開発しよう! | オブジェクトの広場
    kata
    kata 2005/10/23
  • SuperAscii02

    kata
    kata 2005/10/17
    Smalltalkでの開発プロセス
  • http://www.lostway.org/~tko/cgi-bin/bakagaiku.rb?bakaid=200509082

    kata
    kata 2005/09/09
    プログラマがアジャイルを求める理由
  • 開発の現場

    「開発の現場」休刊のお知らせ 諸般の事情により、vol.012 をもってしばらくお休みさせていただくことになりました。 これまでご愛顧くださり、誠にありがとうございました!

    kata
    kata 2005/09/08
  • デスマーチ

    This guide is the safest way to do a domain switch, you get all you need to change a blocked domain. What is a user flow and a user journey? There’s a macro view of a customer experience that we can analyze and partially control.

    デスマーチ
  • 極北データモデリング: IE問題の解決

    経営工学者・川瀬武志氏の数少ない、しかし圧倒的な内容の著書。 「マネージャと一般社員を分けて、前者が後者を管理する体制」を徹底的に攻撃している。 こので明かされている経営の秘密の一つを書いておくと... 工員に業績に連動したボーナスを払うことは、会社の金の使い方としては効率が悪くもったいないことだ。 いちばんいいのは ラインの仕事を減らして、例えば4時で仕事が終わるようにする。4−6時は業務改善に使わせる。 改善によって、4時で終わる仕事が3時半−3時 ... とだんだん早く終わるようになってくる。ここで、仕事を増やして余裕を取り上げてはならない。 午前中で仕事が終わるようになったら、ラインの工員に臨時ボーナスを払う。そして、また4時までかかるように仕事を増やす。 1に戻る。 この金持ちサイクルに工場を乗せることだ。 このサイクルでは、永続的な改善効果に対して、報償を1回だけ払っている。

    極北データモデリング: IE問題の解決
  • リーダーシップは天性ではない

    連載内容のおさらい まずは連載内容のまとめとして、それぞれの連載内容の要約と、「どのような人が、どのようなときに読むと効果的か」を説明します。もちろん連載内容は、初回から順次読むと効果的なように組み立ててありますが、それぞれの回を単独で読んでも、なんらかの気付きがあるはずです。 第1回 開発者からリーダーへの視点の切り替え 連載初回は、プロジェクトリーダーが持つべき価値観と、従うべき原則論について説明しました。メンバーとリーダーでは全く違う視点を持つ必要があり、これらの切り替えが最も難しい課題となります。いままで何回かリーダーの経験があるけど、どうもチームがうまく機能していないと感じるリーダーは、まずは初回から読み進めてください。 第2回 なにはともあれ、まずはチームビルディング リーダーにとって、チームビルディングは最も重要な活動の1つです。第2回は、プロジェクトチーム計画書作成を通じて

    リーダーシップは天性ではない
    kata
    kata 2005/08/25
  • [結] 2005年8月 - 結城浩の日記 - テストが困難な性質

    目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日

    kata
    kata 2005/08/24