번역 시도

  •  
  • 398
  • 0
  • 3
  • Korean 
Apr 20, 2011 15:41
스티브 므콘넬은 시각을 잘 못 맞춘 쓰레싱이 모든 소프트웨어 프로제크트에게 방해하는 점을 우리에게 알려줬다. 사실성은 소프트웨어 외에 이 문제가 더 크게 퍼지는 것이다.
 
아무런 할 만한 프로제크트에서는 발명, 영감, 그리고 당시 만들어 내는 것이 있다. 보통 작은 아이디어부터 시작하고 배송할 날짜가 다가어면서 더 자세하게 개발한다. 배송일이 가까울수록 쓰레싱이 더 많이 한다. 쓰레싱은 어떤 프로제크트를 개발하면서 브레인스토밍과 튀킹인 뜻. 쓰레싱이라면 사용자 인터페이스를 바꿈이도 도입부 문단을 다시 씀일 수도 있다. 간혹 쓰레싱이 작은 수정밖에 없다. 하지만 큰 수정이 필요할 때도 있다.
 
쓰레싱은 필요하다. 언제 해야할지는 문제다.

평범한 애미튜어 프로제크트에서는 끝나면서 모두 쓰레싱을 하게 된다. 배송할 때가 가까울수록 사람의 숫자가 커지며 미팅도 더욱 많이 하며 회장님까지 본이을 포함하고 싶어한다. 왜 그렇게 할까? 뭔가 생산해 놓은지도 안 보이고 본인의 한 일도 수정할 가능성이 높으면 일찍 연관되는 목적은 도대체 뭐냐?

그 목적은 매우 간단하다. 늦게 쓰레시해서 생산도 못 한다. 늦게 쓰레시해서 오류가 발생한다. 전문생산자들은 일찍 쓰레시한다. 프로제크트를 완성할 때 올수록 프로제크가 덜 많은 사람들에게 보이며 수정시켜도 될 가능성도 감소해진다.

목표 마감일에 놓친 모두 소프트웨어 프로제케트는 늦은 쓰레싱에 당했기 때문이다. 창조자들은 쓰레싱을 일찍 하게 시킬 규율이 없었다. 저항이라는 것에 좌우된 것이다.
Learn English, Spanish, and other languages for free with the HiNative app