タグ

agileとbizに関するyamanetoshiのブックマーク (5)

  • アジャイルと受託開発

    先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの!?というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか?筆者の見解では、たぶんしない。何故か?それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し

    アジャイルと受託開発
  • 42歳の抱負。(現在のソフトウェア開発における3つの個人的課題):An Agile Way:オルタナティブ・ブログ

    先日、5/20で42歳になったので、抱負、というか今ぼくが課題に思っていること、考えていることをいくつかメモとして書いてみます。技術的なことと、ビジネス的なこと、そして人生についてのことがあります。 1.ソフトウェア工学 ソフトウェアアーキテクチャ、および開発方法論はまだまだ進歩過程にあるが、次の2つのことが最近分かってきており、今後より強く浸透していくのではないだろうか。 ・再利用性、という価値観と、変更容易性という価値観が独立し、これら2つの価値観は別個に発展する。オブジェクト指向をはじめとする設計手法は、再利用性という方向では組織・流通・資産化を含んだプロダクトライン、変更容易性という方向ではリファクタリング、テスト駆動、アジャイル、というそれぞれのプロセスを伴った方向に分化する。再利用性は、設計のみならず、知識の再利用がキーとなりパターンのようなコンテキスト情報を含んだ知識流通形態

    42歳の抱負。(現在のソフトウェア開発における3つの個人的課題):An Agile Way:オルタナティブ・ブログ
  • アジャイルレトロスペクティブ――強いチームを育てる「ふりかえり」の手引き (recompile.net)

    訳者である角さんから、『アジャイルレトロスペクティブ――強いチームを育てる「ふりかえり」の手引き』をご献いただきました。ありがとうございます。原稿をおえて、ようやく読了しましたので、感想を書きます。 みなさん、ふりかえりの効用を実感したことがありますか。あまりふりかえりの効用ってないよなあって感じている方は、多いのではないでしょうか。そういう方は、ふりかえりって個人的なもので、最後にやるものだとおもっていませんか。実は、私もそう思っていました。 書では、ふりかえりをイテレーティブでインクリメンタルなものとして再定義します。ふりかえりをチームが共有し、プロセスを改善していく原動力とするのです。 ふりかえりを有意義なものとするためには、その時間をしっかりとした構造を持つものとして導く必要がありますし、その構造にそった適切なアクティビティを採用しなくてはなりません。このには、有意義なふりか

  • 不安定であることの機敏性 (arclamp.jp アークランプ)

    ヒトと機械のあいだ―ヒト化する機械と機械化するヒトという、はい、好きなネタなので読んでみました(w。面白いのは情報の話。 わざわざ不安定化することで機敏になれる そもそも機械的というと単純で融通が利かないものと思われがちです。しかし、変化する状況に応じて柔軟に変化に適応する機械も増えています。その先駆けともいえるのがノーバート・ウィーナーが説いたサイバネティクス。 機械の制御入力を希望の出力と現在の出力を比較しながら調整していくことに関する技術である。 こういったフィードバックによる自動制御はヒトの二足歩行にも関係してきます。足の数は4のほうが安定します。しかし、 わざわざ不安定化し、制御・調整という情報機能を付け加えることによってより高い次元に進化することができるのである。 これを示すものとしてあげているのがNASAが開発した航空機X-29。X-29にはCCV(Control Con

  • 開発者にアジャイルを強制するのは、危険信号:An Agile Way:オルタナティブ・ブログ

    開発者にアジャイルを強制するのは、危険信号だ(Imposing Agile Is A Very Red Flag)とマーチンファウラーが書いた。 http://martinfowler.com/bliki/AgileImposition.html 要約すると、 アジャイルを管理者が押し付けてはならない、それは、 「プロセスとツールよりも、個人と対話に価値を置く 」という価値にも反するし、その背後にある原則である、 「動機付けされた人たちを中心にプロジェクトを構成する。彼らに環境と支援を与え、彼らが仕事を成し遂げることを信じる」、そして、「最高のアーキテクチャ、要求、そして設計は、自己組織化されたチームから創発する」 にも反する。 というのだ。 チームは自発的にウォーターフォール型の方法を選ぶことだってできる。その場合、アジャイルではなくなるだろが、アジャイルはもともと万能ではないのだ。私は

    開発者にアジャイルを強制するのは、危険信号:An Agile Way:オルタナティブ・ブログ
  • 1