이번 주 직장에서 나는 다시 한 번 애정을 가졌다 . 표준 민첩성, TDD, 공유 소유권, 카드 한 장에 몇 가지 사용자 스토리를 넘어서는 계획을 세우지 않는 임시 개발 방법론을 겪어 실제로는 실제 작업을 수행하지 않고 타사 통합 광고 구역질의 기술에 대한 신호를 씹었습니다. 지난 몇 개월 동안 누군가의 머리에 닿는 첫 번째 테스트에 모든 생산 코드를 생각하거나 적법하게 고려하고 아키텍처 적으로 결합한 경우 릴리스주기가 끝나고 개발중인 주요 외부에서 볼 수있는 주요 기능이 너무 느립니다. 사용, 버기, 미로처럼 복잡하고 완전히 융통성이 없어집니다.
이 과정에서 "스파이크 (spike)"는 수행되었지만 문서화되지 않았으며 단일 건축 설계는 제작되지 않았습니다 (FS가 없었으므로 개발중인 것을 모르는 경우 어떻게 계획하거나 연구 할 수 있습니까? ?)-프로젝트가 한 쌍에서 한 쌍으로 전달되었는데, 각 프로젝트는 한 번에 하나의 사용자 스토리에만 집중했으며 결과는 불가피했습니다.
이 문제를 해결하기 위해 레이더를 벗어 났고 (두려운) 폭포를 밟고 계획하고 코딩했으며 기본적으로 쌍을 바꾸지 않았으며 혼자서 할 수있는 한 많은 노력을 기울였습니다-단위 테스트보다는 견고한 아키텍처 및 사양에 중점을 둡니다. 모든 것이 고정되면 나중에 올 것입니다. 코드는 이제 훨씬 나아졌으며 실제로는 완전히 사용 가능하고 유연하며 빠릅니다. 어떤 사람들은 저에게 이런 일을하는 것을 정말로 화나게했고 성스러운 민첩한 과정에 거스 르기 때문에 (무의식적으로) 나의 노력을 방해하기 위해 나갔습니다.
따라서 개발자로서 팀에 작업 계획을 세우는 것이 "민첩하지 않다"고 어떻게 설명하고 민첩한 프로세스에 계획을 맞추는 방법은 무엇입니까? (나는 IPM에 대해 이야기하는 것이 아니라 문제에 대해 앉아 문제를 해결하는 사람이 무엇을 알고 있는지 충분히 상세하게 해결해야하는 엔드 투 엔드 디자인을 스케치하는 것에 대해 이야기하고 있습니다. 그들이 사용해야하는 아키텍처 및 패턴과 새 코드가 기존 코드에 통합되어야하는 위치)
