ソフトウェア開発

スケジュールを決め

役割分担を決め

仕様を決め

あらゆる調整をし

スケジュール管理を行い

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

成果を報告する

プロジェクト基本情報

キーワード 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図）、テーブル定義書、画面定義書、画面遷移定義書、帳票定義書、開発標準書
詳細設計	詳細設計書、クラス設計書、構成管理定義書、インターフェイス設計書
開発／単体テスト	単体テスト仕様書
結合テスト／システム・テスト	テスト計画書、結合テスト仕様書、システム・テスト仕様書
本番／運用	環境構築手順書、運用定義書、障害対応手順書、移行仕様書、移行手順書

ソフトウェア開発データ

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

自動化

各フェーズの位置づけ

詳細設計

関数の役割、引数の設計

（スケルトンの作成）

各種ファイル環境の構築
テストケースの記述
テストデータ（サンプル）の作成
製造物のレビュー

製造

関数の中身の処理の記述
ソフトウェアのバージョン管理
テストパターンの記
設計バグの検出

体制開発を３分割する

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

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

クラス: OOの世界では，クラスがソフトウェアシステムの最小構成要素です。
コンポーネント: コンポーネント (またはサービス) は一般的に，複数の協調動作するクラスで構成され，粒度の粗いインターフェースの背後にすべて配置されます。例としては "リスク計算"，"監査コンポーネント"，"セキュリティサービス"，"Eメールサービス" など，開発中のシステムによってさまざまです。
コンテナ: コンポーネントが実行されたり，あるいはデータが設定されたりする場所を表すものです。Webサーバ，アプリケーションサーバといったものから，リッチクライアントアプリケーション，データベース，あるいはファイルシステムといったものが考えられます。コンテナは通常，ソフトウェアシステムが動作している間は常に実行，あるいは有効であることが必要です。コンテナの観点からソフトウェアシステムを理解する上で重要なポイントは，コンテナ間通信にはすべて，Webサービス呼び出しやリモートメソッド呼び出し，メッセージなどのリモートインターフェースが必要である，ということです。
システム: システムは抽象化の最上位レベルであり，例えばエンドユーザに価値を提供する存在を表しています。

MoSCow

必須 Must have ：これがなければシステムが成り立たない
必要 Sould have ：重要な操作
要望 Could have ：できればあった方がよい
次回 Wanto to have ：次回

ジョエルテスト

ソース管理システムを使っているか？
オペレーションでビルドを行えるか？
毎日ビルドを行うか？
障害票データベースを持っているか？
新しいコードを書くまえにバグを修正するか？
更新可能なスケジュール表を持っているか？
仕様書を持っているか？
プログラマは静かな労働環境にあるか？
買える範囲で一番良い開発ツールを使っているか？
テスト担当者はいるか？
プログラマを採用するときにコードを書かせるか？
「廊下での使い勝手テスト」を行っているか？

開発プロセス

ウォーターフォール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

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

アジャイルに何を求めるのかを確認する
準委任(SES)契約を勧める
一括契約ながら成果物をあいまいにしておく

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

サービスキャンバス

満たすニーズ
ターゲット
現状の解決方法
提供する解決方法
利用モチベーション
現状の解決方法に対する優位性
コンセプト
主要成功要因
流入経路
コスト
収益

KPI

コアバリューの醸成に寄与すること
その指標を改善することでサービスのコアバリューがより強固になる指標であること
定点観測可能なもの
日次/週次でユーザの行動を反映した変化を得られる指標であること
定量的であること
数値として測定できる指標であること
分かりやすいこと
プランナーだけでなくエンジニアやデザイナーにとっても理解しやすい指標であること
行動をとりやすいこと
その指標を改善するための具体的な施策がイメージしやすいこと

基本項目

サービス名
ドメイン名
コードネーム
リリース日
提供プラットフォーム
動作環境
サインアップ方法

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

Files

ソフトウェア開発.md

Latest commit

History

ソフトウェア開発.md

File metadata and controls

ソフトウェア開発

プロジェクト基本情報

不確実性

高速適応性

複雑性

レーダーチャート指標

いいプロジェクト

教訓

哲学

Unix哲学

人月の神話

プログラマの生き様

代表的な要素

Googleの開発スタイル

アンチパターン

アジャイル宣言

開発フェーズ略語

文書の種類

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

ソフトウェア開発データ

自動化

各フェーズの位置づけ

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

MoSCow

ジョエルテスト

開発プロセス

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

DevOps

DevOps 文化と組織

参考スライド

アジャイル

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

アンチパターン

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

モダンアジャイル

リーンスタートアップ

開発初期にやるべきこと

サービスキャンバス

KPI

基本項目

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

XPの価値

スクラム開発

スプリント・バックログ

タスクボード

スクラム導入事例

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

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

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

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

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

朝会

キックオフ

プラクティス

ファストワーク