i-like-tdd-16d9ce2c2201
みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
オランダの銀行INGの「アジャイル」な組織作りがとても面白い - グローバル経営の極北
オランダの金融機関INGが取り組んできたアジャイル型組織への変革が興味深いので、マッキンゼーによる彼等へのインタビューについて冒頭の部分を訳してみました。ぜひ読んでみてください。 マッキンゼー: 「アジリティ」をどう定義しますか？ ING: アジリティとはまず「柔軟性」、そして新しい方向に向かってすばやく適応できる組織の力がポイントです。前例踏襲や官僚的な部分を避けて、みんなの力を引き出そうとするわけです。 また、能力が高くバランスの取れたプロフェッショナルを「育成する」という側面も重要です。「アジャイル」であること、は単にIT部門やその他いろいろな部門を「変える」というのに留まりません。大切なのは、End to Endで一貫した原理を持つ、マーケティング、プロダクト、そして営業の専門家、UXのデザイナー、データアナリスト、そしてITエンジニアといった多様な分野の人たちからなるチーム -
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
粘土のように設計して外側のフィードバックループを回す 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （２）
和田：そうですね。 家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永：だんだん変わっちゃって。 和田：単なる作り直しをリファクタリングと呼んでいる、それはある。 家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。 和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田：良い面というのはリファ
燃えろスリーアミーゴス！作れGWT！回せフィードバックループ！〜テスト駆動開発をやめて、なお残すべき習慣とは(6)
実践テスト駆動開発の図1–2を参考にいろいろ追記スリーアミーゴスが協力するシステムで具体的に何をつくったらOKなのか（何を作らなくてもよいのか）は、１人のロールで纏めるのは難しく、スリーアミーゴス（ビジネス、開発者、テスター）の３者の協力が必要です。 ビジネス：対象ドメインに詳しい。ユーザストーリーのWhyに詳しい。ビジネス観点で何がシステム必要で不要かを判断できる。開発者：ユーザストーリー実現の技術的手段のHowに詳しい。問題に対するシンプルな解き方の代案を提示できる。対象ドメインをコードで言語化し、理解を深めることができる。テスター：テストシナリオのパターン出し、特に顧客やユーザに損害を与えるであろう盲点の発見が得意。テストシナリオをリスクベースに評価し順序付けを提示できる。早期に何を作り（何を作らないか）のシステムの理解をすり合わせることで、手待ちや手戻りや抜け漏れや不要な作り込みを
最初からクライマックス！デプロイから始めよう〜テスト駆動開発をやめて、なお残すべき習慣とは(5)
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… １．プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
ソフトウェア開発の基本的な問題〜 18年前からXPが提示するリスクの紹介
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作
忙しい人のための「達人プログラマー」斜め読みガイド
より良いプログラマになるための実践的アプローチを説く名著 本書は、Andrew Hunt and David Thomas, The Pragmatic Programmer (Addison Wesley, 1999) の日本語版です… 頭から一気に読もうとしない「達人プログラマー」は少し分厚く、内容もスラスラと読めるタイプの本ではありません。内容が難しい箇所もあり、途中で読むのを諦めてしまうかもしれません。発表当時の技術要素でピンと来ない箇所もあるでしょう。（新装版では配慮されて、現代の技術要素も追記されています。）。でも、心配することはありません。エンジニアのキャリアを重ねるなかで、定期的にこの本を開くことで、どんどん味わい深くなるのがこの本の魅力です。 また、同僚とエンジニアとして大切にしたいことを「達人プログラマー」を通じて共有したくなる箇所がいくつか発見できるはずです。私の場合
CMMI | CMMI Compatibility | CMMI and Scrum
As an Agile method, Scrum promotes frequent inspection and adaptation, teamwork, self-organization, and accountability. CMMI focuses on improving processes to improve performance. CMMI and Scrum complement each other in ways that enhance the other. Review some of these publications about how these two technologies have worked together successfully: Implementing Scrum (Agile) and CMMI Together, an
agilebok.org - このウェブサイトは販売用です！ - agilebok リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Steve Denning氏、顧客の喜びについてAgile 2011で講演
原文(投稿日：2011/09/03)へのリンク 経営コンサルタントで多数の著書のあるSteve Denning氏は、Agile 2011カンファレンスで2つの講演をした。 Making the Entire Organization Agile（組織全体をアジャイルにする） Creating Customer Delight（顧客の喜びを生み出す） 最初の講演は、大企業において数多くの優れたアイデアが失敗するのはなぜか、具体的事例をあげた説明から始まった。彼は「20世紀のマネジメント」企業における、知識マネジメント、リーン生産方式、優れたマーケティングアイデア、イノベーション、それからもちろん、アジャイルについて調べた。 彼によると、伝統的なマネジメントは互いに連動した5つの原則に基づいているという。 企業の目的はお金を生むアウトプットを作り出すことである マネジャーは個人をコントロールす
The Agile Inception Deck
Download Blank Inception Deck Online course Udemy One area most agile methods are completely silent on is project chartering. Below is a lightweight you can use to fill this gap and get your project headed in the right direction long before the first line of code every gets written. 10 questions to ask at the start of your next project It starts out so hopefully. As you begin the project, you and
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新連載開始 (1)〜技術的負債とダンスを
MY STYLE AGILE!
IT Project Success Rates: 2011 Open Research
Perceive like an Artist – Think like an Ecologist – Act with Clarity and Wisdom: An Emergent Manifesto of Emergent Design « Emergent Performance Consulting
Softwarepassion.se
Microsoft – クラウド、コンピューター、アプリ & ゲーム
InfoQ: Agile と Scrumの重大な欠陥を明らかにする
