エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）XP 祭り 2016
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
確率的に犠牲的 - steps to phantasien
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
Thoughtworks: Delivering extraordinary impact together
We're a leading global technology consultancy that integrates strategy, design and software engineering to enable our clients to thrive. For over 30 years, we’ve been at the forefront of digital innovation and have vast experience creating adaptable technology platforms, designing world-class digital products and harnessing the power of data and AI to unlock new sources of value. We’re laser-focus
「Appleのソフトウェアへの不満」はOS Xの開発方法にフェデリギの「スプリントシステム」が採用されたからではないか？という匿名の元OS X開発者の書込みが面白い。
HackerNewsは投資会社YコンビネータLLCが運営する掲示板ですが、この掲示板に投稿されたスレッド”Apple has lost the functional high ground“のコメント欄に元AppleのOS Xエンジニアと現Appleエンジニアが書き込んで意見を交わしているとTUAWなどが紹介しています（HackerNewsは匿名性なの話半分ですが）。 元AppleのOS Xエンジニアの書込みは以下の通りで、彼の意見としては「騒がれているAppleのソフトウェア（OS X）の品質の話については昔の方が悪いと思う。昔の方が良かったという方は、古いOS Xが単に古く安定していたからで、近年のOS Xに違和感を覚えているならそれはクレイグ・フェデリギが導入した”スプリントシステム”が原因で更新頻度が頻繁になったからだと思います。」というものです。 Former OS X deve
ZenHub.io - Agile Project Management inside GitHub
AI is radically changing the way that we build software. Yet the way we manage software projects still looks a lot like it did twenty years ago. Engineering teams are still spending hours manually updating project management tools, leading to messy, inaccurate project data. This leaves engineering leaders without a clear view of progress, making it difficult to know whether projects will be deli
プレファクタリング
「プレファクタリング」（Prefactoring）とは、pre（事前に）＋refactoring（リファクタリング）という意味の新造語です。リファクタリングとは、コーディング中にコードの動きを変えずにコードを改善する手法のこと。そして、プレファクタリングは、コーディング前にリファクタリングを行うことで、リファクタリングの効率をさらに上げようというもので、著者のKen Pughが提唱している新しい開発手法です。これにより、開発作業の迅速化、効率化が図れると期待されています。本書は開発者自身によるプレファクタリングについての初の解説書です。 はじめに 1章 プレファクタリングの概要 1.1 プレファクタリングとは 1.2 3つの極度 1.2.1 抽象化 1.2.2 関心事の分離 1.2.3 読みやすさ 1.3 指針の探究 1.3.1 背景状況がすべて 1.3.2 各自のやり方に適合させる 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
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
アジャイルなオフショア開発
タウンワークでは、スマホユーザーに向けたiOS及びAndroidアプリのリリースを通じて、日々数多くの開発を行い、機能改善を続けています。これまでのタウンワークアプリは日本ですべての開発を行ってきましたが、より多くの機能改善を行うために、最近はオフショアチームと協業して開発を進めることに取り組んでいます。 今回の取り組みで特徴的なことの1つとして、オフショアチームのエンジニアと日本チームのエンジニア同士が、共通言語である開発言語を用いてコード上で多くのコミュニケーションを直接行っていることがあげられます。これには、異なる母国語によるコミュニケーションを減らし、エンジニアが得意な開発言語でコミュニケーションを行うことで、相互理解を深めるといった狙いもあります。 本セッションでは、タウンワークアプリ開発におけるオフショアチームの成り立ちや、オフショアチームと日本チームがどのように協業しているの
アート・オブ・アジャイル デベロップメント
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 (著), 角征典 (翻訳): 本
Amazon.co.jp: アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE): James Shore (著), Shane Warden (著), 木下史彦(監訳) (監修), 平鍋健児(監訳) (監修), 笹井崇司 (翻訳), 木下史彦(監訳) (読み手), 平鍋健児(監訳) (読み手): 本
Amazon.co.jp: ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション: ThoughtWorks Inc. (著), 株式会社オージス総研オブジェクトの広場編集部 (翻訳): 本
SCRUM BOOT CAMP THE BOOK | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon
アジャイルサムライの次に読む技術書
