header image

Ryuzeeについて

mixi Twitter Twitter

Categories

Archives

携帯対応

QRコード

RING

人気ブログランキング

新着記事

テスト自動化について5分で分かるまとめ add Hatena Bookmark
2010/08/29 21:23:04 Agile・生産性向上 none Comments

紺屋の白袴ということで、試行錯誤中ではあるのだが、自戒を込めてまとめておく。

テスト自動化/テスト駆動開発について

  • XPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つである。
  • このプラクティスのみで１冊の本が書けるくらい奥が深い
  • 基本的な方法
    • 失敗するテストを書く
    • できる限り早く、テストがパスするような最小限のコード本体を書く
    • リファクタリングをする
  • 適用範囲
    • 通常では、独立性の高いクラスやファンクションへの適用が良い。
    • GUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい。
    • 既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。従って新規プロジェクトの初期から導入することが望ましい。
  • 問題点
    • 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識するテストコードに適合していることのみが保証される。

自動化されたテストが満たすべき性質

テストは以下の条件を満たしている必要がある。

  • 簡単実行
    • テストの準備に大量の時間や人手がかかるようにしない
  • 自己検証
    • テストが成功したか、失敗したかはプログラムが判断する。（人手で判断しない）
  • 繰り返し可能
    • 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと
  • 独立性
    • 環境や外部のコンポーネントに依存しないこと
    • テストケースの実行順序に依存しないこと

自動テストをどこまで作るべきか？

  • テストの自動化にはコストがかかるため、自動テストによるカバレージを100%にすることを目標としてはいけない
  • バグが無いソフトウェアは本当に良いソフトウェアなの？
    • 顧客のビジネス価値の実現に寄与できるのが良いソフトウェア
  • XPでは、「問題の発生しそうなところはすべてテストせよ」と言っているが、全てをテストせよ、とは言っていない。
  • カバレージ100%への最後の数%はいばらの道。残り数%のテストに、いままで作ったテストと同じだけの労力を必要とすることになる。
  • 常に品質最優先ではなく、コスト・スケジュールと照らし合わせた割り切りも必要。

テスト自動化のレガシープロジェクトへの導入

  • レガシープロジェクトとは？
    • 自動化されたテストが備わっていないプロジェクトのこと。
    • 利用している言語やフレームワークには関係ない。
  • レガシープロジェクトの問題点
    • 機能追加や改修の際に、現行機能に問題がないことを保証するためには、人力による再テストを実施するしかない。
    • 従って機能追加・改修が度重なるたびに、テストのスコープが膨れ上がり、開発コストの増大につながる。
    • 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい。
  • どうやって導入するか？
    • 結合テストレベルのテストを先に用意し、想定されるアプリケーション全体の動作をチェックできるようにする。
    • これによって内部的なロジックを変更した場合でも、アプリケーション機能が壊れていないことは担保できる。その状態で、現行モジュールの修正に際しては、可能な範囲で、ユニットテストが可能になるように作り替えていく。（詳細はレガシーコード改善ガイドを参照のこと）
    • テストモジュールについてはSelenium等を利用すると良い。
    • 新規開発のテストにおいて、SeleniumでHTTPリクエストをトレースする形でテストを作成するのは難しい(UIの変更が頻繁に起こる可能性がありテストのメンテナンスコストが高い)が、一方でUIが既に存在するアプリケーションのSeleniumでのテストは書きやすい。

レガシーコード改善ガイド (Object Oriented SELECTION)

著者／訳者：マイケル・C・フェザーズ

出版社：翔泳社( 2009-07-14 )

定価：￥ 4,410

Amazon価格：￥ 4,410

大型本 ( 472 ページ )

ISBN-10 : 4798116831

ISBN-13 : 9784798116839

ということでレガシーコードと格闘中orz

[Agile]指示待ちしてしまうメンバーをどう扱うか add Hatena Bookmark
2010/08/27 12:37:43 Agile・生産性向上 1 Comments

よくある質問に適当に答えるコーナー第二回？。
前提は、アジャイル開発を採用しているシステム開発の場合で、ウォーターフォールでの開発や、その他の業界なんかはまったく想定していないし、ターゲットにしていない。

質問：自分のタスクが終わったら、周りを気にせず帰ってしまう人がいて困っています。

質問：メンバーが指示がないと作業が進められないと言って、待ちになってしまい、生産性があがりません。

回答

1)自分のタスクが終われば帰ってしまう人は、どんな価値を実現しているのだろうか?

顧客の価値を実現するために行動していないよね?
こうなってしまうひとつの理由として、その担当者からお客様が見えていな い、ビジネスの価値が分かっていない、という点があげられると思う。従って、とにかくお客様のところに連れて行き、お客様が何を考えているか理解させるようにすべき。
エンジニアはモノを作るのが仕事なんじゃなくて、価値を実現するのが仕事。

そもそも自分のタスクってなんだっけ？というのもある。Scrumであれば、タスクは自分でサインアップすることになるので、チームがコミットしたゴールに向けて、残っているタスクを自分でサインアップしてこなしていかなければならない。
スクラムマスターがタスクの割り当てをしてしまうから、自分のタスクが終わったら帰ってしまうメンバーが出てきたりするのではなかろうか？
なお、付き合い残業しろ、とかいうつもりはサラサラ無い。そんなの糞だ。
あくまで、チームとして(PMが勝手にではなく)コミットしたものがあるのにも関わらず、そのチームのコミットに対して責任を持たない人をスコープにした話である。

2)チーム内のコミュニケーションを活性化させる。

帰ってしまう人がいるチームは、往々にしてチームのコミュニケーションがうまくいっていない。
個人としてではなく、チームとして成果を出すんだ!という前提のもとに全員の問題をいつでも気軽に話せるようにしなければならない。話にくい雰囲気が出来ると、隠ぺい、先延ばしが発生してリスクになる。

3)勤務評価の軸を「顧客からの満足度・信頼度」やチームメンバーからの「信頼度」においてみると良いかも。

※評価を行える人にならないと無理な方法だけど、オープンな評価軸は組織の透明性を強化し、組織力の向上につながる。

4)待ちになってしまう人への対処は、ペアプログラミングやペアレビューによる地道な教育も効果的。

