おまえらｗｗｗｗいますぐリーン開発の現場 カンバンによる大規模プロジェクトの運営見てみろｗｗｗｗｗ – yutarofuji
リーン開発の現場 カンバンによる大規模プロジェクトという本を読んだ感想です。 開発を効率よく進めたいと思っているWebディレクターやプロジェクトマネージャーに読んで欲しい1冊 ご存知の通りWebシステムやソフトウェア開発を行う上でいくつかの開発モデル(生産方式)が存在し、中でもウォーターフォール・モデルという言葉は聞いたことがある人は多いのではないかと思います。 ウォーターフォール・モデルは歴史も長く、色々な現場で採用されて来ました。しかし、万能というわけにもいかず、近年の開発スタイルには合わない部分も多々出てきているようです。そういった実際の現場に携わる人や、現在の開発方法に限界を感じている人に是非読んで欲しい内容となっています。 実例を交えてストーリー仕立てでリーン開発を解説 リーンという概念は知っておいたほうが尚良い この本の特徴は、実際にリーン開発を採用した開発現場の様子がストーリ
アジャイル導入の「最小限」の読書リスト | ワイクル株式会社
『Manage It! 現場開発者のための達人式プロジェクトマネジメント』などで有名なJohanna（かわいいおばちゃん！）が、「アジャイル導入の「最小限」の読書リスト」を公開していました。 http://www.jrothman.com/services/minimum-reading-list-for-an-agile-transition/ 詳細は原文を読んでもらうことにして、簡単に紹介しておきます（※印は私見です）。なお、あくまでも「最小限」なので注意してください。 スクラム スクラムガイド ↑ だけじゃ足りないので、スクラムの本を何か一冊読むといい ※『エッセンシャルスクラム』（翔泳社）がいいと思います!! カンバン David Andersonの『Kanban』 ※↑はいかにも教科書っぽいので『Kanban in Action』がオススメ。これは来年くらいには……。 XP Ke
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
チームでKPTをやってみました - Wantedly Engineer Blog
エンジニアの森田です。 チームでKPTをやってみました。その時に考えたことなどを書きたいと思います。 社内発表資料です。 KPTとは アジャイル開発や反復型開発ではイテレーション（繰り返しの単位）ごとに作業の振り返りが推奨されるが、そのためのチーム反省会などでよく用いられるフォーマットである。 http://www.itmedia.co.jp/im/articles/0905/19/news143.html KはKeep、PはProblem、TはTryをそれぞれ表します。イテレーションの単位でチームで振り返りを行い、良い点（Keep）、問題点（Problem）、具体的な改善項目（Try）を軸にミーティングをします。基本的な流れは、Problemが具体的なTryになり、Tryが解消したら、消える。またはKeepに昇華します。KeepはProblemやTryに関係なく、上げていくこのが良いと思
鉄板！リーンでアジャイルな開発をするなら読むべき３冊 - bake a cake with our creativeness
こんにちは！ プランナーと開発マネージャーの二足のわらじを履く男、兼城です。 まだ新卒入社２年目なのですが、ここ半年は新規アプリや新規事業の企画・開発マネジメント・実装を担当しており、東奔西走な日々を送っています。 忙しくなってしまうと、つい原理原則を忘れてトリッキーなことをしがちに… 今日は、そんな僕が「原理原則に立ち返るべきだ！」と思った時に読み返す本を３冊紹介します。 リーン・スタートアップのバイブル！
現代のプロマネが知っておきたいアジャイル開発の基礎知識まとめ
まずプロジェクトの「マスターストーリーリスト」を作成します。リスト内のストーリーは「ユーザーストーリー」と呼ばれます。 「どの程度のユーザーストーリーがこなせるのか？」「優先すべきはどのユーザーストーリーなのか？」などを加味し、各イテレーションで開発対象となるストーリーを選定します。 イテレーション終了時にはイテレーション開始前に判断した「ベロシティ」は正確だったか、などを振り返り、以降のイテレーションに組み込んでいきます。このように短い期間で開発を見直すことで、リスクを抑えていくことができるのもアジャイル開発における特徴の一つです。 ※参照 『アジャイルサムライ――達人開発者への道』（オーム社） ブラックアジャイルによろしく（＠IT） その他の開発手法 少し今回の本題からは脱線しますが、アジャイル以外の開発手法について、代表的ないくつかを記載します。 ウォーターフォール プロジェクトが上
書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク - プログラマの思索
【1】「実践反復型ソフトウェア開発」は、アジャイルな開発環境作りに興味のある開発者にお勧めだと思う。 理由は、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念が整理されてまとまっているからだ。 SIの現場では、「実践反復型ソフトウェア開発」に書かれているような概念が暗黙知になっており、本来はベストプラクティスないし守るべき規律としてチームが実践すべきルールが徹底されていない場合が多い。 あるいは、10年以上も以前の古い技術に固執しすぎて、アジャイルな開発を阻害している原因になっている時も多い。 だから、そんな現場には、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念や、ベストプラクティスから得られた形式知をチームで共有して実践すべきだと思う。 僕の感想は以前書いた。 実践反復型ソフトウェア開発を読む part1～ブランチの戦略: プログラマの思索 実践反復型ソフトウェア
プロジェクトマネージャへのお勧めの本 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
開発モデルの作り方(守破離の破)
Regional Scrum Gathering Tokyo 2015 で発表したスライドです。 「[1C-2] 開発モデルの作り方 ～守破離の破！～」Read less
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由 - カイゼンにっき。
アジャイルがダメだと思う7つの理由 - arclamp にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。 制作（および詳細設計・結合テスト）フェーズの全体スケジュールを見通しやすい 確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。 ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作（および詳細設計・結合テスト）フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。 ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフ
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
組織パターンを実践する - Kentaro Kuribayashi's blog
先日(10/30)「ジム・コプリエン (James O. Coplien) : Advanced Scrum - 組織パターンでScrumを微調整する "Scrum Fine-Tuning using Organizational Patterns」という研修 + ワークショップに参加しました。先日刊行された『組織パターン (Object Oriented SELECTION)』に基づき、著者のコープ氏自らによる解説を聞ける貴重な機会でした。 研修について コープさんについては、『組織パターン (Object Oriented SELECTION)』その他の本などの活動により、非常な敬意を抱いているのですが、今回、これまた尊敬する角谷さんに機会を与えていただき参加することができて、とてもよかったです。コープ氏、角谷さんをはじめとするコーチ陣のみなさま、ありがとうございました。 研修の内容は
受託開発でアジャイルソフトウェア開発を始める - @ledsun blog
はじめに 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove - HOW TO GO というブログエントリに 受託でアジャイルはどうなのか？ という記述がありました。世の中には受託でアジャイルをどうやって始めるのか悩んでいる人がいるらしいので、体験談を書きます。 ざっくり言うとハイブリッドアジャイル*1です。 請負契約でアジャイルっぽくやるための方法です。 業務委託で契約できるなら（開発側は）リスクが低いのでその方がおすすめです。*2 それから「ディシプリンド・アジャイル・デリバリー」は未読です。読んだ人には釈迦に説法かもしれません。 三回以上の分割納品 始めるのは簡単です。お客さんにスケジュールを提示する際に納品を3回以上にすればOKです。 最初に提示すれば納品回数を一回に変更したがるお客さんはいません。 同じメンバーで同じシステム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A 2a：アジャイルなオフショア開発
20141213 俺のインセプションデッキ #agilesamurai
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
re:workstyle
「正しいアジャイル」でなくてもいい
授業の資料 #1 - ナイスビア珍道記
