ガントチャートの光と影 - プログラマの思索
プロジェクト管理といえば、ガントチャート。 ガントチャートの良い部分と悪い部分についてメモ。 【参考】 下記の連載記事は、初心者向けのガントチャートの記事で読みやすい。 初めてのガントチャート（1）：ガントチャートって何ですか？ - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (1/2) - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (2/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (1/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (2/2) - ＠IT 【1】ガントチャートは、作業が予測
第7回Redmine.tokyoの感想 #redmineT - プログラマの思索
第7回Redmine.tokyo勉強会が無事に終わりました。 参加者の皆様、スッタフの皆様、ありがとうございました。 参加人数も60名近くと過去最高人数で、オープンディスカッションの議論も盛り上がりました。 【参考】 第7回勉強会 - redmine.tokyo 第7回redmine.tokyo勉強会 - Togetterまとめ 【1】Redmineはキャズムを超えた @sakaba37さんのLTにもありましたが、Redmineの普及度合いはキャズムを超えたと思います。 勉強会の議論を聞いてみると、Redmineはアーリーアダプターが使うものではなく、マジョリティが使うプロジェクト管理ツールになったように感じました。 つまり、ソフトウェアに関わる人達にとって、Redmineのようなチケット管理ツールは当たり前の開発環境である、と。 アンケート結果が興味深い。 Redmine勉強会の参加者の
現場の経験知をパターン言語にするコツが分かった #agileto2014 - プログラマの思索
AgileTourOsaka2014に参加してきた。 テーマは「パタン特集」。 パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。 とても有意義な勉強会だった。 ラフなメモ書き。 【元ネタ】 10月11日 AgileTourOsaka2014 Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ KenColle/AutomationPatternLanguage パターンを使うもう一つの動機～パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索 パターン言語の構造と事例集: プログラマの思索 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想～エバンジェリストが自分のアイデア
「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料 - プログラマの思索
astahを使って、T字形ERによるデータモデリング手法を解説した資料があったのでメモ。 これはすごくためになる。 自分なりの理解をまとめるためにメモ。 間違っていたら後で直す。 【元ネタ】 Twitter / akipii:凄く良い資料！dddosaka勉強会の人は必読でしょう笑 RT @hatsanhat: データモデリング入門ーastah*を使ってTMの手法を使う http://www.slideshare.net/mobile/inamiK/ss-36665472 … 大変親切にわかりやすく解説されています。 【1】T字形ERのデータモデリングをastahProfessionalのER図でどのように表現すべきか、を解説している。 非常に丁寧で分かりやすい。 個人的には、既存システムのリバース・エンジニアリングの設計技法を選択するとしたら、T字形ERが最強だと思っている。 既存の画面
ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 - プログラマの思索
ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 @digitalsoul0124さんのBlogを読んで、自分は「ドメイン駆動設計」を完全に理解していないことに気づいた。 ラフなメモ書き。 論理的な文章でないので後で直す。 【元ネタ】 ドメイン駆動設計入門 - Digital Romanticism モデルが息づく場所 - Digital Romanticism 戦略的デザインに関する意思決定のための６つのエッセンス - Digital Romanticism ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索 ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プロ
DOAはOOA以前に表記法の問題点がある - プログラマの思索
UMLモデリングで有名な平澤さんの記事を見つけたのでメモ。 ラフなメモ書き。 椿先生のデータモデリング本 - UMLモデリングレッスン執筆日誌 データモデル表記読み替えハンドブック: プログラマの思索 業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索 データベース設計で派生関係は難しい: プログラマの思索 【1】DOAは日本独自の歴史を持ち、業務モデリングに特化したノウハウも多い。 でも、データモデル表記読み替えハンドブック: プログラマの思索にも書いたけれど、TH法、T字形ER、渡辺式、IDEF1Xなどの記法がたくさんありすぎて、正直読みづらい。 個人的には、ER図はIDEF1Xが一番すっきりしていて読みやすいが、業務フローも考慮すると渡辺式が分かりやすいと思う。 最近考えているのは、ER図を基本にして、業務フローと画面UIを組み合わせたモデリング技術としてDO
野中郁次郎先生の講演資料の解説記事 - プログラマの思索
Scrum Alliance Regional Gathering Tokyo 2013で野中郁次郎先生の講演資料の解説記事が公開されていたのでメモ。 SlideShareの資料だけでは読み取りにくい内容がうまく説明されていて理解しやすくなっている。 【元ネタ】 プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（前編） － Publickey プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編） － Publickey アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ 野中先生の資料を読むと、古き良き時代の日本企業の経営手法からエッセンスを取り出して、知識をベースとした組織のあるべき構造を説明されようとしているように思える。 で
セールスとエンジニアのためのIT提案戦術～SIベンダーの営業方法 - プログラマの思索
「セールスとエンジニアのためのIT提案戦術」を借りて読んだ。 受託開発中心のSIで、顧客折衝が多いSEやシステム提案の機会が多いPMにとっては必須の本だろうと思う。 感想をラフなメモ書き。 【1】システム提案プロセスの問題 普通のシステム提案プロセスでは、発注者がRFIを作ってベンダーに提示し、ベンダーは実現するシステムの内容や見積金額をRFPで発注者に提案する。 日本ならば、ユーザ企業がITを使って経営革新や新しいビジネス戦略を行うための道具としてITを使いたいので、ベンダーにシステム構築だけでなく、ITを使ったソリューション、つまりコンサルティングも求める時は多い。 そして、SIが作ったシステムの運用保守もユーザ企業ではなくSI任せになりやすい。 だから、どうしてもユーザ企業がSIへ丸投げしてしまいがちという日本特有の特徴が出るように思われる。 システム提案プロセスの問題としては、ユー
RedmineのER図 - プログラマの思索
RedmineのER図を作る方法が公開されていたのでメモ。 【元ネタ】 redmineのER図を生成してみた | ぷろぐらま Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。 だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。 Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。 「強制されたサロゲートキー」の事例を眺める: 設計者の発言 複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。 多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。 つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。 DOAの立場の人がサロゲートキ
請負契約がソフトウェア開発者を苦しめている - プログラマの思索
IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。 デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。 請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。 【元ネタ】 Twitter / @akipii: 日本のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。 Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り本当のアジャイルな開発でないと体験してます。それをうまく説明したい。 Twit
メール駆動開発は時代遅れではないか - プログラマの思索
マネージャになるほど膨大な量のメールを処理するのが主な仕事になってくる。 また、SEの仕事の殆どは、顧客やメンバーからのメールや添付されたExcelを元に、設計書をどんどんブラッシュアップしていくことだ。 倉貫さんのつぶやきを読んで、同感すると共に、果たしてそれが本当に良いことなのかラフなメモ。 【元ネタ】 Twitter / @kuranuki: メールで5人とかに送って、ひとりtypoとかで届かなかったときの残念さったらない。もう一度5人に送り直すか、その人だけに送り直すか。前者は他の人にはウザいし、後者はこれからの返信に漏れるし。もう複数人でのメールやだ。 Twitter / @kuranuki: メールでは手紙で出来ること以上のことをやっちゃいけないんだよ。 Twitter / @kuranuki: メールのccにいつまで偉い人を入れておくのか判断が難しい。遠慮なく入れた方が良いの
ソフトウェア開発の工数見積もりが混乱しやすい理由 - プログラマの思索
工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。 考えたことをメモ。 間違っていたら後で直す。 【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。 マネージャの仕事の一つが、月次報告のための工数集計がある。 だが、この工数集計が結構面倒だ。 普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。 しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。 更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。 また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。 特に、本番
ユーザ機能駆動開発FDDを再考 - プログラマの思索
「アジャイル開発手法FDD―ユーザ機能駆動によるアジャイル開発」を読んで、Agile開発のスケールアップに必要な概念が揃っている感覚に陥って驚いた。 考えたことをメモ。 間違っていたら後で直す。 【元ネタ】 ユーザー機能駆動開発 - Wikipedia トカゲの独り言: 『アジャイル開発手法FDD』読了 銀行システムの失敗から生まれた開発方法論 - 日経コンピュータ・コラム：ITpro Twitter / @akipii: FDD(Feature Driven Development)本を読んだら、まるでデジャブみたいだった。概念モデル設計＝ドメイン駆動設計(DDD)。フィーチャ＝ユーザ機能リストorバックログ。フィーチャの進捗＝パーキングロットチャート。 Twitter / @akipii: FDDのクラスオーナーはConwayの法則の観点からも正しい。SW組織はテクノロジラインではなく
SVNのコミットログの書き方 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Mercurialで独立並行リリース管理 - プログラマの思索
「Mercurialで独立並行リリース管理」という良い記事があったのでメモ。 【元ネタ】 Computing Memo of 2008/02/26 パッチを作った場合、そのパッチを取り込む方法はCVS・SVN・Mercurialで違いがある。 例えば、コードラインAのリビジョン修正2にコードライン3のリビジョン修正3を取り込む場合、下記のようになる。 cvs up -j 修正2 -j 修正3 svn merge -r r修正2:r修正3 (A側) hg transplant -s (A')修正3 (前略) むっちゃ簡単! 「どのパッチを取り込む」かを指定するので指定には 「修正3」 とか一個だけでなく何個でも書け，「修正x:修正y」のようにコロンで区切って範囲指定もできる。 そして，既に適用したパッチかどうかはチェンジセットIDで確実に判別してくれるから，リバースパッチなんていうアホな自体
コマンドラインのBTS ditz - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索
第26回redmine.tokyo勉強会で、ウクライナのRedmine開発者が作ったRedmineテーマやプラグインを解説した動画を紹介した。 改めてリンクしておく。 第26回勉強会 - redmine.tokyo Redmineのテーマはタブレットやスマホを意識して作られたらしい。 プラグインも痒いところに手が届くような機能を提供している。 第26回redmine.tokyo勉強会にスタッフとして参加してきた。 久しぶりに常連や新しく知り合った人たちと話して気づいたのは、多様な属性の人達が集まり多様なテーマで議論するのがコミュニティの醍醐味ではないか、と思った。 ラフな感想をメモ書き。 【参考】 第26回勉強会 - redmine.tokyo 2024/6/15 第26回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター] プリザンター｜O
SVNリポジトリの管理方法 - プログラマの思索
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の
ソフトウェア開発のチームビルディング - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プログラマの思索: RubyよりもJavaが好きな理由
最近、Ruby関西に行ってRubyの勢いを感じている。 そんな時に、Javaの最近の動きを聞く機会があった。 Java6やSeasarの話を聞くと、JavaがC#やRailsの影響を受けているように聞こえた。 でも、話しているうちに、「やっぱりRubyよりもJavaが好きなんだ」と気づいた。 その理由は、「JUnitのようなテスト駆動ツールが揃っている」点に尽きる。 そこで「テスト駆動の観点から眺めたJavaの利点とプログラミング思想」について考察してみる。 【１】テストを意識するとメソッドの行数が自然に短くなる プログラミング初心者のプログラムを見ると、行数がやたらと長く、長いプログラムを書き上げた後からデバッグし始める。 だから、いつまで経っても動かない。 プログラミング中級者になると、行数は長いままだが、少しずつ書いてはプリント出力してデバッグで動作を確認し始める。 この
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