待ちになってしまう人は、技術力がない、とかチームのやり方が分からない、等といった理由で待ちをしてしまうことも多い。
技術を身につけ、チームのやり方に慣れるためには、その人をひとりにせず、ペアで活動すると良い。徐々に慣れてくるだろう。
日本のほとんどの企業はOJTでは数年上の先輩１人にくっつく形だが、アジャイルなOJTでは、チーム全体で人を育成することになる。
チーム全体がメンバーの能力を向上させる責任を負っている、と考えるべきだ。

5)何をやってもダメなら。

残念ながらそういう人がいるかもしれない。チームにずっとそういう人がいるとチームの士気が低下して周りにも影響を及ぼすようになる。上長と相談してメンバーを入れ替える、といった対忚が必要になる場合もある。

[Agile]似非アジャイルって何ですか？ add Hatena Bookmark
2010/08/25 15:55:29 Agile・生産性向上 none Comments

いままでアジャイルコーチ稼業をしてきて、よく聞かれた質問があるんだけど、それへの答えを定期的に掲載していってみようかと思う。もし質問があったらコメントでもTwitterでも何でも良いのでいただければ、速攻でブログに私見を書いていきます。

【質問】似非アジャイルって何ですか？

回答

例として以下のようなものがあげられると思う。他にもあるだろうけど代表的なところでは

  • アジャイルの4つの価値(ツールより人と人とのコミュニケーション、包括的なドキュメントより動作するソフトウェア、契約よりも顧客との協働、計画の遵守よりも変化への対応、をそれぞれ重視する)に反している
  • 開発すべきもの、期間が決まっている。
  • 顧客への確認にきっちりした資料が必要になる。
  • スクラムマスターがPMのように振る舞い、チームメンバーに全指示を出している。それによってチームが自律的に機能しない
  • チームが顧客の価値の実現のために働いていない
  • プラクティスのつまみ食い
  • プラクティスへの形式的な準拠に終始し、改善のプロセスが働いていない
  • コミュニケーションに形式が要求される。コミュニケーションが電子媒体に偏重して行われる
  • 問題が起こったときに個人が攻撃される
[Agile][翻訳]アジャイル関連書籍ベスト100 add Hatena Bookmark
2010/08/20 05:20:27 Agile・生産性向上 1 Comments

Top 100 Agile Booksというテーマで、Jurgen氏が書かれていたので、どのくらいの本が日本で翻訳されてるんだっけ？という興味もあり、日本語化されているものはその旨追記してみた。

なお、Jurgen氏によれば、Amazonで、「この本を買っている人は合わせてこれも買っています」みたいな情報によって本の一覧を抽出し、ランキングについては、AmazonとGoodReadsというサイトのデータを参考にして重みづけして集計したとのこと。

