「時が来たら習慣を捨てる」というアジャイルプラクティス
@kakutani に献本いただいたアジャイルプラクティスを読了しました。多謝！レビューはこちらに書かせていただいたので、ここでは本を読んで特にいろいろ考えさせられた「習慣」について書いてみようと思います。 偉大なる習慣 現在は若いメンバーと一緒に働いているので、ふりかえりや朝礼の場で習慣の話をします。アジャイルプラクティスに登場するプラクティスでいうならば、 変化についていこう チームに投資しよう 時が来たら習慣を捨てよう わかるまで質問しよう リズムに乗ろう といった「アジャイルさを育む」話が多いです。メンバーにとって耳の痛い内容だったら、きっと「うるさいなぁ」って思われているのでしょう。だって、自分だったらそう思いますし。 ただ、「それでも伝える必要がある」と思うから何回も話します。 中でも、「時が来たら習慣を捨てる」はとても伝えるのが難しい。 うまくいってないことは徐々に意見として
私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由 - カイゼンにっき。
アジャイルがダメだと思う7つの理由 - arclamp にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。 制作（および詳細設計・結合テスト）フェーズの全体スケジュールを見通しやすい 確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。 ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作（および詳細設計・結合テスト）フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。 ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフ
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/ Read less
アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう？ "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか？」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵（たぶんどこかにある４象限の図）がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
プラクティスのCherry Pickingは善か悪か？ - Always All Ways
昨日、Agile Japan 2012が開催されました。私自身は今年は参加していなかったのですが、twitterなどで情報を追う限りでは今年も熱く有意義なイベントだったようです。それらを見ながら感じたことと今まで考えてきたことを合わせて、全体の文脈や空気を読まないまま、思いをまとめてみたいだらだらと書いてみたいと思います。 プラクティスのCherry Picking "Cherry Picking"とは、Wikipediaからその説明を引用すると以下の通りです。 チェリー・ピッキング(英語：cherry picking)とは、数多くの事例の中から自らの論証に有利な事例のみをならべたてることで、普遍的な真理や政治的な妥当性を導こうとする論理上の誤謬、あるいは詭弁術。cherry-pickingの語義はサクランボの熟した果実を熟していないものから選別することであり、転じて「いい所取り」「(特売
はじめての自己組織化
ｽﾗｲﾄﾞｼｪｱ用 ｽｸﾘｰﾝﾃｷｽﾄ 201307研修効果を最大化ﾎﾟｲﾝﾄｾﾐﾅｰ(人事実務ｼﾘｰｽﾞ2013：wb)kkcolumn
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
ゴールに向かうためにサイドチェンジした - 冥冥乃志
私の今までの取り組みと、このところの取り組みの変化を整理したエントリなので長いです。個人的な話なので、ソフトウェア開発全般に適用できる話を期待されている方にとっては読む価値が薄いエントリだと思います。 3年前に初めてすくすくスクラムに参加して以来、すくすくスクラム瀬戸内の代表として小さいながらも勉強会を開催したり、Agile Japanのサテライトを開催したり、自社の開発をアジャイルに方向づけていこうと小さな取り組みをしたりしてきましたが、最近取り組みかたというか自分の活動に対してフォーカスが当たっている個所が変わってきました。そして、その変化のベクトルが今までとは変わった気がしていて、ゴールが変わってしまっていないかと若干不安になっているところもありました。 変化の理由について自分でもいまいち整理がつかなかったのですが、あるエントリがきっかけで自分の中でも少し言葉になってきたのでまとめて
ドラクエXはこうして作られた、大規模ゲーム開発におけるマネージメント方法
ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ ということで、CEDEC 2012ではドラゴンクエストXの世界観を支えるサーバシステムはどのように構成されているのか、ということが講演されましたが、さらにドラゴンクエストという人気作品を制作する上でどのようなマネージメントが行われたのか、ということについても、スクウェア・エニックス開発部所属の荒木竜馬さんが大規模開発ならではの問題やそれを解決するための工夫について語ってくれています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/BM/C12_P0003.html 荒木竜馬： 今日はドラゴンクエストの話ということで、朝早くからたくさんの人にお集ま
アジャイル開発が重視する品質特性～保守性と移植性 - プログラマの思索
ソフトウェアで出てくる品質はとても掴みどころがなく、測定できたとしても意外に役立たない。 そして、従来のWF型開発が重視する品質に対し、アジャイル開発は別の観点の品質特性を重視することによって、ソフトウェア開発のあり方を変えようとしているように思える。 考えたことをラフなメモ書き。 【元ネタ】 Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索 【1】アジャイル開発の本質は小規模リリースだと思う。 いきなり大きな物を作るのではなく、実際に動くものを小さく作り、小刻みなVerUpによって機能拡張も品質も改善していく手法。 その利点は、顧客やマーケットに対し、不完全であってもいち早くリリースできることで、インパクトを与えることができること。 仕様が完全に固まって作るプロダクトアウトの製品よりも、マーケットの動向に合わせて柔軟に計画や方針を変えていくマーケットインの製品に向いてい
スクラムでの初期の見積り
みなさんこんにちは。@ryuzeeです。 よくスクラムで初期見積りってどうやるの？って聞かれますので、思ったことをツラツラと書いておきます。 ちなみに見積りはあたらないので（もちろん当てる努力はしますし、当たった方がいいのは勿論ですが）、そのつもりで考えたほうが良いでしょう。 例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいませんが、一方で開発の見積りは毎回当たると考えちゃうのはどうかしてるということです。 1. 開発初期に全体を見積もるそもそも一発であたる見積りをするのは不可能であるのは不確実性コーンのグラフ等を見れば分かります。 だからといって見積りをしなくてよいわけではありません。 この時点では、分かっている要求をプロダクトバックログに落として、それぞれのプロダクトバックログアイテムをラフに見積もっておきます。 もしプロダクトバックログがないようであれば、そもそも何のため
資料公開 Agile開発ツール導入の勘所
2012年7月18日(水)に行われたAgile Conference Tokyo 2012に登壇してきました。 30分という短い時間(予定通りの長さで延長したわけではありません！)の中で駆け足でAgile開発から継続的デリバリー、継続的フィードバックやALMへの流れ、なぜテスト自動化が求められるのかといった話と、それに絡めたツール導入の方向性の話をしたつもりです。(もうちょっと笑いを誘える流れにしたかったのですが固くてスイマセン) 当日の参加者の方の多くがAgile開発未経験ということで、Agileに関して銀の弾丸を期待していたり色眼鏡で見られていたりする方もいるかもしれませんが、Agileな開発のやり方や各種ツールは目的達成のための道具でしかありません。 全てのプロジェクトをAgileでやるべきだとも思わないし、Agileでやったからといってうまくいくかの保証もない。ツールも同じで高いお
『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』ノート
2012/06/29に開催された『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』のノートです。 "スクラムを学ぶにあたって直面するであろういくつかのケースの中から、自分が話したいケースについてグループを作り、グループ毎に話し合いを行う"というのを2セット行いました。 自分が参加したテーブルの話だけでも、持ち帰れるものがいろいろありました。なのでつい油断してしまったのですが、各テーブルの話し合いの内容については、全く気に留めていなかったという …自分のノートを整理しているときも、それぞれグループ毎にどんな話をしていたのだろうか、ということがたびたび気になりました。勉強会が終った後に皆でしばらく雑談する時間があったので、そのときに聞いて周ればよかったと思いました。せめて成果物（模造紙）の写真くらい撮っていれば …誰かのノートに期待します。 ◆勉強会の大まかな流れ 1. 勉強会の趣旨の説明
非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）を公開
これまでの活動内容報告書・成果物実績非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書（非ウォーターフォール型開発の海外における普及要因編）を公開 近年、アジャイル型開発をはじめとする非ウォーターフォール型開発が、俊敏かつ柔軟な対応が可能なソフトウェア開発手法として注目されています。 米国や欧州では、インターネットビジネス分野などで、ビジネス環境が急激に変化し、それに伴う要求の変化が大きい領域では、アジャイル型開発が急速に普及しています。例えば、米国で2010年に公表された調査(*1)において、ソフトウェア開発プロジェクトの約半数で非ウォーターフォール型開発（アジャイル型開発、もしくはそれ以外の反復型開発手法）が採用されていたことが報告されています。 しかしながら、日本では、徐々に広がりは見られるものの、未だ従来のウォーターフォール型開発が主流であり、非ウォーターフォー
UMTP Japan - 第9回UMTPモデリング技術ワークショップ 議論詳細
それでは、ワークショップを開始します。まず自己紹介から始めましょう。私はこのモデリング技術部会の主査をしているオージス総研の細谷です。社内の所属はグローバルビジネス推進部で、1年ほど前まで上海でオフショア開発の現場のマネジメントをしていました。その頃はUMTPの国際部会の副主査でした。今年度は、中国以外の海外のビジネスパートナーを作ったり、海外拠点向けのシステム開発のプリセールスなどもやっています。その流れの中で、去年の6、7月に平鍋さんと一緒にブラジルに行く機会がありました。私はそれまでアジャイルというものを避けて通っていたのですが、北米などではアジャイルが普通になっていて、北米からの仕事を請け負っているブラジルでもアジャイルが普通です。海外と仕事をするときにはガチガチのウォーターフォールだと人の育成にも時間がかかるし人もついてこないので、アジャイルでできないとだめだなと心を入れ替えて帰
エンタープライズバックログを使って組織をアジャイルにしていく作戦
ANA recruits are given Military Operational Urban Training アジャイル開発系の勉強会に参加したり発表したりするようになって、いろんな方から社内に広げていく方法について相談されるようになりました。 一概に「これ！」という答えはないのですが、今の自分の考えとして「エンタープライズバックログ」という作戦を今日はをご紹介。 例えば小規模プロジェクトで成功事例を作り横展開する作戦 例えば、広めるための作戦として「アジャイル開発導入事例」で「小さなプロジェクトで成功例を作り、横展開やスケールにつなげる」という作戦をたまに聞きます。この方法は本当にスケールするんでしょうか？ なぜなら、チームやグループといった単位で抱える課題は様々で、優先順位も場所によって違います。扱う業務も違えばメンバーも違う。実際に、社内でアジャイルコーチ/トレーナーのような
「7人のアジャイルサムライ」に参加してきました。 #devlove #agilesamurai - ミッションたぶんPossible
4月24日 七人のアジャイルサムライ(東京都) 昨日は、東京：飯田橋のクラスメソッド株式会社で開催されたDevLove主催勉強会「七人のアジャイルサムライ」に参加してきました。 その名の通り、7人で「アジャイルサムライについて語り尽くす」のがこの勉強会の主旨。少人数の座談会形式で、各々持ち寄ったテーマについて、フランクに参加者が意見を出し合いました。 この勉強会、参加者が7名というのが非常にハードルが高くて、「そもそもオレみたいな勉強不足野郎が参加していいんだろうか？」と遠巻きにイベント告知を見ていたのですが、直前で2名辞退し、開催自体が危ぶまれる事態に。こんな面白そうなイベントが中止されるのは勿体ない、だったら力不足でもなんでも参加して開催できるようにしちゃえ！ とばかりに、勢い参加してきた次第です。いやぁ、開催されて本当に良かった。 自己紹介 残念ながら1名は業務多忙で直前辞退。6名で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
History_of_waterfall_append
History of WaterFall
実践アジャイルテスト トークショーつぶやきまとめ #secafe - Yukarin'Note