제품을 만드는 것으로 소개되지만 무엇이든 다르겠습니까?

상황이 복잡할때는 생각을 멈추고 기본을 생각해야 할때가 있습니다.

많은 것을 잃고 단지 '시간'만 지켰을 뿐이다.

우리의 문제는 분석보다 실험이 필요할 수 있습니다.

애자일 팀은 목적이 아니고 수단입니다.

심리학자들이 오랜 기간 고민한 숙제 중 하나는 '동기는 어떻게 생겨날까?' 하는 것입니다.

모든 역할자가 각 지표의 의미를 이해하고 이 지표들을 활용해서 유저들의 불만을 어떻게 개선할지 논의가 시작되었으면 합니다!

소프트웨어 테스트는 소프트웨어의 결함을 찾아내고 수정하는 과정에서 매우 중요합니다.

책임추궁과 비판을 하기 보다는 지속적인 개선을 위해 긍정적인 개선을 추구해봅시다.

이메일이나 문자 메시지로 요청해 놓고서 상대방이 응하지 않으면 "소통이 잘 안 된다."라고 불만을 터뜨리지는 않나요?

스프린트 리뷰의 방식을 약간 바꾸어 효과적으로만든 사례를 소개합니다.

완벽주의는 일반적으로 생각하는 장점도 있지만 단점도 가지고 있습니다.

두 사고의 행동 방식이 어떻게 다른지 살펴보시죠.

위임을 예술이라고 말하는 사람이 있을 정도로 어렵고 미묘한 부분이 있습니다.

그때는 맞고 지금은 틀리다. 역할에 따라 달라진 성공 방정식을 어떻게 해야하나

스쿼드 업무의 원할한 흐름을 만들어주는 다재다능한 개인을 적절하게 구성원으로 배치하는게 필요합니다.

좋은 지표는 올바른 비교일때만 가능하다.

하나하나 살펴보고 선택하고 자신의 가치관과 통합하여 모두가 더 좋은 개발자가 되시길 기원합니다.

제품의 특징을 만드는 것에 있어 작은 힌트를 얻고 싶을때 활용해보면 좋을 것 같습니다.

"사람들은 비슷한 경험에서도 다른 것을 배우는 것 같습니다. 여러분들은 개발자라서 어떤 것을 배우고 있나요? 아래 글에서 공감하는 것은 무엇이고 다른 배움은 무엇인가요?"