スクラムフェス大阪 札幌トラック「旅するAgile本箱LT」にて登壇した際の資料です #scrumosaka https://www.scrumosaka.org/ https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15351/agilelt-2021
あなたのチームがいくつも未着手の仕事を抱えているとき、どのようにそれらに着手し、そして完了させていったら良いでしょうか? アジャイルには「始めるのをやめよう。終わらせることを始めよう。」という言葉があります。Tebiki株式会社では、この考え方を基本として、 デスクレスワーカーのための現場教育SaaS「tebiki」を開発しています。 この記事では、新しい仕事を「始める」ことを優先する場合と、仕掛り中の仕事を「終わらせる」ことを優先する場合の比較をしながら、かつては「始める」ことを優先していた Tebiki社が「終わらせる」ことを重視するように変わっていった事例を紹介したいと思います。 仕事が「終わる」とはまず前提として、仕事が「終わる」とは、どういうことでしょうか?たいていの仕事では、まず必要な作業を計画し、それを実行することでその仕事を進めるはずです。 それでは、計画していた作業をひと
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! アジャイルコーチの荒瀬です。 ヤフー、および関連会社のアジャイル開発支援や研修を担当しています。 今回はヤフーのスクラム実践者の学習方法についてお話しします。 イベントや研修の中で、スクラムの勉強方法をいろいろな方から質問されることが多かったので、記事にするとより多くの人の役に立つのではないかと思い執筆することにしました。 また、せっかく書くのであれば、ヤフーの中にいるさまざまなスクラム実践者の話も交えると、経験年数別に、より参考になりそうな書籍、セミナーや研修を紹介できるのではないかと考え、ヤフーのスクラム経験者にも協力いただいています。 スクラムを始めた頃の自身のことを考えながら、こういう記事があるといいのにと思
私分かりませんから全てお願いしますは止めろコンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。 自社の業務は理解しておけAccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ?別に業務フロー寄越せとか言ってないぞ。 要求を理解しておけ割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ?」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ!」とキレる役職者まで。コンサルは契約
世の中をみると、官僚的なシステム化と現場主導のアドリブ、二つの世界観に二分されがちです。本当は両者の中間がベストなのに、どうしても片側に寄ってしまうようです。 偏る原因は、おそらく両方が得意な人が少ないため。 このためシステムとアドリブの住み分け、バランスの取り方を人に説明するのは難しいものです。僕も長く悩んでいましたが、最近、ようやく頭の中でメンタルモデル化できました。 岩として考えるシステムとアドリブの特性は、以下のようにモデル化できます。システムは大きな岩。アドリブは多くの小石。 システム化:単一の大きな岩 アドリブ化:大量の小石 システムの考え方平地にドンと置かれた大岩が安定するように、システム化は地盤がしっかりした環境で力を発揮します。また大きな問題をざっくり埋めるような、手っ取り早く80点をとるような場合にも便利です。 一方、大岩を坂道のような不安定な足場に置くと、とても危険で
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 - 調査報告書:みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか? このグラフに当てはまっているでしょうか? もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか? と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん(転職した人)の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか? ・AWSなど
いぐぞー ✈️ 旅するプログラマー @igz0 旅とプログラミングをこよなく愛します。 アメリカ大陸🇺🇸を横断しました!!小学生からプログラミング→新卒SIer→Webに目覚め個人事業主兼会社員。テレビ出演経験あり。 Webサービス制作者。読書・IT関連を中心にツイートします!!ネタツイート有。アイコンは@ixy先生に利用許諾済み。Amazonアソシエイト参加。 note.com/igz0/ いぐぞー ✈️ 旅するプログラマー @igz0 Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」 > アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している これマジ?? 日本のIT企業が、米国では「時代遅れ」のウォーターフォールを未だに信奉してるってコト!? pic.twitter.com/jRofJKmAKM
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する:「単体テストの考え方(UTPPP)」を読む(後編) - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分:UTPPPを読む(前編) - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる? #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの?出来なかったらどうするの?」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
ソフトウェアエンジニアとして働き始めて 20 年以上になります。 元々ソフトウェアでいろいろ作りたくて就いた職業なので、結構な数のプロダクトを開発してきました。 私がメインで開発したもので OSS として出ているものでは、 yrmcds: memcached クローンで、レプリケーション機能などを持つ usocksd: SOCKS4/5 サーバー & ライブラリ transocks: アプリのネットワーク通信を透過的に SOCKS サーバーにプロキシする透過プロキシ coil v2: Kubernetes の CNI ネットワークドライバ moco: MySQL を自動運用する Kubernetes オペレーター accurate: Kubernetes 上で namespace ベースのソフトマルチテナンシーを実現するためのソフトウェア などがあります。これらのソフトウェアの多くは、現役
こんにちは!DA(データアナリティクス)事業本部 サービスソリューション部の大高です。 プロジェクト管理ツールは色々ありますが、スクラム開発を実施する際には一定のお作法などもあり、より特化したツールのほうが利用しやすいかと思います。 今回はそんなプロジェクト管理ツールとして、オープンソースのプロジェクト管理ツール「Taiga」を試してみました。 Taigaとは? Taigaはアジャイルチーム向けのプロジェクト管理ツールです。直感的なユーザーインターフェイスを備えており、また多言語対応もしています。 「Basicプラン」または「Premiumプラン」の2つから、いわゆるSaaS型の利用ができますが、一方でセルフホスティングとして利用することで無償利用も可能です。 今回は、こちらのセルフホスティング型での利用を試してみたいと思います。 前提条件として、Docker環境が必要となるので私はDoc
注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
1. はじめに フロントエンドを始めたばかりの頃、参考書や参考サイトで当然のように使われているものの、特に說明がないような**「慣習」や「テクニック」**に困惑したり、その理由が気になった経験を思い出したので、その一部を簡単にまとめてみました。 2. HTML 2-1. iタグでアイコン HTML の興味深いテキスト要素 (<i>)は、何らかの理由で他のテキストと区別されるテキストの範囲を表します。例えば、技術用語、外国語のフレーズ、架空の人物の思考などです。英文においてはよく斜体で表示されるものです。 <i>: 興味深いテキスト要素 - HTML: HyperText Markup Language | MDN 仕様上は適切な使用方法ではなさそうですが、「Bootstrap Icons」や「Font Awesome」などでも採用されているように、普及している印象があります。 ちなみにHT
以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P2 Agile Testing Fellow https://agiletestingfellow.com/ P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P20 概説テスト分析 http://ww
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな(主に単価的な意味で)と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
Next.js と microCMS と Vercel が面白い。それぞれ面白いし、組み合わせるとさらに面白い。なにせ、メディアサイトがデプロイも含めて 2 時間で出来る。 Next.js + microCMS + Vercel すごいな。メディアサイト(中身スッカスカだけど)がものの 2 時間でデプロイまでできた。 https://twitter.com/yusukebe/status/1435708770705760256 ということで、メディアサイトを作りながら、Next.js と microCMS と Vercel の面白さをまとめる。 2 時間で作るメディアサイト 例として「ラーメンまとめ!」というメディアサイトを作ってみる。このサイトには ラーメン屋 ラーメン屋のまとめ記事 の 2 つの種類のコンテンツがある。「ラーメン屋」が「名前」「場所」「ラーメン写真」というプロパティを持
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに?」「TDDってなに?」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう! スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる 受注側が優秀だと発注側の意思決定の遅さにイライラするし 受注側が未熟だと発注側のイメージが具現化されない 第三者的に両方の場合に遭遇したんだが記録しておきたい 受注側が優秀な場合スプリントのスピードが速すぎて発注側の意思決定が間に合わない 評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる 本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので 最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる 「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる 責任を下位の役職まで委譲しないとアジャイルは成り立たない まぁなのでこういう組織にはアジャイルは向
私は新卒で入社した会社に、 2日目で見切りをつけ、 5日目に最後の出社をし、 15日目で書類上の退職を完了しました。 退職ネタはよくツイッターで書いているのですが、昨年参加させていただいた「新卒退職本5」へ寄稿した文章を元に、ブログ用の記事にいたしました。 これから会社員になる予定の方や、退職するかどうか迷っている方のご参考になれば幸いです。 ーー 留年、そして就職活動のプロに みなさんは「禁煙のプロ」というジョークを聞いたことがあるでしょうか。 俺は禁煙のプロだ。なぜなら何度も禁煙しているからだ というような話でして、類似するものに「結婚」や「ダイエット」等があります。 このジョークになぞらえて言うと、私は「就職活動のプロ」と称してもよい人間です。 プロにならざるを得なかった経緯を告白します。 本来私は2018年の3月に大学を卒業し、内定を いただいていたメーカーへ就職するはずでした。
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー:多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。(2023年6月現在) ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは? アジャイルソフトウェア開発とはなんでしょうか? 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか? 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX(デジタルトランスフォーメーション)」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く