Please enable JavaScript.
Coggle requires JavaScript to display documents.
KPT:+1: - Coggle Diagram
KPT:+1:
Keep
状況報告を早めにできていない:cry:
早めがいつか分からない
いつまでに
終わらぜるべきか聞く:muscle:
いつまでにやればいいのか
確認できるようになった:+1:
状況確認してもらえるので
タイミングがつかめるようになった:+1:
適切なタイミングで報告できていると
ほめてもらえた:+1:
中途半端な状態で
レビューに臨んでしまった:cry:
レビューを分ける場合でも
日にちごとのレビュー範囲を決め、
到達しなければリスケする:muscle:
遅れた場合もリスケできた:+1:
目標を決め、そこに向かって
進めることができた:+1:
問題が起きたらすぐに
打ち上げられるようになった:+1:
人に成果物を見せることに
抵抗がなくなった:+1:
入力文書を塗りつぶしながら
実装できるようになった:+1:
修正箇所に対してデバッグが甘く、
いくつか不具合となった:cry:
修正後も代表箇所だけでなく、
ちゃんとデバッグする:muscle:
デバッグ観点をレビュー時に
レビューアに確認してもらう:muscle:
レビュー前に観点を整理して
デバッグできた:+1:
動かないNGはかなり減った:+1:
(単体検査v1.0)
正常系のNGは出なかった:+1:
(単体検査v1.0)
重めの設計不具合を実装工程の
デバッグで見つけることができた:+1:
テスト設計しやすくなった:+1:
調査結果などのドキュメントに
自分の考えやエビデンスを
残せるようになってきた:+1:
指摘をきっかけに意識するようになり
残せるようになった:+1:
タスクが多い時てんぱりがち:cry:
タスクを整理整頓してみる:muscle:
整理：不必要なものを取り除くこと
整頓：並べること
整理(軽いタスクはすぐ終わらせる)
整頓(優先順位絵を決める)できるようになった:+1:
レスポンスが早いとほめてもらえた:+1:
順を追って話を展開するのが苦手:cry:
レビューでも展開が難しい、、:cry:
アジェンダを先に説明する:muscle:
想像と違う話の展開だと
話が頭に入りにくい
アジェンダを事前に考え
レビューの冒頭で説明できた:+1:
分かりやすかったとほめてもらえた:+1:
レビュー頻度が多いときは簡単に説明するなど
臨機応変に対応できるとよい！
仕様の説明が冒頭にあり分かりやすい:+1:
説明することにより
レビューイが理解できているかの
確認にもなるので良い:+1:
Try
実装工程
実装前に全体像を
把握できていない:cry:
入力を明確にできていない:cry:
先に図にまとめてみる:muscle:
仕様の確認不足が多かった:cry:
本来は考慮すべき箇所が考慮できていないなど
言われたとおりに実装しなくちゃという考えで
なんでその処理が必要なのか考えられていなかった
処理の意図が説明できるようになる:muscle:
なんとなくで実装しない:muscle:
背景を把握する
デバッグの時間が長い:cry:
デバッグNGはあまりよくない
実装内で作り切る:muscle:
:star:先に設計してから実装してみる:muscle:
メッセージが意図通りでない
NGが多かった:cry:
:star:メッセージも意図通りか確認する:muscle:
異常系でテストNGに
なったものもあった:cry:
:star:異常系に考慮漏れがないか
もう少し考えてみる:muscle:
テスト実施工程でも足りていない
テスト観点を見つけられるとよい:muscle:
(自分がテスト設計をしていない場合)
サンプルコードを理解しきらず
レビューにもっていってしまった:cry:
理解しきってからレビューに臨む:muscle:
サンプルコードがある場合、
読解の時間も計画に入れる:muscle:
仕様に合っていない可能性もあるので要注意！
「軽い修正だから」と甘く見てしまい
デバッグしなかったことで
不具合を出してしまった:cry:
軽い修正でも必ずデバッグする:muscle:
テストで見つかりたくない！
という意識でデバッグする:muscle:
テスト仕様書ができていれば
テスト仕様書を確認してデバッグする:muscle:
質問
確認したにもかかわらず、
同じ個所で認識ずれが
起きていることに気が付かなった:cry:
背景を理解できて
いなかったことが原因
背景を理解して実装する:muscle:
:star:実装前に斎藤さんに
仕様の説明を聞いてもらう:muscle:
斎藤さんに仕様説明できた案件は
生産性が高かった:+1:
(MILS-PILS結果v1.0)
規模が大きな実装の場合、
機能の中身はブラックボックスでいいから
機能間の入出力は理解しておく:muscle:
理解のゴールを明確に
しておくと理解しやすい
独自のチェックシートを作ってみる:muscle:
:star:ツールの入出力の
パターンを網羅する:muscle:
(異常系も含めて)
ただし着手が遅れるほど前準備に
時間をかけるのは本末転倒
最初のうちは時間を
かけてでもやってみる
徐々に時間を縮めていく
やるべきことはやらないと
成長出来ない！
質問して解決することが多い:cry:
ゆくゆくは自分で
解決できるようになりたい！
一気に質問数を0にすることを目指すのではなく、
一つずつ減らしていく活動を行っていく:muscle:
質問内容を分析する:muscle:
自分で解決すべきもの
だったのかという観点
同じQAが出そうかという観点
:star:質問時、○○の場合は××ですか？
などと提案してみる:muscle:
自分で考える特訓にもなる！
質問される側も楽！
相手の視点に立って考える
:star:質問時、結論や背景から
述べるよう意識する:muscle:
その他
事前にリスクを洗い出せない:cry:
後からぽろぽろ出てきている:cry:
事前に設計することで先に
リスクを洗い出せる？
:star:先に設計してから実装してみる:muscle:
対策していかないと直らない
メールは3.4回読み返す:muscle:
意図通りか確認する:muscle:
誤字していないか確認する:muscle:
社外の場合特にやり取りは
少ない方がよい！
分析ができていない:cry:
どこで問題が起きたのか考える:muscle:
あの時○○していたら
××になったかもなど考えてみる:muscle:
同じミスを繰り返さないように！
自分なりに完璧なものを作る:muscle:
try&errorを繰り返しよくしていく！
期待通りか期待+αを目指す:muscle:
チャンスがあったら取りに行ってみる
与えられた時間内にやり切るよりも
納得できるものを作る:muscle:
レビュー時間をリスケしてよい
レビューは最終確認の位置づけ
成長につながる！
不安であればレビュー回数を
増やしてもよい
テスト設計の場合
観点表完成時点で
まずレビューするのもあり
心配事はつぶしていく
安心できるように
進めていくことがベスト！
そろそろ議事録も
練習していった方がよい？
機会を作ってもらう
話しながらエクセルに
まとめていく方がよい？
(中村さん流)
紙に書き、あとで重要なものだけ
エクセルに書き出す形でもOK
(竹谷さん流)
エクセルに書きながらでも
後からまとめ直す作業は一緒なので
すきなほうでOK
分担を決めていないのに
相手がやってくれると思い
漏れが出てしまった:cry:
人のものも自分がやる:muscle:
人は楽な方へ行きがち
計画
仕様を読んでどのくらいの行数で書けそうか
感覚的にわかっていない:cry:
まずは見積もってみる:muscle:
徐々に確度を高めていく:muscle:
自分で見積もれるようになる:muscle:
レビュー全般
レビュー指摘が多い:cry:
各出口で出力のパターンを考える:muscle:
誤字も多い:cry:
2.3回読み返す:muscle:
指摘されそうなことを
事前に中村さんに確認できた:+1:
今後レビュー項数を減らす:muscle:
リスクの低い個所は短く、高い個所は
じっくり見てもらい、効率的に:muscle:
じっくり見てほしい個所を
先に伝えるとよい:muscle:
レビューで指摘がなく流出不具合となった場合
どう説明すれば見てもらえたのか考える:muscle:
テスト設計工程
テスト設計が難しい:cry:
外部仕様を徐々に細かく落としていく:muscle:
入力・出力・コンフィグの
各カテゴリに分ける:muscle:
出力：
入力のパターンを出力の
組み合わせから考える
コンフィグもパターンを考える
入力：
入力パターンを考える
(出力は考えない)
入力が4つあれば1つずつ
カテゴリ別に分ける
落し方になれると、
実装や仕様にも応用が利く
製作工程のデバッグ時に、
前より洗い出しがしやすかった:+1:
絵文字ルール
Keep
:+1:
Try
:muscle:
Problem
:cry:
今週のtry
:star:
Problem
計画より大幅に押してしまった:cry:
終盤こそ見積もりが荒くならないように
思い込みで実装してしまった:cry:
末尾に番号をつけるとしか書いていないのに
_番号としてしまった:cry: