タグ

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

  • ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索

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

    ITに係る全般統制とDevOpsの緊張関係 - プログラマの思索
    k-holy
    k-holy 2015/02/27
    開発と運用で共有してるのは本番環境のコードのみという状況もざらだし…組織またがったバージョン管理とかどうやってるのか
  • さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー - プログラマの思索

    さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーに行ってきた。 要件定義の考え方がすごく参考になった。 感想をラフなメモ書き。 【元ネタ】 さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナー - アジャイルウェア | Doorkeeper 要件構造の見える化 #RDRAセミナー: ソフトウェアさかば リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索 【1】要件定義の問題。 いつまで経っても、システムの全体像が見えない。 大量のドキュメントばかりで、肝心のシステムが説明されない。 分析と言う名の転記作業ばかりで、要件定義が完了しない。 では、どうすればいい? 要件定義、要件分析では、個人作業は非効率。 レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。 その場で皆で合意を積み上げて進める方がいい。 ステー

    さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー - プログラマの思索
  • RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題 - プログラマの思索

    RedmineとGitを巡る疑問点をメモ。 詳細は後で書き足す。 【参考】 チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索 分散バージョン管理ツールにおけるブランチ戦略: プログラマの思索 Gitによるチケット駆動開発の事例: プログラマの思索 A successful git branching model とgithub flowの比較: プログラマの思索 第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索 GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索 【1】Redmineは日のSIでかなり普及しているらしい。 その状況と並行して、オープンソース界隈では、GitHubでチケット管理する運用も多い。 すると、最近の状況としては、RedmineとG

    RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題 - プログラマの思索
  • 「挫折しないRedmine」の資料が分かりやすい - プログラマの思索

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

    「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
    k-holy
    k-holy 2014/04/30
    1人チケット管理から脱却したいものの、処理能力に自信がある人ほど使ってくれない感じでつらい。少人数体制だとバージョン管理ほどのメリットは見出してもらえない…
  • 消費税の6つの落とし穴 - プログラマの思索

    日経コンピュータ2014年1月9日号の記事をメモ。 【参考】 日経コンピュータ2014.01.09|HATのブログ 【1】2014年4月から消費税率が5%から8%に上がる。 企業の社内システムも3月末までに、消費税対応を終わらせる必要がある。 しかし、消費税対応には6つの落とし穴がある、という記事。 普通は、税率マスタを別テーブルとして保持しておき、5→8へデータ更新するだけで良いはず。 でも、1997年に消費税率が3→5%へ上がった時とは違う状況がある。 以下は、6つの問題の内容を記事から抜粋して、感想を書いてみた。 【2】社内調整に想定外の時間がかかる 小売流通・アパレルなどの消費者に近い業界では、価格表示は、税込の総額表示にするか、外税表示にするか、で売れ行きが大きく変わる。 記事の例では、税込98円で販売していたとき、体価格は端数切捨てなら94円になる。 (いわゆる税はがし) す

    消費税の6つの落とし穴 - プログラマの思索
  • Redmineの大規模化の壁 - プログラマの思索

    昨日、meeting/17 - Shibuya.trac第12回勉強会~チケット管理システム大決戦 第二弾~Shibuya.trac Wiki - SourceForge.JPが開かれた。 UStreamで観戦して、とても面白かったです。 スタッフの皆さん、お疲れ様でした。 実際の議論を聞いて参考になったとともに、Redmine派の自分としては、@daipresentsさんの話がもっと聞きたかったな、と思っている。 今の僕の興味は、一プロジェクトITSを使ってプロジェクト管理することよりも、1個の事業部、1つの会社全体へRedmineのようなITSを導入して運用して、ソフトウェア開発の基幹業務システムにしてしまいたいという思いに移っているから。 僕もRedmineを4年間使ってみて、一プロジェクトの事例はたくさん経験したし、ボトムアップで成功例を作ることで他チームへ影響させることができる

    Redmineの大規模化の壁 - プログラマの思索
  • バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠 - プログラマの思索

    TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか?の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ

    バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠 - プログラマの思索
    k-holy
    k-holy 2011/03/26
    今日まさにこの罠に陥っていた。現行自社サービスへの機能追加だったので、バージョンの使い方が分からなかったけど、要はバージョン=本番リリースなのね
  • Redmineのトラッカーやステータスの付け方 - プログラマの思索

    Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合/バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合/バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録

    Redmineのトラッカーやステータスの付け方 - プログラマの思索
  • 1