名言に学ぶプロジェクト管理 http://www.codeanimato.com/pm/ 「著者たちは”ベストプラクティス”というものを信頼しない。理由は、最適な手法は状況に応じて異なると信じているからだ。ベストプラクティスの名を冠して売り出されている多くのものが、本来ふさわしくないところに無批判で適用されている、その状況を著者たちは憂いているくらいだ。」 「ソフトウェアテスト ２９３の鉄則」より ja Copyright 2007 Thu, 25 Oct 2007 18:41:09 +0900 http://www.sixapart.com/movabletype/ http://www.rssboard.org/rss-specification 考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に 考えは大きく、行動は小さく、失敗するなら早く、学習は迅速に。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-320.html http://www.codeanimato.com/pm/2007/10/post-320.html アジャイル アジャイル Thu, 25 Oct 2007 18:41:09 +0900 リスクは、それに最もうまく対処できる側が持つべきだ リスクは、それに最もうまく対処できる側が持つべきだ。定額契約では、本来顧客が対処すべきリスクが、ベンダーに移されているように見える。問題が技術的に複雑であれば、そのリスクに最もうまく対処できる立場にいるのはベンダーだ。だから、ベンダーがリスクを受けるのが適当だろう。しかし、問題がはっきりしない場合や変化している場合には、顧客がリスクを対処するのに最適の立場にいる。したがって、定額契約は避けるべきリスクである。定額契約が避けられない場合は、変更が入るのは確実なので、コストが決められた額を大きく超えるという事態を顧客自らが招くことになるだろう。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-319.html http://www.codeanimato.com/pm/2007/10/post-319.html アジャイル リスク Thu, 25 Oct 2007 18:39:33 +0900 全体を測定すべきであり、分解して測定すべきではない 全てが測定されるような方法を確実に行うには、全体を測定すべきであり、分解して測定すべきではない。すなわち、測定手段を1段階下ではなく、1段階上へ移動させることだ。ニューコアは、個人ではなくグループの生産性を測定したことを思い出していただきたい。３Ｍは、製品のコストではなく、製品により生み出されるビジネスの利益性を測定する。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-318.html http://www.codeanimato.com/pm/2007/10/post-318.html アジャイル 測定 Thu, 25 Oct 2007 18:37:23 +0900 測定したものしか得ることができない 「測定したものしか得ることができない」という基本原則はこの場合でも成り立つ。重要なものすべてを測定できない場合、部分的に測定すると局所最適な計測手段となる可能性が高い。もし、ビジネス全体としての成果を最大化するのに必要な「すべて」を測定できないのであれば、局所最適化した部分的計測などない方がよい。中途半端な計測手段を持っていると、局所最適な行為を助長する大きな危険にさらされるだろう。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-317.html http://www.codeanimato.com/pm/2007/10/post-317.html アジャイル 測定 Thu, 25 Oct 2007 18:34:58 +0900 コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない 多くの人は、新製品を発表し大きな成功を収めている企業が、製品開発プロジェクトのコストやスケジュールを管理していないと聞くとびっくりする。なぜかって？コストとスケジュールがプロジェクト管理では重要なことである、と思い込んでいるからだ。コストとスケジュールは局所最適化のための計測手段であるということがなかなかわからない。そのうえ、コストとスケジュールに注目すると。究極の目的、すなわち顧客の要求に合致し、競争優位のある利益の高い新製品を開発して商売する、ということが見えなくなってしまう。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-316.html http://www.codeanimato.com/pm/2007/10/post-316.html アジャイル 局所最適化 Thu, 25 Oct 2007 18:32:51 +0900 自動テストスイートは 自動テストスイートは、建築中の大きな建物のようなソフトウエアを仕上げる際に、システムの建築者に安全と通路を提供する足場であるといえる。この足場なしに、他のツールを効果的に使うことはできない。テストを作成すると開発が遅くなるように思えるかもしれない。実際には、テストはコストではなく、開発期間中とシステムライフサイクル全体の両方で利益をもたらす。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-315.html http://www.codeanimato.com/pm/2007/10/post-315.html アジャイル テスト Thu, 25 Oct 2007 18:30:55 +0900 設計をテストとして文書化することで 設計をテストとして文書化することで、開発者はそれがどう動くと想定されているかを正確かつ明快に理解しながらコーディングすることができる。これは、考えを洗練し、開発者がコンセプト統一性を持ってコーディングする助けとなる良い方法である。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-314.html http://www.codeanimato.com/pm/2007/10/post-314.html アジャイル テスト Thu, 25 Oct 2007 18:28:51 +0900 あるモデルが有用かどうかを判断する方法の一つは あるモデルが有用かどうかを判断する方法の一つは、そのモデルが最新に保たれているかどうかを観察することだ。モデルを最新に保って、使えるようにしておくことが重要であると信じている人がいるが、私たちはその逆だと思っている。モデルが有用でなくなれば、メンテナンスされなくなるはずだ。一時的に役立つモデルを作り、それが最終的に使われなくなるのはかまわない。しかし、ただそれがいい考えのように思えるからというだけで、モデルを作ってメンテナンスをするのは、ムダである。モデルが熱心に参照され、メンテナンスされていたら、有用なモデルを編み出したということがわかる。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-313.html http://www.codeanimato.com/pm/2007/10/post-313.html アジャイル モデル Thu, 25 Oct 2007 18:27:09 +0900 どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ 伝統的には、要求は文書化され、アナリストのチームに手渡されるものである。そして、分析を行い、その結果を設計者に手渡す。設計者はソフトウエアを設計し、その結果をプログラマに渡す。どのようなコードにするかについて、日々の決定を行うのはプログラマなのだ。彼らはシステムの統一性について、顧客がどう受け取っているのかを理解した段階から、ドキュメント2,3個分離れている。そのドキュメントを引き継ぐたびに、かなりの量の情報が失われたり、誤解されたりする。最初から理解されていなかった詳細部分のキーポイントや将来の機能については言うまでもない。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-312.html http://www.codeanimato.com/pm/2007/10/post-312.html アジャイル プログラマ Thu, 25 Oct 2007 18:25:14 +0900 チーフエンジニアの役割は チーフエンジニアの役割は、その車の設計が見えてきたら、最大の認知統一性を持たせられるようにトレードオフを判断できる環境を作ることなのだ。だから、チーフエンジニアは、エンジニアたちが多くのトレードオフと闘う中で、何に苦戦しているのかを理解しなくてはならない。そして、自分たちの決定がどのように製品の統一性に影響するかを、彼らが理解できるように手助けをするのだ。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-311.html http://www.codeanimato.com/pm/2007/10/post-311.html アジャイル チーフエンジニア Thu, 25 Oct 2007 18:18:12 +0900 人は、自分が置かれた組織の期待にこたえるものだ 人は、自分が置かれた組織の期待にこたえるものだ。プロセスやドキュメント、計画の厳守に価値を置く組織では、ソフトウエア開発のリーダーは、多くは生まれてこないだろう。組織が自らの価値を定義すれば、その価値にあったものが手に入る。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-310.html http://www.codeanimato.com/pm/2007/10/post-310.html アジャイル 組織 Thu, 25 Oct 2007 18:16:33 +0900 モチベーションをくじかせる、最も簡単な方法の一つは モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神（zero defects mentality）と呼ばれているものだ。ゼロ欠陥精神は、絶対にミスを許さない雰囲気のことである。つまり、どんな些細なことにでも完全性が求められる。軍隊では、ゼロ欠陥精神をリーダーシップの深刻な問題であると考えている。なぜなら、それが戦場での成功に必要な率先力をそこなうことになるからだ。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-309.html http://www.codeanimato.com/pm/2007/10/post-309.html アジャイル モチベーション Thu, 25 Oct 2007 18:14:58 +0900 ある環境から別の環境へのプラクティスの移植は、間違いである場合が多い 私たちは、ある環境から別の環境へのプラクティスの移植は、間違いである場合が多いと、確信している。そうする代わりに、プラクティスの背後にある基本的な原則を理解し、それらの原則を、新しい環境に合わせた新しいプラクティスに置き換えなくてはならない。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-308.html http://www.codeanimato.com/pm/2007/10/post-308.html アジャイル プラクティス Thu, 25 Oct 2007 18:12:57 +0900 やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている ワッツ・ハンフリーは、CMMの初期開発を先導した人物だ。彼は、訓練された、やる気のある人材がいなければ、ソフトウエア開発が成功することはない、と信じている。私たちはこの意見にまったく賛成だ。しかし、その「最も成功を収めやすい」というプラクティスには、敬意は払うが反対する。・・・私たちは、やる気に重要な要素は計測ではなく、権限委譲（empowerment）であると信じている。つまり、決定権を組織のできるだけ下位のレベルに移し、それと同時に、その人たちの聡明な決定能力を開発することだ。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/empowerment.html http://www.codeanimato.com/pm/2007/10/empowerment.html アジャイル 権限委譲 Thu, 25 Oct 2007 18:11:03 +0900 スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ 急な事態では、情報が指揮系統のチェーンを上がり、そして指示として下す余裕はない。そのため、現場での情報伝達とコミットメントの方法を、それにふさわしいものに作り変える必要がある。そのために重要な要素の一つは、スケジュールによって作業を進める（プッシュする）のではなく、顧客のニーズが作業を引っ張る（プルする）ことだ。

 

「リーン　ソフトウェア開発」

]]> http://www.codeanimato.com/pm/2007/10/post-307.html http://www.codeanimato.com/pm/2007/10/post-307.html アジャイル アジャイル Thu, 25 Oct 2007 18:09:25 +0900