ソフトウェア開発

ソフトウェア開発

スケジュールを決め

役割分担を決め

仕様を決め

あらゆる調整をし

スケジュール管理を行い

サイトまたは案件を世に公開し

成果を報告する

プロジェクト基本情報

  • キーワード e.g.) 爆速等

  • IT戦略 e.g.) 低コストや要求の変化への対応を優先、納期重視等

  • ライフサイクルモデル リリース体制

  • チーム編成

  • プロジェクト期間

  • プロジェクト初期における要件の確定度合い

  • 契約形態

  • 朝会、定例会、振り返り

不確実性

  • 市場の不確実性

  • 技術の不確実性

  • プロジェクト期間

  • 依存関係

高速適応性

  • リリース密度

  • CI環境の商用フレームワークからの独立度

  • ソフトウェア実装フレームワークの複雑度

複雑性

  • チームの大きさ

  • ミッションクリティカル

  • チームの場所

  • チームの能力

  • ドメイン知識のギャップ

  • 依存関係

レーダーチャート指標

  • チームにおける「平均レベル以下の、経験は少ないが勤勉な開発者」の割合

  • チームにおける「プロジェクトをマネジメントできる人」の割合

  • Time-to-market の時間的制約の厳しさ

  • 組織文化

  • システムの重要度の高さ

  • 要求された稼働率の高さ

  • プロジェクト期間の短さ

  • プロジェクト初期における要件確定度合いの低さ

  • ビジネスの新規性の豊かさ

  • 採用技術の新規性の豊かさ

  • 開発人数の多さ

http://sec.ipa.go.jp/reports/20100330a/20100330a_1.pdf

いいプロジェクト

・しがらみがない

・裁量がある

・客先との距離が近い

・エンジニアリング以外のことをやらなくていい（見積もりとか管理とか）

・見渡せる規模である

教訓

  • 実物を見せないと、顧客の希望は分からない

  • 十分な時間があれば、あらゆるセキュリティは破られる。

  • セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。

  • 優れたセキュリティは、出費ではなく戦略上重要な資産となる。一方、不十分なセキュリティは、資産を減じる打撃となる。

  • 単純に見える複雑なものを作るのは難しいが、複雑なものをもっと複雑に見せるのはたやすい。

  • 成功は、失敗から学ぶことで得られる。一方、失敗するのは当たり前なので許されると思うところから、失敗は生まれる。

  • 決して変わらないものなどない。それは変えようのない事実である。

  • 学ぶことをやめてはならない。テクノロジの波はプログラマのすぐ背後まで押し寄せている

  • ソフトウェア産業全体がでたらめな推測の上に構築されている。

  • ある人にとって便利なものが別の人にとっても便利とは限らない。

  • 変化し続ける世界で最も重要なスキルは価値を見極める能力である。

  • 問題の解決方法は1つではない。顧客の立場からすれば、結果が得られれば、どんな方法かは重要でない。

  • 品質は顧客が決める。

  • 無知であることは、プログラマとしての自分を追い込む。なぜならログをためることを行っていないからである

  • より良い方法は常にあるけれど、時間は待ってはくれない。

哲学

  • DRY原則： Don't repeat yourself。情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する

  • KISSの原則：Keep it simple, stupid。 設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだということである。

  • YAGNI： You ain't gonna need it。機能は実際に必要となるまでは追加しないのがよい

  • PIE:Program Intently and Expressively 意図を表現してプログラミングせよ

  • SLAP:Single Level of Abstraction Principle 抽象化レベルの統一

  • 驚き最小の原則： https://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87

  • デメテルの法則：別名最小知識の法則

  • ブルックスの法則：これの言い換えである「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」はとてもわかりやすい。これが成り立つ背景としては、「プロジェクトへの習熟までに時間がかかること」「コミュニケーションコストが増大すること」が挙げられている。

  • コンウェイの法則：「システムを設計する組織は、自分たちの組織のコミュニケーション構造をそっくりそのままコピーした設計を生み出してしまう」という原則

  • ホフスタッターの法則：「いつでも予測以上の時間がかかるものである — ホフスタッターの法則を計算に入れても。」 という自己言及的な見積もりに関する法則。

  • SOLID：オブジェクト指向設計に関する原則の頭文字をとって「SOLID」とまとめられた原則集。

    • Single Responsibility Principle（単一責務の原則）

    • Open/closed principle（開放閉鎖の原則）

    • Liskov substitution principle（リスコフの置換原則）

    • Interface segregation principle（インターフェース分離の原則）

    • Dependency inversion principle（依存性逆転の原則）

