みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
オランダの金融機関INGが取り組んできたアジャイル型組織への変革が興味深いので、マッキンゼーによる彼等へのインタビューについて冒頭の部分を訳してみました。ぜひ読んでみてください。 マッキンゼー: 「アジリティ」をどう定義しますか? ING: アジリティとはまず「柔軟性」、そして新しい方向に向かってすばやく適応できる組織の力がポイントです。前例踏襲や官僚的な部分を避けて、みんなの力を引き出そうとするわけです。 また、能力が高くバランスの取れたプロフェッショナルを「育成する」という側面も重要です。「アジャイル」であること、は単にIT部門やその他いろいろな部門を「変える」というのに留まりません。大切なのは、End to Endで一貫した原理を持つ、マーケティング、プロダクト、そして営業の専門家、UXのデザイナー、データアナリスト、そしてITエンジニアといった多様な分野の人たちからなるチーム -
テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
昨年12月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長/『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
和田:そうですね。 家永:もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田:それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永:だんだん変わっちゃって。 和田:単なる作り直しをリファクタリングと呼んでいる、それはある。 家永:ちょっと何だかなあという感じ。「えっ!?」と、ドキッとする事があります。 和田:それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永:全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田:そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田:良い面というのはリファ
実践テスト駆動開発の図1–2を参考にいろいろ追記スリーアミーゴスが協力するシステムで具体的に何をつくったらOKなのか(何を作らなくてもよいのか)は、1人のロールで纏めるのは難しく、スリーアミーゴス(ビジネス、開発者、テスター)の3者の協力が必要です。 ビジネス:対象ドメインに詳しい。ユーザストーリーのWhyに詳しい。ビジネス観点で何がシステム必要で不要かを判断できる。開発者:ユーザストーリー実現の技術的手段のHowに詳しい。問題に対するシンプルな解き方の代案を提示できる。対象ドメインをコードで言語化し、理解を深めることができる。テスター:テストシナリオのパターン出し、特に顧客やユーザに損害を与えるであろう盲点の発見が得意。テストシナリオをリスクベースに評価し順序付けを提示できる。早期に何を作り(何を作らないか)のシステムの理解をすり合わせることで、手待ちや手戻りや抜け漏れや不要な作り込みを
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… 1.プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍(初版では1章まるごと、第二版・新訳版では1章で部分的に)では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化(=メンテナンス不能に)になり、作
より良いプログラマになるための実践的アプローチを説く名著 本書は、Andrew Hunt and David Thomas, The Pragmatic Programmer (Addison Wesley, 1999) の日本語版です… 頭から一気に読もうとしない「達人プログラマー」は少し分厚く、内容もスラスラと読めるタイプの本ではありません。内容が難しい箇所もあり、途中で読むのを諦めてしまうかもしれません。発表当時の技術要素でピンと来ない箇所もあるでしょう。(新装版では配慮されて、現代の技術要素も追記されています。)。でも、心配することはありません。エンジニアのキャリアを重ねるなかで、定期的にこの本を開くことで、どんどん味わい深くなるのがこの本の魅力です。 また、同僚とエンジニアとして大切にしたいことを「達人プログラマー」を通じて共有したくなる箇所がいくつか発見できるはずです。私の場合
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
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.
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
原文(投稿日:2010/03/02)へのリンク ソフトウェア開発は、創造的なプロセスである、と知られている。 ソフトウェア開発の動的な環境が無視された、伝統的な方法論の失敗によって、Agile な方法論がかなり人気を得た。Agile 方法論、特に Scrumの採用が増えている。しかし、すべてが Agileでうまく行っているか? Kai Gilb 氏は、そう思っていない。彼は、 Agileには重大な欠陥があると言っている。 氏は、Agile の栄光にもかかわらず、 ある重大な欠陥があるという、 Agile に関する大部分の文書は、その栄光について語っていますが、私は、その欠陥について書きます:欠陥は、非常に深刻なので、もし修正されないと、あなたが好きなAgile手法は、去年の流行りだった、ということになります。 氏は、 AgileやScrumの焦点は、間違っている、と言う。これらは、ステーク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く