タグ

アジャイルとマネジメントに関するItisangoのブックマーク (3)

  • 技術なきマネジメントの衰退とその対策 - メソッド屋のブログ

    今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日IT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術

    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
  • アジャイルがダメだと思う7つの理由 - arclamp

    1.全体スケジュールにコミットできない アジャイルはタイムボックス型(一定期間で棚卸しをして、それを繰り返す)のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ

    アジャイルがダメだと思う7つの理由 - arclamp
    Itisango
    Itisango 2013/03/22
    #agile #software #development #批判 。
  • 第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro

    前回,タスクかんばんが,現在の状況を見える化するものであり,先を見通すような視点は持ち合せていないことを説明した。この「先を見通す視点」で「進ちょく状況の見える化」を実現するのがバーンダウン・チャートと呼ばれるチャートである。バーンダウン(burn down:燃え落ちる,全焼する)チャートは,一般的なチャートにありがちな右上がりではなく,右下りになっている。チャートを作成する際には,縦軸に残りの作業量を,横軸に時間を割り当てて日々の残り作業量をプロットしていく。右下,つまり残り作業量がゼロ(=全焼)になれば,すべての作業が完了するというわけだ。 バーンダウン・チャートは,元々リリースまでのバック・ログ(プロジェクトとして実施する必要があるすべての作業)の残量を視覚化するチャートだったが,現在はイテレーション単位でのタスクの残作業量(デイリー・バーンダウン・チャート)の見える化にも使われてい

    第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro
  • 1