Unix哲学

Simple,:単純

Modular:モジュール型

Composable:組みあわせ可能

人月の神話

プログラマの生き様

https://www.gitbook.com/book/masarakki/c89-the-way-of-programmer-life/details

代表的な要素

ベンダとユーザ間

  • 価格

  • 工期

  • 規模

  • 要求

  • 技術

  • 開発技法

  • アーキテクチャ

  • プラットフォーム

  • レビュー

  • テスト

  • 品質

「かぎきひよこ」と覚える

ベンダ

  • 工数（コスト）

  • 要員

  • 体制

  • 環境

  • 生産性

  • 信頼性

  • 教育

  • 開発標準

「せいしんたこかこかきょ」と覚える

ユーザ

  • 方針

  • 要員

  • 体制

  • 価値

  • 満足度

「よかたまほ」と覚える

Googleの開発スタイル

http://blog.livedoor.jp/heitatta/archives/54439839.html

アンチパターン

アジャイル宣言

開発フェーズ略語

工程

略語

内容

企画

SP

System Planning

企画

SP

System Planning

要求分析

SA

System Architectural design. システム方式設計

要件定義

RD

-

基本設計

UI

User Interface

基本設計

BD

Basic Design

基本設計

SS

System Structure Design(構造設計)

基本設計

FD

Function Design(機能設計)

詳細設計

DD

Detail Design

詳細設計

PD

Program Design

詳細設計

PS

Program Structure Design

製造/個別test

CD

CoDing

製造/個別test

PG

ProGraming

製造/個別test

UT

Unit Test 個別テスト

製造/個別test

FT

Function Test 機能試験

結合テスト

SI

-

結合テスト

IT

Integration Test 結合試験

総合テスト

ST

System Test

総合テスト

PT

-

運用テスト

OT

Operation Test

文書の種類

  • 要求仕様書

  • 見積書

  • ドキュメント基準

  • システム構成

  • 詳細設計書

  • コーディング基準

  • 試験報告書

  • 試験計画書

  • 試験仕様書

  • 試験手順書

  • ユーザマニュアル

  • スケジュール

他にも

・要求仕様書

・要件定義書

・基本設計書

・システム概要仕様書

・機能一覧

・業務フロー設計書

・ネットワーク構成図

・画面設計書

・帳票仕様書

・ER図

・インターフェース仕様書

・詳細仕様書

・DB定義書

・プログラム(アルゴリズム)仕様書

・プロトコル仕様書

・クラス設計書

・状態遷移図

・テスト仕様書

・単体テスト仕様書

・結合テスト仕様書

・システムテスト仕様書

http://blogs.bizmakoto.jp/noubiz/entry/4641.html

本当に必要な文書

・DB定義書

・画面設計書

・コードナンバーの定義やバッチ処理のフローなどを書いたプログラム仕様書

・ネットワーク構成図

ウォーターフォール型開発のドキュメント一覧

フェイズ

ドキュメントの種類

要件定義

要件定義書

要件定義

要件定義書

基本設計

基本設計書、機能仕様書、ネットワーク設計書、SW/HW（SoftWare/HardWare）構成書、セキュリティ設計書、性能・信頼性設計書、データ構造定義書（ER図）、テーブル定義書、画面定義書、画面遷移定義書、帳票定義書、開発標準書

詳細設計

詳細設計書、クラス設計書、構成管理定義書、インターフェイス設計書

開発／単体テスト

単体テスト仕様書

結合テスト／システム・テスト

テスト計画書、結合テスト仕様書、システム・テスト仕様書

本番／運用

環境構築手順書、運用定義書、障害対応手順書、移行仕様書、移行手順書

ソフトウェア開発データ

