Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/downlo…
最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
クラウド時代の行動改革、変わるもの・変えてはいけないもの ~シニア世代のPM・エンジニアに捧げる熱きメッセージ~ 岡氏からのメッセージ動画はこちら! 中佐藤氏からのメッセージ動画はこちら! セッション概要 企画者:Agile Japan 実行委員 和田 9月下旬頃、岡氏と中佐藤氏からのメッセージ(動画)を公開する。 10月9日に、お二人の対談形式で、シニア世代の復権について深く語り合っていただく。 「対談への参加は本イベントへの申込が必要です」 岡氏は、ZOZOテクノロジーズでアーキテクトを努めつつ、技術コンサルタントとして、なかなか変われない日本の企業に多く関わられている。中佐藤氏は、最近はアジャイル関連の仕事が多いが、本来はオブジェクト指向・モデリングの人であり、同じく多くの日本企業に関わられている。 お二人とも、このままだと日本の企業が衰退すると感じているとのこと。現状を変えるために
本ページは技術評論社様のご厚意により 2015年1月号の『Software Design』の特集として取り上げられた記事を転載させていただいているものです。 受託開発はITエンジニアの間ではネガティブに語られることの多いビジネスモデルです。その一方で、国内IT業界で一番多いモデルでもあります。受託開発の課題解決に目を背けていては、ITエンジニアの明るい未来はなさそうです。本章では、受託開発の課題を改善すべく、「価値創造契約」という新しいビジネスモデルに取り組んだ(株)永和システムマネジメントの事例を紹介します。 はじめに「ソフトウェア受託開発」という言葉を聞いて、読者のみなさんはどんな印象を持たれるでしょうか? 3K、デスマーチ、オワコンといったネガティブな印象を持たれる方も多いのではないかと思います。どうしてこのような印象を持たれるようになったのでしょうか? 受託開発と自社開発ソフトウェ
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン(ソフトウェア)開発とは何か? 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発~アジャイル開発を実践する22の方法~ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感:結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
2人のプログラマーによるペアプログラミング ペアプログラミング(英: pair programming)はソフトウェア開発の手法の一つで、2人のプログラマが1台のマシンを操作してプログラミングを行う手法。 当初は、2人が1台のワークステーションに向かって作業するものだったが、現在では一人で複数台を同時に使ったり、一台に複数台のディスプレイを使うことも多くなり、具体的なやり方は変わっている。 実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。 ペアプログラミングには、以下のような利点があるとされている。上に挙げた項目ほど重要である根拠を示していない。 規範意識の増大。ペアプログラミングでは、個人の作業よりも怠けるこ
複雑な問題に対する完璧なソリューションを一度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくア
エクストリーム・プログラミング、XP(英: extreme programming)は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして[1][2][3]、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。 エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある[2][3][4]。この方
ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。 ペアプログラミング アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である(アジャイルソフトウェア開発宣言)。すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。 この価値観を
Agile software development is an umbrella term for approaches to developing software that reflect the values and principles agreed upon by The Agile Alliance, a group of 17 software practitioners, in 2001.[1] As documented in their Manifesto for Agile Software Development, the practitioners value:[2] Individuals and interactions over processes and tools Working software over comprehensive document
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く