Scrum Guide | Scrum Guides
This HTML version of the Scrum Guide is a direct port of the November 2020 version available as a PDF here. Purpose of the Scrum Guide We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it. The Scrum Guide contains th
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
デザイナーとプログラマーとの役割 - Ashiras, inc. blog
皆さんは普段Angular開発を進めてている上で思ったより工数が膨らみ遅延した覚えありませんか？ 今回はその問題のひとつについてまとめました。 開発工程 プロジェクト開発における簡単な開発工程図です。 デザイナーは要件定義を汲み取って画面設定書やモックを作成します。 (ここでは基本設計や詳細設計等は省きます) プログラマーはその画面設計書やモックを元に製造を行います。 今回はその 開発プロセスにおけるデザイナーからプログラマーに引き渡す際の役割 について着目したいと思います。 一般的なデザイナーの役割として ・デザインカンプ(PhotoshopやXDなど) ・デザインガイドライン ・モック(HTML・CSS・Javascriptなど) プログラマーに引き渡す プログラマーは モックがAngularのコンポーネントになってないのでAngular用に作り直す ここで問題が発生です！ デザイナー
一休での開発における改善の取組み /devops-at-ikyu
4/28(金) にDevOps推進協議会 で講演したときの資料です。
インフラで実践したチームビルディングそれはサバ天 : インフラエンジニアに成る
スクラムにあこがれて。 インフラで実践したチームビルディングそれはサバ天 from ume3_ カンバンをやってカイゼンをしたというお話です。 ここ1年ぐらいずーっとリーダーとして チームビルディングに勤しんでいた。 チームを強くするにはどうすればいいか？ チームでわいわいやるにはどうすればいいか？ 簡単な話、仕事ってどうやったら進むのか？ それをつきつめていった結果、なぜか特異な結果が生まれた。 なんだこれは。 社内に共有したものをせっかくなのでこちらへ公開という流れです。 モザイク多いのは勘弁。 これでも、けっこう内容けずったのです。 やっていることは、ホワイトボードの前で付箋紙はってわいわいやっているだけ。 スライドでは説明不足ですが、サイクルがちゃんとあって ぐるぐる回すことでチームが加速化するのが狙い。 見える化の力を今も実感しています。 こういったフレームワークの活用からの発展
伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE
伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 （CodeIQ中の人） 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです
チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに - freee株式会社 Qiita Teamインタビュー - Qiita Blog
チームの想いをなんでも共有する「ゆるふわ」「ポエム」タグが議論のきっかけに – freee株式会社 Qiita Teamインタビュー こんにちは！ htomineです。 みなさんのチームには「気兼ねなく情報発信できる場所」はありますか？ 今回は、Qiita Teamをそんな場所としてご活用いただいている、freee株式会社さんの事例をご紹介します。 サマリーポイントをまとめると使い方の指針になるような記事をはじめに投稿してから徐々に広めた開発ドキュメントにかぎらず、仕事のフローの改善案、自分の想いやライフハック的な記事など、メンバーに伝えたい様々な情報を投稿してよい場所として使っている目次freee株式会社Qiita Team導入の経緯導入前の課題使い始めてみてどうだったか―どんな記事が投稿されていますか？―社内に広まるきっかけは何だったのでしょうか？今までのツールではこういった投稿はでき
チーム開発をスムーズにするために何ができるか
DevLOVEさんの「進め、現場のチーム開発 〜チーム開発実践入門〜」で講演した時の資料 http://devlove.doorkeeper.jp/events/12229Read less
久々にチーム開発したのでメモ - ひげろぐ
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った 久々のチーム開発で。チーム人数は3名。 せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。 実践したこと プルリクベースの開発 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 上記のやり方が面白そうだったので試してみた。 Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。 Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。 コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。 一方でい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Slackのワークフロービルダーでコードレビュー依頼の機能を作る｜アマガミナブログ
エンジニアのチーム開発入門 - 心技体を磨いて自身とチームをより良くしよう / Being geek in the team
捨てて開発できるチームづくり
実録！ チーム開発が捗り過ぎるSlack＋GitHub＋Trelloの使い方
会社に Github導入した話
はてなブログチームの開発フローとGitHub