チームで1番弱い子がアジャイルレトロスペクティブやってみたら ・・・1. チームで１番弱い子が アジャイルレトロスペクティブ やってみたら・・・ Yoko Tanaka Osaka Development Group No.2 Ichiba West Japan Section Rakuten Ichiba Development Department Rakuten, Inc. DevLOVE甲子園2014 西日本大会 2014/08/23 今ココ !! 超えられない壁 ノーカット版
アジャイルの「顧客に価値を届ける」の嘘と本当 - mizchi log
酔った勢いでアジャイルについて思うところを書く。 顧客に価値を届けるのは誰か 顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。 難しいことを難しいということ エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。 難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（後編）。Agile Conference tokyo 2011
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 前編に続いて、ファウラー氏の基調講演の様子を紹介しましょう。 （本記事は「マーチン・ファウラー氏が語る、、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011」の続きです） 継続的インテグレーション アジャイル開発の中で重要な「継続的インテグレーション」と「継続的デリバリ」について話そう。まずは継続的インテグレーション。 複数のプログラマが集まって開発しているソフトウェアでは、それぞれのプログラマのコードをマージする作業に苦労する現場を多く見てきた。 あるソフトウェアプロダクトに二人のプログラマ
ソフトウェアデザイン7月号が非常に良いという話。 - 亀岡的プログラマ日記
今月のSoftware Designは非常に面白くてオススメです。 Software Design (ソフトウェア デザイン) 2012年 07月号 [雑誌] 出版社/メーカー: 技術評論社発売日: 2012/06/18メディア: 雑誌 クリック: 60回この商品を含むブログ (4件) を見る Vim/Emacsに目が行きがちなんでしょうが（これはこれで非常に良い記事）、アジャイル特集がとてもいいかんじです。著者はなんと「間違いだらけのソフトウェアアーキテクチャ」の著者、トム・エンゲルバーグ氏（ちなみに、イザヤ・ベンダサン的な意味合いで捉えるべきっぽいですね。某ゴッドハンドなんてどうやって原著から訳したのかと思いましたよｗ） 間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus) 作者: Tom Engelberg,長谷川裕一,土岐
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
モナリザを使った インクリメンタル(漸進的) と イテレーティブ(反復的) の説明 - kawaguti’s diary
Jeff Patton がよく紹介する絵に、モナリザを使ったインクリメンタルとイテレーティブの説明があります。 インクリメンタル = フィーチャごとに作っていく スクラムでは、ユーザーストーリーの独立性を高め、一つ一つのストーリーの独立性を高める事で、スプリント毎に徐々(インクリメンタル)に「出荷可能な増分(Potentially Shippable Increments)」を作っていく、という原則があります。独立性が高ければ、順番を入れ替える事も容易になり、製品開発の方向性を決めるプロダクトオーナーにとっては、現在の状況を見極めてベストな判断を下せる選択肢が増える訳です。 各ストーリーを独立してテストできることで、全体が組み上がった後に膨大なテストをこなすのではなく、各部品(フィーチャー)単位での健全性を確保して、さらに全体を結合したときのテストをしよう、という流れになり、欠陥の発見を早
Scrum概論
Scrum概論 1. Scrum概論 Ryutaro “Ryuzee” YOSHIBAhttp://www.flickr.com/photos/john_scone/493915787// 2. 吉羽龍太郎 アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. 企業のおかれた状況• ビジネスの環境の変化• 迅速な意思決定と具現化が求められる• 変化しないことは市場から見捨てられるリスク がある• 顧客自身が変化していくことが強く求められる• IT投資の目的の変化 – 業務効率化から戦略実現へ – いままではコスト削減、業務
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
第2回 仕組みを育てる | gihyo.jp
すばらしい製品というのは、単に良い習慣の副産物でしかありません。 『Ship It!』（注1） はじめに 本連載では「アジャイルに開発する人達（アジャイル開発者）が開発するからアジャイル開発である」と考え、アジャイル開発者になるために必要なスキルを磨くための習慣を紹介しています（図1)。 図1 アジャイル開発者の習慣 前回紹介した習慣は、習慣を身につけるための習慣（メタ習慣）、「フィードバックを重視する」でした。 第2回である今回は、最初の具体的な習慣として「仕組みを育てる」習慣を紹介します。そのために、アジャイル開発者にとっての「仕組み」とは何か、なぜ重要なのかを説明――する前に、先日体験した印象深い経験について語らせてください。 RubyKaigi2007のDave Thomasとアジャイル 6月9、10日に日本Ruby会議2007（RubyKaigi2007）が開催されました
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
かんばんボードによるプロジェクトの見える化
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
社会的必然性としてのアジャイル - Always All Ways
今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます（笑）。 # 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。 # 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。 元記事ふたつ ウォーターフォールのほうが楽だという話 - 勘と経験と読経 ウォーターフォールの方が楽ですか？ | Ryuzee.com 著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。 まず、両記事を読んで私が感じたのは、（おそらくお二方も承知の上で敢えて書かれているのだと思いますが） 「どちらが楽か」というのは、PMやコーチとしてメン
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
ウォーターフォールの方が楽ですか？
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） (顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身
Redmineでアジャイルチームのスピードやパワーを見える化する
burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか？チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ
インセプションデッキが倒せない
インセプションデッキが倒せない 1. インセプションデッキが倒せない PRESS START @uedayo 2012 2. Question 質問です 3. What’s the HOTTEST topic in “The Agile Samurai”? アジャイルサムライの中で一番ホットなテーマは？ 4. INCEPTION 5. Inception deck, isn’t it? インセプションデッキですよね？ 6. Question もう一つ、質問です 7. How many times have you made an inception deck? 何回インセプションデッキを作ったことがありますか？ 8. Self Introduction Yoshinori Ueda twitter: @uedayo facebook: http://fb.me/yoshinor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】テストについて考える
InfoQ: かんばんとスクラム - 共に最大限に活用する
Agile samuraidojogathering