Scrumプロジェクト開始のベストプラクティス #RSGT2018
みなさんこんにちは。@ryuzeeです。 2018年1月11日から13日まで開催されているRegional Scrum Gathering Tokyo 2018で登壇いたしましたので、資料を公開します。 今回は、実際にスプリント1を開始する前にどのような準備をしておけばよいかがテーマです。 スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。またスプリント中の次以降のスプリントの準備としてプロダクトバックログのリファインメントを実施します。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。 では、これらはどこから出てくるのか、どのように作っていけば良いのか、という話になります。 資
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない - arclamp
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。 Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。 というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる
アジャイル開発と反復開発の落とし穴
前回「『現状のソフトウェア開発は間違っていないか？』（プロセス編）」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発（*1）やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 （*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
アジャイル型開発の重要性とは？ - 株式会社ヴェス
アジャイル型開発の重要性とは？ 従来のウォーターフォール型開発における課題を解決し、手戻り工数を削減！ 近年、激しくなり続ける市場競争はソフトウェア開発においても例外ではなく、今まで以上の短納期が求められています。しかし、従来通りのウォーターフォール型開発の場合、あらかじめ全体の機能設計を済ませてから機能を実装するため、開発着手までにどうしても時間がかかってしまいます。さらに、テストで不具合が発覚すると、後半になればなるほど手戻り工数が大きくなってしまうため、開発途中での仕様変更・追加対応が困難となります。 そこで近年注目されているのが、「アジャイル型開発」による市場投入までの期間短縮であり、競争の激しい分野において採用例が増えてきています。
エンタープライズアジャイル徒然草 | オブジェクトの広場
本コラムでは、筆者が「エンタープライズアジャイル」に関係すると判断した雑多なトピックスを徒然なるがままに取り上げて論じていくつもりである。第 1 回は、筆者が最近執筆に関与した書籍「エンタープライズアジャイルの可能性とその実現への提言」 [1] 向けに執筆した「よく見られるアンチパターンと落とし穴」を掲載する。 エンタープライズアジャイルの実現を阻む障害を理解するために、本記事では日本の企業でアジャイル開発を行う際のアンチパターンを説明する。従来の開発方法に大きく手を加えないアジャイル開発風の開発を行うことでは、アジャイル開発の良さは現れないことがよく分かるだろう。 1. 「うちでもアジャイル開発やってみました」アンチパターン 日本の企業でアジャイル開発を試みる場合、明確な失敗ではないものの、単発のお試しで終わることも多いように思える。これを「うちでもアジャイル開発やってみました」アンチパ
DevOpsに関する12のアンチパターン
みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います！ えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける
「なんちゃってアジャイル」15のアンチパターン | Biblichor - scent of classics
ユーザーメリットを早期に実現するため、迅速かつ適応的にソフトウェア開発を行う「アジャイル開発」。 うまく実施できれば素晴らしい力を発揮するのだが、ややもすると「なんちゃってアジャイル」に陥ってしまうことも…。 過去のプロジェクトの経験から、プロジェクト進行のなかで陥りがちな「なんちゃってアジャイル」の罠と、それを引き起こすカンチガイの原因についてまとめてみた。 チーム環境 "なんちゃってスクラム"編 「アジャイル開発」に必須なのが、チームメンバーが協働で目標に向かうための環境づくり。 以下のことが起きていたら要注意。 1. プロジェクトの目標があいまい プロジェクトの目標について、プロダクトオーナーとスクラムマスターで言っていることが違う場合は要注意。 2. リリース時期が決まっていない プロジェクトのリリース時期が決まっていない場合や、簡単に変更になる場合は要注意。 ずるずると「リリース
アジャイル型開発におけるプラクティス活用事例調査
アジャイル型開発における プラクティス活用事例調査 調査報告書 ～ガイド編～ 平成 25 年 3 月 19 日 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター はじめに 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センタ ーでは、 「日本のソフトウェア産業の競争力を強化すること」 、 「エンジニア 1 人ひとり が生き生きと働ける環境を作ること」を目指すべきゴールとして、 「日本国内における 非ウォーターフォール型開発の普及促進」と「わが国のソフトウェア産業の特性に照ら した非ウォーターフォール型開発の課題解決」を目標に掲げ、平成 21 年度から調査検 討に取り組んで参りました。その中で、開発手法の実践的な解説書と実例やテクニック 等の工夫を取りまとめた Tips 集を、 広く一般に公開することか求められていることが 分かりまし
アジャイル開発でよく見られるアンチパターンと落とし穴、その対策
■ 本章では、アジャイル開発に取り組む際の典型的なアンチパターンをまず説明する。さらにそのようなアンチパターンを防ぎ、アジャイル開発をよりよく活用したり、導入するための提言を当勉強会の実行委員の講演に基づき提供する。 エンタープライズアジャイルの実現を阻む障害を理解するために、まず日本企業でアジャイル開発を行う際の失敗例について触れておこう。現状の開発方法に大きく手を加えずにアジャイル開発の形だけをなぞってみることは、ネガティブな影響しかもたらさないことがよくわかるだろう。 2.1.1. 「うちでもアジャイル開発やってみました」アンチパターン 日本の企業でアジャイル開発を試みる場合、明確な失敗ではないものの、単発のお試しで終わることも多い。これを「うちでもアジャイル開発やってみました」アンチパターンと名付けてみる。 このアンチパターンの各ステップには、さまざまな落とし穴が存在する。落とし穴
アジャイル開発を支えるアーキテクチャ設計とは
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
延びた“そうめん”の固まりのような、旧態依然としたシステムをデジタルトランスフォーメーションに導くための3つのポイント
旧態依然としたシステムに見られる3つの特徴 テクノロジーの力で新しい価値や利便性を生み出す「デジタルトランスフォーメーション」に向けた取り組みでは、エンドユーザーの支持を獲得するために、ニーズの変化に合わせてアプリケーションを改善し続けていくことが欠かせない。優れた体験価値を担保するためには、フロントエンドのアプリケーションのみならず、そのバックエンドを含めた、“システム全体”にもニーズの変化に即応できる柔軟性が求められる。 言い換えると、ビジネスを向上、成長させるためには、システム全体をビジネスに合った形に最適化し続ける「モダナイゼーション」が必要となるわけだが、「旧態依然としたシステムを抱えた企業は大きく3つの問題に悩んでいます」とレッドハットのテクニカルセールス本部 プリンシパルソリューションアーキテクト BRMSエバンジェリストである梅野昌彦氏は指摘する。 「最大の問題は、アプリケ
なぜ超高速開発が話題になるのか～キーワードはビジネスルール管理システム(BRMS) - プログラマの思索
最近なぜ超高速開発が話題になるのか、何となく分かった気がした。 ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 超高速開発先進国、知られざる韓国企業の実態 - サムスン電子に見る「威力」：ITpro NC特集 - 「超高速開発」が日本を救う：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第3回 ビジネスの俊敏性を実現する：ITpro 俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第4回 スマートなシステムを生み出す：ITpro ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経 ビジネスルールとビジネスプロセス（その1） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その2） | 株式会社ＫＢマネジメント ビジネスルールとビジネスプロセス（その3） | 株式会社ＫＢマネジメント ビジネスルールと
ウォーターフォールとアジャイル開発はどちらが優位か？ “超高速開発”を含めて、JUASが3手法の分析結果を公表 | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ 開発ツール／プラットフォーム ＞ 調査・レポート ＞ ウォーターフォールとアジャイル開発はどちらが優位か？ “超高速開発”を含めて、JUASが3手法の分析結果を公表 開発ツール／プラットフォーム 開発ツール／プラットフォーム記事一覧へ [調査・レポート] ウォーターフォールとアジャイル開発はどちらが優位か？ “超高速開発”を含めて、JUASが3手法の分析結果を公表 2015年4月20日(月)田口 潤（IT Leaders編集部） リスト 日本情報システム・ユーザー協会（JUAS）は2015年4月15日、「ソフトウェアメトリックス調査2015」の概要を発表した。今回は、開発生産性を高めるものとして関心が高まっている、アジャイルと超高速開発のアプローチについて、その実態を明らかにする試みをしているのが特徴だ。 ウォーターフォール型開発（W
製造業がアジャイル開発を実践するには？ デンソー デジタルイノベーション室長に聞く「イノベーションの前提条件」
製造業がアジャイル開発を実践するには？ デンソー デジタルイノベーション室長に聞く「イノベーションの前提条件」：DX全盛時代、求められる企業、頼られるエンジニアとは？（2）（1/3 ページ） ITでビジネスに寄与する「攻めのIT」という言葉が叫ばれるようになって久しい。だが多くの企業において、成果に結び付かない単なる掛け声に終始してきた傾向が強い。では、この言葉の真意とは何か――デンソーで「攻めのIT」を実践、リードしているデジタルイノベーション室長 成迫剛志氏に、今、企業とエンジニアが持つべきスタンスを聞いた。 X-Techに象徴されるデジタルトランスフォーメーション（以下、DX）のトレンドが進展し、ビジネスは「体験価値の競争」「ソフトウェアの戦い」に置き変えられつつある。これに伴い、ITサービスの「企画力」と、それを形に落とし込む「スピード」が差別化の一大要件となっている。 何より重要
Agile2017参加レポート - LINE ENGINEERING
By Hiroyuki Ito | 2017.11.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINEのSET（Software Engineer in Test）のItoです。 世界最大のアジャイルのカンファレンス「Agile2017」に参加してきました。 今年は8月7日から11日にかけて、アメリカのフロリダ州オーランドで開催されました。 この記事では、LINEでのSETの仕事と関連付けて、以下の観点からこのカンファレンスをご紹介します。 テスト自動化の進
開発文化を育て広げる愉しみ - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの@yokotaso です。 先日のCybozuTechConference 2017で、「開発文化を育て広げる愉しみ」という内容で登壇させていただきました。 発表内容のカンペを公開します。 かわゆいまとめをしていただいたので、お忙しい方はこちらをどうぞ！ 文章にはなってしまいますが、どうぞ！ 「開発文化を育て広げる楽しみ」という話をさせていただきます。今日は宜しくお願いします。 2011年にサイボウズ新卒入社の横田と申します。Webアプリケーションエンジニアとして主に働いております。 本題の前に 本題に入る前にすこしお話しさせてください。 まずはチーム開発開発体制について。 ユーザー管理などの管理機能の開発を行なっています。 日本で開発と上海で試験の2拠点体制です。 開発のScrum化の波に乗りまして、我々もScrumを採用しています。 Scrum 開始
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟
カンバン方式を適用する間違った理由と正しい理由
スクラムの７つの罪とアジャイルのアンチパターン
オープンソースのTrelloライクなカンバンボードシステム・「Restyaboard」
