吉岡さんがレガシーコード改善ガイド読書会という勉強会を立ち上げた。レガシーコードとどう付き合っていくか、を議論していくらしい。可能なら参加したいが、ちょいと距離があるので中々難しい。 自分もこのお題目については色々考えてきたし、自分なりに実践もしてきたつもりなので、トラックバック送りながら意見などを... レガシーの定義 「テストがないコードはレガシーコードだ」という定義には100%同意。 我々は今この瞬間にもレガシーコードを簡単に書くことができる。 だけど、そのテストのないレガシーコードにも「レガシー度」みたいな尺度があるのではないかと。 レガシー度 といっても簡単に数値化できるようなものではない。 monolithic度合い。何千行とある関数とか、何百とメソッド持ってるクラスとか。 結合度、依存性などという言葉で表現されるアレ。 Interfaceの設計。変な値を渡さない工夫をしている
朝の挨拶を交わすことなく自分の席に座ってPCの電源を入れ，メンバーと互いに助け合うムードがないまま黙々と仕事をし続けている。うまく行っているように見えて，実はメンバーのモチベーションが徐々に下がってきている――最近，自分たちのチームや現場の雰囲気が悪いと感じたことはないだろうか。 実際のところ，ITエンジニアは自分が働く現場の雰囲気をどのように感じているのか。2009年6月30日～2009年7月13日にかけて，日経SYSTMES読者100人に対して，現場の雰囲気を聞くアンケートを実施した。その結果，ほぼ3分の1が現場の雰囲気は明確に「悪い」と回答した。加えて，3年前と比べて現場の雰囲気がどう変わったか質問したところ，「悪くなった」「非常に悪くなった」の合計も全体の3分の1に達し，「良くなった」（21％）を大きく上回った（「非常に良くなった」の回答はゼロ）。このまま何もしないでいると，今は良
東邦チタニウムは、要件を固めきれないが納期は厳守というプロジェクトをアジャイル開発手法を使って乗り切った。アジャイルは短い開発期間を繰り返し、要件を決めながら機能を実装する手法。ユーザー部門のキーマンをチームに引き込んだり、途中でアジャイル開発向きでない開発者を交代させたりして、プロジェクトを完遂した。同社として初めて挑んだアジャイル開発だったが、納期を守り、コストも計画内に収めた。舵取りの難しいアジャイル開発プロジェクトを成功に導いた手腕が評価された。 東邦チタニウムは、「アジャイル」と呼ぶ開発手法でチタンインゴット（金属チタンの塊）の生産管理システムを構築した（図1）。アジャイルは短い開発期間を反復して、機能を組み上げていく。同社にとっては初めての試みだった。要件を決めながら開発できるメリットを得るには、プロジェクトの体制や運営に工夫があった。 「要件を固めきれないうえに納期厳守。仕様
悪い見本発見。 朝日: 「エコポイント」スタート 申請受け付けは７月から どんな商品に交換できるかなど制度の詳細は未定で、小売店の経営者は「交換できる商品を早く決めてほしい」と話していた。 Agileは「走りながら考える」場面は多いけど、上記記事みたいな「肝心な部分」を走りながら考えることはありえない。 見切り発車とAgileとを分ける、明確な一線。
開発支援ツール大手の米Borland SoftwareでCEOを務めるErik Prusch氏は2009年4月17日，都内で会見し，開発プロジェクトの品質を“見える化”する製品群に強化する方針を明らかにした。同社は，チーム開発を支援するALM製品群を提供しているが，今後は，こうしたALM製品群から情報を収集し，開発プロジェクトの状況を可視化するマネジメント製品群に注力していくという。 「BI for ALM（アプリケーション・ライフサイクル管理を対象としたビジネス・インテリジェンス分析）」というコンセプトを掲げて，品質の見える化機能を製品に実装する。米国で昨年から今年にかけて出荷した最新の製品群（TeamAnalyticsやTeamInspectorなど）には，すでに機能が盛り込まれている。開発プロジェクトを通じて，仕様変更の件数がどう推移したのか，といった開発プロジェクトそのものの品質を
「成長」にあえて背を向けている企業がある。この会社が重視しているのは従業員の幸せと企業の永続。そして、それを実現するために持続的な低成長を続けている。人事制度は終身雇用の年功賃金。地域社会への投資も惜しまない。それでいて、10％を超える高い利益率を維持している。 私たちの足元は経済危機に揺れている。強欲の虜になったグローバル資本主義はバブルを膨らませ、金融危機を引き起こした。今の経済危機は強欲がもたらした1つの末路とも言える。であるならば、この会社の生き方は、危機後の資本主義に、そして企業経営に、1つのヒントを与えるのではないだろうか。 48年という長きにわたって増収増益を続けた企業がある。本社は長野県伊那市と、決して地の利に恵まれているわけではない。しかも、扱っているのは「寒天」という地味な成熟商品だ。にもかかわらず、1958年の創業以来、階段を上るように、一段一段、着実に成長してきた。
安井さんから1月下旬に頂いた「アジャイルな見積りと計画づくり」。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎出版社/メーカー: 毎日コミュニケーションズ発売日: 2009/01/29メディア: 単行本（ソフトカバー）購入: 74人 クリック: 764回この商品を含むブログ (226件) を見る なんと読むのに二ヶ月かかってしまった... 言い訳すると...印象に残った所に付箋をペタペタ貼っていたため。 大変遅れてしまって申し訳ないが、読後感想などを... 全般 これからAgileを始めたい人はもちろん、既にAgile開発に詳しいつもりの人も、「俺はウォーターフォールでいいんだ」という人にも是非読んでもらいたい本。 特に「進行基準」に興味ある人には強く推薦。 読んだ後は「見積りを精査します！」なんて
同僚の協力もあり 2002 年にアジャイルモデリング ( AM ) 日本語リソースサイト [1] を開設し, 2003 年に AM 本 [2] を刊行して以降, 筆者にとって「 AM の適用事例を作る 」ことが大きな課題として残されていました. 幸いにも, 2003 年から社内開発でアジャイルなソフトウェア開発を適用する機会を得るとともに, 2004 年にはお客様からアジャイルなソフトウェア開発のプロジェクトのお手伝いを依頼されたり, 社内開発で AM を実践する機会を得ることができました. 読者の皆さんが AM を学ぶ際の参考となることを目指して, 今回から数回の連載で AM を実践するために筆者が勉強したり, 考えたり, 実践したことを紹介させて頂こうと考えています. とりあえず, 今回は AM の土台となるアジャイルなソフトウェア開発について説明します. 1. アジャイルなソフトウェ
http://d.hatena.ne.jp/nanoha3/20090305/1236232630 →今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile＋オフショアは無理な組み合わせ？ 非常に困難。 なぜなら、オフショア側からのフィードバックを受け取るのが難しいから。 オフショア側のコーディングミスや仕様理解の誤りなどのフィードバックを受け取ることが難しいため、そのフィードバックをもとにした改良も困難になる。 こちらの仕様や要求の変更をオフショア側に伝えるのも難しい。 （厳密な仕様を作って伝えるくらいなら、こちらでコードを書いた方が早いと思う） コーディングスキルが無ければ、オフショア側が作ったコードの品質もチェックできないだろうし。 ビデオ会議やメールで、相手の理解度のチェックや、こちらの仕様を理解させるのは非道く疲れることですし（
id:nanoha3さんよりトラックバックをいただいた。 大規模プロジェクトでagileやった結果がこのざまだよ 知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 消されないうちにトラックバック返しておきます。 所感 ちょっと無茶があった感じはする。 という自分も、Agileわかってない状態でAgile開発して痛い目にあった経験はある。 なので、今回の結果を分析して、次回以降の挑戦につないでほしい。 間違っても「だからAgileはダメだ」なんて思わないことだろうね。 ウォーターフォールを支えるフレームワークは経験の蓄積と共に肥大化する。肥大化したことが逆に頼もしく思えて、そのフレームワークに依存し続ける。イノベーションのジレンマ的展開。 この対策は簡単。 今のフレームワークであと何年生き残るかを経営が判断すれば良い。 そして、その先を担う新たな世代に対し
http://d.hatena.ne.jp/nanoha3/20090305/1236232630 http://d.hatena.ne.jp/masayang/20090305/1236278171 経由 今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。 必要とされるスキルに対して、個人のスキルが足りないケースが多かった。→今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile＋オフショアは無理な組み合わせ？ チーム人数が多いため、コミュニケーションがうまくいかない。→これはagile固有の問題かな？ 既存のIT系人材のコミュニケーション能力の問題もある。 それは大規模が原因ではない気
知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 【状況】 ・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。 ・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。 →クリティカルなシステム（例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム）をagileでやるのは、先が読めないからいかんとのこと。 【問題発生】 /結局SI側もクライアント側もあまりagileを理解してなかった系 ・今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。 ・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。 →今
ちょっと古いけど、こんな記事があったので訳してみた。 Allan's Blog: Failures in Agile process?(Agileでの失敗?) ACCU*1の会議でよく受ける質問に「Agile開発の欠点は？」「Agileでの失敗はどんな感じなの？」というのがある。 一つ目の質問には答える事ができなかった。ただ、プロダクトオーナーに負担がかかりやすい、という問題点はあるかもしれない。通常はビジネスアナリスト、製品マネージャ、顧客、あるいは顧客窓口の人がプロダクトオーナーになるのだけど、とても負荷のかかる仕事だ。このあたりはJames Nobleが研究しているね。 プロダクトオーナーは本来の仕事をこなしつつ、Agileチームの相手をすることになる。Agile開発チームの生産性があがってくれば、チームはプロダクトオーナーに「あれはどうするの？」「これはどうするの？」と色々と質問す
InfoQ: Refactoring Not a Substitute for Design リファクタリングは設計の代わりにはならないよ 2009年2月9日 Chris Sims 「設計ってリファクタリングの一部なの？」という質問を受けた。この質問の背景には、Agileにおける設計の考え方に関する勘違いが見受けられる。よくAgileな人は「テストしろ！ コード書け！ リファクタリングしろ！ 以下繰り返し！」とマントラのように繰り返す。でも、このやり方が設計を置き換える事はない。プロジェクトにおいて一連の作業が延々と繰り返されているだけなんだ。 Phil Hがこんな質問をしてきた： 新しいやり方ってのは、まずとにかくコードを書いて初期イタレーションの目的を達成し、それから必要に応じてリファクタリングを行い、洗練していくっていうことらしい。コードは漸増的に増えていく一方、全体的な設計はしてい
画面設計とか外部設計とか、もうやめようよにおいて 「権限」「ステータス」など、システム内部の話がでている。→明らかに実装と要件とを勘違いしている。 と書いたら「権限って要件じゃないの？」という問い合わせをいくつかいただいた。 できるだけ簡単・簡素に考えよう 例えば「水泳選手として、指定した水泳種目の記録を折れ線グラフで見ることができる」というストーリがあったとする。*1 ここで「水泳選手を特定するために認証を実装する必要がある」と考えちゃう時点で、余分なことを考えちゃっている、と言ってよい。 極端な話、マイケル・フェルプス専用の端末を用意し、彼しか入れない部屋にそれを設置すれば、認証の実装は不要なのである。 「そんなのインチキ」と思うかもしれない。 でも、実際に開発する場合には認証もへったくれもなしで実装・テストしておいて、後から権限や認証を実装するほうが、開発もテストもすっきりする...
「リーンソフトウエア開発」の著者で知られるメアリー・ポッペンディーク氏。ムダを徹底的に排除するトヨタ式改善は，アジャイル開発の源流であるという。リーンソフトウエア開発の利点と現場における実践テクニックを語った。 IT業界で30年の経歴を持ち，ソフトウエア開発の問題解決に取り組む。トヨタ式改善に出会ったのは，米3Mでビデオテープの生産プラントのITマネージャを務めたとき。現在は，リーンソフトウエア開発の導入コンサルティングを手掛ける米ポッペンディークLLC社長。アジャイルアライアンスの運営委員 欧米では今，「リーンソフトウエア開発」と呼ぶ考え方が広がりを見せている。もともと「リーン（Lean）」という言葉は，ムダ取りをベースとした生産管理手法として，1980年代に広く知られていた。そう，トヨタ式改善のことだ。 2000年以降，リーンの考え方がソフトウエア開発にも拡大。ムダを徹底的に排除するソ
Agile開発の話をすると、ほぼ必ず出てくるのが「うちらは大規模開発だから。Agileなんて無理でしょ。」という指摘。 「あ〜そうですか〜 大変ですね〜」と頷きながら、「本当は『大規模開発』と『大規模な開発』を履き違えているんだろこの野郎」と心の中では思っているのであった。 Slashdot: Hello World? That's easy!より引用: public interface MessageStrategy { public void sendMessage(); } public abstract class AbstractStrategyFactory { public abstract MessageStrategy createStrategy(MessageBody mb); } public class MessageBody { Object payload;
「レガシーシステムとは？」と訊かれたら、自分は迷わず「Agileで作られてないシステム」と答える。 Java(servlet直呼び出し)で書かれた古いシステムをRailsで書き直したことがあるけど、非常にコンパクトなコードになってしまった。むしろ周囲が「これで旧システムと互換性あるの？」と心配したくらいである。 で、同じような案件がないか調べていたら次の短論文を発見。 An Agile Approach to a Legacy System(PDF、英語) 例によって無断適当に邦訳。長文注意。 An Agile Approach to a Legacy System Chris Stevenson and Andy Pols 概要: 本稿では小規模かつ自発的に形成されたXPチームがいかにしてぐちゃぐちゃな問題を抱えたシステムをきれいにしていったかを解説する。我々はレガシーアプリケーションを
『アジャイルレトロスペクティブズ』読了。献本感謝。 GoF本がデザインパターンの教科書であり、XP本がソフトウェア開発の手法に関する教科書だとすれば、本書はチーム開発における「ふりかえり」の教科書であると言ってよいのではないだろうか。 本書では、「ふりかえり」に関するパターンが50近く紹介されているのだが、一つ一つがとても実用的かつユーモラスにまとめられている。 本書で紹介されている方法はゲーム的で、模倣可能で、隠れてしまっている改善へのヒントを引き出すものとなっている。 以下、おもしろかったものをいくつか、コメントを交えて。 ■ アジャイルレトロスペクティブなチーム まずいきなりインパクトがあるのが、アジャイルレトロスペクティブなチームの会議の例。一見何ともない普通の会議に思えるが、この箇所だけ見ても、明確なゴールと時間の設定、冒頭に全員に発言させる点など、参考になる点がいくつもある。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く