「クマデジタル」さんから、お忙しい中、わざわざお返事エントリーをいただいたので、
私も追記エントリーしてみることに。
デジタル家電の開発環境、私も一時期、某社で携帯電話の組み込み
ソフトウェアの開発をやったことがあるので、多少は理解していたつもりでしたが、
予想以上に激しい環境なようで…。
まぁ、私の場合、そういう「力業で自転車操業」な会社も経験済でして、
転職しつつ、安住の地を求めてさまよった(?)という過去もありますが。(苦笑)
幸い、今の会社では、世界を相手に戦えていますし、アメリカのソフトハウスとも
いっしょに仕事していますが、だいぶその良さ、悪さを補い合える準備が
整いつつあるといえるかと。
それはともかく、そういった短期で「高速回転」が必要なレーシング仕様(爆)な
開発には、「エクストリームプログラミング」が向いているのではないかと。
これもさんざん取り上げられて有名なので、詳しい説明は他のサイトに
譲りますが、コーディングとテスト重視で、フィードバックによる再設計を
大胆におこなうところが、画期的だと感じています。
また、XPの必須条件ではないですが、開発者が2人でプログラムソースを
共有して開発を進めていく「ペアプログラミング」も、プログラマの成長を促す
良い仕組みだと思います。
「40時間労働」なんてのは、まぁ日本の実勢には則さないとしても、
うまく取り入れるべき「エッセンス」が含まれた技法だと感じています。
本としては、「XPエクストリーム・プログラミング適用編」あたりが
概念を掴む上ではよろしいかと。
 |
XPエクストリーム・プログラミング適用編―ビジネスで勝つためのXP ケン アウアー ロイ ミラー Ken Auer ピアソンエデュケーション 2002-08 by G-Tools |
あと、「12,000項目のテストをやるのに７日必要です」とのことですが、
これってきっと回帰テストですよね？＞クマデジタルさん
ここで影響範囲を絞り込んで、いかに無駄なくテストするか、っていうのが
実は品質向上のキーポイントだと、良く言われることかと。
まぁ、そのあたりは「HAYST法」あたりが参考になろうかと。
とはいえ、会社の一員として品質管理に関わる限り、なかなか組織にまでは
手が出せるものではありません。
ただ、自分でできる範囲の手段を取り、良いものは啓発していくだけでも
結構、組織って変わるものだと、私の経験では感じている次第です。
久々にお堅い話題を書いてみましたが、所詮、「なんちゃってプログラマ」の
たわごとですので、あまり本気にされませんように。(^^;＞みなさま