稼働率100％の罠 - プログラマの思索
@hatsanhatさんのツイートから良い記事を見つけたのでメモ。 以下はメモ書きであり、特に主張はない。 【参考】 とれるだけ仕事をとってはいけない : タイム・コンサルタントの日誌から 稼働率100%をねらってはいけない : タイム・コンサルタントの日誌から 佐野 初夫さんはTwitterを使っています: "とれるだけ仕事をとってはいけない http://t.co/JQRIl8fTqP ソフト業界だと危険稼働率をはるかに超えて受注することも普通です 主任の頃に「無理です」と言うと「それを回すのがお前の仕事」と言われました" 受託開発中心のSIでは、PGやSEの稼働率が売上に直結する。 受注したシステム開発案件にメンバーを投入して、人月計算で売上を稼ぐスタイルだから。 すると、PGやSEの稼働率が低いと、空いた時間は売上につながらない作業をしていることになる。 だから、営業も管理職も必死
一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索
一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。 理由は2つある。 【参考】 ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索 システムのリプレース案件が最も危険な理由: プログラマの思索 請負契約がソフトウェア開発者を苦しめている: プログラマの思索 【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。 結局、発注者に全てリスクで跳ね返ってくる。 発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。 民法の請負契約では、受託側は成果物の完成責任があるからだ。 しかし、その契約スタイルはソフトウェア開発になじまない。 たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
「データモデリング入門－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が最強だと思っている。 既存の画面
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
Mantisの使い方 - プログラマの思索
RedmineやTracよりもおそらくBTSで最も使われていると思われるMantisについて、ロードマップの設定方法がようやく分かったのでメモ。 【元ネタ】 バグ管理システム「Mantis」 - SourceForge.JP Magazine : オープンソースの話題満載 Roadmap [MantisBT] ロードマップの使い方 - こげつきません akky’s log ? Blog Archive ? mantisのroadmapを試してみたよ Mantisでロードマップを使うには、下記の設定を行う。 1・プロジェクト設定画面のバージョンの編集で「リリース」のチェックを外す →チェックを付けると、そのバージョンはリリースされたので、ロードマップに表示されなくなる。 2・チケット(詳細)の登録画面で「修正予定バージョン」にバージョンを設定する。 →リリース予定のバージョン(Target
ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係 - プログラマの思索
ソフトウェアプロダクトライン(SPL)を分かりやすく解説された記事があった。 考えたことをメモ。 【元ネタ】 ZACKY's Software Engineering Laboratory: プロダクトラインとは(1) ZACKY's Software Engineering Laboratory: 共通性と可変性，スコーピング ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(1) ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(2) ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(3) 研究室｜株式会社エクスモーション 組込みシステム開発を現場から支援する「実践型トータ
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
TortoiseHgで日本語が使えるようになった - プログラマの思索
TortoiseHg0.8.1になって、ようやく日本語がほぼ使える状況になったのでメモ。 【元ネタ】 TortoiseHg / wiki / install ― bitbucket.org Windowsにてwin32mbcsを有効にしてMercurial 1.3 を使うとエラーになります - mercurial-ja | Google グループ gitやめてmercurialとtortoiseHGをインストール TortoiseHg0.8.1に同梱されているMercurial 1.3.1で、win32mbcsが効くようになったらしい。 実際、パスやファイル名が日本語でも、コミットエラーが出なくなった。 メニューも日本語化されて使いやすくなった。 但し、日本語のダメ文字は使えないので注意。 また、Mercurialのオライリー本の日本語訳がPDFで公開されているのでメモ。 分散バージョン管
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