本が売れないから邦訳が出るのを時間をかけてまっても仕方ないという気もするので、この本翻訳まだー？みたいな人は英語で読んでしまうと良いのではないかと思う。

  1. Agile Estimating and Planning

  2. Clean Code: A Handbook of Agile Software Craftsmanship

    • Robert C. Martin
    • 2008
    • Clean Code

    • Clean Code アジャイルソフトウェア達人の技

      著者／訳者：Robert C. Martin

      出版社：アスキー・メディアワークス( 2009-05-28 )

      定価：￥ 5,040

      Amazon価格：￥ 5,040

      大型本 ( 528 ページ )

      ISBN-10 : 4048676881

      ISBN-13 : 9784048676885

  3. Working Effectively with Legacy Code

    • Michael Feathers
    • 2004
    • レガシーコード改善ガイド

    • レガシーコード改善ガイド (Object Oriented SELECTION)

      著者／訳者：マイケル・C・フェザーズ

      出版社：翔泳社( 2009-07-14 )

      定価：￥ 4,410

      Amazon価格：￥ 4,410

      大型本 ( 472 ページ )

      ISBN-10 : 4798116831

      ISBN-13 : 9784798116839

  4. Refactoring: Improving the Design of Existing Code

  5. The Art of Unit Testing: With Examples in .Net

    • Roy Osherove
    • 2009
  6. Agile Software Development, Principles, Patterns, and Practices

  7. The Pragmatic Programmer: From Journeyman to Master

    • Andrew Hunt, David Thomas
    • 1999
    • 達人プログラマー―システム開発の職人から名匠への道

    • 達人プログラマー―システム開発の職人から名匠への道

      著者／訳者：アンドリュー ハント デビッド トーマス

      出版社：ピアソンエデュケーション( 2000-11 )

      定価：￥ 3,990

      Amazon価格：￥ 3,990

      単行本 ( 333 ページ )

      ISBN-10 : 4894712741

      ISBN-13 : 9784894712744

  8. Kanban: Successful Evolutionary Change for Your Technology Business

    • David J. Anderson
    • 2010
  9. Succeeding with Agile: Software Development Using Scrum

    • Mike Cohn
    • 2009
  10. Growing Object-Oriented Software, Guided by Tests

    • Steve Freeman, Nat Pryce
    • 2009

  11. User Stories Applied: For Agile Software Development

    • Mike Cohn
    • 2004
  12. Lean Software Development: An Agile Toolkit

    • Mary Poppendieck, Tom Poppendieck
    • 2003
    • リーンソフトウエア開発～アジャイル開発を実践する22の方法

    • リーンソフトウエア開発～アジャイル開発を実践する22の方法～

      著者／訳者：メアリー・ポッペンディーク トム・ポッペンディーク

      出版社：日経BP社( 2004-07-23 )

      定価：￥ 2,520

      単行本 ( 307 ページ )

      ISBN-10 : 4822281930

      ISBN-13 : 9784822281939

  13. Domain-Driven Design: Tackling Complexity in the Heart of Software

    • Eric Evans
    • 2003
  14. The Art of Agile Development

  15. Making Things Happen: Mastering Project Management

  16. Agile Principles, Patterns, and Practices in C#

    • Robert C. Martin, Micah Martin
    • 2006
  17. Agile Testing: A Practical Guide for Testers and Agile Teams

  18. Practices of an Agile Developer: Working in the Real World

    • Venkat Subramaniam, Andy Hunt
    • 2005
    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

      著者／訳者：Venkat Subramaniam Andy Hunt

      出版社：オーム社( 2007-12-22 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 220 ページ )

      ISBN-10 : 4274066940

      ISBN-13 : 9784274066948

  19. Behind Closed Doors

    • Johanna Rothman, Esther Derby
    • 2005
  20. Applied Software Project Management

    • Andrew Stellman, Jennifer Greene
    • 2005
  21. Agile Project Management: Creating Innovative Products (1st+2nd Edition)

  22. xUnit Test Patterns: Refactoring Test Code

    • Gerard Meszaros
    • 2007
  23. Scrum and XP from the Trenches

    • Henrik Kniberg
    • 2007
  24. Implementing Lean Software Development: From Concept to Cash

    • Mary Poppendieck, Tom Poppendieck
    • 2006
    • リーン開発の本質 ソフトウエア開発に活かす7つの原則

    • リーン開発の本質 ソフトウエア開発に活かす7つの原則

      著者／訳者：メアリー・ポッペンディーク トム・ポッペンディーク

      出版社：日経BP社( 2008-02-07 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 336 ページ )

      ISBN-10 : 482228350X

      ISBN-13 : 9784822283506

  25. Agile and Iterative Development: A Manager’s Guide

  26. Writing Effective Use Cases

    • Alistair Cockburn
    • 2000
    • ユースケース実践ガイド―効果的なユースケースの書き方

    • ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

      著者／訳者：アリスター コーバーン Alistair Cockburn ウルシステムズ株式会社 山岸 耕二 矢崎 博英 水谷 雅宏 篠原 明子

      出版社：翔泳社( 2001-11 )

      定価：￥ 3,990

      Amazon価格：￥ 3,990

      単行本 ( 330 ページ )

      ISBN-10 : 4798101273

      ISBN-13 : 9784798101279

  27. Refactoring to Patterns

  28. Agile Coaching

    • Rachel Davies, Liz Sedley
    • 2009
  29. Agile Retrospectives: Making Good Teams Great

  30. Agile Adoption Patterns: A Roadmap to Organizational Succes

    • Amr Elssamadisy
    • 2008
  31. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

    • Johanna Rothman
    • 2009
  32. The Principles of Product Development Flow: Second Generation Lean Product Development

    • Donald G. Reinertsen
    • 2009
  33. Scaling Software Agility: Best Practices for Large Enterprises

  34. Crystal Clear: A Human-Powered Methodology for Small Teams

    • Alistair Cockburn
    • 2004
  35. Requirements by Collaboration

    • Ellen Gottesdiener
    • 2002
  36. Agile Software Development with Scrum

  37. The Productive Programmer

  38. Organizational Patterns of Agile Software Development

    • James O. Coplien, Neil B. Harrison
    • 2004
  39. Agile Project Management with Scrum

    • Ken Schwaber
    • 2004
  40. Extreme Programming Explained: Embrace Change (1st+2nd Edition)

    • Kent Beck, Cynthia Andres
    • 1999
    • XPエクストリーム・プログラミング入門―変化を受け入れる

    • XPエクストリーム・プログラミング入門―変化を受け入れる

      著者／訳者：ケント ベック

      出版社：ピアソンエデュケーション( 2005-12 )

      定価：￥ 2,415

      Amazon価格：￥ 2,415

      単行本 ( 189 ページ )

      ISBN-10 : 4894716852

      ISBN-13 : 9784894716858

  41. Managing the Design Factory

    • Donald G. Reinertsen
    • 1997
  42. Manage It!: Your Guide to Modern, Pragmatic Project Management

  43. Leading Lean Software Development: Results Are not the Point

    • Mary Poppendieck, Tom Poppendieck
    • 2009
  44. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2009
  45. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2008
  46. Agile Software Development: The Cooperative Game (1st+2nd Edition)

    • Alistair Cockburn
    • 2001
    • アジャイルソフトウェア開発

    • アジャイルソフトウェア開発 (The Agile Software Development Series)

      著者／訳者：アリスター・コーバーン Alistair Cockburn

      出版社：ピアソン・エデュケーション( 2002-08-30 )

      定価：￥ 3,360

      Amazon価格：￥ 3,360

      単行本 ( 400 ページ )

      ISBN-10 : 4894715791

      ISBN-13 : 9784894715790

  47. Test Driven Development: By Example

    • Kent Beck
    • 2002
    • テスト駆動開発入門

    • テスト駆動開発入門

      著者／訳者：ケント ベック

      出版社：ピアソンエデュケーション( 2003-09 )

      定価：￥ 3,150

      Amazon価格：￥ 3,150

      単行本 ( 217 ページ )

      ISBN-10 : 4894717115

      ISBN-13 : 9784894717114

  48. Continuous Integration: Improving Software Quality and Reducing Risk

    • Paul M. Duvall, Steve Matyas, Andrew Glover
    • 2007
    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法

    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法

      著者／訳者：ポール・M・デュバル スティーブ・M・マティアス アンドリュー・グローバー

      出版社：日経BP社( 2009-08-06 )

      定価：￥ 3,360

      Amazon価格：￥ 3,360

      単行本（ソフトカバー） ( 304 ページ )

      ISBN-10 : 482228395X

      ISBN-13 : 9784822283957

  49. Collaboration Explained: Facilitation Skills for Software Project Leaders

    • Jean Tabaka
    • 2006
  50. Changing Software Development: Learning to Become Agile

  51. Ship it! A Practical Guide to Successful Software Projects

    • Jared Richardson, William A. Gwaltney
    • 2005
    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

      著者／訳者：Jared Richardson William Gwaltney Jr. でびあんぐる

      出版社：オーム社( 2006-08-26 )

      定価：￥ 2,730

      Amazon価格：￥ 2,730

      単行本（ソフトカバー） ( 224 ページ )

      ISBN-10 : 4274066568

      ISBN-13 : 9784274066566

  52. Agility and Discipline Made Easy: Practices from OpenUP and RUP

  53. Refactoring Databases: Evolutionary Database Design

    • Scott W. Ambler, Pramodkumar J. Sadalage
    • 2006
    • データベース・リファクタリング

    • データベース・リファクタリング

      著者／訳者：スコット W アンブラー ピラモド・サダラージ

      出版社：ピアソンエデュケーション( 2008-03-26 )

      定価：￥ 3,780

      Amazon価格：￥ 3,780

      単行本 ( 330 ページ )

      ISBN-10 : 4894715007

      ISBN-13 : 9784894715004

  54. Managing Agile Projects

    • Kevin J. Aguanno
    • 2005
  55. Beyond Software Architecture: Creating and Sustaining Winning Solutions

    • Luke Hohmann
    • 2003
  56. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders

    • Andrew Stellman, Jennifer Greene
    • 2009
  57. Beautiful Testing: Leading Professionals Reveal How They Improve Software

    • Adam Goucher, Tim Riley
    • 2009
  58. Managing Agile Projects

    • Sanjiv Augustine
    • 2005
  59. Lean-Agile Software Development: Achieving Enterprise Agility

    • Alan Shalloway, Guy Beaver, James R. Trott
    • 2009
  60. Agile Product Management with Scrum: Creating Products that Customers Love

    • Roman Pichler
    • 2010
  61. Implementation Patterns

    • Kent Beck
    • 2006
    • 実装パターン

    • 実装パターン

      著者／訳者：ケント・ベック Kent Beck

      出版社：ピアソンエデュケーション( 2008-12-22 )

      定価：￥ 2,310

      Amazon価格：￥ 2,310

      単行本（ソフトカバー） ( 208 ページ )

      ISBN-10 : 4894712873

      ISBN-13 : 9784894712874

  62. Extreme Programming Installed

    • Ron Jeffries, Ann Anderson, Chet Hendrickson
    • 2000
    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き

    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

      著者／訳者：ロン・ジェフリーズ アン・アンダーソン チェット・ヘンドリクソン

      出版社：ピアソン・エデュケーション( 2001-08-10 )

      定価：￥ 2,520

      Amazon価格：￥ 2,520

      単行本（ソフトカバー） ( 348 ページ )

      ISBN-10 : 4894714914

      ISBN-13 : 9784894714915

  63. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams

    • Greg Cohen
    • 2010
  64. Balancing Agility and Discipline: A Guide for the Perplexed

    • Barry Boehm, Richard Turner
    • 2003
  65. Effective Project Management: Traditional, Agile, Extreme

    • Robert K. Wysocki
    • 2003
  66. Emergent Design: The Evolutionary Nature of Professional Software Development

    • Scott L. Bain
    • 2008
  67. Fearless Change: Patterns for Introducing New Ideas

    • Mary Lynn Manns, Linda Rising
    • 2004
  68. Stand Back and Deliver: Accelerating Business Agility

    • Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald
    • 2009
  69. A Tale of Two Systems: Lean and Agile Software Development for Business Leaders

    • Michael K. Levine
    • 2009
  70. Just Enough Requirements Management: Where Software Development Meets Marketing

    • Alan Mark Davis
    • 2005
  71. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

    • Lyssa Adkins
    • 2010
  72. Growing Software: Proven Strategies for Managing Software Engineers

    • Louis Testa
    • 2009
  73. Becoming Agile: …in an Imperfect World

    • Greg Smith, Ahmed Sidky
    • 2008
  74. Agile Game Development with Scrum

    • Clinton Keith
    • 2010
  75. Test Driven: TDD and Acceptance TDD for Java Developers

    • Lasse Koskela
    • 2007
  76. The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation

    • David F. Rico, Hasan H. Sayani, Saya Sone
    • 2009
  77. A Practical Guide to Distributed Scrum

    • Elizabeth Woodward, Steffan Surdek, Matthew Ganis
    • 2010
  78. Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development

    • Ken Whitaker
    • 2009
  79. Patterns of Agile Practice Adoption

    • Amr Elssamadisy
    • 2007
  80. Innovation Games: Creating Breakthrough Products Through Collaborative Play

    • Luke Hohmann
    • 2006
  81. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

    • David J. Anderson
    • 2003
    • アジャイルソフトウェアマネジメント

    • アジャイルソフトウェアマネジメント

      著者／訳者：David J. Anderson

      出版社：日刊工業新聞社( 2006-03 )

      定価：￥ 4,410

      Amazon価格：￥ 4,410

      単行本 ( 385 ページ )

      ISBN-10 : 4526056162

      ISBN-13 : 9784526056161

  82. Project Management the Agile Way: Making It Work in the Enterprise

    • John C. Goodpasture
    • 2009
  83. The Software Project Manager’s Bridge to Agility

    • Michele Sliger, Stacia Broderick
    • 2008
  84. Business Agility: Sustainable Prosperity in a Relentlessly Competitive World

    • Michael H. Hugos
    • 2009
  85. The Enterprise Unified Process: Extending the Rational Unified Process

    • Scott W. Ambler, John Nalbone, Michael J. Vizdos
    • 2005
    • エンタープライズ統一プロセス

    • エンタープライズ統一プロセス (Object Oriented SELECTION)

      著者／訳者：John Nalbone Michael J. Vizdos 藤井 拓

      出版社：翔泳社( 2006-07-11 )

      定価：￥ 4,725

      Amazon価格：￥ 4,725

      大型本 ( 400 ページ )

      ISBN-10 : 4798109347

      ISBN-13 : 9784798109343

  86. Kanban and Scrum – Making the Most of Both

    • Henrik Kniberg, Mattias Skarin
    • 2010
  87. Agile Software Development: Best Practices for Large Software Development Projects

    • Thomas Stober, Uwe Hansmann
    • 2009
  88. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

    • Gojko Adzic
    • 2009
  89. Software Endgames: Eliminating Defects, Controlling Change, And The Countdown To On-time Delivery

    • Robert Galen
    • 2004
  90. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process

  91. Agile Software Development Ecosystems

  92. Software by Numbers: Low-Risk, High-Return Development

    • Mark Denne, Jane Cleland-Huang
    • 2003
  93. Scrumban – Essays on Kanban Systems for Lean Software Development

    • Corey Ladas
    • 2008
  94. The Enterprise and Scrum

    • Ken Schwaber
    • 2007
  95. Test-Driven Development: A Practical Guide

    • David Astels
    • 2003
  96. Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed

    • Mario E. Moreira
    • 2009
  97. Testing Extreme Programming

    • Lisa Crispin, Tip House
    • 2002
  98. Patterns for Effective Use Cases

    • Steve Adolph, Paul Bramble
    • 2002
  99. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development

    • Bruce Powel Douglass
    • 2009
  100. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems

    • Jim Highsmith
    • 1999
