スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

見積手法


 Cohnは[Coc04]フィボナッチ数を使ってタスクの大まかな見積もりを作る方法を提案している。タスクには1,2,3,5,8,13,21,34,55,89…といったサイズがある。今まで正確な見積もりをしてきた実績のあるチームなら、21までのフィボナッチ数と40,60,80,100の4つの数を使って大きさを見積もる。

Johanna Rothman(でびあんぐる)『Manage It! 現場開発者のための達人式プロジェクトマネジメント』オーム社、2008年、第5章



 見積事態が正確ではなく、あくまで予想なので、このフィボナッチ数を使うのは非常に良いアイディアだと思います。
即ち7と思うのだったら5か8どちらがいいか考え8にするといった具合です。


 このフィボナッチ数を利用した面白い見積ゲームがある。
その名も「計画ポーカー
計画ポーカー

 これは、複数人で見積を行い、同時にフィボナッチ数のカードを出し合いサイズを決定するゲームです。
ここで注意するのが、平均を取ったりしないことです。
全員が不満のない数字になればよいのであって、全員が合意する必要がないことです。
計画ポーカーは見積が難しい場合に有効な手段ではないでしょうか。
スポンサーサイト

テーマ : プログラミング
ジャンル : コンピュータ

性格

プログラマに向いている性格とは、どのようなものなのでしょうか?
 プログラミングにおいて必要とされる性格上の特徴のうちでも、もっともたやすく見わけがつくのは、多少ともきれい好きだ、とうことである。

 プログラミングにとって不可欠なもう一つの性格要因は、せめて少しばかりの謙虚さを持ち合わせていることである。

ジェラルド・M・ワインバーグ(木村 泉)『プログラミングの心理学-または、ハイテクノロジーの人間学25周年記念版』毎日コミュニケーションズ、2005年、第8章

きれい好き
これはソースコードのきれいさに結び付くものだと思います。
雑であるのは致命的です。

謙虚さ
プログラミングの世界は日々新しい技術がうまれ、技術進歩の速い分野です。
その技術を一人で全てマスターするのは不可能でしょう。
謙虚な気持ちで教わる素直な気持ちが大切だと思います。

テーマ : プログラミング
ジャンル : コンピュータ

ものつくりのセンス

 同じ物を違うプログラマに作らせたら、ほぼ100%ソースコードは違ってくる。
何故なのでしょうか?

 それはソースコードが芸術作品であるからだと、私は思っています。

 絵画を例にしてみると、上手い人もいれば、下手な人もいる。
下手な人同士でも違う絵を書くし、上手い人同士もそうです。

 『ハッカーと画家』で良いデザインについて次のように語られています。
良いデザインは単純である。
良いデザインは永遠である。
良いデザインは正しい問題を解決する。
良いデザインは想像力を喚起する。
良いデザインはしばしばちょっと滑稽だ。
良いデザインをするのは難しい。
良いデザインは簡単に見える。
良いデザインは対称性を使う。
良いデザインは自然に似る。
良いデザインは再デザインだ。
良いデザインは模倣する。
良いデザインはしばしば奇妙だ。
良いデザインは集団で生起する。
良いデザインはしばしば大胆だ。

Paul Graham(川合 史郎)『ハッカーと画家 コンピュータ時代の創造者たち』オーム社、2005年、第9章


 コーディングも芸術作品を作っていると意識すると、また違ったものになるのではないでしょうか。

テーマ : プログラミング
ジャンル : コンピュータ

言葉の魔力

 前回の記事でリファクタリングについて話しました。
不吉な兆候の一つで「重複したコード」という項目があり、
プログラマであれば、誰もが「」だと思っているはずです。

 この「悪」に対して使える言葉があります。
