本当はすごいKPTで強いチームを作る for エンジニア - Qiita
この通り、KPTはみんなでやるデバッグ作業です Problem -> Try -> Keepと全てはつながっています 繋がっていないKeepは？ ナレッジ共有と捉えると良いと思います ただ、その場合もはじめに何かしらの問題があって〜からスタートすることが多いのではないでしょうか KPTすごい これで何となく伝わりますかね？ KPTが毎週上手く回っている ＝ 毎週バグを潰している １年続けると KPTが回っている → テスト53回、デバッグ53回行って、チケット消化しつづけ改善してる状態 KPTが回っていない → テスト0、デバッグ0、チケット消化数0 KPTを上手く回すには 伝わったとしたら幸いです それでは次にKPTを上手く回すことを目標にします そもそも上手く回ってる、良い状態ってどんな感じでしょうか？ 良いKPT＝良いデバッグ エンジニアならもう既にわかるはずです 良いProblem
超高速で仕様変更に対応するデザインパターン （for リーン駆動＆アプリ） - Qiita
前置き リーンスタートアップ＆スクラム駆動で1年半アプリを継続開発した時 巷によくあるデザインパターンや考え方がイマイチしっくり来なかったので試行錯誤しました そのまとめです 注意 この方法が合うかどうかは状況に依ります 用法用量を守り適切にお願いします あと読んだあとに 「それただのオブジェクト指向じゃん？」とか 「それただのMVCじゃん？」とか 「それただのDDDじゃん？」とか言いたくなると思います そこらへん分かってる人にはあまり価値が無いかもしれません 対象者 アジャイル、リーンスタートアップ、グロースハックなどの開発をガチで行う事になった人 機能レベルの仕様変更がバンバン入る状況に置かれている人 プロダクトオーナーとの仕様会議に出られる人（内部設計、できれば外部設計、要件定義までやってる人） リーンスタートアップって何？ 時間があったら青本読んでみてください 乱暴にまとめてしまう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
