アジャイル / スクラム / チーム開発の[不吉な匂い]まとめ まずはポエム やることを考えて自力で実現できるスキルがあれば良い。何か一芸に秀でていればやり方を決めたりはそこそこ好き勝手できるし、自分のやったことに満足したら自分だけは気持ちよく帰れる。って思ってた。 時間外に月何十時間あるいは百数時間コーディングしたり、先輩に昼夜問わずコードを送りつけて見てもらったり、中途採用者のために用意してある受入課題を一人で何回もやり直したりと、あほみたいなことをやっていた。 事実それで設計とコーディング作業の生産性は数倍、数十倍になってきた。 けど、どうもイケてるってのはそれだけじゃあないらしい。ある時期急にそう思った。(遅い) 話してみると、(少なくとも僕の先輩たちのいくらかは)イケてる集団を作れる奴がイケてる奴って考え方らしい。(曲解拡大解釈誇大表現含む) はじめに せっかく Engineer
ふりかえりだけでなく、会議のファシリテーターとして呼ばれることもあります ―― お忙しいところ、インタビューを受けて下さってありがとうございます。森さんは社内外の活動をすごく活発にされていて、最近だと『カイゼン・ジャーニー・カンファレンス』でも発表されていましたね。自分は参加できなかったんですけれど、発表資料は見ました。まずは、森さんの社内外の活動について聞かせていただけたらと思います。 森さん― 自分の主催でやっているのが、『ふりかえり実践会ワークショップ』と『ふりかえり悩み相談会』です。実践会ワークショップは月1回ぐらいの頻度で、ふりかえりのやり方を学ぶワークショップをやっていて、悩み相談会ではふりかえりに関するいろんな相談を受けてアジャイルコーチみたいなことをやっています。 それと、『カイゼン・ジャーニー』つながりの『越境者の集い』という、ヴァル研究所の新井さんとギルドワークスの市谷
みなさんこんにちは。@ryuzeeです。 スクラムはフレームワークです。ロール、作成物、イベントが決められていますが、それを具体的にどうやってこなしていくのかは定義されておらず、それぞれの環境にあわせてやり方を考えていく必要があります。 それを分かりやすく説明したのが、Scrum is an abstruct classという記事です。 今回、記事を執筆したPaddy Corry氏に快諾いただきましたので、和訳にてご紹介します。 なお、誤解のないように言っておくと、スクラムはアジャイル開発を進める上での唯一のフレームワークでは決してありません。 つまりスクラムのフレームワークで既定されていることを止めた場合、それはスクラムではありませんが、だからといってアジャイルでなくなることとイコールなわけではありません。 自分たちにとって良いやり方があれば、それをやればいいのであって、スクラムに厳格に
社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ソフトウェアを開発するにあたり「ウォーターフォールモデル」と「アジャイル開発」は比較対象として取り上げられ、どちらが優れているのか、あるいはどちらが正しいのかという議論がよく見られますが、果たして比較可能な対象でしょうか。これらに限らず、さまざまな開発手法の違いを客観的に比較することができないだろうか、といった疑問を持ちました。客観的な基準があれば、何を採用するのかといった議論もスムーズに行えるはずです。任意の開発手法に対する比較は困難ですが、「ウォーターフォールモデル」と「アジャイル開発」に絞ったモデルを作成することで、それぞれの違いを比較できるところまで示すことができました。 開発手法の選択はなぜ難しいのか? システム開発を進めるための手段には多種多様なものがあり、
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. ……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが;、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ;」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話だったのかというと、 アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ? → そんなわけないでしょ;。 これからの開発は当然アジャイルとか DevOps でしょ! → そんなわけないでしょ;。 みたいな話;。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール
イベント概要 先日、アジャイルの本質について語るイベントが日本橋で開催された イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」 アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り 会の後半では、参加者を交えたディスカッション(フィッシュボール形式)も行われた イベント詳細はこちら:https://connpass.com/event/96750/ 登壇者 やっとむさん「アジャイルってなにが美味しいの?」 きょんさん「目的論からのアジャイル~手段を目的化すること~」 ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」 感想を一言で言うと タイトル通り、内容が本質すぎて辛かった 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした 「アジャイルってなにが美味しいの?」 by やっとむさん 登壇資料 そもそもア
はじめに いきなり質問ですいません。 「アジャイルの反対」ってなんでしょう? ・・・ ・・・ ・・・ もし、「ゆっくり」とか「ウォーターフォール」みたいな単語が頭に浮かんだ方はこの記事で学べることが多くあるかもしれません。 質問の答えは最後に記載しています。 参考文献 アジャイルソフトウェア開発宣言 アジャイル宣言の背後にある原則 スクラムガイド スクラム入門 Scrum Boot Camp 認定スクラムマスター研修 アジャイル スクラムの前にアジャイルに触れておく。 アジャイルとは アジャイルとは、より良い解決方法を探している状態である。 "状態"なので、よくある「アジャイル開発をやろう!」というのはおかしくて、振り返ってみて「あれはアジャイルだったなー」ってなるものだ。"Don't just do agile, be agile."という名言があるくらい。だから、極端な事を言うと、より
スクラムはじめようって何からはじめればいいの? スクラムやりたい! いきなりスプリント開始~! なんてうまくいくはずがありません。 走りながらにも限界があると思いますし、途中で疲れちゃいます。 スクラムは、実は事前の準備が本当に大切です。スクラムガイドなどには謳われていませんが…。 ここでは、今までスクラムを導入したことが無い組織でスクラムを導入するための道標を記載してみました。 真っ白な状態からスクラムをやりたいのであれば、一番最初に スクラム・マスターが必要だと思います。 スクラム・マスターが、「スクラムやろうぜ」の発起人になっていないとうまく回らない可能性が高いです。 チームとプロダクト・オーナーをうまく導けないからです。 今までスクラムを導入したことが無い組織の場合、スプリントの開始までに、2~3週間ぐらい必要です。 ここで述べるのはあくまで私個人の経験・学習の結果からくるものです
先日会社で株式会社アトラクタのみなさんを講師に迎えたアジャイル開発研修を受ける機会に恵まれました。 質疑応答ではかなり素朴な疑問をぶつけてしまいましたが、講師の先生方に快く教えていただきました。以下、個人的に印象に残った質問と回答を紹介します。 Q. プロダクトオーナーとスクラムマスターは既成概念であるディレクターやプロジェクトマネージャーと何が違うか A. 責任範囲の違いがある。ざっくり言うとスクラムマスターは開発プロジェクトの円滑な進行に責任を持ち、プロダクトオーナーはビジネス上の成果に責任を持つ。ここがはっきりと分業される。 既成概念であるディレクターやプロジェクトマネージャーは、開発プロジェクトの進行とビジネス成果の両方に責任を持つケースが多い。そのため開発プロジェクトのボトルネック/単一障害点になり、休めなくなりがちである。アジャイルチームにおいては、プライマリ・ロールの責任を果
スマホアプリの分析プラットフォーム「F.O.X」が主催する、スタートアップで働くエンジニア向けコミュニティイベント「F.O.X Meetup」の第3回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としている本イベント。今回は、「スタートアップのチームビルド」をテーマに、経験豊富なプロジェクトリーダー達が自身の知見を披露します。株式会社マクアケの吉田慶章氏は、「さぁ!今すぐプロジェクトリーダーに立候補しよう」というテーマでプレゼンテーションを行いました。チームの特性に合わせたチームビルディングやマネジメント手法について、自身のノウハウを明かします。 プロジェクトをリードする技術 吉田慶章氏(以下、吉田):こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思い
先日、社内でアジャイル関連のイベントがありました。私は参加できなかったのですが、大変な盛り上がりをみせていたようです。私の所属する有志団体のSlackでも同様に盛り上がっていたのですが、その中で「心理的安全性って何だ?」という話題になっていました。スクラム開発をしたことがないメンバーにとっては聞き慣れない言葉だったようだったので、心理的安全性がいかに大事かを紹介しました。(後述しますが、スクラムだろうがなんだろうが、心理的安全性はどんな組織においても非常に重要だと思います。) その後、過去のスクラム案件で、心理的安全性を高める上で良かったことを整理するのは有意義かもなー、と思い記事にまとめることにしました。どれも私が主体的に施策として考えたもものではなく、自然発生的に始まったもの、お客さんのそもそも風土などが中心ですが、どんな組織でもすぐに取り組めるものばかりだと思います。 「心理的安全性
はじめに こんにちは。花粉症のカイゼンを日々願っています。開発部の野村です。 今年の2月から DataSpider Servista のスクラムチームでスクラムマスターをやっています。 年度末ですが、みなさん「ふりかえり」していますでしょうか? わたしたちスクラムチームは1週間のスプリントで走っています。 毎週「ふりかえり」を行って、さらに高いレベルのチームを目指して「カイゼン」アクションを決めています。 私がスクラムマスターになってから試したプラクティスを、それぞれよかったことを交えて紹介していきたいと思います。 「ふりかえり」プラクティス KPT Keep, Problem, Try を書き出す、定番のプラクティスです。 How to 1週間のできごとを確認*1したあとに、10分程度でKeep, Problem をふせんに書き出してもらい、Keep の中からより良くする Try を出し
どの会社にも、どんなコミュニティにも一定数、「失礼な人たち」がいる。 「失礼」は抽象的な表現であり、相対的なものなので、当然、ある人が失礼と感じることが、他の人にはそうではないことがたくさんある。 だが、「失礼」は確かに存在している。 「論語」によれば、失礼というのは、慎みと敬意がない、ということである。 例えば、インターネットではよく見かけるが、相手に「バカ」「無能」と言ってしまうのは、失礼にあたる。 同じように、誰かが間違ったことをした時に、皆の目の前で「間違っている」と批判することも、失礼な行為だ。 ◆ 以前、こんなことがあった。 その企業は小さなシステム開発会社で、ワンマン経営をしている社長がいた。 そして、その社長は思い込みの強いタイプで、会議でよく間違ったことを言った。 例えばこんな具合だ。 「ソフトの品質が悪いのは、仕事への思い入れが足りないからだ!」 現実的には、ソフトの品
先日、Twitterを見ていたら、あるアカウントが「論理の間違い」を指摘されていた。 「そこは因果関係ではなく、相関があるだけですよ」と、指摘されたのだ。 だが、客観的に見れば、指摘はまっとうで、非難めいた口調でもなく、丁寧な指摘だった。 ところが、そのアカウントの主は、怒った。 「私がいいたいのは、そのようなことではない」と、指摘した人をブロックした。 * 最近、親戚がうちに来てくれたときのこと。 その方は、親切で、人の世話を焼くのが大好きな方だ。非常に献身的で「子どもたちのために、スープを作りたい」と、わざわざ遠くから来てくれたのに、料理を振る舞ってくれた。 ところが、子どもたちがスープをあまり飲まない。 「味が変」というのだ。 その方は「好き嫌いはダメだよ−」と子どもたちにいうのだが、結局、子どもたちはスープを残してしまった。 味をみた妻が「これちょっと酸っぱくない?」と指摘したとこ
昨年末にスクラムマスター研修を受けてきて、認定スクラムマスター (CSM)となりました。スクラムマスター研修で学んだこととして社内で共有した内容を本ブログでも共有してみようと思います。 Scrum vs Agile 〜歴史から学ぶ〜1993年: スクラム誕生2001年: アジャイルソフトウェア開発宣言 アジャイルマニフェスト: アジャイルソフトウェア開発宣言アジャイル原則: アジャイル宣言の背後にある原則アジャイルは「より良い開発/方法を探している」という状態のことです。状態なので原理的には「アジャイル開発をしている」という表現は正しくありません。振り返ってみて「あのプロジェクトはアジャイルだった」と評価できるもの。極端に言うといわゆるウォーターフォール型の開発も1つのアジャイルと定義することもできます。 Don’t do agile, be agile (訳: アジャイル開発をするな、ア
先日、コーチしているメンバーからスクラムの価値基準とスクラムの柱の関係について質問を受けたので、こちらにも書いておきます まずはスクラムガイドよりスクラムの価値基準を抜粋 スクラムチームが、確約(commitment)・勇気(courage)・集中(focus)・公開(openness)・尊敬(respect)の価値基準を取り入れ、それらを実践するとき、スクラムの柱(透明性・検査・適応)は現実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムの役割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索する。 とあります。 私自身、スクラムのフレームワークに則っていればスクラムが円滑に回るわけではなく、アジャイルマニフェストに書かれているマインドに則り、ふるまいを変える必要があると考えていました。スクラムの価値基準は、そのふるまいを表して
基幹系システム ERP 会計システム 電子帳票システム ワークフロー 勤怠管理システム もっと見る 情報共有システム・コミュニケーションツール グループウェア Web会議 テレビ会議/ビデオ会議 ファイル共有 文書管理 もっと見る 情報システム SFA CRM コールセンター/CTI BPM PLM もっと見る メール 電子メール メールセキュリティ メールアーカイブ その他メール関連 もっと見る エンドポイントセキュリティ アンチウイルス 暗号化 認証 ID管理 メールセキュリティ もっと見る ネットワークセキュリティ ファイアウォール WAF IPS UTM セキュリティ診断 もっと見る 運用管理 統合運用管理 IT資産管理 サーバー管理 ネットワーク管理 統合ログ管理 もっと見る バックアップ バックアップツール バックアップサービス テープバックアップ その他バックアップ関連 もっ
チームが主役のスクラムにおいて、2つだけ定義された特殊な役割。それが、プロダクトオーナーとスクラムマスターです。前回は、プロダクトオーナーについて紹介しました。プロダクトオーナーはチームが進むべき方向、ゴールへの道筋を示す役割です。 今回はもう1つの役割、「スクラムマスター」について紹介します。 チームには、不都合な事実に目を向ける「医者」が要る リーダーの仕事の中でも、「チームにビジョンを示す」ことは特に重視されてきました。ビジョンを示し、チームを励ましながら目標に向かってひたまい進する――優れたリーダーと熱意に満ちたチームがあれば、素晴らしい成果が得られるでしょう。 しかし、状況は変化します。全力で前進するリーダーとチームは、チームの何かが壊れそうになったとき、しばしばその徴候を見逃してしまいます。 「この事実をチームの皆が知ったら、士気が下がるだろうな……」 といって不都合な事実を見
2016年2月27日(土)Dots Conference Spring 2016にて。 「Team Refactoring -強いチームをつくる技術-」。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く