社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ソフトウェアを開発するにあたり「ウォーターフォールモデル」と「アジャイル開発」は比較対象として取り上げられ、どちらが優れているのか、あるいはどちらが正しいのかという議論がよく見られますが、果たして比較可能な対象でしょうか。これらに限らず、さまざまな開発手法の違いを客観的に比較することができないだろうか、といった疑問を持ちました。客観的な基準があれば、何を採用するのかといった議論もスムーズに行えるはずです。任意の開発手法に対する比較は困難ですが、「ウォーターフォールモデル」と「アジャイル開発」に絞ったモデルを作成することで、それぞれの違いを比較できるところまで示すことができました。 開発手法の選択はなぜ難しいのか？ システム開発を進めるための手段には多種多様なものがあり、
最近のソフトウェア開発チームの多くは，スクラムのフレームワークを適用していなくても，いわゆる「アジャイルなプラクティス」に則ったイテレーティブな開発スケジュールを持っている組織が多いのではないかと思います． 自分もそのような組織に幾つか属してきた中で，周囲のやり方やインターネット上で見られる事例を形だけ適用してイテレーション *1 の「ふりかえり」*2 を行っているもののうまくいかない，という組織をこれまで多く見てきました．本稿では，特にスクラムには特に精通していないチームに向けて，スクラムから得られる知見や，自分がこれまでスクラムに取り組んできた中での経験を元に，よく見受けられるパターンと，それに対する処方箋をまとめようかなと思います． 時間内に議論が収まらない チーム規模やイテレーションの長さに対して，どういうことが起きたか，何が問題だったか，どう改善するかという話が，予め予定したタイ
社内の「何を話してもいい」勉強会で発表してきました。ちょうど↓の「心理的安全性」の記事を書いたタイミングだったので、その話をしてきました。 www.ketancho.net この記事では「7つの方法」でしたが、過去のスクラム案件の棚卸しをしてみた結果、今回の発表では薄く広く「14つの方法」として紹介しました。資料は下記になります。 口頭で補足するスタイルで発表したので、この記事ではその内容を簡単に紹介します。 打ち合わせ編 ① 話してる人が話しやすくなる雰囲気を作る 話を聞く 最悪聞いてなくても、聞いてる感は出す（出せないならその場にいない方がいい） むしろ話し手をリラックスさせてあげて、100%の力を引き出してあげるつもりで聞く ネタに反応してあげる。つまらなくても笑ってあげる ② 全員が発言する朝会をする スクラムでいう「デイリースクラム」 全員が「昨日やったこと」「今日やること」「困
先日、社内でアジャイル関連のイベントがありました。私は参加できなかったのですが、大変な盛り上がりをみせていたようです。私の所属する有志団体のSlackでも同様に盛り上がっていたのですが、その中で「心理的安全性って何だ？」という話題になっていました。スクラム開発をしたことがないメンバーにとっては聞き慣れない言葉だったようだったので、心理的安全性がいかに大事かを紹介しました。（後述しますが、スクラムだろうがなんだろうが、心理的安全性はどんな組織においても非常に重要だと思います。） その後、過去のスクラム案件で、心理的安全性を高める上で良かったことを整理するのは有意義かもなー、と思い記事にまとめることにしました。どれも私が主体的に施策として考えたもものではなく、自然発生的に始まったもの、お客さんのそもそも風土などが中心ですが、どんな組織でもすぐに取り組めるものばかりだと思います。 「心理的安全性
この記事はRecruit Engineers Advent Calendar 2017の5日目の記事です。 4日目はy_kabutoya先輩の環境依存情報をコードから分離するというエントリーでした。 本エントリーは「プロダクトオーナーとは何ぞや」という話の整理になります。 認定プロダクトオーナー研修の内容をもとに、社内有志でディスカッションした内容に基づいております。 前提 スクラムとPO ROI(投資対効果) ManageとControll InvestmentのコントロールによるROI最大化 チーム スプリントセレモニーでのROI最大化 プロダクトバックログでのROI最大化 プロダクトバックログ PBI→PBL→プロダクト→Return PBI PBL ACとDD リリース戦略でのROI最大化 QCDSの関係性 リリースの方程式 見えにくいUndone（ムダ・ムラ・ムリ）を排除する ス
みなさんこんにちは。@ryuzeeです。 スクラムのトレーニングをしている中でよく質問を受ける項目の1つに、スクラムマスターはどんなことをすればよいのか？というものがあります。 答えを一言で表すなら、「スクラムがうまく回るようにする」なのですが、実際にどんな仕事をするのか簡単にご紹介したいと思います。 なお雑多なリストなので網羅性はありません。 スクラムマスターの仕事の一例スクラムのフレームワークをうまく回せるように支援するスクラムチームにスクラムの価値やフレームワークを理解してもらうステークホルダーにスクラムの価値やフレームワークを理解してもらうスクラムチームが持続可能なペースで進められるように支援するスクラムチームが集中を維持できるように支援するスクラムチームが透明性を維持できるように支援するスクラムチームが規律を守れるように支援するスクラムチーム内外のお互いの協力を促すスクラムチーム
Regional Scrum Gathering Tokyo 2017
2017年1月12日（木）Regional Scrum Gathering Tokyo2017にて。
クラウドワークスCIOの大場です。 この記事はクラウドワークス コーポレートDiv アドベントカレンダーの23日目の記事です。 先日３歳の娘が、１ヶ月の練習で長いセリフのある劇や、前列と後列で動きの違うダンスと歌をクリスマス会で披露してくれました。感動です。２歳のときとは見違えるようで自然知能ってすごい！ スクラムとはという説明はこういったところをよく見る人には不要でしょう。開発チームが同じゴールに向かって一体となって働くための方法論です。クラウドワークスの開発チームでも、関係する部門が多く位置づけが曖昧になりやすいチームを例にしてスクラムでいい感じにドライブしていくために取り組んだことをまとめた大浦さんの記事があります。 先日もアジャイル労働が話題になったり近年、システム開発の分野でここ10年ぐらい取り組んできたことが、ITの普及やITそのものがビジネスに直結するようになってきたことを背
こんにちは。kintone開発チームの天野(@ama_ch)です。3ヶ月ほど前からスクラムマスターを始めました。 10/18(金)に@ryuzeeさんにサイボウズ東京オフィスにお越しいただき、kintone開発チームのメンバーでスクラムトレーニングを受講しました。 きっかけ 私が開発しているkintoneはクラウドサービスですが、サイボウズはパッケージ製品の開発でスタートした歴史があり、開発プロセスにもパッケージ時代の習慣が強く残っていました。 長大な要件リスト 実装と試験工程の分断 開発後期での手戻り etc... もちろんこれまで手をこまねいていた訳ではなく、開発チーム内では次のような活動に取り組んできました。 タイムボックス(イテレーション)を区切った開発 テスト自動化の推進 ビルドパイプラインの構築 開発者環境への継続的デリバリー ふりかえり KAIZEN DAY, KAIZEN合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