ソフトウェア開発データ白書

自動化

各フェーズの位置づけ

  • 詳細設計

  • 関数の役割、引数の設計

（スケルトンの作成）

  1. 各種ファイル環境の構築

  2. テストケースの記述

  3. テストデータ（サンプル）の作成

  4. 製造物のレビュー

  • 製造

  • 関数の中身の処理の記述

  • ソフトウェアのバージョン管理

  • テストパターンの記

  • 設計バグの検出

  • 体制

    開発を３分割する

要求分析  基本設計   詳細設計  製造   テスト
|<----------------------->|<------------->|<------------->|
P1         P2             P3

ソフトウェアシステムをモデル化

  • クラス: OOの世界では，クラスがソフトウェアシステムの最小構成要素です。

  • コンポーネント: コンポーネント (またはサービス) は一般的に，複数の協調動作するクラスで構成され，粒度の粗いインターフェースの背後にすべて配置されます。例としては "リスク計算"，"監査コンポーネント"，"セキュリティサービス"，"Eメールサービス" など，開発中のシステムによってさまざまです。

  • コンテナ: コンポーネントが実行されたり，あるいはデータが設定されたりする場所を表すものです。Webサーバ，アプリケーションサーバといったものから，リッチクライアントアプリケーション，データベース，あるいはファイルシステムといったものが考えられます。コンテナは通常，ソフトウェアシステムが動作している間は常に実行，あるいは有効であることが必要です。コンテナの観点からソフトウェアシステムを理解する上で重要なポイントは，コンテナ間通信にはすべて，Webサービス呼び出しやリモートメソッド呼び出し，メッセージなどのリモートインターフェースが必要である，ということです。

  • システム: システムは抽象化の最上位レベルであり，例えばエンドユーザに価値を提供する存在を表しています。

MoSCow

  • 必須 Must have ： これがなければシステムが成り立たない

  • 必要 Sould have ： 重要な操作

  • 要望 Could have ：できればあった方がよい

  • 次回 Wanto to have ： 次回

ジョエルテスト

  1. ソース管理システムを使っているか？

  2. オペレーションでビルドを行えるか？

  3. 毎日ビルドを行うか？

  4. 障害票データベースを持っているか？

  5. 新しいコードを書くまえにバグを修正するか？

  6. 更新可能なスケジュール表を持っているか？

  7. 仕様書を持っているか？

  8. プログラマは静かな労働環境にあるか？

  9. 買える範囲で一番良い開発ツールを使っているか？

  10. テスト担当者はいるか？

  11. プログラマを採用するときにコードを書かせるか？

  12. 「廊下での使い勝手テスト」を行っているか？

開発プロセス

ウォーターフォールvsアジャイルvsスクラム

https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/

DevOps

http://www.buildinsider.net/enterprise/devops/01

人（People）： マインドセットや考え方

プロセス（Process）： 開発や運用の手法

プロダクト（Product）： ツールや技術

Cluture（文化）

Lean（リーン）

Automation（自動化）

Measurement（計測）

Sharing（共有）

DevOps 文化と組織

  • 積極的に協力

  • 情報を積極的に活用

  • リスクを共有

  • 仲介を奨励

  • 失敗を調査

  • 新規性を積極的に受け入れる

https://cloud.google.com/solutions/devops/devops-culture-westrum-organizational-culture?hl=ja

参考スライド

https://slide.meguro.ryuzee.com/slides/87

アジャイル

アジャイル開発プロジェクトの始め方

http://www.ryuzee.com/contents/blog/7110

http://dev.classmethod.jp/tool/github/github-constellation-conf-ryuzee/

アンチパターン

http://www.infoq.com/jp/news/2016/04/agileindia-7sins-scrum

顧客にアジャイル開発でと言われたら

  1. アジャイルに何を求めるのかを確認する

  2. 準委任(SES)契約を勧める

  3. 一括契約ながら成果物をあいまいにしておく

http://takigawa401.hatenablog.com/entry/2017/06/12/183007

モダンアジャイル

人々を最高に輝かせる（Make people awesome）

安全を必須条件にする（Make safety a prerequisite）

