アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
「終わらなかったから次のスプリントにまわそう」なんてありえない
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
継続的インテグレーション - Wikipedia
継続的インテグレーション（けいぞくてきインテグレーション、英: continuous integration、CI）とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることである。1日複数回行われるのが一般的である[1]。グラディ・ブーチは1991年のメソッド[2]でCIという用語を最初に提案したが、彼は1日に数回の統合を提唱していなかった。エクストリームプログラミング(XP)ではCIの概念を採用し、1日に1回以上、おそらく1日に何十回も統合することを提唱した[3]。 開発者は変更に着手するとき、現在のコードベースのコピーを取って作業する。他の開発者が変更したコードをソースコードリポジトリに提出すると、このコピーは徐々にリポジトリのコードを反映しなくなる。既存のコードベースが変更されるだけでなく、新しいコードを追加したり、新しいライブラリやその他のリソースを追加した
イテレーションとは？スプリントとの違いや開発プロセスを解説！｜ITトレンド
イテレーションとは、一連の工程を短期間で繰り返す、開発サイクルのことです。短いスパンで開発手法を見直す「アジャイル開発」における概念として知られています。 設計、開発、テスト、改善のサイクルを短期間で繰り返すため、問題の発見や改善が容易になります。イテレーション１、イテレーション２、イテレーション３...のように繰り返しますが、１つのイテレーションサイクルは、１週間～４週間ほどになるのが一般的です。 イテレーションとスプリントの違いは？ イテレーションとスプリントは、どちらも開発サイクルを表しますが、それぞれどう違うのでしょうか。 イテレーション：XPで使われる XPとは過去の経験則などから、開発や運用指針をまとめたものです。英名はeXtreme Programing、日本語ではエクストリームプログラミングと呼ばれます。 名前のとおり、ソフトウェア開発の成功例を、極端（＝extreme）に
スクラムマスターの育て方 / Training Scrum Master
スクラムフェス三河の登壇資料です。 https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593
かんばんボードによるプロジェクトの見える化
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
なぜ、マネジメントが重要なのか？ 米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part3
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ！ エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。 ハッカソンがエンジニアにもたらすもの 河野通宗氏（以下、河野）：では、話の続きをやります。（スライドを指して）ハッカソンの力って書いてあるんですけど、ハッカソンって、みなさんどういうイメージを
スクラムとウォーターフォールの違いはどこにあるのか？ シミュレート可能なモデルを構築して検証する
社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ソフトウェアを開発するにあたり「ウォーターフォールモデル」と「アジャイル開発」は比較対象として取り上げられ、どちらが優れているのか、あるいはどちらが正しいのかという議論がよく見られますが、果たして比較可能な対象でしょうか。これらに限らず、さまざまな開発手法の違いを客観的に比較することができないだろうか、といった疑問を持ちました。客観的な基準があれば、何を採用するのかといった議論もスムーズに行えるはずです。任意の開発手法に対する比較は困難ですが、「ウォーターフォールモデル」と「アジャイル開発」に絞ったモデルを作成することで、それぞれの違いを比較できるところまで示すことができました。 開発手法の選択はなぜ難しいのか？ システム開発を進めるための手段には多種多様なものがあり、
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
日本にアジャイルが普及しづらい本当の理由 ～不確実性に向き合うマネジメント論～：新刊ピックアップ｜技術評論社
アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから，日本国内においてもアジャイル型の開発プロセスが注目を浴びて，多くの企業が実践するようになりました。 ところが，世界各国に比べて日本のアジャイル型開発の普及率は依然として低く，理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか，今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても，それが何なのか，けむにまかれたような説明をされてしまい，いまいち納得できないまま始めると言ったこともよく聞く話です。 一体，アジャイルとは何なのでしょうか。アジャイルに限らず，IT界隈にはバズワードとして瞬間的にブームに
「カンバン仕事術」には「始めるのをやめて，終わらせることを始める」ための実践的なアプローチが凝縮されていた - kakakakakku blog
2016年に出版されて，読もう読もうと思いつつ積読になってしまっていた「カンバン仕事術」をやっと読んだ． もう，とにかく良かった．カンバンに限らず，アジャイルな開発プロセスに興味がある人は全員読むと良いんじゃないかと思うほどオススメできる良書だった．僕が推進しているプロジェクトのメンバーに繰り返し，繰り返し説明している話（WIP，終わらせることを始める，振り返り，緊急など）も全て書かれていた．僕自身もっと早く読むべきだったし，メンバーにも読んでもらえば良かった ( ﾟдﾟ)!!! カンバン仕事術 作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘出版社/メーカー: オライリージャパン発売日: 2016/03/26メディア: 単行本（ソフトカバー）この商品を含むブログ (7件) を見る WIP 制限 仕掛りタスク (WIP)
チーム開発における「ニワトリ」が適切に鳴くために - 病みつきエンジニアブログ
アジャイルやスクラムとかの文脈で「ニワトリ」と「ブタ」という概念がある。 その言葉自体は結構ググれば出てくると思うんだけど、一つ寓話を引用してみる。要は、「ニワトリとブタ」のプロジェクトメンバーが「ハムエッグ」を作る上で、「ブタ」は自分の身を削っているのに対し、「ニワトリ」は身を削っていないですね、ということ。 ニワトリとブタがいた。 ニワトリは「さあ、レストランでもやろうよ」と言った。 ブタはよく考えてから「レストランの名前は何にしようか」と言った。 ニワトリは答えた。「ハム・エッグさ」。 ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」 recompile.net ※ 原典は シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」？ 原義からずれるかもしれないが、自分は「ブタとニワトリ」をこう解釈している。 ブタ・・・開発チームのメンバーであり
Joy, Inc. のジグソー法ワークショップ - kawaguti’s diary
Developers Summit 2017 でやった、Joy, Inc. のジグソー法ワークショップの資料を公開しました。Joy, Inc. は2000年代初めからアジャイル開発とデザイン思考を取り入れて顧客を巻き込んだ受託開発を行っている、メンローイノベーションズ社の取り組みについて、ファウンダーであり現職のCEOであるリチャード・シェリダン自らが描き下ろした本です。米国のアジャイルコーチの多くが見学ツアーに訪れる、活きた実例であるメンロー社の徹底した顧客志向の文化に触れることができます。 書籍の無料お試し版(電子版、固定レイアウトのみ Kindle Kobo ほか)がありますので、購入前の方でもこのワークショップを行うことができます。イベントなどでワークショップを行うこともできますので、お声掛けいただければ幸いです。 ジグソー法の読書会への適用は教育心理学概論読書会で試みられ、知識
【資料公開】アジャイル開発プロジェクトの始め方
みなさんこんにちは。@ryuzeeです。 これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。 これもやった方がいい、こういう時にはどうするの？などありましたら是非[Twitter](https://twitter.com/ryuzee)などでお知らせいただければと思います。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-20単行本（ソフトカバー）：288ページISBN-13：9784798163680ASIN：4798163686
グラス片手にアジャイル開発 第2回 － アジャイルの主な実践手法とその取捨選択
第1回ではアジャイル開発の理念や位置付け、特徴について紹介しました。アジャイル開発にはより良いソフトウェアを低コストで、かつ高品質に開発できる大きなポテンシャルが秘められていると感じたことでしょう。今回は、アジャイル開発の代表的な手法「XP」と「スクラム」の特徴を紹介し、これらの手法を実際の開発現場にどのように適用していくのかを示します。 アジャイル開発の代表的手法 アジャイル開発には、さまざまな手法があります。 XP スクラム 動的システム開発手法（DSDM：Dynamic Systems Development Method） クリスタル 機能駆動型開発（FDD：Feature Driven Development） アジャイルユニファイドプロセス（AUP：Agile Unified Process） リーンソフトウェア開発 このように数え上げればきりがないほどですが、この中で人気を二
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
第6回 アジャイル開発でタイム・ボックスを決める---TRICHORDの開発現場から
前回までの平鍋からバトンタッチして，今回から懸田が本連載を担当する。筆者は平鍋が代表を務めるチェンジビジョンで，プロジェクトの見える化ツール「TRICHORD（トライコード）」の開発を担当している。以下では，TRICHORDの開発を例に，Web 2.0時代の軽量開発について具体的に考えていく。 TRICHORDは，先の4月3日に最初の公開版であるバージョン0.1をリリースした（図1[拡大表示]）。TRICHORDは本連載で提唱したコンセプト・アウト/デマンド・イン型の開発プロジェクトとなっている。まだ完成していない状態でプロダクトを世に送り，利用者にそのコンセプトを問うて，フィードバックをもらいながら，プロダクトを育てていこうとしている。 図1 TRICHORDの画面 2006年4月に最初の公開版であるバージョン0.1をリリースした。現時点ではごく基本的な機能しか実装していない。 [画像の
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
かんばん！～もし女子高生がRedmineで「スクラム」開発をしたら
アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟
