タグ

ブックマーク / forza.cocolog-nifty.com (16)

  • 「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム - プログラマの思索

    ヘンリック著「リーン開発の現場」の感想をラフなメモ書き。 【1】「リーン開発の現場」で最重要の概念は「仕掛り(WIP:Work In Progress)」である。 僕もレビューに加わったのだが、WIPをどう訳すか、という問題を翻訳者の藤原さんや市谷さんだけでなく、レビューアも巻き込んで議論となった。 「リーン開発の現場」の翻訳書では、WIPという単語をそのまま表現し、脚注で「仕掛かり」と記載されているが、僕は、WIPのような英単語ではなく、仕掛かりという日語で表現すべきだったと考えている。 その理由を、以下、色々書いてみる。 【2】理由の一つ目は、会計簿記の観点だ。 工業簿記(簿記2級)の観点では、工場では原材料→仕掛品→製品の流れでモノが作られる。 原材料を仕入れて、仕掛品という未完成の中間物を経て、製品という完成品へモノが価値あるもの(実際は売上計上されるもの)へ変わる。 仕掛品とい

    「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム - プログラマの思索
  • プロジェクト管理ツールを使いこなせないのはITリテラシーが低いから - プログラマの思索

    何故、Excelによるプロジェクト管理に限界があると分かっているのに、プロジェクト管理ツールを使わないプロマネが多いのは何故か? 実は、従来のプロマネはITリテラシーが低いのではないか、という原因で考えてみた。 【元ネタ】 情報リテラシー - @IT情報マネジメント用語事典 ITリテラシーとは来、情報やデータを扱う時にコンピュータを操作できることを指す。 そこから、コンピュータを使って情報を収集したり加工したり発信する能力まで指すようになった。 上記の用語辞典によれば、情報システムを企画し、業務をIT化して変革していく能力まで対象にする時もあるらしい。 (前略) リテラシーとは来「識字力=文字を読み書きする能力」のことで、情報リテラシーとは情報・情報機器活用能力がナレッジワーカーにとって“基礎的能力” であることを示す言葉だが、企業などにおける情報活用が高度化するに伴って、情報システム

    プロジェクト管理ツールを使いこなせないのはITリテラシーが低いから - プログラマの思索
  • 韓国SIがIT技術を日本に逆輸出 - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    韓国SIがIT技術を日本に逆輸出 - プログラマの思索
  • 実践的データモデリング入門の感想 - プログラマの思索

    DOAの体系的方法を知るために「実践的データモデリング入門 (DB magazine selection)」を読んでいる。 IDEF1の説明から、ビジネスロジックからER図への落し込み、データモデルパターン、データモデルの物理的配置の方法まで、全ての情報を網羅しているので読みやすい。 「実践的データモデリング入門 (DB magazine selection)」を解説しているHPがあったのでメモ。 以下は、「実践的データモデリング入門」から僕が理解できた内容を抜き出している。 詳細は「実践的データモデリング入門」を参照してください。 【元ネタ】 履歴モデル サブタイプ構造の明確化 サブタイプ分割されたエンティティから関連付けるエンティティ 取引モデル 関連が隠蔽されているモデル 同一主キーでの別エンティティ化の基準 代理キーによる複合キーの抑制 【1】「実践的データモデリング入門 (DB

    実践的データモデリング入門の感想 - プログラマの思索
    takeshiketa
    takeshiketa 2010/08/21
    買おう!
  • 現代のAgile開発が抱える課題 - プログラマの思索

    チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S

    現代のAgile開発が抱える課題 - プログラマの思索
  • Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索

    Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet+JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって? ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発:第1回 Hello, Wicket|gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ

    Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
    takeshiketa
    takeshiketa 2010/06/13
    まぁ確かに。GoFの考え方は大いに勉強になるけど、パターンそのものは使えなくなったものが多い。
  • IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索

    IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyRailsアジャイル開発などの昨今の話題を日IT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構:ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ

    IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
    takeshiketa
    takeshiketa 2010/04/07
    ちょ、そんなすげー文章だったのか。早く読まなきゃ
  • Railsの性能検証報告書 - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    Railsの性能検証報告書 - プログラマの思索
  • Rails検証報告書 - プログラマの思索

    OSS推進フォーラムという団体がRailsに関する調査結果を公開していたのでメモ。 【元ネタ】 日OSS推進フォーラム 「RubyTF_Ruby_on_Rails検証報告書」 (PDF:975KB) おそらくIPOの外郭団体のような立場で、日の大手SIの技術者がRailsを調査したらしい。 その報告書を読むと、Railsは企業向けにそこそこ使えるが、スケールアップやセキュリティ技術蓄積にやや難がある、とのこと。 報告書で興味を引いたのは、セキュリティに関する所。 リダイレクト、Web アプリケーション内リンクをSSLにする対応は特に問題なく非常に簡単。 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsでは、HTTPセッションをシリアライズ化してCookieに書き込む。 この時、サーバーにもハッシュ

    Rails検証報告書 - プログラマの思索
  • メトリクスでソフトウェア品質を見える化する - プログラマの思索

    「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。 【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。 内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。 【書で解説するEclipseプラグイン】 ・Checkstyle → コーディング規約チェック ・FindBugs → バグパターン検出 ・JUnit → 単体テストの作成/実行 ・TPTP → プロファイリング(非機能テスト) ・djUnit → カバレッジ計測 ・StepCounter → ソースコード行数測定 上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか? 僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは

    メトリクスでソフトウェア品質を見える化する - プログラマの思索
  • チケット駆動開発のアンチパターン - プログラマの思索

    チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過

    チケット駆動開発のアンチパターン - プログラマの思索
  • Redmineのプラグインが充実している - プログラマの思索

    昨年に比べると、Redmineのプラグインがすごく充実している。 いろいろ試してみてメモ。 【コードレビュー】 r-labs - Code Review - Redmine Redmineリポジトリ画面からコードレビューのチケットを発行できる。 UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。 それぐらい素晴らしいプラグイン。 【Hudson】 r-labs - Hudson - Redmine RedmineからHudsonと連携できる。 以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。 Hudsonを使っているなら、このプラグインは必須。 このプラグインのおかげで、ビルド管理をチケット駆動開発に含

    Redmineのプラグインが充実している - プログラマの思索
    takeshiketa
    takeshiketa 2009/11/03
    おお、素敵
  • RedmineとTracの機能比較 - プログラマの思索

    RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱ExcelRedmineアジャイル開発を楽々管理 - @IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。

    RedmineとTracの機能比較 - プログラマの思索
  • アジャイル開発はツールに依存している~SW構成管理を再考しよう - プログラマの思索

    アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。 【元ネタ1】 Kent Beck VSTSのホワイトペーパーの日語訳 (前略) アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。 (中略) アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。 (中略) アジャイル開発は既に開発ツールに影響を与えています。 (中略) 今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。 以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用

    アジャイル開発はツールに依存している~SW構成管理を再考しよう - プログラマの思索
  • チケット駆動開発のFAQ - プログラマの思索

    チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD:チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱ExcelRedmineアジャイル開発を楽々管理 - @IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

    チケット駆動開発のFAQ - プログラマの思索
  • プログラマの思索: RubyよりもJavaが好きな理由

    最近、Ruby関西に行ってRubyの勢いを感じている。 そんな時に、Javaの最近の動きを聞く機会があった。 Java6やSeasarの話を聞くと、JavaがC#やRailsの影響を受けているように聞こえた。 でも、話しているうちに、「やっぱりRubyよりもJavaが好きなんだ」と気づいた。 その理由は、「JUnitのようなテスト駆動ツールが揃っている」点に尽きる。 そこで「テスト駆動の観点から眺めたJavaの利点とプログラミング思想」について考察してみる。 【1】テストを意識するとメソッドの行数が自然に短くなる プログラミング初心者のプログラムを見ると、行数がやたらと長く、長いプログラムを書き上げた後からデバッグし始める。 だから、いつまで経っても動かない。 プログラミング中級者になると、行数は長いままだが、少しずつ書いてはプリント出力してデバッグで動作を確認し始める。 この

    takeshiketa
    takeshiketa 2007/05/02
    テスト駆動ツールの利便性と裏腹に、筆者レベルに至るまでのコストなどの足し算引き算を考えると、生産性のスコープは難しい。これは納得いかず「1・コンストラクタがなくなる。」オブジェクト外注化はいいのか?
  • 1