DRY [Don't Repeat Yourself] 繰り返しを避けること
レビューしているときに「それってドライ!」というような使い方をします。

 DRY原則を破るということは、同じ知識を2ヶ所以上に記述することです。
この場合、片方を変更するのであれば、もう片方も変更しなければならないのです。
さもなければ異星人のコンピュータのようにプログラムは矛盾につまづくことになるのです。
これはあなたが憶えていられるかどうかという問題なのではありません。
これはあなたが忘れてしまった時の問題なのです。
...
我々はこれが達人プログラマーの道具箱の中にある道具のうちで最も重要なものの一つであると考えています。

アンドリュー・ハント(村上 雅章)『達人プログラマー-システム開発の職人から名匠への道-』ピアソン・エデュケーション、2000年、第2章


 言葉が使い慣れてくると、実際にコーディングしながらも、「これってドライかな?」などと独り言が始まります。
「重複したコード」ではなしえないスキルアップです。

テーマ : プログラミング
ジャンル : コンピュータ

匂うコード

 デジタルデータであるソースコードが異臭を発するわけはないですが、
リファクタリングの「きっかけ」を匂いの比喩で表す言葉です。

リファクタリングとは
ソフトウェアの外部的振る舞いを保ったままで、内部の構造を改善していく作業

マーチン・ファウラー(児玉 公信)『リファクタリング プログラムの体質改善テクニック』ピアソン・エデュケーション、2000年

 上記の書籍では、この匂うコードの不吉な兆候について次のものだとしています。
・重複したコード
・長すぎるメソッド
・巨大なクラス
・多すぎる引数
・変更の発散
・変更の分散
・属性、操作の横恋慕
・データの群れ
・基本データ型への執着
・スイッチ文
・パラレル継承
・怠け者クラス
・疑わしき一般化
・一時的属性
・メッセージの連鎖
・仲介人
・不適切な関係
・クラスのインタフェース不一致
・未熟なクラスライブラリ
・データクラス
・相続拒否
・コメント

 既に存在する匂うコードをいつリファクタリングすればよいのでしょうか?
臭いものに蓋をする」という言葉もありますが、何の解決にもならず状況は悪化するでしょう。
割れ窓の原理」というのがあって、窓ガラスが1枚割れて放置していると、
どんどん割れていく現象を匂うコードを放置すると状況がさらに悪化することに例えています。

 私が愛用している言葉に「ボーイスカウト精神」というものがあります。
私はボーイスカウトではありませんが、ボーイスカウトはキャンプなどで行った先では、
元の状況より綺麗にしてその場を去る教えがあるそうです。
これにならって、コードを追加したのならば、一ヶ所でもいいからリファクタリングをしてコミットするようにしています。
これにより「割れ窓の原理」を防止しています。

テーマ : プログラミング
ジャンル : コンピュータ

35歳定年説

一人前になる前に技術の第一線から退いてしまい、新たな技術を学ぶのをやめたり、創造する活動をやめたりしてしまう人が多いのではないでしょうか。

柴田芳樹『プログラマー現役続行』技術評論社、2007年、第1章

 一人前のプログラマになるには一生懸命に努力して10年を要するといわれています。
大卒で22歳、ここから10年で32歳、死に物狂いで勉強できますか?

 殆どの一流といわれる人は、天才ではなく、努力の積み重ねで築いた地位です。
しかし、彼らは、努力を努力と思っていないのでしょう。
新しい技術を習得するのが楽しくて仕方ないのです。

 では、どうしたら新しい技術を習得するのが楽しくなるのでしょうか?
それに、まず基本的な技術をしっかりマスターすることでしょう。
いきなり新しい技術を得ようとしても、理解できないことばかりで面白くありません。
基本的なことが分かっていれば、理解できるものが多くなり、創造を刺激して楽しくなります。
上辺だけの技術ではなく、しっかりとした基本技術を身につけましょう。

 厳しい言い方をすれば、
 「Love It or Leave It」 (情熱を持ちなさい、さもなければ、去りなさい)

苦しい思いを定年までするより、新しい道を探した方が得策だと思います。

テーマ : プログラミング
ジャンル : コンピュータ

プレッシャーの代償

リスターの法則
 人間は時間的なプレッシャーをいくらかけられても、早くは考えられない

トム・デマルコ(伊豆原弓)『ゆとりの法則 誰も書かなかったプロジェクト管理の誤解』日経BP社、2001年、第7章

 知的労働者にとってプレッシャーほど悪なものはない。
考える速さが変わらないとしたら、労働者は次の方法を取るだろう。

1.無駄な時間をなくす
2.クリティカルパスにない仕事を後回しにする。
3.夜遅くまで仕事をする

 この方法は全て健全にみえますか?

私はどの方法も取りたくないと思っています。

「1.無駄な時間をなくす」について
現状の作業で無駄な時間がありますか?
知的労働者であれば、遊んでいるわけがありません。
トイレや喫煙所でさえも仕事のアイディアを模索しているのではないでしょうか。

「2.クリティカルパスにない仕事を後回しにする。」
これも、知的労働者であれば、自然とやっていることです。

「3.夜遅くまで仕事をする」
最悪です。そのうち優秀な人材から履歴書を作成し始めるでしょう。

 これでも部下にプレッシャーを与えますか?
適度な緊張感は必要です。人間、直ぐにだらけてしまいます。
しかし、上司のエゴで部下にプレシャーを与えることはパワーハラスメントです。
立派な犯罪です。今すぐにやめましょう。

テーマ : プログラミング
ジャンル : コンピュータ

ハドソン湾スタート

 カナダ北東部にあるハドソン湾会社の1600~1700年代の習慣に由来している。当時のハドソン湾会社は毛皮商人に遠征のための物資を提給していた。毛皮商人たちが必要なものを忘れていないか確認できるように、会社は商人たちにハドソン湾を出て数マイル先の地点でいったん野営させていた。商人たちは、ほんの数マイル先で野営することにより、文明を離れる前に道具や消耗品の忘れ物がないか確認していただけだ。旅を小さく始めることで、遠征を耐え抜く能力を確認していたともいえる。

Johanna Rothman(でびあんぐる)『Manage It!現場開発者のための達人式プロジェクトマネジメント』オーム社、2008年、第4章

 自分にもプロジェクトチームにもまったく経験がないプロジェクトを管理する場合、プロジェクトを見積もる方法にハドソン湾スタートで検討しよう。
 プロジェクトチームが実際のプロジェクトの環境で物事を試行する技法で、試行できるのはできるかぎり小さなものにする。("Hello World"プログラムでも十分かも)4時間以内で完了できることから始め、何かを作ったら、必要なタスクをどうやって見積もるか、前よりも理解しているだろう。理解が少ししか増えていなかったら、短いイテレーションを開始してから決める。
 有利な点として次のものがある。
・自分たちが何かを達成できるという確信をチームが得られる
・いくつかのタスクをどうやって整理すればいいかについても理解が深まる

 プロジェクトマネージャーであれば誰もが、やっている技法ですが、私が気に入ったのはネーミングです。技法に名前を付け、組織で共通言語にまで育つと、組織のスキルも上がり、コミュニケーションも良くなります。

テーマ : プログラミング
ジャンル : コンピュータ

アセンブリのすすめ

 コンピュータはなぜ動くのでしょうか?

 高級言語しかやってこなかったプログラマの解答は、「プログラミングでCUPに命令することによって動く」などでしょう。
しかし、求めている解答は、もっと低レベルでCUPに命令している動作を説明できるかなのです。
要するに、「あなたはアセンブリレベルでプログラムを理解していますか?」ということなのでしょう。

 何故このようなことを聞くのでしょうか?

 今の時代、高級言語ができれば仕事はできます。
よく考えてみてください。高級言語プログラマにとってアセンブリはブラックボックスです。
そのブラックボックス部分が技術者として気になりませんか?

 そのブラックボックスを知ってどうするのでしょう?

 これは基本的な技術になるので高級言語を勉強していくときに理解が深まります。
例えば、配列のサイズを動的に確保できない言語仕様があったとします。
これをただ「そんなもんなんだ!」と思うのと、スタックをアセンブリレベルで知っているので「当たり前」と解釈するのは全然違います。
 特に原因不明のバグを解決するには、低レベルな技術は必要不可欠ではないでしょうか。

 アセンブリが書けなくても読めるようになるだけで理解力が全然違います。

次に紹介する本は、アセンブリができるようになるための本ではありませんが、
CPU、メモリ、I/Oを紙上ではありますが線で結んで結線し、CPUの動作メカニズムを知ることができます。

矢沢久雄『コンピュータはなぜ動くのか 知っておきたいハードウエア&ソフトウエアの基礎知識』日経BP社、2003年

テーマ : プログラミング
ジャンル : コンピュータ

技術の伝承

 初心者の頃を思い起こすと、叩いたコードは、とりあえず目的の動きをするレベルで、
テストが始まれば、バグを収束させるのに夜遅くまで仕事をしていました。

 初心者ながらに、どうすればバグの少ないコードを書けるようになるのかを考える毎日でした。

 そこで出た一つの答えが「美しいコード」です。

 ここでは、その内容には触れませんが、美しいコードを追及していると、
自然とバグも少なくコーディング時間も短くなり、仕様変更も柔軟に対応できたり、
バグが出たとしても簡単に修正できるようになりました。

 このスキルを身に付けるのに色々と回り道をしたのも事実ですが、
簡単に人に教えられるものでもありません。
その技術の伝承方法としてコードレビューが使えないか検討しました。

 コードレビューの一つに「ペアプログラミング」というものがあります。
最近よく耳にするようになった言葉なので、ご存じの方も多いかもしれませんが、
簡単に内容を説明すると。
 2人でペアを組んでコーディングを行っていきます。一人がドライバーとしてキーボードを叩く、
もう一人がナビゲーターとして考えをいう。ときどき役割を交代しながら実装を行う方法です。
 ペアプログラミングは、コーディングが難しいときに有効な手法なので、
毎日、毎回、実施するのは非効率です。

 次に考えたのが「ピックアップゲーム」です。
恐らく殆どの方が知らない手法だと思います。
簡単に内容を説明すると。
 コードを書いて、コンパイルが完了し、テストも通って、チェックインする段取りが整ったら、
すぐにそのコードを別の開発者にレビュー対象としてピックアップしてもらう。
このような「コミットレビュー」は、事前にコードがチェックイン可能なレベルになっていることを
手っ取り早く確認する、形式ばらない方法として考案された。
マンネリ化を防ぐためにレビューをする開発者は持ち回りにしたほうがいいだろう。
例えば、前回ジェリーのコードをレビューしたのがジェーンなら、今度はマークがレビューする番だ。
この方法は非常に効果的だと思う。

Venkat Subramaniam and Andy Hunt(角谷信太郎)『アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣』オーム社、2007年、第8章

 私のプロジェクトでは実際に前述のペアプログラミング以外のコードは、
ピックアップゲームが手軽に行えることもあって100%実施しています。
 もう1年以上継続していますが、私が教えた人が、また他の人へ伝えと、
人から人へ技術の伝承はうまくいっていますし、私自身も他の人の考えを吸収でき勉強になっています。
 気になるのがコストですが、その場だけをみればコスト増ですが、
バグも少なくなり、コーディング速度も速くなってくるので、お釣りがくるほどの手法です。

またの機会に、ピックアップゲームの細かなルールや注意事項を書けたらと思っています。

テーマ : プログラミング
ジャンル : コンピュータ

目標管理制度の崩壊

 目標管理制度がうまくいっている企業は存在するのでしょうか?
私の会社では半年に一度、目標を設定し、それを評価に結び付けるのですが、
半年後の目標って何なのでしょうか?
・△□アプリケーションを○月○日迄にリリースする?(そんな正確な見積もりできるのか)
・△□言語を取得する?(どのレベルまで)
・コードを3万行叩く(バカバカしい)
※具体的に数値で測れるように指示されます。
 半年前に立てた目標を何が何でも達成することが大切なのでしょうか?
環境は刻々と変化しています。その変化に柔軟に対応できることが、企業にとって利益になるのではないでしょうか。
 評価をしたいのであれば、部下のスキルを判別できる上司を雇えばいい。
社員のモチベーションを上げたければ、大きな夢を与えたら良いのではないでしょうか?

 次の文章を紹介します。
目標管理に対するデミングのアドバイスは、「目標管理はやめろ」である。

トム・デマルコ(伊豆原弓)『ゆとりの法則 誰も書かなかったプロジェクト管理の誤解』日経BP社、2001年、第18章

目標管理に違和感を感じる私には救われる言葉です。
ただ、目標管理に替わるものが何なのかは、未だに分かりません。

テーマ : プログラミング
ジャンル : コンピュータ

素直なだけ

伸びる人の特徴
まずは素直にやってみること
 伸びる権利を持っている人には、共通の特徴があります。素直にひたすら努力することです。自分にとって未知のもの、未知の考え方であっても、まずは素直にやってみる。まずやってみて、躓(つまづ)くところについて考えていくといった、「素直にひたすら努力する人」です。

荒井玲子『ソフトウェア開発で伸びる人、伸びない人』技術評論社、2006年、第3章


 コードレビューしていると、頑なに修正するのを拒み、言い訳ばかりする人がいます。教える立場から見れば、非常に勿体ないことです。拒むためにそれ以上のことを教えても無駄だと判断してしまいます。

 素直な人もだいぶ増えてきたと感じています。ただ、言ったその場は良いのですが、日が経つと、何もなかったかのように、聞き流しているようです。
素直だけでは駄目で、ひたすら努力することが必要なのではないでしょうか。

テーマ : プログラミング
ジャンル : コンピュータ

プロフィール

夢追

Author:夢追
芸術プログラミングの世界へようこそ

検索フォーム
最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
フリースペース
RSSリンクの表示
ブロとも申請フォーム

この人とブロともになる

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。