[Trac][Agile]Agilo日本語版Trac 0.11.7に対応しました add Hatena Bookmark
2010/08/14 18:43:47 Agile・生産性向上, Trac none Comments

Sourceforge.jpで公開しているAgilo日本語版ですが、Trac 0.11.6およびTrac 0.11.7でインストールに失敗する件について対応を行ないました。

入手は以下から。
http://sourceforge.jp/projects/shibuya-trac/wiki/plugins/Agilo_ja

なお、インストール後にプロダクトバックログ画面で、UnicodeDecodeErrorが表示される場合は、http://www.ryuzee.com/contents/blog/941を参照して、sitecustomize.pyを作成してください。

Agiloって何という方は以下のスライドを参照ください。

TracでAgileプロジェクトを可視化する方法
ドキュメントレビューをする際の10のポイント add Hatena Bookmark
2010/08/07 08:47:42 Agile・生産性向上 none Comments

重厚長大なドキュメントなんて、動かないし嘘書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで著しく否定的なんだけど、とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみる。

なお、個人的には、ドキュメントレビューするよりソースをレビューしろ！、という主張。

とはいえドキュメントレビューで肝心なのは、

  • ドキュメントレビューやるなら、その投資に見合う何を得るのか？を決めておく必要がある。
  • 本当にそのドキュメントは必要か？をよく考える（会社のルールだから！という理由は考えていない答えだ）

