タグ

agileに関するtmf16のブックマーク (99)

  • フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

    今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな?誰だっけ、それ言ったの?オレじゃねーよ。お前だよ。おめーの

    フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
    tmf16
    tmf16 2017/06/15
    久々にプランニング・ポーカーを思い出した
  • https://www.esm.co.jp/agile/business_plan_esm_agile_div_35th.pdf

    tmf16
    tmf16 2014/08/22
  • 「ピープルウェア」を読んだ - $shibayu36->blog;

    この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ;ティモシー リスター日経BPAmazon このはソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこのの関連する内容に「

    「ピープルウェア」を読んだ - $shibayu36->blog;
    tmf16
    tmf16 2014/03/09
    3版で章追加されてるな。読みたいけど持ってるしな。自分が最初読んだのは10年位前?だけど、問題は解決されてないんだな
  • 開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba

    自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう?と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる

    開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
    tmf16
    tmf16 2014/02/21
  • 英国における巨大アジャイルプロジェクト失敗の原因調査結果

    Spring BootによるBuilding an ith Spring Boot」から、Spring Bootを使ったREST では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    英国における巨大アジャイルプロジェクト失敗の原因調査結果
    tmf16
    tmf16 2013/10/29
  • アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!

    アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは

    アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
    tmf16
    tmf16 2013/07/25
  • アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー

    アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが家/.にて話題になっている。 アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。 しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人は

    アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー
    tmf16
    tmf16 2013/06/07
  • 「正しいアジャイル」でなくてもいい

    34. スケジュール 先行開発チーム 仕様策定チーム 開発チーム 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 ▼先行開発 ベースラインアーキテクチャの策定やコア機能を先行で開 発。何度となくハマったが、難易度の高い部分に取り組んだ ことによって早期に多くことを学習できた。 顧客 10年戦士 5年戦士 13年5月26日日曜日 35. スケジュール 先行開発チーム 仕様策定チーム 開発チーム 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 ▼既存システム調査 既存システム要件/機能を分析し、随時「仕様策定チーム」 と連携。テスト仕様書に積極的にフィードバックし、仕様書 の精度を上げていった。 顧客 10年戦士 5年戦士 13年5月26日日曜日

    「正しいアジャイル」でなくてもいい
    tmf16
    tmf16 2013/05/29
    これ発展させると自分たちをどう変化させれるかの話になっちゃうな
  • 自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!

    現場のオペレーションを改善するために、最初に着手するなら何か?と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要

    自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
    tmf16
    tmf16 2013/05/28
    ふりかえり重要
  • アジャイル開発は工事進行基準と相性が良いという仮説 - プログラマの思索

    アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。 【元ネタ】 Twitter / z200: スクラムを例に取ると、リリース(および検収)と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。 【続報】ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ 販売管理~売上の計上時期(売上計上基準) 【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。 作って納品しておしまい

    アジャイル開発は工事進行基準と相性が良いという仮説 - プログラマの思索
    tmf16
    tmf16 2013/05/06
    言ってることはわかるんだけど、どやってagileで契約するかだなー
  • チケット駆動開発で作業管理はしないほうがいい - arclamp

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

    チケット駆動開発で作業管理はしないほうがいい - arclamp
    tmf16
    tmf16 2013/04/03
  • アジャイルの取り組みが大きく遅れている

    アジャイル開発が盛んな米国に対して、日では依然としてウォーターフォールモデルによる開発が大半だといわれている。実際に、日アジャイルの取り組みが米国のほか英国、ブラジルなどと比べても遅れを取っていることが調査結果からも明らかになった。 情報処理推進機構(中国では低い(図1)。ここで、非ウォーターフォール型開発とはアジャイル開発など、短いサイクルで反復的に開発を進める手法のことである。 アジャイル開発の普及が進まないと、激しさを増す市場や社会環境の変化に日ITが対応しにくくなる恐れがある。技術部 ソフトウェア・エンジニアリング・センター エンタプライズ系プロジェクト 研究員)は、「アジャ

    アジャイルの取り組みが大きく遅れている
    tmf16
    tmf16 2013/01/10
    いつまでたっても普及の兆しなんだよな。まあアジャイルだけが正解って訳ではないので普及が良いことなのかわからないけど
  • NTTデータグループと楽天がアジャイル開発人材育成プログラムを共同開発

    株式会社社:東京都江東区、代表取締役社長:岩 敏男、以下社:東京都目黒区、代表取締役社長:家田 武文、以下楽天株式会社(社:東京都品川区、代表取締役会長兼社長:三木谷 浩史、以下楽天)は、楽天グループの社員を対象としたアジャイル開発人材育成プログラムを共同で開発し、2012年12月より各社社員向けに同プログラムを利用した研修を開始します。 ビジネス環境の変化が早い現代では、お客さまにとっての価値創出のために、ニーズに合致したITシステム・サービスを少しでも早く提供していくことが求められています。このため、アジャイル開発手法の重要性がより増していくことが見込まれ、アジャイル開発人材の育成は急務といえる状況です。 そこで、アジャイル開発分野のプロジェクトマネジメント

    tmf16
    tmf16 2012/11/02
    開発現場の文化が違いすぎるから、間をとって意味ないものができそう
  • あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある

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

    あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある
    tmf16
    tmf16 2012/09/13
    右は勝手に用意できるけど、左はみんなを巻き込まないといけないから大変
  • 『日本のアジャイル開発は成功しない!』

    令和からの働き方について 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 日人の特性上アジャイル開発はまず成功しない。 その理由を如何に書いて行く。 「XPならここで定義されているプロクティスを必ずやらなければならない。」と言うような これをやれば成功する! と言う銀の弾丸っぽい心の拠り所を持ってないと日人は先に進めない。 高度成長期を参考にしてもらえれば分かると追うが、日人はもともと模倣する事が非常に上手い。中国をさんざん批判しているが、過去を振り返ってみると日のやってきた事と今の中国のやっている事は大差がない。日も真似をしてきた文化なのだ。ひとつだけ中国と違う点を上げるとすれば、模倣技術が特筆して高かったことだ。(また、真面目な文化が功を奏して橋の中からゴミが出てくるような事は無かった。) このように過

    『日本のアジャイル開発は成功しない!』
    tmf16
    tmf16 2012/05/31
  • アジャイル開発検定試験の準備委員会を日本IBM、NTTデータ、日立ら7社が設立

    国内のシステムインテグレータ7社が、アジャイル開発ができる技術者の育成とそのスキルの公的な証明を目的にした検定試験の準備委員会「アジャイルソフトウエア開発技術者検定試験準備委員会」を設立を4月13日に発表しました。 設立に参加したのは、トランスコスモス・テクノロジーズ、日IBM、日立製作所。試験の名称は「アジャイルソフトウエア開発技術者検定試験」。 より公的な検定サービスを目指す 準備委員会設立の背景について発表資料(アジャイル開発は来、理解しやすく、ソフトウエアを開発する「人」に重きを置く手法です。しかし、従来の開発手法とは全く違う考え方も含まれるため、プロジェクト内でのメンバー同士の認識の差異により、失敗を招くのではと誤解されている部分も少なくありません。 アジャイル技術者検定は、この

    アジャイル開発検定試験の準備委員会を日本IBM、NTTデータ、日立ら7社が設立
    tmf16
    tmf16 2012/04/18
    開発子会社に検定受けさせてお金を稼ぐビジネス
  • アジャイルネイティブの為の受託開発から離れた理由 - komagataのブログ

    受託開発から離れた理由というエントリーを書きましたが、 「新卒の時からウォーターフォール開発じゃあ既になかった。」 というアジャイルネイティブ(コンチクショウ!)な方には少し分かり辛いかなと思い少し補足を。 受託開発から離れた理由 - komagata (僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。) 「開発会社とクライアント(開発を依頼した会社)の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。 下記は全てフィクションです 開発会社が論文検索システムを4人月(1人月=100万円)と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数(というか土日で仕様

    tmf16
    tmf16 2012/03/27
    この人、自分が経営者になった場合にどの選択肢を選ぶんだろう?
  • 受託開発から離れた理由 - komagataのブログ

    数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今(FJORD, LLC)に至ります。 上記のような事を思った切欠は下記の様なことがあったからです。 中規模の案件 その時、僕はコンシューマ向けのWebシステムの案件を5〜6人ぐらいのチームで取り組んでいました。データベースに保存されたデータをJavaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。 サーバーとFlashクライアントが連携するのでema)に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバー

    tmf16
    tmf16 2012/03/20
  • My first Agile Samurai Dojo Japan

    Arriving in Tokyo a couple days ago, I had the pleasure of attending my first Agile Samurai Dojo. Mike (mee-hey) and Miho were kind enough to pick me up at my hotel where we then proceeded to the agile samurai dojo ai Dojos are self study groups that have sprung up acJapanese translated

    My first Agile Samurai Dojo Japan
    tmf16
    tmf16 2012/03/11
    いいなー
  • ソフトウェア開発に携わるすべての人に捧げる、アジャイルにソフトウェアを開発する為に読むべき15冊 | Act as Professional

    私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を

    ソフトウェア開発に携わるすべての人に捧げる、アジャイルにソフトウェアを開発する為に読むべき15冊 | Act as Professional
    tmf16
    tmf16 2012/01/05