【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。 本
Scrum is fragile, not Agile – Dennis Weyland's Blog
As the title suggests, this post is about two different aspects of Scrum. The first part deals with Scrum not being Agile and the second part is about Scrum being fragile. Before going more into detail, a short disclaimer: Everything I present in this post (and in this blog in general) is my personal view and does not represent the view of my current employer, my former employers and any future em
ムービングモチベーターズによるモチベーションの可視化 - Qiita
実施手順 事前準備 Management3.0のサイトから １０種類のカード をダウンロードし人数分プリントアウトしてカットし10枚1セットを作っておきます。 プリントアウトできる環境によるかもしれませんが可能ならカラーのほうが10種類が色分けされているので見やすいです。さらに可能ならカードになるような硬めの紙にプリントアウトしたほうが繰り返し使いやすいと思います。 場の設定 進め方にもよりますが十数分から数十分かかりますので会議室などに集まり1人ずつ席について行うのが良いでしょう。 テーマの確認 会社に対するモチベーションなのか、プロジェクトに対するモチベーションなのかなど、テーマによってモチベーションは変わるのでまずはテーマを共有しメンバー全員で認識を合わせます。 カードの並び替え 全員にカードを配り、10種類のカードの並び替えを行います。モチベーションが上がるキーワードを上に、上がら
【資料公開】スクラムの落とし穴 #RSGT2017
みなさんこんにちは。@ryuzeeです。 2017年1月12日〜13日にかけてスクラムのイベントであるRegional Scrum Gathering Tokyo 2017が開催されました。 その中でスクラムでよく起こる問題やその原因・対策に関するセッションを行いましたので資料を公開いたします。 アジャイルなやり方でプロジェクトをやろうとしたときの「あるある」な失敗をまとめたものとなっていますので、いま何となく上手く行っていない気がする方はセルフチェックとしてもご利用いただけるのではないかと思います。内容に関するご質問やご要望がありましたら是非Twitterなどで気軽にお寄せください。 それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-2
アジャイルメトリクス実践ガイド
近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.また、DevOps開発では本番稼働中のシステムについてもレジリエンスの枠組みで障害やバグに関するフィード バックを獲得し継続的に学習する.本講演ではアジャイル /DevOps の品質保証と信頼性におけるメトリクス活用の方法について事例も交えながら紹介する.
Barclayがアジャイル移行で得たもの
スループットの向上，コードの複雑性の低減，運用時の障害減少，デプロイメントサイクルの短縮，チームの幸福度向上 — これらはみな，Barclaysがアジャイル移行で実現したメリットだ。ディシプリンド・アジャイルのアプローチに基づいて実施された同社の移行は，最初の１年間で800以上のチームにアジャイルを採用するという，アジャイルの実践例として最大級のものだ。 InfoQは，Barclay全体のアジリティ能力をリードするJonathan Smart氏と，中核的なアジャイル採用チームのプロダクトオーナであるIan Dugmore氏に，同社のアジャイル移行についてインタビューした。そこで我々が聞いたのは，Barclayがアジャイル実践を決めた理由，採用するアジャイルフレームワークの選択方法，アジャイルが影響を与える目標，チーム間の実践方法の違いへの対処，アジリティ向上のためにBarclayが行なった
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自
チームパフォーマンスモデルとは？
みなさんこんにちは。@ryuzeeです。 人が集まっただけでは機能するチームにならない、というのはみなさんご存知のとおりです。 そしてチームの形成過程をあわらすモデルの1つとして有名なものに「タックマンモデル」があります（こちらを参照）。 今日はもう1つ別のモデルとしてDrexlerとSibbetが提唱している「チームパフォーマンスモデル」を紹介します。 タックマンモデルでは、チームの形成過程は形成期・混乱期・統一期・機能期・解散期の5段階（初期は4段階）で構成されていましたが、このチームパフォーマンスモデルでは、以下の7段階で構成されます。 オリエンテーション信頼の醸成ゴールの明確化コミットメント実行ハイパフォーマンスリニューアルこれらのステージは前半上から下に向います（形成段階）が、この段階では、徐々に制約を感じるようになっていきます。一方で後半に下から上にあがっていく（持続段階）につ
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみた - Grooves開発ブログ
こんにちは、Forkwell事業部の中の人です。 本日は、つい最近 Forkwell Jobs の開発現場で起きたエピソードについてご紹介します。 きっかけはあるメンバーの一言でした。 「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。よし、ここらでおれたちのベロシティをあげて、ビジネスサイドの連中をあっと言わせてやろうぜ！」 この一言で息巻いた我々は、ベロシティをあげることを目標に設定し、ビジネスサイドのホワイトボードに ◯pt / 10pt のような数字を書き加えました。 しかし、すぐに色々な現場を経験してきた他事業部のエンジニアの面々から、ベロシティをあげることを目標にすることには弊害があることを教わることになりました… ベロシティを目標にする弊害 目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る 目先のポイン
企業システムにアジャイルは必要か
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。Read less
今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
富士通がアジャイル受託開発の社内標準を策定、需要増に応える
富士通は、企業向け業務システムの受託開発に向けたアジャイル開発手法の標準モデル「アジャイル開発実践標準」を策定した（図）。2015年4月から社内向けに公開する。アジャイル開発を望む顧客企業が増加していることに対応。ウォーターフォール型開発に慣れた社内技術者に、アジャイル開発の実践的知識を身につけさせる考えだ。 この標準モデルは、初めてアジャイル開発に取り組む技術者を対象にしたもの。プロジェクトの準備フェーズと開発フェーズで必要な作業を記述する。標準の使用に当たっては、「知識の習得だけではアジャイル開発は身につかない」（同社 SI技術本部 システム技術統括部 アジャイル実践センターの和田憲明氏）との考えから、スクラム開発を一通り体験できる実践研修などの受講を求める。 標準モデルの策定と合わせ、2015年4月から社内のプロジェクトマネージャーや契約担当者を対象に、新たにアジャイル開発におけるプ
エンタープライズアジャイルは「アジャイル開発が大人になった姿」らしい - プログラマの思索
日経コンピュータ２０１４年５月号の記事にエンタープライズアジャイルの記事があったのでメモ。 ラフなメモ書き。 【参考】 日経コンピュータ2014.05.15｜HATのブログ リックテレコム 書籍情報「ハイブリッドアジャイルの実践」 ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン: プログラマの思索 【1】日本でもアジャイル開発の流れが来ている、という記事。 平鍋さんが「エンタープライズアジャイルについて、アジャイル開発が成熟した大人になったことの現れ」と評価している文章が興味深かった。 事例はいくつかあがっていた。 但し、佐野さんがおっしゃるように、IBMのRUP発のDADとSAFeの話が中心で、「ハイブリッドアジャイルの実践」本にあるような日本発の事例や運用ノウハウが紹介されていなかったのは残念かな。 僕は、RUPの案件に開発者として携わった経験があるが、正直、WF型開発と
News ＆ Trend - 三菱東京UFJ銀がエンタープライズアジャイル導入、“攻めのIT活用”を実現：ITpro
三菱東京UFJ銀行が、アジャイル開発と従来のウォーターフォール型開発を組み合わせた企業向けシステム開発手法である「エンタープライズアジャイル」を導入する。2014年9月にも社内の標準プロセスとして取り入れ、“攻めのIT活用”の実現を目指す。メガバンクが正式に採用することで、日本でもエンタープライズ分野におけるアジャイル開発の導入が加速する可能性が高い。 3種類の開発プロセスを定義 エンタープライズアジャイルは、数週間の短いサイクルでシステムを段階的に開発してプロジェクトリスクを低減するというアジャイル開発の良さを生かしつつ、全体計画の策定や要件定義、設計といったウォーターフォール型開発の要素を加えたもの。三菱東京UFJ銀行は、システムの段階的な開発に計画、設計といった作業を組み合わせて、エンタープライズアジャイルの社内標準プロセスを策定する。従来は、ウォーターフォール型開発の開発プロセスし
1カ月でプログラム300本を開発・変更、中電CTIの挑戦（上）
IT部門が”儲かるシステム”の実現に貢献するには俊敏さと計画性を両立するシステム開発手法の採用が不可欠。その最有力候補が「エンタープライズアジャイル」だ。アジャイルが本格的な企業システムにも使える新手法へと生まれ変わった。エンタープライズアジャイルの導入に踏み切った、中電シーティーアイ（CTI）の事例を見てみよう。 「多いときは1カ月で300本近くのプログラムを開発・変更する」。中部電力グループのシステム子会社であり、グループのIT部門としての役割を担う中電シーティーアイ（CTI）ビジネスシステム部開発第1グループの大橋正敬リーダーは、当然のように語る。 中電CTIの主要な業務の一つが、発電所の工事案件の管理から資材調達、施工管理までを担う「営業・資材・工事管理総合システム」の開発・運用である。発電所の建設やメンテナンスを担当する、中部プラントサービスが利用している。 ユーザーに相当する中
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソシオクラシ(Sociocracy)3.0を適用したアジャイルプラクティスの実践
Jikkan Kudo