だと思う。

1. 体裁をレビューするのではなく、中身をレビューする

ひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェックしているケースがあるようだが、そうではなく中身をレビューする。（ただしあまりに体裁がひどい場合は、往々にして中身もひどかったりするのだが・・・）
中身が分からないから体裁をレビューする、というのもあるようだが、そのレビューの結果は、どんな利益を生んでいるのかよく考えるべきだ。
なお、レビューワーはレビュー前に資料を確認しておくべきであることは言うまでもない。いきなり初見の資料を見てレビューできる項目はたかがしれている。

2. 標準化ではなく、顧客や案件ごとに最適化できるような自由度をチームに与える

必要なドキュメントは顧客毎、システム毎に異なる。
常に自社の標準に無理やり押し込めようとするのではなく、案件特性や顧客特性を踏また上で、どのようなドキュメントが必要なのかは最初に考えよう。
そしてドキュメントも常時リファクタリングできるように。

3. レビューの目的を明確にする

レビューは実施することに意義があるのではなく、そこで問題となりそうなことを早期に検出し、将来のリスクを軽減することに意味がある。
レビューワーの時間、参加者の時間を投資するわけだから、その投資に見合うリターンを生むようにしなければならない。

4. 大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す

アジャイルなレビュー。
大量に作ってしまった問題あるドキュメントを修正するのは簡単なことではない。
リスクを早期に検出しクリアにするためには早期レビューと繰り返しが必須である。
次の工程に入る前にとってつけたようなレビューをして、条件付きで承認をする、といったやり方をするチームもあるようだが非効率で、問題の先送りである。

5. レビューでの指摘事項をすべて対応しなければならないとは限らない。チームにとって労力をかけるだけのメリットがあるものから優先順位付けをして実施する

レビューワーは気づいた点を大小問わずすべて指摘するだろうが、それを全て修正する必要が必ずしもあるわけではない。修正にかけるコストと効果を勘案し、優先順位をつけて対応すれば良い。

6. レビューで人格を非難しない

ついついレビューワーは上から目線で、「こんなことも出来ないのか！」みたいなトーンで指摘してしまいがちである。そういうことをしていると、レビューを受ける側は、レビューを通りさえすれば何でもいいや、と思うか、レビューを受けることすら嫌がるようになる。
レビューをする側も、顧客へ届ける製品の品質の一旦を担っていると考えられるので、同じ土俵の上で純粋に同じゴールに向かってレビューしよう。

7. レビューの順番もレビュー効果が高いものから実施すること

同じフェーズの設計書でも、システム内での機能の重要度には差があるはずだ。全部が重要な機能である、というシステムはいまだかつて見たことはない。限られた時間の中で最大の効果を出すためには、アジャイルで構築するフィーチャーに優先順位をつけるのと同様に、レビューする範囲にも優先順位をつけること。
レビューでは100%のレビューカバレージを取ることが目的なのではなく、問題を早期に検出し、将来にリスクを顕在化させないようにするためのものである。

8. 機械的に検証可能なドキュメントのレビューは自動化すること

体裁にこだわっても仕方ないが、字面しか見ないようなチェックであれば、perlのスクリプトなんかでも十分チェックできる。それこそソースコードをコミットする際に、自動でCode Snifferかけるようなもので良い。

9. レビューワーも技術もしくは顧客の業務をしっていること

技術を知らないとアーキテクチャの妥当性や注意すべきポイントの指摘ができない。
業務を知らないと仕様の妥当性が理解できない。
どっちも知らない人がレビューしても字面チェックしかできないので時間の無駄である。

10. レビュー結果はチーム内外含めて共有すること

レビューの結果の中で有意義なものがあれば、チームの中で最大限活用すれば良い。指摘項目の中で簡単に自動チェックできるようなものがあれば自動化も検討すること。

なお、ソースコードのレビューもほぼ同じことが言えるとは思う。

会議で成果を出すための１０の方法 add Hatena Bookmark
2010/07/31 04:56:25 Agile・生産性向上 2 Comments

生産性や品質に問題のある現場の話を聞くと、だいたいの場合、会議のやり方が上手くない。成果を出すことが目的なのではなく、アリバイ作りだったり、会議をすること自体が目的化してしまっているケースが多々ある。
今回はそんな会議をなくし、より会議で成果を出しやすくするための方法を紹介する。なお全部出来てたらかなりすごい。

1. 時間通りに開始する

