14. なぜ、エンタープライズ業界でアジャイル・リーンは普及しないのか？ | fukabori.fm
話したネタ なぜ、企画と開発が責任を押し付け合う会社の前途は暗いのか？ 計画が悪い vs 実装が悪い、というどっちが悪い論 問題の理解と、その実装（人・システム）が時間軸で離れると学習がない、課題の理解は実装で深まる 市場、世界は悠長に回っていない 将棋でのメタファーとRTSでのメタファー 上手くいかないのは全体という前提をどこまで作れるか？ 仕様が固まってから開発の後半で発生する変更を怖がる あたかも世界の時間が止まっているように振る舞う オーシャンズ11 その場の状況にあった計画を立て直していく、情報を得続ける 現代の戦争は火力戦・物量戦から変わってきている 企画と開発も同じコンテキストで話さないと、リアルな変化に追従できない ピラミッド構造は例外処理が役割の1つ 手順書はQ&Aに答えてくれない Q&Aに答えられる人が現場にいない リーンスタートアップやアジャイルなやり方が出てきた背景
クレイの「つくる」「かんがえる」
作りたいものを一緒に考える 何を作りたいのか、どんなニーズを満たすものなのか、どんな問題を解決するのか、喜ばせたい相手は誰か、など一緒にアイデアを詰めていきます。 一緒に考えることで、「作りたいもの」を共有し、認識のズレを無くしていきます。 期間：２週間〜１ヶ月程度 かんがえるシートの作成と共有 ユーザーストーリーマッピングで要件を整理し、チーム全員で共有する ユーザーストーリー作成 ユーザーストーリーの優先順位付け 一番大事な部分の画面設計 1かんがえるシートの作成と共有 かんがえるシートとはアプリやサービス開発前に作るヒアリングシートになります。 サービスの目的やターゲット、開発における優先度を明確にすることで、顧客と開発チームが共通意識を持てるようにします。 http://kray.jp/blog/agile_1/#think 2ユーザーストーリーマッピングで要件を整理し、チーム全員
コミットメントとは何か？ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 昨年夏に同人誌として刊行された「Ultimate Agile Stories」に寄稿させていただいたのですが、昨日のJim Coplien氏の認定スクラムマスター研修でもコミットメントの話が出ていましたので、参考までに僕の考えを転載します。 なお、Ultimate Agile StoriesはIteration2として今年も刊行を計画されるそうなので、是非動向をウォッチしておいてください。昨年は平鍋さんをはじめとする日本のアジャイルコミュニティを牽引するすごい方たちがたくさん寄稿されていました。 システム開発をしていると「コミットメント」という単語をよく耳にするだろう。アジャイル、特にスクラムの文脈においては「コミットメント」は重大な意味を持っている。本稿ではシステム開発における「コミットメント」とは何なのかについて考察してみたい。 1. 辞書の定
スクラムにおいて欠陥をどのように扱うか
みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため対
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
capsctrl
Generated by Hiki 0.8.7 (2007-06-24). Powered by Ruby 1.8.6 (2007-09-24). Founded by kdmsnr.
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-menRead less
Ultimate Agilist Tokyoでアジャイルとテストの話をしてきました - Yasuo's Notebook
11/17に東京のオラクル青山センターで開催されたUltimate Agilist Tokyoに参加しました。 以前、このブログで書いたようにこのイベントは、アジャイル同人誌Ultimate Agile Storiesをキッカケに @papandaさん、@daipresentsさんが中心となって企画、運営をしていただきました。 素晴らしい会場とスピーカ陣、そして参加者の皆さんに恵まれて素晴らしいイベントになったと思います。 Ultimate Agilist Tokyo - 集え、日本の活動家たちよ。 - Ultimate Agilist Tokyo 私は、「アジャイル×テスト開発を考える」というタイトルでアジャイルとテストについての話をしてきました。 この話は、数年前の東京のXP祭りでお話させていただいた内容が元になっており、ソフトウェアテストの同人誌、Software Testing M
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
受託開発から離れた理由 - komagataのブログ
数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今（FJORD, LLC）に至ります。 上記のような事を思った切欠は下記の様なことがあったからです。 中規模の案件 その時、僕はコンシューマ向けのWebシステムの案件を５〜６人ぐらいのチームで取り組んでいました。データベースに保存されたデータをPHPでXMLを返すAPIを作り、Flashで表示するサイトで、時代が時代だったので「このトラフィックをPHPで構築するなんて。Javaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。 サーバーとFlashクライアントが連携するのでAPI（XMLのSchema）に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubのEnterpriseとはいったいなんだったのか - Agile Shibuya github_enterprise
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～