고칠 수없는 끝없는 프로젝트에 대처

기술적 인 부채 가 많은 웹 사이트 (1200 시간 이상)가 있습니다 . 이것은 주로 다음과 같은 이유로 발생합니다.

1. 개발 중에오고가는 여러 프로그래머.
2. 개발 중 사양 변경.
3. 수많은 추가 기능이 추가되었습니다 (짧은 시간에).

고객은 새로운 기능을 많이 원하고, 그것은 기본적으로이 프로젝트에 참여 내려 온다 매주 10 + 시간.

기술 부채로 인해 문제를 해결하거나 조사 하는 데 많은 시간이 소요되며 일반적으로 다음 중 하나에서 발생합니다.

1. 사람들을 울게하는 뻔뻔스럽고 바보 같은 버그.
2. 새로운 기능이 영향을 미칠 수있는 모든 위치를 예측하지 못했기 때문에 새로운 기능으로 인해 위와 같은 결과가 발생합니다.
3. 우리가 겪었던 다른 문제들 (fe 서버 마이그레이션, 업그레이드)

우리는 매일 문제 가 있으며이를 중단시키기 위해 다음과 같은 일을 시도했습니다.

1. 웹 사이트의 수입, 지불 및 일반 작업에 관한 기술 문서를 작성했습니다.
2. 이번 주 초에 회의를 개최하여 현재 문제 또는 개선 사항 및 해결 방법을 논의하십시오.
3. 테스트 계획을 세우십시오. 프로그래머 A 테스트 B, B 테스트 C 및 C 테스트 A. 그러면 프로젝트 관리자가 일부 테스트를 수행합니다. 기능의 영향과 관련하여 준비 환경에 해당 기능을 던져 고객이 스스로 확인할 수 있도록합니다.

문제는 문제가 계속 발생한다는 것입니다. 어떻게 든 문제를 해결할 수 없습니다. 새로운 기능은 여전히 ​​버그를 일으키고 오래된 버그는 계속해서 인사합니다. 어쩌면-아마도 프로젝트의 규모로 인해-우리는이 프로젝트를 파악하지 못하는 것 같습니다.

더 큰 프로젝트를 수행하는 프로그래머가 많다고 가정합니다. 그래서 제가 제 질문에옵니다 :

대규모 프로젝트에서 이러한 문제를 피하기 위해 무엇을 할 수 있습니까?

사소한 편집, 추가 정보 :

1. 버전 제어 (SVN)를 사용합니다.
2. DTAP 개발 프로세스가 있습니다.

나는 악마의 옹호자를 할 것이다. 이것이 얼마나 자주 나타나는지 보았을 것이다. 나는 당신이 실제로 시스템에 실제로 문제가있는 유일한 사람임을 보증합니다. 그렇지 않으면 회사 문화가 버그를 없애고 코드를 수정하는 것이기 때문에 어떻게 대처할 것인지 묻지 않아도됩니다. 가능한 경우, 즉 실제 전문가의 작업 방식.

단위 테스트 작성을 시작하기에는 너무 큽니다. 왜냐하면 단위 테스트 방법을 아는 사람이 없었기 때문입니다 (팀의 다른 사람들과 함께 운이 좋을 것입니다). 정확한 구현과 구체적인 데이터에 의존하기 때문에 테스트하기 때문에 인터페이스, 모의 품, 스터브 등으로 모든 것을 제거하는 데 너무 오래 걸리므로 처음부터 테스트 할 수 없습니다. 또한 리팩토링해야 할 항목이 너무 밀접하게 결합되어 있기 때문에 리팩토링 할 필요가 없으며 테스트가 없기 때문에 누가 나쁜 코드를 수정하여 손상 될지 알고 있습니다. 요컨대, 심각하게 고치기에는 암이 너무 많을 수 있지만 물론 잘라내어 새로 시작할 수는 없습니다.

내 친구,지는 전투와 싸우고있어 어느 쪽이든 당신은 좌절에서 태워 결국 종료 또는 정신 이동, 또는 충분히 문제를 실현하기 위해 다른 사람을 얻으려고 노력 그것에 대해 불평하는 경우, 그들은 유일한 문제라고 생각 게요 당신을 당신이 문을 표시됩니다.

단위 테스트는하지 않는 것이 좋은 출발점입니다. 최소한 오래된 버그를 고칠 때 새로운 버그가 추가되지 않도록 보호합니다.

