タグ

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

  • 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ - プログラマの思索

    初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。 理解できた内容をラフなメモ。 【参考】 初中級プロマネのための 現場で活かせ!統計情報1 初中級プロマネのための 現場で活かせ!統計情報2 「ソフトウェア開発分析データ集2020」の発行:IPA 独立行政法人 情報処理推進機構 「ソフトウェア開発データ白書」のダウンロード:IPA 独立行政法人 情報処理推進機構 初中級プロマネのための現場で活かせ!統計情報  2019年4月19日| CITP Community CITPアニュアルレポート2018を公開しました | CITP Community 【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。 【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。 1つ目は、プロマネとしてシステムの企画書や

    初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ - プログラマの思索
  • チケット駆動開発のアンチパターン - プログラマの思索

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

    チケット駆動開発のアンチパターン - プログラマの思索
  • 一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索

    一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。 理由は2つある。 【参考】 ERPの落とし穴part4~システム移行という名のデスマーチ: プログラマの思索 システムのリプレース案件が最も危険な理由: プログラマの思索 請負契約がソフトウェア開発者を苦しめている: プログラマの思索 【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。 結局、発注者に全てリスクで跳ね返ってくる。 発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし番障害があれば、瑕疵担保責任でベンダーに追求できる。 民法の請負契約では、受託側は成果物の完成責任があるからだ。 しかし、その契約スタイルはソフトウェア開発になじまない。 たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが

    一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索
  • データモデルパターンのリンク - プログラマの思索

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

    データモデルパターンのリンク - プログラマの思索
  • チームビルディング~現場リーダーの必須技術 - プログラマの思索

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

    チームビルディング~現場リーダーの必須技術 - プログラマの思索
  • スケジュールを見ればマネージャのレベルが分かる - プログラマの思索

    @hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。 【元ネタ】 Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。 Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。 【1】Redmineでチケット駆動開発を運用していると、チケットの粒度

    スケジュールを見ればマネージャのレベルが分かる - プログラマの思索
  • astahのモデルをGitで差分比較する方法のリンク - プログラマの思索

    astahのモデルをGitで差分比較する方法の記事があったのでリンクしておく この方法は使えそう。 【参考】 astah*とGit | astah in 5 min 【1】UMLでモデルを書いていると、差分比較を取りたくなる時がある。 顧客の要求事項を一つずつモデルに反映して、課題を一つずつ潰していく作業は地道で労力がかかる。 だから、顧客のヒヤリングのたびに、想定したモデルをどんどん洗練させていく時、前回の状態とどれだけの変更箇所があったのか、後で振り返りたくなる。 また、マイルストーンごとに、モデルの差分比較もやりたい時がある。 仕様変更のスコープだけ、顧客に見積もりを請求したいからだ。 その為には、たとえモデルがバイナリファイルであっても、ソースと同じような差分比較機能が欲しくなる。 【2】(引用開始) astah*には、プロジェクトの比較機能というものがあります。これをコマンドライ

    astahのモデルをGitで差分比較する方法のリンク - プログラマの思索
  • PlantUMLを使ってExcel設計書をテキスト化するアイデア - プログラマの思索

    以前、Excel設計書をテキスト化できないか、考えたことがあった。 ネットしながら、PlantUMLや他ツールを使ってExcel設計書をテキスト化するアイデアをメモ。 以下は、後で自分が参考にしたい記事をリンクしておく。 仕様書にもExcel脱却が求められている: プログラマの思索 【参考1】 PlantUML 埋め込み AsciiDoc の Gradle を用いた HTML 一括変換 ・ Yutaka ?? Kato 【参考2】 AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ 【参考3】 PlantUML を導入するのに適したケースとは - kkeisuke blog (引用開始) 以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。 一人で利用する場合 少数精鋭、もしくは統制(教育)されたチームで

    PlantUMLを使ってExcel設計書をテキスト化するアイデア - プログラマの思索
  • 歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク - プログラマの思索

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

    歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク - プログラマの思索
  • ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索

    アジャイル開発に慣れている人から見ればDevOpsなんて当たり前に見えるが、DevOpsを阻む障壁として「ITに係る全般統制」がある。 ITに係る全般統制とDevOpsは真っ向から対立する概念と捉えた方がいいのではないか、と最近考えている。 以下メモ。 【参考】 開発と運用の新しい関係、「DevOps」とは何か? - Publickey 全般統制,業務処理統制[ITの統制] 海外会計税務用語 :総合型税理士法人山田&パートナーズ|東京,関西,名古屋,福岡の総合税理士事務所 【DevOpsが変える開発と運用[#1]】 DevOpsは開発と運用の分離と対立するのか?:情報インフラ24時 眠らないシステム:ITmedia オルタナティブ・ブログ 【DevOpsが変える開発と運用[#3]】運用が権威的になると開発のやる気が損なわれる:クックパッドのチャレンジ:情報インフラ24時 眠らないシステム:

    ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索
  • アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺 - プログラマの思索

    最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。 内容がとても奥深い。 僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。 以下、ロジカルでないラフなメモ書き。 【参考】 @yusuke_arclampさんのまとめ記事が公開されました。 アジャイルにおける事前合意について - arclamp 【1】エンタープライズアジャイル勉強会 2017年12月セミナー開催のお知らせ アジャイルを機能させる外枠について - arclamp (引用開始) アジャイルを機能させる2つの外枠 1つ目の外枠は「何を作るべきか」という観点。 チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@pa

    アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺 - プログラマの思索
  • Jenkinsをジョブ管理ツールとして使う事例part2 - プログラマの思索

    Jenkinsをジョブ管理ツールとして使う事例を見つけたのでメモ。 【元ネタ】 Jenkinsで定期実行するJobを管理したほうが良い3つの理由|Pimp my Code. @wataru420 上記の記事では、Jenkinsを高機能なCronとして使うメリットが書かれていて、参考になる。 (引用開始) 定期実行って、Cronを使ってやるのが一般的ですよね。 エンタープライズシステムだとJP1とか使って管理したりしますが、 それJenkinsで良くない? というわけで考えて見ました。 なんでJenkinsがいいのか。 メリット(cronとの比較) ① SVNなどのSCMとの連携が可能 ② メール等のアラートが可能 ③ 実行履歴の確認が容易 デメリット ① Jenkinsが落ちたら動かない ただこれはJenkinsの監視やバックアップである程度回避できます。 またJP1 などは大変高価なので

    Jenkinsをジョブ管理ツールとして使う事例part2 - プログラマの思索
  • 「電子立国は、なぜ凋落したか」の感想~日本の技術者は減価償却のコスト意識が低い - プログラマの思索

    「電子立国は、なぜ凋落したか」の感想をメモ。 理解できた部分だけラフなメモ書き。 あくまでもメモなので、時々論理は飛んでいる。 【元ネタ】 日の製造業もアジャイルの概念が必要ではないか: プログラマの思索 ユーザの力を利用するアジャイル開発: プログラマの思索 【1】「電子立国は、なぜ凋落したか」では、特に日における半導体、電子電気の業界の栄枯盛衰を多角的に記載している。 そこで興味深い文言だけ拾っておく。 「日技術者は減価償却のコスト意識が低い。なぜなら、技術ではなく経営の問題だから。」 【2】日技術者は減価償却のコスト意識が低いのではないか 日の半導体は世界を席巻していたが、諸外国に負けた時の言い分は「経営、戦略、コスト競争力で負けた」「技術では負けていなかった」とよく言う。 しかし、著者は、製造コストを考える時に、日技術者は減価償却のコスト意識が低いのではないか、と

    「電子立国は、なぜ凋落したか」の感想~日本の技術者は減価償却のコスト意識が低い - プログラマの思索
  • RedmineのREST APIは素晴らしい~ビッグデータの手法をRedmineにも活用する - プログラマの思索

    RedmineのREST APIを実際に試してみたら、とても素晴らしい。 分かったことをメモ書き。 【元ネタ】 Rest api - Redmine Redmine REST API - r-labs Rest Issues - Redmine コマンドラインとブラウザで JSON API を手軽に試す | COLOPL Engineers' Blog | 株式会社コロプラ【スマートフォンゲーム&位置ゲー】 RedmineのREST APIを使ってみる | 『世界』はあまりにも広い Redmine REST API の翻訳 | プログラマーズ雑記帳 【1】RESTはマッシュアップというWebサービスの一つ。 REST APIを使えば、Redmineからチケットの情報だけでなく、プロジェクトやユーザ、果てはWikiまでHTTP経由で取得できる。 RedmineのREST APIの内容を見ると

    RedmineのREST APIは素晴らしい~ビッグデータの手法をRedmineにも活用する - プログラマの思索
  • Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 - プログラマの思索

    Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et

    Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 - プログラマの思索
  • 「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索

    技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。>技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、当によくある。 (引用開始) 1年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理

    「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
  • 「挫折しないRedmine」の資料が分かりやすい - プログラマの思索

    僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる

    「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
  • 最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで : プログラマの思索

    【公開】第30回IT勉強宴会「最近感じる日企業のITの問題と展望~「ソフトを他人に作らせる日、自分で作る米国」を読んで」 【1】「ソフトを他人に作らせる日、自分で作る米国」の著者である谷島さんが来阪されたのを記念に勉強会が開催されました。 数人がの感想をメインに発表し、谷島さんに感想を述べてもらうという緩い勉強会でした。 いろんな議論がありましたが、詰まる所、「日のユーザ企業がシステム開発を内製化するにはどうすればよいのか?」というテーマを巡る話だったと思います。 僕は、SIとユーザ企業の両方を経験した立場から、現状の日IT企業(SIとユーザ企業の両方)について、話しました。 【2】「日企業はロールが多すぎる」という問題 【2-1】SIにしても、ユーザ企業にしても、日企業は役職が多すぎる。 特に、管理職は部長、課長だけでなく、事業部長、PMO、○管理長、主査など色んな肩書

    最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで : プログラマの思索
    koma_g
    koma_g 2014/03/08
  • 第5回品川Redmine勉強会の感想 #47redmine - プログラマの思索

    いろんな議論が出てきた。 皆同じような問題を持っているのね、と共感している人も多かった。 僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。 顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。 トラッカー=顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。 実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。 この事例は、RedmineCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。 このアイデアは、第8回勉強会の感想~RedmineCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理

    第5回品川Redmine勉強会の感想 #47redmine - プログラマの思索
    koma_g
    koma_g 2013/06/30
  • 1