開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
漫画を糾弾する、自称科学的な人たち
『美味しんぼ』という漫画の内容に、批判を越えた糾弾と言えるような声を上げる方が多いようです。一部は研究者や医療関係者のようですが、彼らの『科学的』にあり得ないという論を元に一般の方や政治家も糾弾しているようです。 根拠の無いデマを広げる無知蒙昧な人間を、正義感をもって成敗しようとしているように見えます。そこで自明のように語られる科学的知見とは何でしょうか。 管理された実験室での放射線と、無秩序に飛散した複数の放射性物質の影響を同列に扱えるはずもありません。従来の原発事故や大昔の原爆の調査の知見は、規模や内容が違いすぎて十分とは言えないのです。 ある方は粘膜への影響が『噴飯もの』と表現されていました。ごく微細な放射性物質の粘膜への付着による影響などどれほど研究されていたのでしょうか？ましてや人体への影響などそもそも実験が不可能です。また『放射線は量の問題です』と単純化することで、実際には距離
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scala の Future と Haskell の IO
