[B! アジャイル][開発] Drunkarのブックマーク

ソフトウェア開発プロセスから無駄を省くための7つの方法

コスト/アクティビティの観点から考えると、私たちは開発スケジュールやコスト(20%の遅延)について大きな問題とは思っていませんでした。大きな問題だったのは、統合/メンテナンスです。安定化に2ヶ月ではなく、11ヶ月もかかってしまったことです。サービスパック開発の7ヶ月はリリースとは別で考えていました。メンテナンス予算に含んだのです。リーンの考え方の場合(例えば、顧客の観点から見る)は、以下のような問題が現れます。 12ヶ月の開発計画が23ヶ月かかって顧客に価値を提供することになってしまった(サービスパックを考慮すると30ヶ月)。11ヶ月の遅延。その結果は以下の通り。遅延: 遅れたことは顧客を幸せにしない。コスト: 追加で11ヶ月分のコストを支払い、リリースするためのリソースを確保した。遅延: リリースNを準備している間、準備できないリリースN+1も遅れる。収入: 売り上げがあがるま

Drunkar 2014/08/19

リンク

[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com

みなさんこんにちは。@ryuzeeです。 Scrum CrazyというサイトでスプリントのタスクについてたくさんのTipsがまとめられているのでご紹介します。 Sprint Tasking Tips ここではTipsのタイトルだけ紹介しておきますので、詳しくは上記サイトを参照してください。 Scrum Crazyでは他にも色々なTipsがあるので是非見ておくと良いと思います。正直に見積もり、見積りが正確であることに価値をおく環境を作ることタスクを見積もる際は時間で見積もることを強く推奨実時間ではなく理想時間を使うことが望ましいより粒度を小さくしたタスクにすることを強く推奨1日は5〜6理想時間とすること作業量を見積もるのであって期間を見積もるのではないできるだけアトミックな単位にタスクを分ける「作業中」の状態が2日以上にならないようにするタスクはチームで見積もるスプリント途中での再タスキン

Drunkar 2013/04/29

リンク

かんばん！～もし女子高生がRedmineで「スクラム」開発をしたら

本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法である「スクラム」とプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです ■ 登場人物の紹介

Drunkar 2013/04/27

リンク

チケット駆動開発で作業管理はしないほうがいい - arclamp

先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。チケット駆動開発とウォーターフォールパネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。僕自身はBTS（Bug Tracking Syste

Drunkar 2013/04/27

リンク

アジャイル開発は常識だ - プログラマの思索

アジャイルサムライ著者のインタビューを読んで、心の琴線に触れるフレーズがいくつもあった。感想をラフなメモ書き。【元ネタ】 Jonathan Rasmusson さんインタビュー ( 前編 ) Jonathan Rasmusson さんインタビュー ( 後編 ) 【1】Jonathan さんが「アジャイルサムライ」を執筆した動機の一つは、アジャイル開発をコーチングや導入する時に使いたいためだったらしい。というのも、新たな会社にアジャイル開発を導入する時には、7冊のアジャイル本を読んでから説明しなくてはならなかった、と。ユーザーストーリー、計画、見積りについても10ページの説明で十分だ、と。「アジャイルサムライ」の良い所は、アジャイル開発の概略を網羅的に知ることができる点にあると思う。「アジャイルサムライ」はXPやScrumにも触れているけれど、XPやScrumを全て説明していると

Drunkar 2013/03/12

リンク

DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組

このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。 2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。（元請け会社の2人、当時同じ会社だった先輩、僕の4人）そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは201

Drunkar 2013/01/23

リンク

とりあえず30分でひととおり分かった気にはなれるアジャイル入門

2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-men