Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
t-wadaのブックマーク / 2005年7月28日 - はてなブックマーク
[go: Go Back, main page]

タグ

2005年7月28日のブックマーク (9件)

  • IT屋のトヨタ生産方式:An Agile Way:オルタナティブ・ブログ

    『実践!!IT屋のトヨタ生産方式―あるソフトウェア会社の挑戦』 http://www.amazon.co.jp/exec/obidos/ASIN/4833151472/xpjp-22 アマゾンにも並びましたね。いやー、熱いです。 最初のページをめくると、そこにはVMボード(ビジュアルマネジメントボード)がたくさんあります。とにかく「見える化」です。ぼくもお邪魔してアジャイル開発のコンサルをさせてもらってましたが、トヨタ生産方式とアジャイルって、実は同じことを言っていることが多いんですよ。そして、「改善塾」という中堅社員の巻き込み方はとても参考になります。 やっぱい、ものづくりは、人づくりなんですね。

    IT屋のトヨタ生産方式:An Agile Way:オルタナティブ・ブログ
  • kuranukiの日記 - 計画書を作るということ

    管理職になってから、社内向けの資料を作る機会が多くなりました。その傾向は、上に行けばいくほど、強くなっている気がします。 なんたら計画書とかね。計画だか、スキームだか、ロードマップだかね。自分のアイデアを会社のお金で実現しようというのだから、当たり前の話ですよね。会社が大きいとなおさら、説得の相手が多くなるので大変です。 ただ、計画書を作るのも、そんなに悪いことばかりではないんです。自分の頭の中にしかないものを、紙に(実際にはエクセルかパワポに)落としていく段階で、検討が練られますし、リスクも見えてきます。また、内容の『わかりやすさ』も非常に重要になってきます。それは、その計画書を使って、上司がさらにその上に対して説明するのに使うからです。そのためには、なるべくわかりやすくなければいけない。わかりやすい計画書にしようとすることで、アイデアもさらに洗練されていきます。 さて、アジャイルだと、

    kuranukiの日記 - 計画書を作るということ
  • http://log.giantech.jp/837

  • リファクタリングとTDD - ひがやすを技術ブログ

    リファクタリングは、あまりリファクタリングのことを知らない他人もしくは過去の自分が書いたコードが健全になるように修正するもので、今自分が書いてるコードのためのものじゃないと個人的には思います。 自分でコードを書いているんだったら、最初からリファクタリング不要なコードを書けばいいからです。人は、コードを書いたそばから忘れていくものですから、コードを書いているときが一番コードについて分かっているはずです。後から思いつくことも当然あると思いますが、そのようなケースはそれほど無いんじゃないでしょうか。 もし、後から思いつくことが多いとしたら、最初にコードの意味を理解して書いていないためではないでしょうか。 テストを書けば、書いたコードの意味を確かめることができます。コードの意味を理解していれば、最初からリファクタリング不要なコードを書けるのではないかと思います。 私が後からコードを変えることがある

    リファクタリングとTDD - ひがやすを技術ブログ
  • 失敗プロジェクトを繰り返さないために:ITpro

    コスト最優先で力量が定かでないSIベンダーにシステム開発を発注。結果としてベンダー側の経験/技術不足がたたり,システム・テストで「レスポンスが5分以上も返ってこない」「バッチ処理が異常終了する」などのバグが多発した──(某メーカーの人事システム) いい加減なフィット&ギャップ分析しかせず,どんぶり勘定で開発費を見積もりプロジェクトをスタートさせたことで,10億円以上の追加負担が発生。ユーザー側の猛抗議にあい,追加コストの大半はベンダー側が負担するはめに──(某金融業のERPシステム) ベンダー側の担当SEが立て続けに2回交代。担当者間でRFP(提案依頼書)の内容や合意事項が全く引き継がれておらず,度重なる手戻りで稼働時期が7カ月も遅延──(某製造業の生産管理システム) 繰り返されてきた失敗プロジェクト システム開発の現場では,今日もまた失敗が繰り返されている。その原因の質を突き止めたい─

    失敗プロジェクトを繰り返さないために:ITpro
    t-wada
    t-wada 2005/07/28
  • Think difficult.

    名前のない世界 外崎さんとこがしばらくお休みなので、 その間にシコシコ更新して失いかけた(失い切った?)読者を取り戻そうと思っていたのだが、 こんなものを作らされたりしていてちょっと遅くなってしまった。 面目ない。 さてさて、今回はちょー真面目にインターフェースの話をするのである。 そしてそのテーマは、「名前」である。 ちょっと頭が痛くなる人もいるかもしれんが、がんばって読んで欲しいもんである。 なんでコンピュータを使ってると虚しくなるのか、多少はわかるかもしれない。 コンピュータを使っていると、とにかくいろいろな場面で名前をつけさせられる。 ファイルを保存する時にもそう。ネットワークにマシンを接続する時もそう。 OSによっては、まず自分につけられた名前を宣言しないと相手にもしてくれない。 メールアドレスだってウェブのURLだって名前の一種だ。 いま自分のいる部屋を見回してみて、自分が普段

    t-wada
    t-wada 2005/07/28
  • http://d.hatena.ne.jp/swat/20050311

  • Agileに計画はいらないか?!:An Agile Way:オルタナティブ・ブログ

    アジャイル、って「オヤジ語」に直すと、PDCAなんです。Plan-Do-Check-Action。上司に「アジャイルでやりましょう」というと煙たがられる(あるいは理解されない)場合は、「PDCAをちゃんと回したいんです」と言ってみよう。「おお、君もようやく一人前になったな」と褒められること、請け合いです。 計画をつくるということ↓ http://d.hatena.ne.jp/kuranuki/20050728 そういう意味で、計画は大事。しかし、計画と言う言葉は、後で変更しづらい、あるいは、計画通りにやることが正しい、という「間違った」イメージを作ります。APMでは、構想とよび、計画作りのフェーズを構想フェーズ、としています(Vsion と Envision Phase です)。 構想⇒思索⇒探索⇒適応 ↑-----↓ というループ。 実は、トヨタ生産方式では、「進捗管理」は、「計画と実績

    Agileに計画はいらないか?!:An Agile Way:オルタナティブ・ブログ
  • Gmane -- Mail To News And Back Again