高速に実験＆学習する（Experiment and learn rapidly）

継続的に価値を届ける（Deliver value continuously）

リーンスタートアップ

原則1：ムダをなくす

原則2：品質を作り込む

原則3：知識を作り出す

原則4：決定を遅らせる

原則5：速く提供する

原則6：人を尊重する

原則7：全体を最適化する

開発初期にやるべきこと

http://post.simplie.jp/posts/44

サービスキャンバス

  1. 満たすニーズ

  2. ターゲット

  3. 現状の解決方法

  4. 提供する解決方法

  5. 利用モチベーション

  6. 現状の解決方法に対する優位性

  7. コンセプト

  8. 主要成功要因

  9. 流入経路

  10. コスト

  11. 収益

KPI

  1. コアバリューの醸成に寄与すること

  2. その指標を改善することでサービスのコアバリューがより強固になる指標であること

  3. 定点観測可能なもの

  4. 日次/週次でユーザの行動を反映した変化を得られる指標であること

  5. 定量的であること

  6. 数値として測定できる指標であること

  7. 分かりやすいこと

  8. プランナーだけでなくエンジニアやデザイナーにとっても理解しやすい指標であること

  9. 行動をとりやすいこと

  10. その指標を改善するための具体的な施策がイメージしやすいこと

基本項目

  1. サービス名

  2. ドメイン名

  3. コードネーム

  4. リリース日

  5. 提供プラットフォーム

  6. 動作環境

  7. サインアップ方法

XP（エクストリームプログラミング）

・ソフトウェア要求仕様の変更などの変化に対して機敏に対応する

・初期段階の設計よりもコーディングとテストを重視する

・ドキュメントよりもソースコードを重んじる

・各工程を段階的に進めていくより、常にフィードバックを行って修正・再設計していくプロセスを重視する

XPの価値

(1).顧客と開発者の、もしくは開発者間の円滑な「コミュニケーション」(communication)

(2).必要最小限の設計しか行わない「シンプルさ」(simplicity)

(3).頻繁なテストによる「フィードバック」(feedback)

(4).大胆な設計変更に立ち向かう「勇気」(courage)

対象者

プラクティス

解説

/4. 共同

反復

開発を反復（設計・実装・テストを繰り返す小さなサイクル）から構成する。 全体の開発期間はイテレーションと呼ぶ1～2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。 またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。 このように反復によって、徐々に完全なシステムを構築していく手法を取る。 このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。

/4. 共同

反復

開発を反復（設計・実装・テストを繰り返す小さなサイクル）から構成する。 全体の開発期間はイテレーションと呼ぶ1～2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。 またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。 このように反復によって、徐々に完全なシステムを構築していく手法を取る。 このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。

共通の用語

用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。

開けた作業空間

会話しやすく、作業に打ち込める雰囲気を作る。

回顧（頻繁な振り返り）

現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境・体制を構築しておく。

/6. 開発

テスト駆動開発

実装を行うより先に、自動化されたユニットテストないしは手順の明確化されたテストを作成する。 実装はそのテストをパスすることを目標に行う。 ユニットテストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。 テストはユニットテスト（ホワイトボックステスト）と受け入れテスト（ブラックボックステスト）からなる。 受け入れテストも自動テストであることが推奨される。 自動化されたテストが、コードの共同所有・リファクタリング・頻繁な結合を可能にし、開発が進むにつれ変更コストが増大することを防ぐ一因となる。

ペアプログラミング

二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。 この役割を随時交代しながら作業を進める。 これによって、細々した問題解決に要する時間が短くなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、などの多彩な効果が得られる。

リファクタリング

完成済みのコードでも、随時、改善処置を行う。 この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。 テストが作成されていることが前提になる。

ソースコードの共同所有

誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。 ただし、全てのコードに対する責任を、全員が担う。

継続的インテグレーション

単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。 少なくとも一日に一回は、結合テストを行う。 また、全体のコンパイルおよび自動テストを行うための継続的インテグレーション用のコンピュータを準備することが推奨されている。

YAGNI

