Why Perfect is the Enemy of Good
완벽을 추구하는게 품질의 적이되는 이유
And ‘Done’ is just a part of the journey
그리고 ‘완료’ 는 단순히 과정의 일부일 뿐이다.
Why ‘Done’ is Important for Scrum Teams
스크럼 팀에게 ‘완료’가 중요한 이유
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. ()
스크럼 (n) : 사람들이 가능한 한 높은 가치의 제품을 생산적이고 창의적으로 제공하면서 복잡한 적응 문제를 해결할 수 있는 프레임워크이다.
Complex, adaptive problems are tricky and elusive. Understanding customer needs can be tortuous. Design is difficult and coding is hard. Testing is gruelling and releasing is painful. It’s all complex. We get it.
복잡하고 적응하기 어려운 문제들은 까다롭고 이해하기 어렵습니다. 고객의 요구를 이해하는 것은 복잡할 수 있습니다. 디자인은 어렵고 코딩은 어렵습니다. 테스트는 까다롭고 배포는 고통스럽습니다. 그것은 모두 복잡합니다. 우리는 이해합니다.
This post is about the demands of adaptive problems. Immediately after traversing the complexity of simply getting something done, we might need to change our approach and respond to feedback.
이 게시물은 적응 문제에 대한 요청입니다. 단순히 무언가를 수행하는 복잡성을 극복한 직후에 접근 방식을 변경하고 피드백에 대응해야 할 수도 있습니다.
In other words, building products, we need to get work done and into our customers’ hands early. However, ‘done’ is only the start of the journey. ‘Done’ helps us to learn from customer feedback.
다시 말해, 제품을 구축할 때는 일을 조기에 완료하여 고객의 손에 전달해야 합니다.다만, '완료'는 여행의 시작일 뿐입니다. '완료'는 고객의 피드백에서 배우는 데 도움이 됩니다.
When we receive this feedback, we might need to change course. We learn more about our problem and may need to adapt based on that new information.
이 피드백을 받은 경우 방침을 변경해야 할지도 모릅니다.우리는 문제에 대해 더 자세히 배우고 그 새로운 정보를 바탕으로 적응할 필요가 있을지도 모릅니다.
Adaptive is about what happens next. Our problems are adaptive, but how adaptive are we?
적응성이란 다음에 무슨 일이 일어날 것인가 하는 것입니다.우리의 문제는 적응적이지만 우리는 어느 정도 적응할 수 있을까요?
Are we done?
해치웠나?
There are many ways to uncover complexity in Software Development. Architects influence design. Developers implement coding standards. Testers find bugs. Customers change their minds. Competitors release cool new things and we suddenly need to keep up.
소프트웨어 개발의 복잡성을 밝히는 방법은 많이 있습니다.건축가는 디자인에 영향을 미칩니다.개발자는 코딩 표준을 구현합니다.테스터는 버그를 찾습니다.고객의 생각은 바뀝니다.경쟁사가 더 좋은 신제품을 출시하면 우리는 갑자기 따라잡을 필요가 있습니다.
To mitigate the risk of going off track with all of this complexity, Scrum Teams plan relatively small batches of work. They take small steps forward and frequently check in with each other and with their stakeholders to ask the same question in many different ways:
이러한 복잡성으로 인해 궤도를 벗어나는 위험을 줄이기 위해 스크럼 팀은 비교적 작은 배치 작업을 계획합니다.그들은 조금씩 전진하여 자주 서로나 관계자와 연락을 취하고 다양한 방법으로 같은 질문을 합니다.
Are we there yet?
아직 멀었나?
Scrum Teams ask that question in Daily Scrums (are we going to achieve our Sprint Goal?), in Design Sessions (are we building it the right way?), in code reviews (is this code maintainable?) and with all kinds of testing (does it meet acceptance criteria and non-functional…