WeBLoG

走り書き

デスマーチ

こないだの某所での事をメモしておこう
(※参考は全てリンクになっています　切れている可能性があります)
みなさんお疲れ様でした＆ありがとうございました
抜けていたりすると思うので突っ込んでくれると有難いです
思い出したらまた書き足します．．．

組織の種類

カンパニー制、機能別組織、マトリクス組織について

XP、アジャイル

ペアプログラミングで知識共有、スタートダッシュができる
ペアプロの状態でフローまで持っていけるか？
参考．．．ペアプログラミングとフロー状態 - t-wadaの日記

リーンソフトウェア開発

トヨタの生産方式の応用
顧客と開発の接点を見つける
開発だけ最適化するのではなく全体(営業、要求仕様、開発、マーケティング、販売)の中でボトルネックを最適化する
今までは開発の中のボトルネックを探していた
顧客、営業、開発、広告でスタート時からスパイラルを描いていくのが理想、分割されていると伝言ゲームになる
決定は先に延ばそう　問題先送りというわけではない。決定する幅を持たせよう
参考．．．「リーンソフトウエア開発」 - やまざきのはてなダイアリ

銀の弾丸

TOC、XP、SSM等いろいろ言われているが本質は大体同じようなもの
ボトルネックを探して改善する事を一気にやるのではなく必要最低限、少しずつやる、そして続ける
小さなコストの積み重ねで小さく変えていく　魔法ではない
参考．．．デスマーチが起きる理由-推敲版

技術ミーハー

新しい技術にすぐ流される、「あの本ではこうやってるんです　だから大丈夫です」等
新しい技術と今の自分に必要なものが分かれば差分だけ取り込む事ができ、コストも少なく済む

責任と権限

権限は下へ委譲して、責任は上が取る
しかし… 普通の会社は、権限は上にあって、責任は下に押しつける

変える人と、同じ事をやる人と、何もしない人
- 改革派　現状維持嫌い、とりあえずやり方を変えて力を示したい
- 保守派　今までのやり方でなんとかなってきたのだから．．．
- 受身派　皆でデスマってれば精神的コストは少なくて済む

- 改革派、保守派、受身派．．．均衡が保たれるバランスが丁度良い

境界線が難しい
- 上の人が下の人と同じ視点になる危険性がある

参考．．．“オープンソース型ビジネスマン”の生きる道

開発

技術を売るのか、遊びを売るのか
デバッガ以外にプレイヤも欲しいかも．．．
雑誌で批評されていてもそれは顧客のフィードバックではない
言われたモノをキッチリと!?
仕様と期限と金額を守るのがモラル！？
モノを提供する？カチを提供する？
モノの納入までが責任範囲！？
ユーザに博打うたせる！？
生産性，競争力向上をうたって，最新の足枷をはめる!?
使い続けられるモノを！！
作る時間，かかるお金 vs 使う時間，かぜぐ｜うかせるお金（価値）
各個人のノウハウを抽出して共有する
参考．．．友枝＠ななめねこのpapersアーキテクチャ指向的要求獲得ぷち事例パターンランゲージ風参照

音楽とコーディング

雑音とコミュニケーションをシャットアウト
参考．．．Privacy and Collaboration - Radium Software Development
参考．．．プログラミングと音楽の話 - やまざきのはてなダイアリ
参考．．．プログラミングと音楽の話 - t-wadaの日記

家を建てる話しと一緒

そうしたいなら、これくらいの金額になるよ
顧客満足第一、工務店とSEは近いかな
お客さんが自分の家を自慢できるようにしよう！
参考．．．建築業との置き換え - 全体の設定

１００人で開発できるか？

半分が管理者、混乱するコミュニケーションスレッド
誰が誰だか分からない、インターフェース、アーキテクチャが合わない等

XMLでコーディング

コンパイル時はソースに落としてコンパイル、関数のインデックスだけ見る、差分を残しておける
いわゆるメタテキスト
参考．．．メタテキスト論考 - やねうらお

テストコード

実装コードよりもテストコードの方が大事
テストコードは顧客に近いもの
テストを通すコードはすぐに書けるが設計、実装は時間が掛かる
テストは設計の段階で書かれているほうが良い
テストコード、サンプルコード、注意事項はソース、ドキュメントに書いておく
テストの方が寿命が長い

自動化、ツール等

makefileよりはAnt等の方が楽かも
BTSは結構便利．．．
参考・・・バグトラッキングシステム影舞
参考・・・Mantis