このタイトルには特に意味も伏線もないことを説明し忘れた【TECH::EXPERT】
SQL TECH::EXPERT アジャイル開発 スクラム プログラミング 応用カリキュラム編
【本日のメニュー】
・SQL （データの検索 発展）
・iPadでプロゲート
・嬉し恥ずかし再試（嬉しくない）
・アジャイル開発
【SQL （データの検索 発展）】
▼SELECT user_id, COUNT(*)
Length的なやつで、そのカラムの件数を数えるようでうす
▼GROUP BY句
GROUP BY カラム名
エクセルでいうところのセルの結合が行われるようです。
個人的にエクセルのセルの結合は嫌いです。
なのであんまり頭に入ってこなかった。
ここら辺はProgateでやるので、何回か遊んでみて雰囲気掴もうかと。
もしくは必要にかられたら戻ってきます。
このカリキュラムの最後の方にあった理解度テスト難しそ〜
早く挑戦して玉砕しなきゃ（使命感）
【iPadでプロゲート】
Bluetoothキーボードの「”（ダブルクォーテーション）」問題は無事に解決。
iPadの設定＞キーボード＞スマート句点
これをオフで、いつも使ってるダブルクォーテーションが出る。
このスマート句点っていうので、クォーテーションを2個入力すると、
引用の時使う全角ダブルクォーテーションに変換されてしまうみたい。
これでなかなかスムーズに電車の中での学習が進みますよ！
SQLの問題もやったのですが、SHIFT押しながら入力が、電車内で立ちの状態だとフラついたり、
指がプルプルしたりとありますが、特に問題なくできています。
これは爆速で捗りますわ！
そう思った矢先、新たな問題発生。
iPadだと右クリックがうまく効かない問題。
厳密にいうと右クリックらしきことはできるのですが、
問題は、iPad対応してないPC版のProgateを無理やりプレイしていることにあり。
右クリックでProgate特製メニューが表示され、そこにはファイルやフォルダの作成と言った項目があるのですが、
その特製メニューがひらけないです。
メニュー上のテキストをコピーするか？と聞かれるものの、
私が表示して欲しいものは表示されませんでした。
こうなると、何ができないって、Progateのrailsレッスンです。
これが電車の中でやりたくてiPad買ったんだYO！
Railsレッスンは、railsコマンドにて作成されたファイルの階層が表示され、
「ルーティング設定したね！次はコントローラーを設定しよう！」
「コントローラー設定したね！次はindex.html.erbを作成してみよう！」という流れで進みますが、
このファイル作成の際に、フォルダを右クリックしてProgate特製メニューからファイルを作成します。
このファイルの作成ができないため積みということです。
「採点間違いで再受験お願いします！」よりはるかにショックでした。
電車の中で「はぇええええええ〜〜」って声出てましたもん。
でもSQLはなかなかできたし、SASSのレッスンもあるし、
無駄な買い物ではない。はっきりわかんだね。
色々見てるとアップデートでiPadがマウスに対応するとかなんとか書いてあるんで、
そしたらトラックパッド付きのBluetoothキーボード買えばいいかな。
今のキーボードはメルカリで売って、メルカリの勉強にもなる。
きっと、もともとそういうシナリオだったんだ。そう思ったとさ。めでたし。
【嬉し恥ずかし再試（嬉しくない）】
再試を受けました。恥ずかしながら採点ミスで再試になるという試練が与え給われたり。
自己採点5分って短いから焦るんだよね（言い訳）
問題とは全く関係ないルーティングエラー（凡ミス風）とかすげーいやらしかったゾ。
またgit cloneしくじったのかと思ってキョロキョロしましたわ。
再試受けた人ならわかってくれるかと思いますが、まだ普通体型でよかったです。
頭使うから食べる量が半端なくてさ。最近太ったんだよね。
【アジャイル開発】
できるときにやったこうと読み物系をクリアしておこうと思って先んじて読みました。
が、進捗上がらない項目で地味にがっかり。
できるようになって嬉しいって結構後で気付くから、
序盤はこういう進捗溜まってるで心の平安が保たれていたのですが…
でも真面目読んだのでメモ書いておくわ！
▼アジャイル開発とは
依頼主からの要望が変わるということは日常茶飯事なので、この仕様変更に対応するために細かく作って細かく確認する必要があり、
それに最適な方法がアジャイル開発である。
アジャイル開発は、仕様が決まったものを一気に作り上げるわけではなく、少しずつ確認をはさみながら開発を進めることが特徴の開発手法です。
利用者からのレビュー、関係者からのレビューなどで調整しながら進める。
＞説明を聞くとアジャイル開発の方がメリットが高そうですね。依頼やレビューに柔軟に対応できる。
私はまだまだ超初心者の部類なので、少しずつ確認しながら進める方がやりやすく感じます。
単純に考えてまとめて一気に作ると１か所しくじったら爆発じゃないですか。
でも、まだまったくできてないのに要望だけが増えてくると困るけど。
▼アジャイル開発のキーワード
・スプリント
＞１週間ずつのスプリントで回していくことが多いそう。PDCAの単位のようなもの。
・スプリント計画ミーティング
＞１スプリントが始まる前にするMTGでタスクと目標を共有する
・スプリントレビュー
＞スプリント計画ミーティングは開始日、スプリントレビューは終了日に行うもの。
依頼主や上長にレビューをもらう場
・スプリントレトロスペクティブ
＞スプリントレビュー後に行う、反省点や維持する施策などをチーム
で共有する
【他の開発手法】
▼ウォーターフォール開発
「開発初期段階に要件を決定し、完成までの実装スケジュールまできっちり決めて開発に取り掛かる」方法だそうです。
初めに決めた要件を、ある期限までに完了するという手法です。元来からの契約→開発→納品というフローに則ったシンプルなもの。
厳密な要件定義と納期に合わせた進捗管理が必要。
＞なれた人だったら、この方法でやった方が一気に作り上げることができて、時間も調節しやすいからライフワークバランスとりやすいのでしょうか。
これをしても納期が守れないこともあるし、仕様変更しないと実装できないこともあるので、この方法にピンときません。
規模が小さく、とくに仕様が揺れない、納期が決まっているなどだとこの方法が適しているのかな？という感想。
【開発手法比較】
▼アジャイル
メリット：手直しが容易で仕様変更に柔軟に対応可能
デメリット：進捗が把握しづらい
▼ウォーターフォール
メリット：開発計画がシンプルで、進捗管理がしやすい
デメリット：仕様変更に対応しにくい
【スクラム】
アジャイル開発でも様々なフローがあるらしく、有名なもので「スクラム」があるという。
リーダー・マネージャーが主体ではなく、メンバーひとりひとりが主体性を責任を持つこと。
簡単にいうと指示待ちはダメで、関係はフラットにしようっていうようなことかな？
どっかのコンサルさんが、マネージャー層の高給取りの人数が減って、
全員が主体的に手を動かして何かを作るていうのがアメリカだと増えてきているとか。
経営者・役員 + その他大勢のプレイヤー というふうな会社がどんどん増えてくると予想するてきなことを言っていた記憶がある。
メルカリではこのスクラムをするそうなので、「ああ、近い未来こういう感じで仕事するんだなぁ」っていう肌感がわかるかもしれませんね。
▼スクラムの大まかな進め方
①アプリケーションの要件を決定
・アジャイルだとしても大枠を決めるくだりは必要
・依頼者からヒヤリングしてどのようなアプリケーションを作るか把握
②開発の意図を、開発する人々が完全に把握する
・どんな目的のためにそのプロダクトを作るのかを把握する
・その目的に矛盾する機能や優先順位付けのためにこの考え方はメンバーで統一しなければいけない。
③実装すべき作業を洗い出す
・洗い出しリスト化する
④作業の量を見積もる
・上記作業の作業量（工数）を見積もる
⑤スプリントごとに実装する
・スプリントはアジャイル開発のPDCAの単位みたいなもの
・これを区切って実装する計画を立てる
⑥スプリントの成果を発表する
・１スプリントの計画が計画通りかのチェック
⑦振り返りを行う
・早く進める対策などを立てる
多分⑤～⑦が終了までリピートする。
【スクラムにおける役割分担】
▼プロダクトオーナー：プロダクトバックログの管理責任者
・プロダクトの結果責任を追う
・開発チームのパフォーマンスの最大化＝プロダクトの価値の最大化
・各々の主体性が求められる手法だが最終的決断を下すのはプロダクトオーナー
＞意見が割れた時や仕様が大きく変わりそうな時はプロダクトオーナーが決断を下すとい解釈
▼スクラムマスター：スクラムの調整役
・スクラムがうまく回るようにサポートする
＞スケジュールや工数見積もりなどかな？
・人間関係をスムーズに保つように妨害（暴力的な発言？）など排除する
・スクラムが円滑に回るよう世話役ポジション
＞中間管理職？
▼開発チームメンバー：実際に開発に携わる
・上記のプロダクトオーナー、スクラムマスターはこれを兼任？
・計画に沿ってプロダクトを作る
・開発計画について話し合い、必要であれば計画変更の申し入れなども行う
・上下関係はなく、チーム内の進め方はメンバー間で決める
３つの役割を合わせてスクラムチームとなる。
【開発開始から終了までのサイクル】
▼要件とゴールの確認
依頼主よりヒアリングしどんなものを作って、何を達成したいのかを知る。
▼作業を洗いだしてリストを作成する
プロダクトが完成するまでに必要な工程(要件定義、実装、テスト、公開など)を洗い出し、リスト化する。
これをプロダクトバックログという。
プロダクトバックログ単位で作業を分担する。
チーム全体のTODOリストのような塊。
▼スプリント計画ミーティングの実施
プロダクトバックログを具体的なタスクに分割し、スプリントバックログというリストにまとめる。（TODOリストのようなもの）
タスク細分化の例
#プロダクトバックログ
– Pictweetのツイート機能を作成する
↓
#スプリントバックログ
– ツイート保存用のテーブルを作成する
– 投稿の一覧画面の見た目を作成する
– ツイートが保存されるまでの処理を書く..など
あらかじめ担当を決めることをせず、
実際に作業をする時に、開発メンバーがスプリントバックログの項目を選択するようにします。
＞こういうところで主体性を発揮して、柔軟な開発をしていくイメージですかね。
▼デイリースクラムの実施
毎日決まった場所で、15分間のミーティングを行います。
▼スプリントレビューの実施
目的通りのプロダクトになっているかレビューを受けます。
▼スプリント振り返りの実施
スプリントレビューでの振り返りを行う。
「スプリントのよかった点」「改善したい点」「次回のスプリントで挑戦すること」の3項目について話し合う。
＞レビュー後の作戦会議のようなもの。
【開発の終了の定義】
プロダクトバックログの内容を全てクリアできたらプロダクトの完成。
ToDoリストにチェックを入れて消していく快感を味わおうぜ（ゲーム脳）