# アジャイルとは

https://whimsical.com/26cN3PYqCh7i9RAndebVWQ

そもそもの業務内容，アジャイル対象の業務（上流？中流？全工程？）
- 現在のプロジェクトの人数，体制
- 1チーム5名＊3チーム程度．チームごとにアイテム（粒度中）を取ってもらう．アイテムに作業録が必ず紐付き，たどれるようになっている．
- 上流アジャイルの方法(僕らのメーカーフェアスタイルは割とアジャイルだったと思う．あれみたく，いくらかは内製要素が必須？完全外注で上流のみ管理のときに回せる者では無いと思うが，どうだろう)
- 依頼する側はできるだけ早期に不確実性を潰したい．そのためには早期にプロトタイプが入手できる必要があり，これには依頼先がアジャイルを取り込んでいる必要がある（アジャイルによって正しく機能するものを作っていく）
- ハードウェアの方法
- できあがってからreviewではなく，なるはやでプロトタイプでfeedbackすること．できるだけ早い段階で齟齬に気づくことで，遅くてもいいから正しく作ることが重要=アジャイル
- アジャイルでもwaterfallでも計画立ては大事．難しい複雑な課題が明確/不明確な部分を仕分ける．e.g.統合試験で問題が出そうなとき，早く取り組めること
- 失敗前提でもいいから早期に．
- 不確実性を取り除くことを最優先
- 目的不確実性
- 計画不確実性
- 
-　文書管理は透明性を重要視．検索性の向上（単語，日付，作業録）．個人で持たない

## アジャイルでのPMの仕事
- 優先度の管理．あとはリファインメントの検討，進め方の組み替えなど（サブシステムのtopなど）
- 自分が抱え込まないように，透明性の維持
- 現場の力だけではなく，上の人の理解も必要

## 重要なのは継続的な振り返り，互いに指摘しあえる関係
* （熟練者以外が入る状態で例えば3ヶ月のキャンペーンを乗り切る！などには，知見が溜まる前にチームが解散してしまうので次に活かしづらくアジャイル向きではない）．2，3年を経てチームが進化していき，徐々に加速していくイメージ．

どう進めていくかを常に皆と話し合う・共有が大事
立ち上げから完了・運用まで同じ人が携わり続けるのが理想（途中で出てくる問題に臨機応変に対応するために）
waterfallの要件定義したから後はよろしく，だと上流に帰結してフィードバックがきかない．
waterfall/agileのハイブリッドが良い

- agileはまっとうに正しく開発できる点．科学的再現性が高い方法であって高速に開発できるわけではない
- やること決まっててぶれないときにはwaterfallの方が良い
- その場合はwaterfallの方が早い
- agileはユーザに話を聞いたりやってみないと分からないことが多い場合
- 失敗・成功経験は文書から得られる者は少なくて，やってみないとわからないことが多い．障害対応をアイテムとして詰んで経験したり．

## 一問一答
- 抜けるとき，入るときの引き継ぎ方法
- Whimsical参照

- サイクルの回し方（スクラム？），進捗や残りA/Iの確認タイミング
- Whimsical参照

- 予算の申請・見積もり（計画外の出費の程度は多い？そうでもない？）
- 出費の発生原因を時々で振り返るしかない.不確実項目は早期に潰すしかない
- 開発速度についてどうおもう？はやい？そうでもない？
- 遅いけど、正確、品質が保証される
- プロジェクト規模によってやり方が変わる？小型の場合，大型の場合(社内で．情報共有サイトをためしにアジャイルでやってみようとしている（sharepointベース）．期間1ヶ月程度．もしノウハウなどあれば教えて欲しい．あるいはおすすめの題材等)
- waterfall/agileのくくりはない．agileのコーチを雇って教育しながらやる方法もある．進める中で発生する疑問にすぐ答えてくれる環境が必要．最初は5,6人程度ではじめるのがおすすめ．
- 大型の場合は，一番の課題となる目的不確実性を潰すこと・その敷居をさげることにagileの体で早期に取り組む（e.g.毎週かみ合わせ試験する）

- インセプションデッキは，プロジェクトのたびにやっているのか？プロジェクト中にもやることがあるのか？時間取られてしんどそう
-　プロダクトビジョンは1週間に一度共有．インセプションデッキは3ヶ月に一度．中でもトレードオフスライダーが大事．
- ビジョナリーリーダ，オペレーショナルリーダに相当する者はいるのか？理想論？
- 役割を明確に振ってはいない．プロダクトビジョンは，PMや偉い人たちが意義・価値を熱い思いで抱いている必要はあり，皆がそれを認識して動けること
- 各サブシステムごとの障壁を潰すためにアイテムを消化していく．役割を置く必要がある場合は用意したらいいだろう

## 宇宙機の開発フローざっくり

1. ブレッドボードモデル (BBM)
- 実現可能性の検討
3. エレキモデル (EM)
- かみ合わせ・バグ・要回収項目洗い出し
4. フライトモデル (FM)
- 最終試験・flight

## 小型衛星

EM,FMでそれぞれ通信機を2つ用意した。一つはバックアップの位置づけで、宇宙研で不具合が見つかったらすぐにメーカーに置いてある通信機にフィードバックした。結果，私見を平行しながらも改修が早くできた。

2つあるので、冗長性を保てる。
一つしか用意しない場合，それも買い物の場合には問題が起きたらどうしようもない。

## 組織

アジャイル開発組織は、できるだけ同じメンバーが携わることが望ましい。
- アジャイル開発の重要な要素として、「継続的な振り返り」「お互いに課題を指摘しあえる信頼関係」

プロジェクトではなく、プロダクトで考える。