タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

ProgrammingとprogrammingとProjectManagementに関するatsushifxのブックマーク (5)

  • 泥沼プロジェクト振り返り

    はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない

    泥沼プロジェクト振り返り
    atsushifx
    atsushifx 2015/04/19
    典型的な日本のSIerによるデスマーチプロジェクト。しかも、国レベルで http://d.hatena.ne.jp/JavaBlack/20150407/p1という話なのが泣ける。
  • 開発者の生産性:Noと言える技術 | POSTD

    生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン(超集中状態)に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります: あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題

    開発者の生産性:Noと言える技術 | POSTD
    atsushifx
    atsushifx 2015/04/17
    ピープルウェアで「プログラムは夜できる」と書かれた頃からちっとも変わっていない
  • 【就活】「 プログラミングできなくても大丈夫です!」SIerにはコーディングスキルは必要ない?

    S.ver.1.22474487139 @wtisd17 就職活動で大手SIerの説明会に行った時,学生側は「プログラミングできなくても大丈夫ですか?」としきりに聞き,社員側は「プログラミングできなくても大丈夫です!」としきりに繰り返す日のソフトウェア産業構造において,どうやれば日がソフト面で優位に立てると思うのだろうか. 2014-10-11 19:13:09

    【就活】「 プログラミングできなくても大丈夫です!」SIerにはコーディングスキルは必要ない?
  • ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から

    ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日IT業界の現状をなげく論調にうつった。日を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 --だとすると、日のSI業界というのは将来性があるのでしょうか? わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情

    ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から
    atsushifx
    atsushifx 2013/07/08
    「ピープルウェア」「ゆとりの法則」を読んでからだな。それにアイデアや企画のような知的生産の生産性をどうやって計るつもりなのか。アイデアは数じゃないようにプログラミングも行数じゃない
  • 技術的負債を管理する

    1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す

    技術的負債を管理する
  • 1