railsのエラー処理
参考
1.controller外でのエラー処理
例えば、routing時のエラー(存在しないurlの指定)など
Rails の rescue_from で拾えない例外を exceptions_app で処理する - Qiita
参考コード
add: routing時のエラー制御等を追加 · fv17/rails6-practice-guide@9867d5a · GitHub
2.controller内でのエラー処理
Action Controller の概要 14.Rescue
参考コード
add: エラー表示画面を作成 · fv17/rails6-practice-guide@d86e36a · GitHub
メモ、補足
書籍(Rails実践ガイド)だとStandardErrorもハンドリングしているが、Railsガイドだと非推奨。 親クラスなので、一番最初に指定しないと全て500でキャッチしてしまうリスクがある。
rescue_fromにExceptionやStandardErrorを指定すると、Railsでの正しい例外ハンドリングが阻害されて深刻な副作用が生じる可能性があります。よほどの理由がない限り、この指定はおすすめできません。
参考コード
スクラムマスターとしてすべきこと
メモ
SMとしての役割
- 仕事の可視化
- ムダの可視化
- モチベーション向上
- 障害の追跡と除去
- イベント成果物への集中
- 依存関係の可視化
POへの支援
- リリース計画の支援
- Epicを見積もる
- リリースバーンダウンチャートの作成
- デミングの20%の変動(期間が長いと50%ズレる例も)
- ステークホルダーからの要求管理を支援
- スコープ設定やMVPでの製品開発を支援
開発チームへの支援
- 機能横断的な動きを支援
- スケジュールの可視化を支援
- 技術的リスクの発見を支援
- リーンなドキュメント作成を支援
- タスク分割や割当等を支援
1/2の時間で2倍の成果を出すには？
- 安定したチーム
- 昨日の天気で早く終える
- 3スプリントの平均ベロシティを計画に考慮
- 終わらないスプリントはチームの士気を大きく下げる！
- スウォーミング
- 思考の切り替えはムダである
- 優先順位の高いものから順に終わらせる
- 機能横断を実践するためT型人材
- 割り込み
- 割り込みのためのバッファを、あらかじめ計画に含めておく
- 計画時に詰め込みすぎず、余力を残す
- クリーンなコード
- バグはその日のうちに
- 幸福指標
- コミュニケーションコストを下げる(RW時)
- 必要なツールは導入
- テキストではなく、小さいMTGを開く
ファシリテーションについて
自分用メモ
ファシリテーションとは
- 「腹落ち」を生み出すコミュニケーションの技術
- 「腹落ち」= 目的と理由の理解、ゴールの理解、当事者意識、ワクワク
- リーダー必須スキル
目的、重要性
- 参加メンバーの知恵を引き出し、意欲を高める、自ら動く
難しさ
- 思考力、理解力、表現力が同時に必要
- しかし、思考の処理能力には限界
- そのため、会議中に考えることを少なくしておくことが必要！
事前準備(仕込み)
- 出発点と到達点を明確に
- どこから始めるべきか / どこまで結論を出すべきか
- 具体例：課題を解決したい場合のSTEP(次の4つのうち、スタートとゴールは？)
- 場の目的の共有(なぜ？)
- 解決に向けたアクションおよび理由の共有
- アクションの合意
- 実行プランの共有
- 出発点@参加者の状況の把握
- 認識レベル
- 意見や態度
- キーパーソンや人間関係
- 出発点と到達点における参加者の状態を明確に
-
- 到達点に至る論点の整理
-
会議の進行(さばき)
- 発言を引き出す
-
- 発言を理解/共有
-
- 議論の方向づけ
-
- 結論づける
-
スクラムマスターとして意識すること
- 質問を多くする
- 素晴らしい聞き手
- アイデアをまとめる手助け
- プロセスの外部に
スプリントバーンダウンチャートとは
概要
タスクの残りの作業時間見積もりをチャートにしたものを、スプリントバーンダウンチャートと呼ぶ。
X軸には、経過日数や日付。Y軸には、作業時間やベロシティ。
目的
チームの自己管理能力を強化するため、
- スプリントの進捗、WIPであるタスクの有無を可視化する
- 問題が発生している場合には、早期に手を打つ、POに相談する
- 余力がある場合には、次の作業に取り掛かる
※通常、スプリントの半ばまでに順調に行っていない場合は、問題点を明らかにし、改善策を考えたり、POとの連携が必要になる。
運用
チャートを更新する
- タスクの完了時
- 緊急の要件と計画外の作業の発見時
重要なイベントでは付箋を貼る
- 増減があった場合などメモを残し、振り返り時に活用する
チャートから分かること
進捗が悪い場合
- 緊急の要件
- 技術的な問題
- 既存コードの品質が悪く、不具合が多く出た
- 技術的負債が多く、思ったように進まない
- 新規技術など、学習コストが掛かる
- 重要な人や能力の喪失
- 計画に詰め込みすぎ(キャパシティには昨日の天気を使用すること)
- 計画時のタスクの洗い出しの抜け漏れ
後半に一気に終わる場合
- スプリント最後に追い込み(無理)
- タスクの残時間の更新を毎日していない
- 終わってないタスクの省略や持ち越し(テストなど)
理想的なチャート
- 最初は作業量が増える山なりのチャート。
- 計画時には70%ぐらいしか見えないため、開発中にタスクが判明することは多々ある。
問題発生時の対処(優先度順)
- 作業方法の変更(戦略変更やスウォーミングなど)
- スコープの縮小
- スプリントを停止し、再計画
- リリース日に影響する場合は、ステークホルダーへ通知
補足
タスク毎に作業時間を出してプロットする派閥と、PBIの完了だけをプロットする派閥の2つ存在する。
参考
スクラムチームをカイゼンするアイディア
自分用メモ
- 設計やそのための調査におけるペアプロ
