タグ

Agileに関するstray346のブックマーク (11)

  • Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita

    Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)agilelean はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。 今回、このビデオを未熟なりにディクテーションして、適当ですが、日語訳を作ってみました。人に承認を取るつも

    Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita
  • プランニング・ポーカーで始める楽しい見積り - mixi engineer blog

    こんにちは、UX統括部の横幕です。すっかり春になって、桜を眺めるのが気持ち良いですね。 最近、社内で活発に「デイリースクラム」が行われるようになりました。 日々、チームメンバーの持っているタスクの進捗を確認し合うことで、スケジュール感の共有・調整、あるいは、チームメンバー同士でタスクの振り分けを見なおしたりなどができ、チームの有機的な動きを作ることが出来るようになってきています。 さて、そんななかで、今回は、プロジェクトを進める上で、また日々のデイリースクラムをする上で重要な「タスクの見積り」についてお話しようと思います。 これが実際のPlanning Pokerです。アメリカのMountain Goat社が企画発売し、ライセンスしています。 1. 見積る前に 1-1. 計画を立てよう タスクの見積りをする前に、何をするのか、その計画を立てていきます。 ・フィーチャーを考える フィーチャー

    プランニング・ポーカーで始める楽しい見積り - mixi engineer blog
  • プランニングポーカーのやりかた | Ryuzee.com

    かわぐちさんが簡単ガイドを作られていたので僕も普段研修とかコーチングで使っているマテリアルを晒しておきます。 色々なやり方があるので、どれがあってるとか間違っているとかは無いですし、認定スクラムマスター研修なんかでも講師によって若干やり方が違ったりします。一例ということで。 なお、僕が普段コーチをする上でよく言っている点を以下に書いておきます。 大きすぎると見積り精度はどんどん落ちる。ストーリーがでかいと思ったら分割するそれに関連して僕は1,2,3,5,8,13,?くらいしか使わない。20は使う必要ないなぁみんなが似たような数字出したからといって中身の完成イメージが同じとは限らない。見積もる際の議論大事タイムボックス大事。だらだら時間かけてやらないプロダクトバックログの見直し(リファインメント)同様に、見積りも定期的に見直す追記 いま日でプランニングポーカーを入手する方法は以下の通りです

    プランニングポーカーのやりかた | Ryuzee.com
  • Homepage - Flyway

    Increase reliability of deployments by versioning your database Get Flyway for free Stay updated about Flyway Get all the latest guides, community news, product updates, and resources

    Homepage - Flyway
  • 超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ

    「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました(これまでの記事一覧)。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか? 1週間? 1ヶ月? 1年? 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに

    超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
  • あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある

    国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI(継続的インテグレーション)を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人

    あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある
  • アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ

    アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI(継続的インテグレーション)を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう? "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか?」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵(たぶんどこかにある4象限の図)がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え

    アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ
  • モデリングとプログラミングの観点の違い - プログラマの思索

    要求開発の記事を読みながら思ったことをメモ。 #あくまでもメモ書きであり、ロジカルでない。 モデリングとプログラミングは、根底から考え方が違うと思う。 モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。 でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。 モデリングとプログラミングは相互に補完する関係にある。 モデリング技法には、OOAやDOA、他にも色々あるけど、基は、エンティティを中心にその関係を考える。 一方、プログラミングは、基はやはり手続きを考える。 構造化分析とは異なり、モデリングという概念が出てきたのは、DOAからだと思う。 DOAはモデルからデータと処理を区別して、データだけを取り出し、その関係をまとめる手法。 DOAはエンティティという入れ物が最初にありき

    モデリングとプログラミングの観点の違い - プログラマの思索
  • 新人SEがSIerに絶望した時に読みたいスライド4選 - ギークに憧れて

    新社会人の皆さん、いかがお過ごしでしょうか。 最近、SIerに就職した知人が「会社辞めたい」というのをちらほら聞く。聞いてみれば、彼等は仕事で挫折しているわけではない。むしろ、技術に優れ熱意を持っている事が多い。ではなぜ辞めたいのかと聞けば、一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて、「ああ、そっか…そうだよね…。」となる。 そんな時は、SI業界の熱い人達のスライドを見て何かを感じよう!という事で4つ選んでみた。弊社関係者が多いのは僕のネットウォッチの都合上お許しください。moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド。「自分の生き方を他人任せにしない」受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス

  • アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経

    「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である

    アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
  • こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ

    最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今やもしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ

    こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
  • 1