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