よくあるのが、会議の開始時間になると、席をたって移動し始めるパターンや、会議室には集まっているんだけど、プロジェクタのセッティングや資料の配布をそこから始めるパターン。
そうではなくて、定刻になったら本題を開始できるようにする。
たとえ、偉い人が参加する会議でも徹底して時間通りに始める。事前に不可避な事情について連絡がなくて会議に参加しない、または遅刻してきた場合は会議での決定事項はその場にいる人に委任したものと見なして良い。

2. 会議を開催する際には、会議の趣旨、ゴール、出席希望者を明示する

ただ出席依頼が来ただけでは、会議に参加する前に、何を準備したら良いか、自分が発表するのか、どういう立場なのか全く分からない。
出席を依頼する側が期待するパフォーマンスを発揮できない可能性があり、お互いにとっての損失だ。

3. 会議の冒頭では、その会議におけるゴールを確認する

ゴールが満たせれば、例え会議室を１時間確保してたって、１０分で終わって良い。
ゴールが明確でない会議はそもそも存在の必要性について考え直す必要がある。
進行役がひとこと「今日のゴールは◯◯です」といえばOK。会議中はゴールに関係ない話は誰もが軌道修正をかけて良い。

4. 会議の終わりには、その会議における決定事項と、宿題事項を再確認する

いくらゴールを明確にして会議を設定して、その場で意思決定を行ったとしても、結論を誤解していたり、聞き漏らしていたりするケースはやはりある。そして次回に向けたアクションを決めないと、せっかく会議で意思決定しても実行に移せなければ絵に書いた餅だ。

5. 会議は定期的に不要かどうかの判断をする

無駄な会議はリファクタリングする。たとえ３０分の会議でも、参加者が１０人いたら５時間分の人件費が掛かっていることになる。
プリンターをカラー印刷するな！とかいうよりも圧倒的にコスト削減、無駄の削減になる。
モノを削るのではなく、不要な時間を削って、投資効果の高いものに時間を使うべし。

6. 会議に関係ありそうだから、という理由で大量の人を呼ばない

原則的に意思決定権を持っている人、専門性ゆえに会議に必要な人、同じ案件の仕事をしているチームメンバーが入れば良い。
単に情報共有が目的ならば、あとから議事録でも送ればよい。
大量の人が参加したあげくに、それぞれが好きなことを言って会議が踊るのはよくあること。無駄。また、いつも発言しない人は会議には不要。呼ぶ必要もなし。

7. ゴールの達成のため、職場の職位を会議に持ち込まない

偉い人がアホなことをいって、咎められないような会議じゃ意味なし。
ゴールを達成することが目的なので、そこでの発言内容をネガティブな人事評価に利用しないこと。こういうことをやりだすとイエスマンばかりになり、会議が顔色伺いの場になり、組織の競争力が落ちる。

8. 長時間の会議を設定しない

人間の脳は長時間集中できるようには出来ていないので、２時間とか３時間の会議を設定しない。学校の授業が小学校４５分、大学でも９０分なのには理由がある。

9. 会議の時間は延長しない

延長を許すとずるずる脇道に逸れたりしやすい。
またブレストのような会議はゴールが不明確なので、なんとなく延長すると時間を浪費するだけ。

10. 就業時間後に会議を設定しない

そもそも人間の脳は朝起床後３時間くらいが一番働きやすく、夜に向かうに連れて疲れがたまり効率が落ちてくる。夜は時間が延びても良いから、とか昼間は忙しいから、とかいう理由で会議を設定する人もいるが、必要な会議なら日中の業務時間中に実施すれば良い。
家庭を犠牲にして良いと思ってる、または家庭に居場所がないオジサンにつきあって会議する必要なし。

[Agile]そもそもアジャイルって何さ？ add Hatena Bookmark
2010/07/22 05:54:12 Agile・生産性向上 none Comments

Q:あなたは以下のどの理由でアジャイルではないのでしょうか？
　以下から１つ以上選んでください。
　a デイリースタンドアップミーティングしていない
　b ペアプログラミングをしていない
　c TDDをしていない
　d 象徴となるような人を雇用していない
　e スクラムマスターがいない
　f イテレーション計画ミーティングをしていない
　g インデックスカードを使っていない

答えはHで、上のどれでも無いです。プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではない。
アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならない。

以下いくつかよくある例や思ったことの補足を。

  • RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、というわけではない。ツールは道具であり、価値の実現に寄与して初めて価値があるといえる。
  • 従って、自分たちにとって価値の実現に寄与できる！と思う機能は現場ごとにも違うだろうし、ツールの全ての機能を使う必要性はない
  • ツールの機能は一般的に「最高にうまくいっているチームはこうしてるよ！」というモデルをベースにして開発されるので、チームの成熟度が低いうちにツール化に走ると、かえって混乱に陥る可能性もある。もちろんツールをうまく使いこなせると生産性はあがる。
  • TDDやCIやペアプロはウォーターフォールにだって適用できるし、やっている現場は多々ある。アジャイルにおけるプラクティスがウォーターフォールにおいて排他なわけではない
  • 一気に完璧なチームが出来上がるわけではなく、チームのアジリティの向上はプロジェクトを通じて改善のループを回して、反映していけるかどうかである。
  • 現状がうまくいっていても、もっとうまくいくかもしれない。改善をやめた時点で、思考停止→組織の力が衰退していく
  • そういう意味でも、アジャイルな開発プロセスを、書面で標準化して守らせよう、というアプローチを全面的に採用しない方が良いだろう。マイクロソフトにおけるVisual Studioの開発は多数のチームから構成される大規模分散開発だが、最低限のルールと品質チェック項目（クオリティーゲート）以外については、各スクラムチームの裁量が多い
[Agile]Agile Conference Tokyo 2010に行ってきた add Hatena Bookmark
2010/07/21 18:58:49 Agile・生産性向上 none Comments

技術評論社さん主催のAgile Conference Tokyo 2010に行ってきました。
スーツ率は半分くらいで、年齢層は30代から40代くらいの人が多かった感じで、いつものアジャイル系のイベントとは若干客層が違う感じかな。
頑張ってまとめようかとも思ったのだけど、その場で相当Twitしたし、かなりの内容をカバーしているかと思うので時系列で引用。
なお赤字は大事だと思うところ。
なんだかんだいって、マイクロソフトさんとIBMさんは別格だなぁ、と改めて思った。これはグローバルの強さでもある。