You Aren't Going to Need It（今必要なことだけ行う）。 先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。 むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。 このことで後のイレギュラーな変更に対応しやすいようにする。 必要なコードは先回りして書くのではなく必要になったときに書くという意味である。

/5. 管理者

責任の受け入れ

援護

四半期毎の見直し

ミラー

今どういう状態かをチームに知らせる。

最適なペースの仕事

知的作業には週40時間の労働時間が最適である。 特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。 そのため、計画的に開発スピードの調整を行う。

/4. 顧客

ストーリーの作成

求める機能のコンセプトを短い文章で記したストーリーカードを作成する。 そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。

リリース計画

どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。

受け入れテスト

イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。 もし満足できない場合は、それを指摘する。

短期リリース

スクラム開発

  • 原則として、スプリントで着手するプロダクトバックログ項目は、上位の項目から着手する

  • 幅広くいろいろなプロダクトバックログに着手するのではなく、上位の項目から「1つづつ」「全員でよってたかって」「完成させる」

  • すなわちプロダクトバックログ項目の単位での同時仕掛りの数をなるべく少なくし、かつ完成までのリードタイムを短くする

  • 完成させるためには、プロダクトオーナーの受け入れ確認が必要なので、項目が1つでも完成したら速やかに受け入れ確認を依頼する。すなわちバッチサイズを大きくしない

  • 完成させることが何より重要なので、効率ばかりを追求しない

http://www.ryuzee.com/contents/blog/7111

プロダクト・バックログ

プロダクト・バックログは、機能や技術的改善要素を優先順位を付けて記述したものです。ステークホルダ全員が参照し、現在のプロダクトの状況を把握できるようにします。

「ユーザーストーリー」形式がよく用いられますが、形式が重要なのではなく、関係者がいつでも内容を思い出せるようにすることが目的です。

| 誰のために 何のために

それを実現するのか|

について合意し、いつでも思い起こせるようにしておくということです。そうすれば、仕様変更が起きた時、「なぜ変更が必要なのか」が理解しやすくなり、プロダクトの全体の進捗への影響の把握・伝達がスムーズになります。

緊急な変更の時「そもそもこの機能は……」という議論や説得に時間をかけてしまえば、プロジェクトの死に直結しかねません。危機に陥る前に、定期的に自分たちの状況を共有しておき、透明性、信頼性を醸成しておきたいものです。手の内を隠してポーカーフェイスで交渉するより、手の内をさらして実力をありのままに把握してもらうのです。

スプリント・バックログ

スプリント・バックログは、プロダクト・バックログからスプリント期間（1～4週間）分を抜き出した「チームのタスクリスト」です。

チームは、予測どおりにきちんとタスクを終わらせられるかを検討します。チームメンバーの多種多様なスキルを総動員して、自信を持って「終わる」と宣言できるかどうかが、確認すべきポイントです。

スプリント期間中は、スプリント・バックログにある作業や機能を完了させるべく、チームとしてベストを尽くします。「私の仕事、あなたの仕事」ではなく、「チームの仕事」です。チームとして責任を持ち、全力で仕上げていきます。

そのため「チームとして情報を共有」することが必要不可欠です。そのために効果的なのが「デイリースクラム」（朝会）です。デイリースクラムは毎日、全員で進捗を確認するミーティングです。

答えることは3つの質問だけ。

|昨日やったこと 今日やること

障害になっていること|

この3つの答えをチーム全員で共有します。細かい問題に立ち入ることは避け（別に時間を取る）、トータル15分を目安に完了させます。

タスクボード

タスクボードは、バックログを壁とふせんで表現したものです。視覚的に状況を把握できるため、短時間で最新状況を共有するのに役立ちます。

|ToDo（これからやること） Doing,WIP,InProgress（着手していること）

Done（完了したこと）|

という領域の中で、タスクを表すふせんを動かしていきます。

スクラム導入事例

スクラム適用で重要と思われる点

  • 上級管理職のスポンサーシップとサポート

  • 経験豊富なトレーナーやコーチの参画

  • スクラム自体が会社の全体的な戦略やゴールに合致していること

  • スクラムを使って達成したい明確なビジネスゴールがあること

  • 従来のやり方からの反発の少ない移行

  • 成否を測定するための明確なメトリクスの存在