소스 컨트롤은 사용하지 않는 한 도움이됩니다. 특히 비난과 로그 기능은 버그가 많은 코드 조각이 어떻게 / 왜 커밋되었는지를 잘 보여줍니다.

결국, 변경 / 추가 기능을 요청하자마자 가격 및 (길이) 지연에 대해 논의하는 것은 디자인 / 디자인에 소요되는 시간에 대한 비용 청구와 마찬가지로 합리적으로 잘 작동한다는 것을 알았습니다. 고객은 종종 생각할 때까지 기다릴 수 있다고 결정합니다.

반면에, 즉시 사양과 구현 아이디어를 파헤 치면 일반적으로 "오, 나는 우리가 어쨌든 그렇게하겠다고 생각했다"고 생각하게됩니다. "이것은 이미 설계되었으며 우리가 논의한 내용은 그렇게 들리지 않습니다!")

마지막으로, 나는 하루에 한 번만 전자 메일을 읽는다는 사실을 미리 알게되었고 (직장에 도착했을 때) 긴급한 일이있는 전화를 사용하면 생산성이 크게 향상되는 것으로 나타났습니다.

가장 자주 중단되는 영역에 대해 CI 기반 테스트를 추가하는 것이 좋습니다. 프로젝트에서 작업이 진행되는 동안 품질을 향상시키는 데 도움이됩니다.

또한 어떤 영역 / 기능이 더 자주 중단되는지가 더 명확 해 지므로 리팩토링이 필요한 부분 또는 최소한의 테스트가 필요한 부분을 결정하기가 더 쉽습니다.

수동 테스트 위험을 더 추가하면 프로젝트가 추가 된 기능 당 필요한 $$$ 및 시간 측면에서 잘못된 방식으로 진행됩니다.

일부 코드 검토는 좋지만 A-> B-> C-> A 테스트 체계의 일부일 수 있습니다. (다른 방향으로 코드를 검토 할 수 있습니까?)

우화를 던져 보자. 당신은 거리의 낮에 일찍 사람과 산책하고 목적지에 도달합니다. 당신과 함께 걷는 사람은 그가 길을 따라 어딘가에서 그의 반지를 잃어 버렸다는 것을 알게되어 당신은 역 추적하고 그것을 찾기로 결정합니다. 함께 걷는 사람은 램프 기둥에서 빨리 멈추고 열광적으로 보입니다. "골목을 지나갈 때 램프 기둥을 잃어 버렸다고 생각할 때 왜 램프 기둥을보고 있습니까?"라고 말합니다. 그는 대답한다. "나는 알고 있지만 빛이 더 낫다."

나는이 상황에 몇 번 이상 있었고 몇 가지 공통점을 발견했습니다. 이러한 종류의 유지 관리 악몽 프로젝트는 일반적으로 관리에 의해 부과되는 엄격한 감독 및 프로세스 개선과 함께 프로세스가 많은 환경에서 실행됩니다. 프로세스 개선이 나쁜 것은 아니지만 일반적으로 경영진이 시행하고자하는 프로세스 개선 유형이 두 가지 핵심 사항을 갖는 것은 아닙니다.

1) 그들은 일반적으로 사무실 정치와 권력의 균형을 방해하지 않습니다. 2) 문제의 핵심이 아니라 경영진의 통제 착각에 성공했다.

경영진은 일반적으로 "새로운 기능은 모두 자세한 기술 사양을 갖추어야합니다"또는 "문제를 해결하기 위해 매일 시간별 상태 회의를 갖도록해야합니다."라고 말합니다.

이 두 가지가 실제로 문제의 핵심에 부딪치지 않고 생산성을 떨어 뜨릴 수도 있지만 경영진에 의한 통제의 착시를 확실히 입증합니다.

당신이 추진할 수있는 유일한 변화는 일을 흔들리는 것입니다. 나는 웹 사이트에 대한 당신의 괴로움이 아마도 지금 시점에서 수리를 넘어서고 있다고 생각합니다. 그러나 앞으로는 일정 변경없이 범위 변경을 최소화하기 위해 엄격한 변경 제어 절차에 따라 규제되는 애자일 방법론, 지속적인 통합, 테스트 주도 개발, 코드 검토 및 비즈니스 요구 사항 사양의 중요성을 명심할 수 있습니다.

