Developers Summit 2014 【13-D-7】 コミュニティLT - Story 5. 「新人技術者にどうプログラミングを教えたか」Fujio Kojima
少ない手間と知識でそれなりに見せる、ズルいデザインテクニック with Sass / Compass (English Version) https://speakerdeck.com/ken_c_lo/zurui-design-technique-english-version 第一回…
前回([id:rabbit2go:20080601:1212326562)に続き、ソフトウェア品質改善委員会に参加。隣の事業部がやっているから、という安直な理由で設置された委員会だが、経験者が揃っているのであーだこーだと議論は盛り上がる。しかし、自分がコードを書いていて時代の技術しか知らず、今の現場で起こっている問題を正しく把握できていなかったりするので、ひたすら空虚な主張が続く。曰く、 設計書のレビューはきちんと行うべきである。 ソースコードのレビューはきちんと行うべきである。 割り込み作業が入って場合、工程の見直しを行うべきである。 仕様変更は関係者の事前合意を得るべきである。 進捗確認はきちんと行うべきである。 そんなことを実践できるのなら、もうやっている。組織の開発体制として、そのような作業が出来ない(許されない)やり方を続けているから、問題が山積み状態になってしまうのだ。そもそも
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く