Agile Development Leadershipアジャイルソフトウェア開発では従来のリーダーシップとは異なる形のサーバントリーダーシップが求められます。 アジャイル開発の基本的な知識とサーバントリーダシップについて解説した際の資料です。
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
リモートワークでも改善のサイクルを回す。Misoca流の「ふりかえり」を紹介。 - 弥生開発者ブログ
こんにちは。 最近、スラムダンクの新装版を買ってバスケ熱があがっている @RyoKawamata です。気になるキャラは森重 寛です。 さて、今回はMisoca流のふりかえり についてまとめてみました。 ふりかえりというと、一つの空間に皆で集まり、ポスト・イットにKPTを書いてホワイトボードに貼って、、、というイメージがあると思いますが、Misocaはフルリモートワークの会社です。 リモートでどのようにふりかえりを行うのか？まだあまり事例がないものだと思うので紹介します。 ふりかえりとは？ 最初にふりかえりの定義を確認。 ふりかえりはスクラムの文脈だとスプリントレトロスペクティブです。スプリントレトロスペクティブは、下記のように定義されています。プロジェクト、チームを継続的に改善していくために、とても重要なものですね。 スプリントレトロスペクティブは、スクラムチームに考える機会を与えるもの
ふりかえりの実施状況に関する調査結果 (Annual Agile Retrospective Report)
みなさんこんにちは。@ryuzeeです。 アジャイル開発に関する調査レポートはVersion OneによるAnnual State of Agile Surveyなどをはじめとしていくつかあります。 今回retriumという会社が、Retrospective(ふりかえり)に特化した調査を行った資料を公開したので、簡単に紹介します。 なお、レポートはこちらから無料でダウンロードできます。 調査の概要回答者は277人で、そのうち44%は米国在住者です。 回答者の分布は33%がスクラムマスター、16%が内部コーチ、13%が外部コーチ、12%がリーダーやマネージャーとなっています。 調査結果の紹介前述のとおり項目数が多いので、その中からいくつか特筆すべき項目について見ていくことにしましょう。 なお数字はレポートからの引用、文章はその数字に対する私のコメントです。 Retrospectiveで難しい
権限を委譲したい/してほしいときに便利なデリゲーションポーカー - Qiita
デリゲーションポーカーの出典はこのあたりです。 仕事は、あらゆる場面で、様々な決定をしながら進める必要があります。 ですが、何を誰が決めるかでモメることはありませんか？ チームメンバーは「私はどこまで決めていいのか」と思うときがあるでしょう。 また、偉い人も「私はどれほど決定していいのか、又は委ねていいのか」と思う時があるでしょう。 そんな時に便利なのが「デリゲーションポーカー」です。 権限委譲は「する/しない」といった2値の問題ではなく、7段階のステップに分かれています。 7段階のステップは以下です ※私=偉い人、彼ら＝チームメンバー 命令する(私が彼らに決定を伝える) 説得する(私が彼らに売り込む) 相談する(彼らに相談し私が決める) 同意する(私と彼らが合意して決める) 助言する(私は助言するが彼らが決める) 尋ねる(彼らが決めた後で私が尋ねる) 委任する(私は彼らに完全に委ねる)
DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い
両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者（以下、Dev）と運用者（以下、Ops）の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは（DevOpsの概念と同じく）、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
魅力的なプロダクトバックログで開発を楽しく！
どんな開発プロセスでも製品やサービスを作るときは何からの形で要件をまとめると思います。KRAYが採用しているアジャイルソフトウェア開発フレームワーク『スクラム』では、製品やサービスの要件リストをプロダクトバックログと呼びます。実はこのプロダクトバックログ、その書き方や運用の仕方で開発のモチベーションが大きく違ってきます。書き方一つで、開発チームにとってもプロダクトオーナーにとっても見るのが楽しみな資料になりうるのです。 今回は、見るのが楽しみになる魅力的なプロダクトバックログを作るコツについてお話しします。 プロダクトオーナーから見たプロダクトバックログ 最初にプロダクトバックログのライフサイクルについて簡単におさらいします。 開発が決まったら、プロダクトオーナーは製品のビジョンを実現するために必要な機能などをユーザーストーリーと呼ばれる文章で表現し、プロダクトバックログに追加していきます
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)agilelean はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。 今回、このビデオを未熟なりにディクテーションして、適当ですが、日本語訳を作ってみました。本人に承認を取るつも
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
スクラムの落とし穴 #RSGT2017
29 Scrum Retrospective Tools for Distributed Agile Retrospectives