이러한 종류의 변화는 경영 수준에서 사고 방식의 변화를 필요로하며, 전문적인 경험을 통해 중간 정도의 중간 수준의 흔들림 없이는 이런 일이 발생하지 않았습니다. 오르막 전투를 치르더라도 싸우지 않더라도 옳은 일을 시도해야하기 때문에 너무 낙담하지 않기를 바랍니다. 왜냐하면 현 상태를 좋아하는 사람들에 의해 격렬한 저항에 직면 할 수 있기 때문입니다.

나는 얼마 전에 같은 자리에 있었어요. 나는 더 이상 두 가지 간단한 규칙 덕분에 아닙니다.

• 매주 1, 2 일은 앱의 대부분의 털이 많은 부분을 수정 / 다시 쓰는 데 소비됩니다. 버그 헌팅, 새로운 기능 개발이 없습니다.
• 새로운 기능을 구현하는 동안 고객이 기대하는 것보다 더 많은 시간을 소비했을 때에도 올바르게 작동하도록 노력하고 있습니다.

유일한 문제는 다른 사람들이 그들을 존중하도록하는 것입니다. 쉬운 부분은 놀랍게도 고객이었습니다. 실제로 이유를 설명 할 수는 없지만 어쨌든 우리는 그 기능을 조금 더 오래 작업 할 때 모든 사람에게 더 좋다고 확신했습니다. 첫 번째 규칙을 존중하는 것이 더 문제가있는 것으로 판명되었지만 우리에게도 큰 도움이된다고 생각합니다. 응용 프로그램의 다른 부분이 나아질수록 꾸준한 발전을 보장합니다.

코드 검토 단위 테스트. 실제 품질 관리 테스트. 사양 수집 프로세스 및 증분 개발-대부분의 문제를 해결해야하는 사항입니다.

또한 고객이 개발자에게 직접 핑을 보내지 못하게하십시오. 일반적으로 문제를 해결하는 가장 비생산적인 방법입니다. 고객과 개발자 사이의 인터페이스를 형성 할 훌륭한 프로그램 관리자를 고용하십시오. 그의 임무는 제품의 전체, 현재 상태, 향후 방향 등을 아는 것입니다. 고객이 다른 새로운 기능을 원할 때마다 현재 항목 목록을 제공하고이 새로운 요청을 수행 할 경우 고객에게 어떤 문제가 발생했는지 보여줄 수 있어야합니다.

너무 적게 또는 너무 많이 사용하면 프로세스가 나쁩니다. 나는 당신이 이전 상태에 있다고 생각합니다.

Deni가 언급했듯이 프로젝트에 단위 테스트를 추가 할 수 있다면 도움이 될 것입니다. 변경 / 수정하려는 시스템의 일부를 포괄하는 테스트가 있으므로 리팩토링 코드를 사용하는 경우이 테스트를 지침으로 사용하여 문제가 없는지 확인하십시오.

또한 코드에서 가장 깨진 부분을 심사합니다. 최악의 영향을받은 위험 요소를 위험 목록에 넣고 해당 위험을 독립적으로 관리하십시오. 버그가 가장 많이 발생하는 위치를 쿼리하여 코드베이스에 코드가 얼마나 깨진 지 알 수 있습니다. 그런 다음 버그 수 (또는 문제가보고 된 문제)별로 영향을받는 영역을 나열 할 수 있습니다.

코드를 패치하고 정리하는 데는 시간이 걸리지 만 팀의 각 개발자가 코드를 조금 더 깨끗하게 남겨 둘 수 있다면 코드를 작성하기 전에 코드베이스가 향상됩니다. 신속하고 군대 스타일을 찾고 있다면 지금 솔루션으로 분류하십시오. 실용적이거나 권장되는 것이 도움이 될 것입니다.

건배. 재스.

명확한 기능 사양을 작성하십시오. 이러한 사양을 기준으로 기능을 검토하고 정기적으로 검토 할 수 있다면 개발자가 자신이 개발하고있는 것에 대한 아이디어가 적을수록, 개발 방식이 될 가능성이 줄어 듭니다.