アジャイルの導入は難しい。これは事実だと思う。顧客もそうだし自社も変えなきゃいけない。現状をただ嘆くだけじゃなくて、あきらめず行動を起こしてすこしづつ変えられるかどうか。

　今日は結構年齢層高い感じがするね #agiletokyo(2010-07-21 10:14:01) link
　会場前方のディスプレイに表示されちゃうからあんまり変なツイートできないじゃんｗ #agiletokyo(2010-07-21 10:18:34) link
　MacBook公称10時間駆動！ RT @hirsato: ところで、Twitter流すのはいいのですけど、みなさん電源もつんですかねぇ。 ^HS #agiletokyo(2010-07-21 10:25:59) link
　去年のコクヨホールのほうが見やすくてよかったです #agiletokyo(2010-07-21 10:27:19) link
　アジャイルに興味はあるけどまだやってない、という人たちが多いのだろうかね。 #agiletokyo(2010-07-21 10:28:51) link
　アジャイルコーチをしてて、ここ１年くらい大分潮流が変わったように見える。客層も以前と違ってきているようだし。 #agiletokyo(2010-07-21 10:34:31) link
　つうかむしろウォーターフォールがなんでうまくいくと思うのかが不思議なんですがね。。 #agiletokyo(2010-07-21 10:39:00) link
　生産性だけじゃなくて、顧客ROIも語って欲しいですよ #agiletokyo(2010-07-21 10:40:02) link
　Scrum of Scrumとか。玉川さんの本が日本語文献としては秀逸 #agiletokyo(2010-07-21 10:40:55) link
　一括請負契約とはなじまないなぁ、とは思う(準委任がいい)のだけど、もし一括請負しても内容の変更を顧客と随時できる関係にあるかどうか、顧客と同じゴールを向いているか、というのも大事だと思います #agiletokyo(2010-07-21 10:45:03) link
　英語だけでいいよｗ #agiletokyo(2010-07-21 10:46:42) link
　開発環境と本番環境やCI環境は揃える方がいいねー。仮想化が解決策だと思うよ #agiletokyo(2010-07-21 10:50:13) link
　常にリリース可能に！ #agiletokyo(2010-07-21 10:52:58) link
　僕も紺屋（コーチ屋）の白袴なんですがね。。。 RT @rajun1971: ここ数日耳が痛い。。。 RT @Ryuzee: 常にリリース可能に！ #agiletokyo(2010-07-21 10:57:35) link
　CI使おう、ユニットテストと結合テスト、受け入れテストの自動化。言うは易し、行うは難しというのが日本の受託開発の現場でしょう。製品開発なら容易だけどね #agiletokyo(2010-07-21 11:00:23) link
　いまの話ってVisual Studioの開発プロセスに似てるね #agiletokyo(2010-07-21 11:03:48) link
　まぁ、アジャイル自体がそもそもリスクマネジメント手法であるといえる。 #agiletokyo(2010-07-21 11:05:24) link
　過去のいかなる環境（断面）も復元できるのが理想型だよね。 #agiletokyo(2010-07-21 11:07:35) link
　コード書いたりテストするのが仕事なんじゃなくて、顧客のビジネス上の成果をあげるのを助けるのが仕事でしょ、と思います #agiletokyo(2010-07-21 11:15:09) link
　ミルズさんとか！　RT @yusukef: 翻訳者がCSMだと もっとこのPrinciplesが効果的に伝わりそうですね #agiletokyo(2010-07-21 11:15:37) link
　それだけじゃないですが。顧客も参加してもらうと良いです。 RT @UnderClock: チーム全員がみんな参加してみたいなところがアジャイルなんですね。
(^_^)
#agiletokyo(2010-07-21 11:18:23)		 link
　コマンド・コントロールからの脱却が必要 RT @materia_x64: 自分はこれだけしかやりません。他は知りませんってのもダメですね RT @diizuka: あなたはこれだけやればいい、という意識では駄目だよね #agiletokyo(2010-07-21 11:22:02) link
　リーンにおけるラインの停止 RT @kyon_twit: 何かトラブルが起きたら、チーム全員が立ち止まること。一人で立ち向かったりしない。トラブル対処者が決まって初めてチームはもとの動きに戻ること。 #agiletokyo(2010-07-21 11:28:15) link
　Fitnessとか使ったりしますね RT @kaorun55: 自動化された受け入れテストはイメージがわかない。どうやるんだろう？ #agiletokyo(2010-07-21 11:29:20) link
　いまのセッションにおいて気をつけないといけないことは、対象のプロジェクトが自社の製品開発や永続的に面倒を見るシステムなのか、作りきりの受託開発なのか、という点だろう。自動化のコストとROIを天秤にかけないと、際限なく自動化すると辛くなる。 #agiletokyo(2010-07-21 11:34:13) link
　そうそう。ビジネス上の価値の実現のためにリリースする。 #agiletokyo(2010-07-21 11:39:03) link
　仮想化とかクラウド使えば大したコストではないと思います。得られるものとの比較でしょうね RT @diizuka: 本番環境を二組用意するコストを経営者が許してくれるかね #agiletokyo(2010-07-21 11:40:13) link
　振り返りとか反省がなきゃ、アジャイルではないと思います #agiletokyo(2010-07-21 11:42:45) link
　本でるんだ！翻訳したいねー #agiletokyo(2010-07-21 11:43:15) link
　おー、以前玉川さんがTwitterで質問求めたパターンがメソッド化されてる。IBMさんさすがですねー #agiletokyo(2010-07-21 11:52:40) link
　大澤さんCSM同期ですねー #agiletokyo(2010-07-21 11:53:00) link
　どうせなら玉川さんがやったもんたメソッドも使ったらさらに驚いたのにｗ #agiletokyo(2010-07-21 11:55:27) link
　RTC Expressは１０ユーザーまで無料です！（とつぶやき隊の前にいっておくｗ） #agiletokyo(2010-07-21 11:56:05) link
　IBMにおける製品開発はかなりアジャイルが適用されているはず。確かアジャイルを採用するかどうかの判定メソッドもあるよね。公開してほしいなぁ #agiletokyo(2010-07-21 11:58:43) link
　以前玉川さんとも話したのだが、大規模開発と大人数開発は違うと思う。 #agiletokyo(2010-07-21 12:02:45) link
　というかメールってコミュニケーションの道具ではすでにない、と思います。伝わったかどうか判らないUDPプロトコルみたいなもんでしょ #agiletokyo(2010-07-21 12:07:12) link
　通常、誰々が何何する、それによって何何を得る、という書き方をする RT @Kyoko_Hattori: 「Story」＝顧客がわかる言葉で書かれた要求。一般的に2週間以内に実行できる要求の単位。 #agiletokyo(2010-07-21 12:22:41) link
　プロダクトバックログのサンプルとか http://bit.ly/9TmDIM #agiletokyo(2010-07-21 12:26:36) link
　NRIの人が質問中。もうアジャイルあきらめた感じじゃなかったっけか。。 #agiletokyo(2010-07-21 12:30:43) link
　TFSも無償版だして欲しいなぁ #agiletokyo(2010-07-21 12:32:08) link
　じゃあ、また@masayangの出番ですね！ RT @samuraiRed: お客様の要望から熱を取り戻しつつありますよ～ RT @ryuzee: NRIの人が質問中。もうアジャイルあきらめた感じじゃなかったっけか。。 #agiletokyo(2010-07-21 12:34:34) link
　しかし大手SIerがゼネコンモデルを維持するのは、レバレッジを多くかけられる、最後は２次請け以降を泣かせてでも利益を確保する、という考えのもとでそうしていて、今構造改革すると売上が減るんじゃないか、という変な危機感をえらい人が持っているんだよね。。。 #agiletokyo(2010-07-21 13:40:39) link
　Scrum的には２～４週が１イテレーションですね。 #agiletokyo(2010-07-21 13:45:36) link
　アジャイルを安い、早い、うまい、みたいに思われると困る #agiletokyo(2010-07-21 13:48:05) link
　大規模アジャイルだとアーキテクチャは前払いするのが定石ですねー RT @yoshidaei: だよなー、アーキテクチャってあまりYAGNIれない。アーキテクチャはagileの課題の一つ #agiletokyo(2010-07-21 14:01:44) link
　そうそう。アジャイルでやったからって１００％成功するわけじゃない（銀の弾丸じゃない）。これもエライ人は誤解したりする #agiletokyo(2010-07-21 14:05:09) link
　えらい人たちはあと数年逃げ切ればよいだけだから RT @wasaist: 一次受けは全然変わってないなぁ。事業部長クラスはセキュリティ面とかのリスク以外、昔のPJの進め方から変わってくれない。 #agiletokyo(2010-07-21 14:07:26) link
　紙ばっか書いて人が作ったものの良し悪しを判断できる能力があまりついてなく、数値的な指標偏重で見ざるを得ないようになってるから RT @wasaist: 最近、システムインテグレータが丸投げしてくるのも原因な気がします。PJ管理だけで開発したことがないから、#agiletokyo(2010-07-21 14:25:40) link
　フェーズ型ウォーターフォールに見えたけど、アジャイル開発ではなく、アジリティ開発と言われれば多少納得かも。 #agiletokyo(2010-07-21 14:39:17) link
　次のアジャイルソフトウェアプロジェクトに使える１０の契約 http://bit.ly/93lTtB これみるといいよ #agiletokyo(2010-07-21 14:40:16) link
　アジャイルプロセスへの期待に、顧客満足度とか顧客ROIは出てこないの？そこはすごい違和感だなぁ #agiletokyo(2010-07-21 14:44:46) link
　この絵だと顧客テストって最後しかないじゃん？ずっと毎イテレーションごととか数イテレーションごとにやれば良いのに・・・ #agiletokyo(2010-07-21 14:48:28) link
　あ、イテレーション中に顧客テストあるのか。 #agiletokyo(2010-07-21 14:52:25) link
　Macbookのバッテリーがなくなった。。。以降iPhoneへ移行(2010-07-21 14:58:02) link
　いや、大規模アジャイルだと定番ですね RT @materia_x64: 各チームにスクラムマスターとかキツくない？ #agiletokyo(2010-07-21 14:59:01) link
　@m_seki あ、そうですね。動くモノを常に顧客が触れる必要はあります。顧客の受け入れテストというコンテキストだとスプリントレビューでのデモとそこからの顧客側の精査かなーともおもうんですが。(2010-07-21 16:20:17) link
　残念だが顧客もまだまだ予算主義。 RT @miholovesq: Jezさんの話は理想的。でも競合他社に「この金額で全部やります！」ってやられちゃうと負けるんだよなあ…。ユーザーメリットで説得したい。 #agiletokyo(2010-07-21 17:58:38) link
　個人的には明らかに他社とは違う生産性と品質を顧客に先に見せられるか。差別化ポイントをみせてこそ、交渉もできようと思ったり。 #agiletokyo(2010-07-21 18:01:55) link
　そもそもSIってのが日本独特で、海外はかなりの割合で自社主導の開発してるからなぁ #agiletokyo(2010-07-21 18:09:13) link
　パネルディスカッションみるかぎり、みんな同じ問題を抱えているような感じだねー。 #agiletokyo(2010-07-21 18:11:52) link
[Agile]スクラムマスターを発狂させる10個のこと add Hatena Bookmark
2010/07/13 20:24:32 Agile・生産性向上 none Comments

Slideshareを見ていたら偶然見つけたのでご紹介。

10 Things To Drive Your Scrum Master Crazy
  1. スプリントバックログの項目ではないタスクをやり続けること
  2. 妨害事項を隠してしまうこと
  3. スプリント中はプロダクトオーナーと決して会話しないこと
  4. Doneの定義を無視すること
  5. スプリントバックログの前で、「俺やることないや」ということ
  6. スプリントレビューのわずか５分前から準備を始めること
  7. スプリント期間中全部を使ってしまうほどのタスクを小さいタスクに分割しないこと
  8. いつも遅刻すること
  9. 次にどのタスクをするべきかいつもスクラムマスターに聞くこと
  10. スクラムミーティングで関係ない話をしたり、誰かと電話していること

心当たりがあったら注意しよう！

 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有


ads

読まなきゃモグリ

Recent Posts

最近のコメント

あわせて読みたいブログパーツ