エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）XP 祭り 2016
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
確率的に犠牲的 - Spinach Forest
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
Thoughtworks. AI that works.
Meet Thoughtworks' Agentic Development Platform AI/works™ packs decades of engineering IP into a platform that changes the economics of building industrial-grade systems. With our technologists steering AI/works, you get higher quality systems, delivered at radically lower cost. Faster than you can say “algorithmic bias”. Leaders want AI to work by ‘next Tuesday’. But there are three foundations y
ZenHub.io - Agile Project Management inside GitHub
Advanced sub-issues and issue types have arrived ✨ Learn more →
プレファクタリング
TOPICS Programming 発行年月日 2006年01月26日 PRINT LENGTH 280 ISBN 4-87311-272-9 原書 Prefactoring FORMAT 「プレファクタリング」（Prefactoring）とは、pre（事前に）＋refactoring（リファクタリング）という意味の新造語です。リファクタリングとは、コーディング中にコードの動きを変えずにコードを改善する手法のこと。そして、プレファクタリングは、コーディング前にリファクタリングを行うことで、リファクタリングの効率をさらに上げようというもので、著者のKen Pughが提唱している新しい開発手法です。これにより、開発作業の迅速化、効率化が図れると期待されています。本書は開発者自身によるプレファクタリングについての初の解説書です。 はじめに 1章 プレファクタリングの概要 1.1 プレファクタリ
第1回 連載を始めるにあたって | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人（わだ たくと）といいます。 このたびgihyo.jpにて、テスト駆動開発（TDD）の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演！ リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演！ テスト駆動開発」と「実演！ リファクタリング」は、本誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方
連載：アジャイル開発者の習慣―acts_as_agile｜gihyo.jp … 技術評論社
第4回特別コラム 「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」 角谷信太郎 2008-04-22
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
継続的Webサービス改善ガイド 第2章開発環境の改善 ～技術的負債の返済と、レガシーコードの仕様化テスト 技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられま
アジャイルなオフショア開発
1 2014年9月29日 ＧＭＯインターネット株式会社次世代システム研究室 藤村 新 アジャイルな オフショア開発 ～オフショア開発の動向、問題点とその改善施策～
アート・オブ・アジャイル デベロップメント
TOPICS 発行年月日 2009年02月 PRINT LENGTH 464 ISBN 978-4-87311-395-1 原書 The Art of Agile Development FORMAT PDF アジャイル開発は人のなせる技です。アジャイル開発を極めるためには、その時々で無数の可能性を評価して最善の方策を選択することを学ぶ必要があります。本書は、あなたがアジャイル開発の「道」を極める手助けをしたいと思っています。 本書は、アジャイル開発の実践方法の1つであるXPを中心に解説します。XPの概要と導入について解説し、XPによるアジャイル開発をチームに導入することを目指します。さらにXPのプラクティスについても詳述します。なぜうまくいくのか、うまくいかないのか、繰り返し実践することでXPが身につき、XPの指針を深く理解できるでしょう。最後に、さらなるアジャイルの理解へのアドバイスを
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き: Esther Derby (著), Diana Larsen (著), 角征典 (翻訳): 本
「Appleのソフトウェアへの不満」はOS Xの開発方法にフェデリギの「スプリントシステム」が採用されたからではないか？という匿名の元OS X開発者の書込みが面白い。
Amazon.co.jp: アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE): James Shore (著), Shane Warden (著), 木下史彦(監訳) (監修), 平鍋健児(監訳) (監修), 木下史彦(監訳) (読み手), 平鍋健児(監訳) (読み手), 笹井崇司 (翻訳): 本
Amazon.co.jp: ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション: ThoughtWorks Inc., オ-ジス総研オブジェクトの広場編集部: 本
SCRUM BOOT CAMP THE BOOK | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon
アジャイルサムライの次に読む技術書
