팀장이 릴리스를 발표하면서 데이터베이스 스키마를 깨 뜨리면 어떻게해야합니까?

우리 팀장은 데이터베이스 스키마를 다루는 끔찍한 습관을 가지고 있으며 변경 사항이 코드베이스에 어떤 영향을 미치는지에 대해 실제로 상담하지 않고 코드베이스를 심각하게 손상시키는 변경을합니다.

일반적으로 나는 그것과 함께 살 것이지만, 우리는 2 주 만에 마감 시간이 있으며 이것은 1 개월 반 전에 시작한 이후로 계속되고 있습니다. 프로젝트 개발 속도를 높이기 위해 노력했습니다.

마감 기한으로 인해 나는 이미 일주일에 60 시간 이상을 투자하고 있으며, 이것을 해결하기 위해 실제로 에너지가 남아 있지 않습니다 (나는 이미 몇 가지 방법으로 시도했습니다). 우리는 단지 2 인 팀이며 매일 데이터베이스를 변경하는 것 외에도 실제 개발 (코딩)에 크게 기여하지 않았습니다.

현재, 나는 모든 일을하고 있고 그가 그의 변화로 깨지는 것을 '수정'해야한다는 느낌을 받고 있습니다.

이것을 어떻게 처리합니까? 개발 부서에서의 노력 부족에 대해 이미 관리자에게 이야기했습니다. 그는 내가 가진 것보다 6 개월 더 오래 있었지만, 그가 기여한 5 번째 일반 양식 데이터베이스 괴물을 제외하면 코드의 95 %를 작성했습니다.

어떤 제안?

검시:

금요일에 우리는 관리자와 토론을했고 걱정을 알게되었습니다. 이로 인해 약간의 대립이 있었지만 전반적으로 관리자가 나와 함께 있다고 느꼈습니다. 최소한 데이터가 제자리에 고정 되었으니 여기에서 어떻게 진행되는지 봅시다.

"마감일은 2 주 안에 있습니다. 스키마에 도달하려면 스키마를 고정시켜야합니다."

같은 회의에서 관리자와 개발자에게 말하기 :

"데이터베이스와 코드 변경 사항이 동시에 나타나야합니다. 데이터베이스를 변경하면 코드베이스도 변경하고 테스트해야합니다. 그렇지 않으면 중단 된 커밋을 제출하고 있습니다. 마감일을 지키면 받아 들일 수 없습니다. 더 이상 코드를 수정하지 않습니다. 귀하의 커밋으로 인해 변경 사항을 철회하고 할당 된 작업 이외의 문제를 조사하고 수정할 수 없으며 마감일이 계속되기를 기대하기 때문에 전자 메일 메모를 남기겠습니다. "

테스트 계획이 없으면 훨씬 더 어려워집니다 ...

당신은 더 강력해야하고 곧 (어제, 어제 전날 또는 지난 달과 같이) 스키마를 결정하고 앞으로 나아가 야합니다. 움직이는 대상인 데이터베이스를 사용하여 앱을 계속 개발할 수있는 합리적인 방법은 없습니다.

그와 대면하고 그의 변화가 어떻게 코드베이스에 영향을 미쳐서 프로젝트 타임 라인에 영향을 미치는지 설명해야합니다. 변경 사항을 적용하기 전에 변경 사항의 영향을 고려해야한다고 확신합니다. 또한이 행동으로 인해 야기 된 지연에 대해 책임을 질 것이라는 점에 대해 귀하의 상사 앞에서 동의하도록하십시오.

팀장이 합리적인 사람이 아닌 경우 (그의 행동에 대한 설명에서 합리적으로 들리지 않는 경우) 관리자에게 문의하여 상황이 진행되는 동안 마감 시간을 지키지 않을 것이라고 설명하십시오. 관리자에게 기대치를 설정하는 회의를 열어서 팀 리더가이를 잘 알고 있는지 확인하도록 요청하십시오.

또한 팀 리더의 개발 기여 부족에 대한 사례를 추진해야합니다. 프로젝트가 성공하기 위해서는 두 가지 문제를 모두 해결해야합니다.

당신은 당신의 팀에 약간의 제한을 가할 것이지만, 그것은 당신의 위치에서 플레이하기 까다로울 수 있습니다.

이를 다루는 유용한 방법은보다 엄격한 문서화 된 변경 관리를 채택하는 것일 수 있습니다. 현재 임시 변경으로 인해 예기치 않은 최종 결과를 초래하지 않는 방식으로 시스템 업데이트를 관리 할 수있는 능력이 위험에 처해 있음을 주장함으로써이를 수행 할 수 있습니다 (사실). 따라서 모든 변경 사항에는 제안 된 변경 사항과 그 밖의 모든 코드 및 구조에 미치는 영향을 보여주는 문서가 제공되어야합니다. :-)를 통해 발생하는 변화의 양을 줄일 수있는 방법에 놀랄 것입니다.

팀과 회고를 했습니까? 그렇지 않은 경우 하나를 잡습니다. 그렇게하면 데이터베이스에 대한 계획되지 않은 변경 사항 (문제가있는)을 문제로 식별하십시오. 작업 수명의 위험 및 품질과 관련하여 귀하와 타인에게 비용을 명시하십시오. 지속적으로 60 시간 동안 일하는 것은 지속 가능하지 않습니다. 개발 속도를 유지할 수 없다면 민첩하지 않은 것입니다.

또한 TDD (테스트 중심 개발) 또는 자동화 된 기능 / 회귀 테스트를 수행하고 있습니까? 그렇다면 데이터베이스를 변경하면 테스트가 중단됩니다. 이를 통해 영향을 해결하고 업데이트해야 할 코드를 식별 할 수 있습니다.

이 경우 팀 리더는 " 너무 민첩 하지 않습니다 ", 팀 리더는 " 애자일 카우보이 "입니다. 회고를하고 무엇이 잘못되었는지 확인하십시오. 우선 순위를 높게 설정 한 후 다음 반복 중에 처리하십시오. 그것은 당신의 민첩한 카우보이에 밧줄을 묶어야합니다 !!!

약 1 년 전에도 같은 문제가 없었습니까? ' 우리 팀장은 A.Property = A.Property; 괜찮아요 . 댓글 기록에서 볼 수 없기 때문에 qustion이 금지 된 것 같습니다. 어쨌든 요점은 다음과 같습니다.

모든 팀 리더 가 경험의 절반 정도를 엉망으로 만든다고 생각한다면 , 하나도없는 직업을 찾게 될 것 입니다. 시도해보고 다른 옵션으로 리드가 되길 제안합니다. 그래도 가능하다면 이미 그렇게하도록 제안 받았을 것입니다.