スクラムを使って成果を出す上で障壁となっている点

  • 組織構造や企業文化があわない

  • 伝統的なウォーターフォールからの移行が難しい

  • 他のプロジェクトとの兼ね合い

  • どうやって成功を具体的に測定してよいか分からない

  • 信頼関係の欠如

  • 予測を欲しがる

  • プロダクトオーナーや開発チームがスクラムのプラクティスに従わない

  • 透明性に対する恐怖

  • 顧客にスクラムが正しいアプローチだと理解してもらうのが難しい

  • 上級管理職がスポンサーになってくれずサポートもしてくれない

スクラムと併せて使っている技術プラクティス

  • 完成の定義

  • 自動化されたテスト

  • 継続的インテグレーション

  • リファクタリング

  • 適切なツールの活用

  • ペアプログラミング

  • テスト駆動開発

  • 受け入れテスト駆動開発

  • システムデザインのシンプル化

  • 技術的負債の測定

  • Specification by Example

  • BDD(ふるまい駆動開発)

  • モブプログラミング

導入状況サマリー

http://www.ryuzee.com/contents/blog/7112

スクラムマスターの仕事内容

  • スクラムのフレームワークをうまく回せるように支援する

  • スクラムチームにスクラムの価値やフレームワークを理解してもらう

  • ステークホルダーにスクラムの価値やフレームワークを理解してもらう

  • スクラムチームが持続可能なペースで進められるように支援する

  • スクラムチームが集中を維持できるように支援する

  • スクラムチームが透明性を維持できるように支援する

  • スクラムチームが規律を守れるように支援する

  • スクラムチーム内外のお互いの協力を促す

  • スクラムチーム内外のコミュニケーションを促す

  • スクラムチームの自己組織化を促す

  • スクラムチームが心理的に幸福であるように支援する

  • スクラムチームが自律・自立できるように支援する

  • スクラムイベントを時間通りに開始する習慣をつけさせる

  • スクラムイベントをファシリテートする

  • スクラムチームの学習を支援する

  • スクラムチームの気づきを促す

  • スクラムチームの改善を助ける

  • スクラムチームが無駄を減らせるように支援する

  • スクラムチームをとりまく問題を明らかにするのを支援する

  • スクラムチームが必要とする環境やツールの準備を支援する

  • スクラムチームが生産的な環境を維持できるように支援する

  • スクラムチームの整理整頓を促す

  • スクラムチームの要請に基いて手助けする

  • プロダクトオーナーから開発チームへの圧力解消を支援する

  • プロダクトオーナーと開発チームの対立解消を支援する

  • ステークホルダーとスクラムチームの対立解消を支援する

  • 開発チームやプロダクトオーナー単独で解決できない問題の解決を支援する

  • スクラムチームの外からの割り込みを止める

  • プロダクトビジョンの作成を支援する

  • プロダクトのマイルストーン作成を支援する

  • プロダクトバックログの作成を支援する

  • プロダクトバックログの並べ替えを支援する

  • 完成の定義の作成を支援する

  • メトリクスの収集を支援する

  • 見える化を支援する

  • スクラムチームやステークホルダーを観察する

  • スクラムチームやステークホルダーの相談に乗る

  • スクラムチームにフィードバックする

  • スクラムチームに対して指示をしない

  • 体調の悪い人を帰らせる（指示をしないの例外）

  • 開発チームの中にいる開発チームを破壊する人を取り除く（指示をしないの例外）

  • スクラムチームにとって自分が必要なくなったら自分を首にする

http://www.ryuzee.com/contents/blog/7115

オープンソースライセンス

朝会

キックオフ

キックオフミーティング

プラクティス

プラクティス一覧

ファストワーク

  • 「顧客にとって成功とは何かを把握する

  • 「それを基に素早くシンプルに実現する方法を探る」

  • 「その方法を試して学びを得る」

  • 「学びを踏まえて行動する」

http://itpro.nikkeibp.co.jp/atcl/column/16/111800263/111800001/?rt=nocnt

PreviousセキュリティNextチャットツール

Last updated