スケジュール
システム開発におけるスケジュール
プロジェクトによって性質が異なる
具体的なゴール日がないもの
調査的なタスクなど
明確にゴール日があるもの
請負的なタスクなど
リリース日が決まっているものなど
https://gyazo.com/9b7b5ee3dc501ece154b2a7bfda6dbdf https://twitter.com/oryzae1824/status/1759423071633719626
マジでそうかも知れない
「適切性や妥当性」の検証方法を誰も知らない
作る際のコツ
スケジュール
上手く言ったパターン
上手くいかなかったパターン
を考えておく
実際にかかった時間をメモっておく
予定していた時間おｔ
何で遅れたのか、何で早まったのか
感覚を洗練させていく
いずれにせよ、メモしとかないといけない
知らないところをどう想像するのか
例えばRustをやったことがない人が、「RustでHogeHogeを作る！」と言ってスケジュールを立てる時に、まずしないといけないことはなにか
Rustについても、HogeHogeについてもよく知らない状態
みたいなところがちゃんと理解できていない
想像ができない
できるが、甘い、全く足りていない
足りていないことを考慮に入れてスケジュールを広めに作るのか
スケジュールを立てるなら、想像できないといけない
そのために
自分で調べる
時間は決める
対象が複数ある場合もトータルの時間を決めてみる
今は二日間だが、無理でした、というのもあり得る
知っている人に聞く
何を知ってて
何を知らないか
逆に0ベースで、概要を人に聞く、というのもある
実際に手を動かして触ってみる
まずスケジュールを建てるために必要なこと」を知るために必要なこと」を知らないといけない
プロジェクトを始める前に「毎回このサイクルをやる」というのを決めておきたいmrsekut.icon
これまでの反省と問題点
たぶん、プロジェクト開始時に「まずスケジュールを立てる」という発想がおかしい
スケジュールを立てるまでに必要なことをかなりすっ飛ばしている
フェーズごとの見落としがちな項目をメモっておくと良いかもねmrsekut.icon
開発の終盤
運用側で何かしらの手順が必要ではないか？
運用する人たちに運用手順を確認してもらう必要はないか？
テスト期間とは別に「UX改善を検討する」期間を設けて置いたほうが良い
デザインだけでは見えていなかった、動き込みのUX改善というものが存在する
この段階で検討するのはおそすぎる気もするけど、時間は取っておいたほうが良い
パフォーマンスを改善する期間もいる
SEOやメタタグ
未定義の機能があることを前提として、その分の余裕を持っておく
UXを考える時間が必要
実装してから体験の悪さに気づく部分はある
導線でもありうるし、ロジックの実装の仕方でもありうる
validation errorのタイミング、ローディングの表示など
パフォを考える時間も取っておく
3だんかい
docs読む
手を動かす
テスト/リファクタする
5分プロダクトを触って不具合が1件以上出る
→潜在的な不具合が10個ぐらいある
15分プロダクトを触って不具合が1件以上出る
→潜在的な不具合が5個ぐらいある
30分プロダクトを触って不具合が1件以上出る
→潜在的な不具合が2~3個ぐらいある
リリース前日の時点でここのレベルに来ていれば、翌日にはリリースできる
理想では二日前にこの状態になっていると良い
リリース日の延長をもうちょい早めに決定するとか
5~10分触って指標にしよう
残りの時間で
リファクタできる
テストコード書ける
UIを改善できる
リリース直前の改修によるデグレを防げる
https://gyazo.com/886630e856190e9707428e5c11993d8b
気になっているのは、「スケジュールを立てる」ためにかける時間
いつもここに焦ってあまり時間を取れないでいる
さっさと開発を始めなきゃ、という気持ちになってしまう
調査系のことが多い時にどういう見積もりをするのか
「工数見積」と聞くとなんかだるさがあるが、「論理構造の組み立て」と考えると楽しく見える
ググって出てきた手順
規模ごとに計画を作る
毎回3つとも付くわけではない
大日程計画
プロジェクトで実施すべき作業内容と作業日程を明確にする
見積もり時、プロジェクト計画時に作成する
月単位、週単位
中日程計画
タスクごとの詳細な作業日程を明確にする
各タスク開始前に作成する
週単位
少日程計画
タスクごとの個人レベルの作業内容と作業日程を明確にする
各タスク開始前に作成する
日単位
手順
作業を分割
WBSによって作業を分割
大日程計画
成果物を作成する作業の最小単位
工数にして2週間程度らしい
1週間でもいいらしい
これを超えるなら更に分割しよう
中日程計画、少日程計画
アクティビティまで分割する
成果物の有無を考慮しない作業単位
どういう意味？？？？
この時に用いるのが作業項目ごとに成果物や工数，要員などを定義する手法，WBSだ。これを使うメリットは大きく2つある。1つは，成果物に基づいて作業を分割していくため，作業漏れの有無を検証しやすいこと。もう1つは洗い出した作業と成果物の関係が明確になるため，作成する成果物の量や作業にかかる工数の見積もりがしやすいことだ。
わかりそうで何を言っているのかわからん
作業内容を定義
基本設計
詳細設計
プログラム作成
デバッグ
リリース作業
このタイミングでドキュメントを色々整備できたのは良かった
deployの方法を具体的に把握していなかった
メンテにする方法
ここの準備が足りていないことに気付いていなかった
りりーする方法
当日やった「リリース工程」を2人で見ながらの確認を前日までに済ませるべきだった