코드 작성을 시작하기 전에 선행 설계 작업을 수행하십시오. 완벽하거나 거대하거나 UML을 포함 할 필요는 없지만 해결해야 할 문제에 대한 확실한 해결책을 제시해야합니다. 소프트웨어를 적게 계획할수록 더 나빠질 수 있습니다. 작업을 시작하기 전에 디자인에 대해 토론하십시오.

명백히 나쁘고 진전을 방해하는 코드 영역에서 작업을 시작할 때; 추가를 중단하고, 문제에서 물러나고, 장애가 없었으며 앞으로 더 적응할 수 있도록 아키텍처를 재 설계 할 수있는 방법을 찾으십시오. 기술 부채를 다루기 전에 더 이상 떠나지 않으면 완전히 다시 쓰지 않고 다루기가 더 어려워집니다. 나는 그것이 기하 급수적이라고 말하고 싶다.

동작 을 테스트 하고 아키텍처와 밀접하게 연결되지 않는 테스트를 설계 하십시오. 그것은 유행이 아니지만 코드의 진정한 목적이 명확해질 때까지 테스트를 시작하지 말라고 말할 것입니다. 실제로 테스트 할 대상을 알 때까지 테스트를 시작하지 마십시오. 잘못 생각한 IMO는 테스트가없는 것보다 나쁩니다. 테스트가 많을수록 내부적으로 코드를 변경하기가 더 어렵습니다. 테스트 코드를 프로덕션 코드처럼 취급하십시오. 계획하고 잘 작성해야합니다.

정기적 / 일일 코드 검토를 수행하십시오. 개발자가 멀지 않은 상태인지 확인하기 위해 온 전성 검사에 대한 자세한 내용입니다. 다음 세션을 계획하려면이 세션을 사용하십시오. 5 분 또는 1 시간이 걸리는 날이있을 수 있습니다. 요점은 대화를 열어 놓고 개발자에게 다른 개발자와 자신의 작업에 대해 토론하고 조언을 구할 수있는 기회를 제공하는 것입니다. 코드의 거친 부분이나 아이디어를 프로토 타이핑하기 위해 몇 가지 페어링 세션을 수행하지만 사람들이 자신의 작업 시간을 갖도록하십시오.

코드를 쉽게 구축하고 배포 할 수 있습니다. 빌드 시간을 짧게 유지하십시오. 더 많이 만들수록 더 많이 지을수록 빠를수록 빠릅니다.

코딩 표준을 채택하고 엄격하게 시행하십시오. 여기에는 파일 시스템에서 프로젝트가 있어야하는 위치부터 개인 구성 요소의 케이싱까지 모든 것이 포함됩니다. 이것은 무의미하고 성가신 것처럼 보이지만 좋은 습관은 개발 과정의 초석입니다.

기본적으로 나는 당신이 사용하는 과정이 그렇게 중요하다고 생각하지 않습니다. 패션은왔다 갔다합니다. 실제로 중요한 것은 소프트웨어 개발 방법에 대해 전문가이며 실습에서 훈련을 받는다는 것입니다.

연기 테스트를 설계 및 자동화하고 CI 환경에 적용하는 것부터 시작하겠습니다. 그것들은 기능적이어야합니다. 고객이 무언가 잘 작동해야한다고 말하면 나중에 참조 할 수 있도록 메모 해 두십시오. 소프트웨어에서 특정 솔루션을 발견하면 질문을하고, 답변을 받으면 바로이를 지식 기반에 통합하여 추적 가능하게하십시오.

확실한 경우에 대한 기본 기능이 작동하는지 확인하십시오. 그런 다음 부정확 한 데이터 처리에 대한 증분 테스트 구축을 시작하여 필요에 따라 결함을 배치하십시오. 우선 순위에 대해 길고 심도있는 토론을하고 테스트 관리자가이를 인식하도록하여 테스트 시간을 적절하게 지정할 수 있습니다. 모든 것을 자동화하려고 시도하지 말고 곧 일부 테스트 케이스가 자동화되는 것이 합리적이므로 망설이지 마십시오.

일반적으로 즉시 품질을 향상시키는 도구가 아니라 제품에 대한 신뢰를 높이기 위해 테스트를 사용하십시오. 침착하면서도 독단적입니다 :). 민첩하게 시도해 볼 수 있지만, 절대적으로 인증 된 PM에 적극적으로 참여할 수 있습니다. 애자일을 모르는 사람이 애자일을 도입하면 프로젝트가 중단 될 수 있습니다.