タグ

2011年4月17日のブックマーク (5件)

  • アジャイルコミュニティのエネルギーを作り出した人々 〜 AgileJapan2011にて 〜 - メソッド屋のブログ

    アジャイルジャパン2011のコミュニティのエネルギー AgileJapan2015に参加して講演して、ハードダンスをしてきました。 講演の内容はリンダ・ライジングさんの素晴らしい講演や、USP(ユニバーサルシェルプログラミング)での驚異的な事例、SalesForceでの実践的なアジャイル事例など強力な内容でした。これらは多くの方がブログされているので、私が駄文で補足するまでもないでしょう。 フリーペーパーEMZeroでの素晴らしい公式レビューがありますのでリンクを張っておきます。 http://www.manaslink.com/article/ 私が講演の中身について書かないのには理由があります。 今回のアジャイルジャパンで、私が最も感慨深かったことは、このアジャイルコミュニティのエネルギーの強大さです。昔アジャイルを始めた頃はみんなマイナーでテロリストや宗教家扱いでした。それがIBMの

    アジャイルコミュニティのエネルギーを作り出した人々 〜 AgileJapan2011にて 〜 - メソッド屋のブログ
  • 日本語でプログラミングしてはいけない理由 - プログラマーの脳みそ

    詳しすぎる詳細設計書 - SiroKuro Page とか 詳細設計書に何を書くべきか? - Sacrificed & Exploited 関連。 ソースコードと1対1で対応するような仕様書を書いてはならない理由。 日語は読み上げれるかもしれないが内容を理解できるとは限らない 日人なら日語で書かれた相対性理論の教科書を読み上げることはできる。しかし相対性理論を理解できるというわけではない。 日語は論理演算を表現するのに向いていない OR と XOR の区別がつかなかったり、括弧による演算順番の指定がやたら面倒くさくて見通しの悪いものになったり。 日語は例外処理を記述するのに向いていない 法律の例外事項とかの読みにくいことと来たら。 日語はシンタックスハイライトされない 「を」とか「は」とかカラフルになっても嬉しくないけど。 日語はコンパイラによる静的チェックができない Wor

    日本語でプログラミングしてはいけない理由 - プログラマーの脳みそ
  • 詳細設計書が滅亡しない理由 - kagamihogeの日記

    IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ!】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ

    詳細設計書が滅亡しない理由 - kagamihogeの日記
    kkotyy
    kkotyy 2011/04/17
    "その根底にある思想―完璧なドキュメントが作られればプログラミングは完了したも同然―" なるほどー(棒)。偉い人との相互理解のためには必要な知識。
  • 詳細設計書に何を書くべきか? - Sacrificed & Exploited

    詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと1対1に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容(内部の処理の実装方法)の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、

    詳細設計書に何を書くべきか? - Sacrificed & Exploited
    kkotyy
    kkotyy 2011/04/17
    "処理内容を一切書かない代わりに書くべきなのは、詳細な仕様だ。"
  • 詳しすぎる詳細設計書 - SiroKuro Page

    「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力: 「性別と身長のペア」のリスト 出力: 男性の平均身長」と「女性の平均身長」の差 処理概要: 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を1つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を1増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を1増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい

    詳しすぎる詳細設計書 - SiroKuro Page
    kkotyy
    kkotyy 2011/04/17
    "実際書いてみて異様なほど書き直したい気持ちに満ちあふれているんですが、そのためには詳細設計書が異様なほどに邪魔になります。詳しすぎるんです。" 悩みはみな同じ。