변경 당 버전 제어 및 버그 추적 오버 헤드가 너무 많습니까?

나는 CVS-crazy와 Bugzilla-nuts에서 근무한다.

1. 각 릴리스에는 너무 많은 브랜치가 있으므로 셀 수 없습니다. 모든 사람은 끊임없이 자동 병합됩니다.

2. 이 직업 에는 유동성 이 없습니다 . 모든 것이 단계적으로 느껴집니다 . 간단한 것조차도 25 단계가 필요합니다. 공장 생산 라인에있는 것이 아니라 매일 공장을 직접 설정하는 것과 같습니다.

상황 예 :

단일 버그를 해결하기 위해 먼저 깨끗하고 새로운 가상 머신을 얻습니다. 그런 다음 Bugzilla 보고서에 설명 된 다른 분기를 기반으로 해당 단일 버그 수정에 대한 분기를 만듭니다. 기계에 지점을 설치하고 설정했습니다. 버그를 수정했습니다. 나는 그것을 체크인하고 다른 사람들이 테스트 할 수 있도록 기계를 남겨 둡니다. 그런 다음 버그 제어 소프트웨어로 들어가서 내가 한 일을 설명하고 모든 단계와 함께 테스트 사례를 작성해야합니다. 결국 다른 누군가가 그것을 릴리스와 병합합니다.

버그가 아무리 작아도이 모든 일을해야합니다. 때로는 사람들이 여러 버그에 대한 작업을 결합하지만, 내가 말했듯이 너무 많은 가지가 있으므로 거의 불가능합니다.

다른 작업에서는 그냥 들어가서 버그를 고치려고합니다. SCM 사용을 기억하는 경우는 거의 없었지만 모든 작업에서 사용한 적이 있습니다. 다른 모든 작업에서는 다른 방식으로 작업을 중단 했기 때문 입니다.

프로세스가 방해를 받고 끝이되는 시점이 있습니까? 심지어 공학적입니까?

프로세스가 방해를 받고 끝이되는 시점이 있습니까?

불행히도 많은 프로세스가 일반적입니다. 일부 사람들, 특히 경영진은 프로세스 가 제품을 생산 한다고 종교적으로 상상합니다 . 그래서 그들은 프로세스를 과장하고 실제로 제품을 만드는 소수의 열심히 일하는 똑똑한 사람들이라는 것을 잊었습니다 . 최고 경영진에게는 그들의 사업이 몇 명의 괴짜들의 손에 달려 있다고 생각하기 때문에 현실에서 눈을 감고 대신에 사랑하는 "프로세스"를 생각하여 통제의 환상을줍니다.

그렇기 때문에 소수의 우수한 엔지니어를 보유한 민첩한 스타트 업이 프로세스 및보고에 에너지의 95 %를 소비하는 기존의 대기업을 이길 수 있습니다. 한때 소규모 신생 기업이 경쟁 업체를 이겼거나 완전히 새로운 시장을 창출 한 사례 :

• Apple (Apple I은 1 명의 엔지니어에 의해 만들어졌습니다 . 당시에는 3 명의 남자가있었습니다).
• Google (원래 프로그래머 2 명 작성)
• 페이스 북 ( 원맨 노력 1 ).
• Microsoft ( 1975 년 2 인 회사).

이것들은 단순히 이상치, 극단적 인 예외이며 심각한 일을하려면 쉽게 설립 된 대기업이되어야합니다. 그러나 목록은 계속됩니다. 그리고 계속. 너무나 길다. 거의 모든 오늘날 주요 기업은 차고 상점으로 시작하여 특이한 일을했습니다. 뭔가 이상 해요 그들은 잘못하고 있었다. 그들이 프로세스 에 따라하고 있다고 생각 합니까?

회사는 일반적으로 Control-Flexibility 딜레마라고 부르는 데 어려움을 겪고 있습니다. 규칙, 구조 및 관료적 인 오버 헤드가 적을수록 일을 더 쉽고 빠르게 달성 할 수 있습니다 (더 재미 있음). 그러나 "나쁜"일을 "좋은"일로하는 것도 마찬가지로 쉽습니다. 즉, 중요하지 않은 실수를 거의하지 않는 숙련 된 직원이있을 때만 괜찮습니다.

반면에, 숙련도가 낮거나 준 숙련 된 직원이 많거나 실수 비용이 너무 높은 경우 (북반구의 우주 왕복선 잔해 위험과 같은) 회사는 점점 더 많은 규칙을 쌓는 경향이 있습니다. "및"프로세스 "를 시도하여 최소화하십시오.

유일한 문제는 이러한 프로세스의 누적 오버 헤드로 인해 더 재능있는 직원이 회사를 떠나는 결과를 달성하기가 어렵다는 것입니다. 이로 인해 평균 기술이 훨씬 낮아지고 더 많은 프로세스와 관료주의가 필요합니다. 따라서 급진적 인 일이 일어나거나 회사가 배를 until 때까지 죽음의 나선이 계속됩니다.

이 측면에서 돌아올 수없는 지점을 지나간 것으로 보이는 회사에서 자신을 발견하면 자신의 직업에 대해 "돌보지 않는"것으로 자신을 해결할 수 있습니다. 당신의 영혼은 그대로 :)

회사가 너무 멀리 가지 않고 당신이 확실한 결정과 의지력을 통해 과정을 취소 할 수있는 수단이 있다면. 성공을 보장하지 않으면 서 엄청난 양의 작업과 개인 에너지를 소비 할 수 있으므로 가치가 있는지 확인하십시오. 때로는 자신의 상실을 줄이고 자신의 경험이 풍부한 사람을 세는 것이 좋습니다.

이러한 스타일의 개발에는 한 가지 정당한 이유가 있습니다. 개발 된 소프트웨어는 미션 크리티컬 한 것이며 어떠한 상황에서도 버그를 포함해서는 안됩니다. 여객기의 제트 엔진 연료 분사 펌웨어, 심장 박동기 펌웨어 또는 핵 미사일 발사 시스템을 생각하십시오.

다른 모든 상황에서는 비용 오버 헤드로 인해 비즈니스가 중단 될 수 있습니다. 움직일 시간이야.

이 질문에는 실제로 두 가지 질문이 포함되어 있으며 별도로 해결해야합니다.

일부 팀은 왜 엄격한 개발 프로세스를 가지고 있습니까?

간단한 대답은 그렇지 않은 경우 실수가 발생하기 때문입니다. 값 비싼 실수. 이는 개발에 해당되며 나머지 IT 분야 (sysadmins, DBA 등)에도 적용됩니다.

많은 개발자와 IT 직원이 이해하기가 매우 어렵습니다. 왜냐하면 우리 중 대부분은 "최고"중 한 곳에서만 일한 적이 있기 때문입니다. 사람들이 심하게 조여주지 않거나 조업 비용이 저렴한 소규모 마이크로 ISV 또는 프리랜서 작업.

그러나 밝고 재능있는 IT 직원을 보유한 회사를 포함하여이 단계 사이에 회사를 본 적이 있다면 프로세스가 없거나 절반이 걸리는 프로세스의 위험을 이해할 수 있습니다. 직원들 사이의 의사 소통은 조합 폭발 문제에 시달리고 있습니다. 단일 팀에서 약 6-10 명의 개발자 수준에 도달하면 주요 또는 중대한 결함의 주요 원인은 인재 나 노하우가 아니라 의사 소통이 부족하기 때문입니다.

앨리스는 월요일 아침에 물었다. 그 누구도 그 일을하고 있지 않기 때문에 몸통에서 재건 수술을하는 것이 좋다고 결정한다. 밥은 한 시간 후에 휴가를 마치고 에너지가 가득한 곳으로 돌아와서 정확히 같은 지역에 새로운 주요 기능을 구현하기로 결정했습니다. 앨리스는 그 "기술 부채"를 갚고 밥은 6 개월 동안 버너에 있던 살인자 기능을 구현하고 마지막으로 코드를 체크인 할 때 (물론 금요일 마감 시간 직전!) 팀은 뒤에서 몇 주 동안 버그와 회귀로 계속되는 악몽 같은 지옥의 갈등을 극복하기 위해 노력해야합니다.

Alice와 Bob 둘 다 코딩 작업에 큰 도움이되었지만 둘 다 잘못된 결정으로 시작했습니다 ( "최악의 결과는 무엇입니까?"). 팀장 또는 프로젝트 관리자는 사후 검토를 통해이를 점검하고이를 다시 방지하기 위해 점검 목록을 작성합니다.

• 충돌의 영향을 최소화하려면 체크인이 매일 수행되어야합니다.
• 하루 이상 크게 소요되는 변경은 지점에서 수행해야합니다.
• 모든 중요한 작업 (리팩토링과 같은 비 기능적 작업 포함)은 버그 추적기에서 올바르게 추적되고 할당되어야합니다.

많은 사람들에게이 "프로세스"는 상식처럼 보입니다. 낡은 모자입니다. 그러나 많은 소규모 팀이이 작업을 수행하지 않는다는 것을 알고 있습니까? 2 인 팀은 소스 제어에 전혀 신경을 쓰지 않을 수도 있습니다. 누가 신경 쓰나요? 솔직히 필요하지 않습니다. 팀이 커질 때만 문제가 발생하지만 프로세스는 진행되지 않습니다.

물론 프로세스 최적화는 성능 최적화와 같습니다. 역 지수 곡선을 따릅니다. 위의 체크리스트는 결함의 80 %를 제거 할 수 있지만,이를 구현 한 후 나머지 80 %가 결함의 원인 임을 알게 됩니다. 가상이지만 익숙한 예제에서는 빌드 환경이 다르기 때문에 빌드 오류가 발생할 수 있습니다. 이는 표준 하드웨어가 없으며 개발자가 2 주마다 업데이트되는 오픈 소스 라이브러리를 사용하고 있기 때문입니다.

따라서 (a) 하드웨어를 표준화하고 타사 라이브러리 사용을 심각하게 제한하여 비용이 많이 들고 생산성이 크게 저하되거나 (b) sysadmin 그룹과의 협력이 필요한 빌드 서버를 설정합니다. 풀 타임 개발자가이를 유지 관리하거나 (c) 표준 가상 머신을 배포하고 개발자에게이를 구축하도록 지시하여 개발자가 직접 할 수 있도록합니다. 분명히 (b) 가장 장기적인 해결책이지만 (c) 더 나은 단기적 안정성과 편의성의 균형을 가지고 있습니다.

사이클이 계속 진행됩니다. 당신이 보는 모든 "정책"은 일반적으로 실제 문제를 해결하기 위해 설립되었습니다. Joel Spolsky가 2000 년 에 완전히 썼던 것처럼 (완전히 다른 주제를 생각하지만 그럼에도 관련이 있음) :

식당에 들어가서 "No Dogs Allowed"라는 표시가 보이면 그 표시는 순전히 설명적인 것으로 생각할 수 있습니다. Restaurant 씨는 개를 좋아하지 않기 때문에 식당을 지을 때 그 표시를했습니다.

그것이 모든 것이 진행 중이라면, "뱀 없음"표시도있을 것입니다. 결국, 아무도 뱀을 좋아하지 않습니다. 그들이 앉을 때 의자를 깨뜨리기 때문에 "코끼리 금지"표시.

표시가있는 진짜 이유는 역사적입니다. 사람들이 개를 식당에 데려 오려고했던 것을 나타내는 역사적 표식입니다.

대부분의 소프트웨어 팀에서 동일합니다. "모든 버그 수정에 대해 테스트 사례를 추가해야합니다" 와 같은 정책 은 팀이 역사적으로 회귀 문제를 가지고 있음을 거의 나타내지 않습니다. 회귀는 무능력보다는 의사 소통 고장으로 인해 가장 자주 발생하는 문제 중 하나입니다. 정책을 이해하는 한 합법적 인 지름길을 취할 수 있습니다 (예 : 6 개의 작은 버그를 수정해야했지만 모두 동일한 기능을 수행 했으므로 실제로 9 개 모두에 대해 하나의 테스트 사례를 작성할 수 있습니다).

프로세스가 존재하는 이유를 설명하지만 전체 이야기가 아닙니다. 나머지 절반은 다음과 같습니다.

프로세스가 왜 그렇게 어려워?

이것은 실제로 대답 할 수있는 간단한 질문 : 팀 (또는 관리)에 초점을 맞추고 때문입니다 반복 가능한 결과 및 최소화 결함 (위와 같이)하지만 충분한 관심을 부여하지 않은 최적화 및 자동화 그 과정의.

예를 들어, 원래 질문에서 몇 가지 문제가 있습니다.

• CVS (Revision Control System)는 오늘날의 표준에 따라 다릅니다. 들어 새로운 프로젝트, 그것은 신속하게 의욕 (수은)과 같은 분산 시스템에 의해 가려지고 자체의 파괴 (SVN)에 의해 거의 대체되었습니다. Hg로 전환하면 분기 및 병합이 훨씬 간단 해지며 위의 가상의 예에서도 일일 커밋 요구 사항이 훨씬 덜 고통 스럽습니다. 저장소는 로컬이기 때문에 코드를 컴파일 할 필요조차 없습니다. 실제로 지연 개발자는 원하는 경우이 단계를 자동화하여 로컬 저장소에 자동으로 변경 사항을 커밋하도록 로그 오프 스크립트를 설정할 수 있습니다.

• 가상 머신 프로세스를 자동화하는 데 소요 된 시간이 없습니다. 소스 / 라이브러리를 가져 와서 구성하고 가상 머신에 다운로드하는 전체 프로세스는 100 % 자동화 될 수 있습니다. 로컬 컴퓨터의 버그 수정 작업을 수행하는 동안 중앙 서버에서 무인 프로세스를 수행 할 수 있으며 VM 만 사용하여 깔끔한 빌드를 보장 할 수 있습니다.

• 반면에 특정 규모에서 개발자 당 VM 솔루션은 어리석기 시작하고 Continuous Integration 서버 만 있으면됩니다. 실제 생산성의 이점은 개별 개발자가 빌드에 대해 전혀 걱정할 필요가 없기 때문입니다. 빌드 서버는 항상 깨끗 하기 때문에 가상 머신 정리에 대해 걱정할 필요가 없습니다 .

• 질문의 문구 ( "모든 단계의 테스트 사례")는 수동 테스트가 진행되고 있음을 나타냅니다. 이는 다시 작업량이 적은 소규모 팀에게는 효과적 일 수 있지만 더 큰 규모에서는 전혀 의미가 없습니다. 회귀 테스트는 자동화 할 수 있으며 자동화해야합니다. "단계"가 없으며 단위 / 통합 테스트 스위트에 추가 된 클래스 또는 메소드입니다.

• 말할 필요도없이, Bugzilla에서 새로운 (더 나은) 버그 추적 시스템으로 이동하면 경험의 그 부분이 훨씬 덜 고통 스럽습니다.

기업이 이러한 문제를 해결 하지 않았다고해서 반드시 싸 거나 바보 인 것은 아닙니다. 그들이 아는 것은 현재 프로세스가 작동 한다는 것 입니다. 어떤 경우에는 위험 회피 적이며 프로세스 에 대한 변경을 꺼려합니다. 그러나 실제로는 그 이점을 확신 할 필요가 있습니다 .

개발자가 일주일 동안 모든 비 코딩 작업에 대한 시간을 추적했다면이를 쉽게 추가 할 수 있으며, 예를 들어 Mercurial 로의 업그레이드에 대한 자본금 100 시간짜리 투자는 병합 충돌을 해결하는 데 일주일에 최대 10 시간을 제거하면 10 주가 소요되며 거의 확실하게 동의합니다. 빌드 서버 (CI) 또는 더 나은 버그 추적과 동일한 아이디어.

요점을 되풀이 : 팀은 아직 이러한 일을하지 않았다. 왜냐하면 아무도 오늘날 경영진이 그토록 중요하다고 확신 하지 않았기 때문 이다 . 따라서 이니셔티브를 수행하여 비용-편익 방정식으로 바꾸십시오. 최소한의 위험으로 단순화 / 자동화 될 수있는 작업에 소요되는 시간을 확인하고 새로운 도구 또는 기술의 손익 분기점 및 최종 수익을 계산하십시오. 그들이 여전히 듣지 않으면 나머지 옵션이 무엇인지 이미 알고 있습니다.

개발자가 일주일 동안 모든 비 코딩 작업에 대한 시간을 추적했다면 쉽게 추가하고 관리를 표시하고 비용 편익 방정식 등으로 바꿀 수 있습니다.

위 부분은 더 확장 할 가치가있는 것으로 보입니다.

작동하는지 확인할 수 있습니다. 프로그래머는 내가 작업 한 프로젝트 중 하나에서 몇 번 사용하고 원하는 변경을 할 때마다 사용했습니다.

나의 전반적인 인상은 바르게하는 경우,이 트릭은 어 수 있었다 번복 관리 무지와 관성의 매우 무거운 양.

우리 (개발자)가 이런 종류의 DIY 접근 방식에 의존해야했던 회사 는 IT에 미숙했습니다. 보다 노련한 소프트웨어 공급 업체에서 나는 주로 관리자 자신이하는 일을 보았습니다. 그리고 원칙적으로 그들은 우리 프로그래머보다 생산성이 뛰어났습니다. 훨씬 더 생산적입니다.

엄격하게 규제되는 산업에서 일하는 경우 번거로운 프로세스에 대한 몇 가지 이유가있을 수 있습니다. 언젠가 감사를받을 수 있으며 버그를 수정 한 사람, 방법, 검토 대상, 테스트 대상을 설명하기 위해 모든 기록을 표시해야합니다. 등 ...

따라서 필요한 악이 될 수 있습니다.

다른 한편으로, 경영진의 신뢰 부족 이외의 프로세스에 대한 타당성이 없다면 관리자에게 문의하여 회사의 시간과 돈을 절약 할 수있는 방법을 알려 주어야합니다.

올바르게 설명되어 있으면 더 빠르고 더 나은 프로세스를 거부하는 사람은 없습니다.

그러나 변화를 정당화하기 위해 당신의 주장을 방어 할 준비를하십시오.

문제의 절반은 프로세스에서 사용되지 않는 도구를 사용하지 않는다는 것입니다. 버그별로 브랜치를 생성하는 번거로운 작업없이 현대 DVCS에서 설명하는 것은 매우 쉽습니다.

또 다른 문제는 당신이 즐기는 일에 분명하지 않다는 것입니다. 개발을 원하는 동안 유지 관리 작업을합니다. 직업을 바꾸는 것 외에는 할 수있는 일이 거의 없습니다.

소프트웨어 공학의 학문은 본질적으로 "프로세스에 관한 모든 것"이므로 그러한 방식이 "가되어"있는지 궁금해하는 것은 요점을 놓치고 있습니다.

대부분의 프로그래머가 아니라 일부는 그들의 조직이 직면하고있는 문제를 해결하지 않는 경우에도 민첩 방법론을 옹호 할 정도로 과정의 절대 최소한으로 방해 될 수 있지만, 그것은이다 전적으로 가능 기업이 사용하기로 결정하는 " " 고객이 요구하는"과 같은 건전한 비즈니스상의 이유로 프로세스가 과중 합니다. 고객이 Fortune 500 대 기업, 대학 또는 정부 기관인 경우에 일반적입니다. 이러한 고객들에게 판매 한 보상은 추가 된 프로세스 오버 헤드를 정당화하기에 충분히 클 수 있습니다.

회사는 하나의 데이터 포인트이므로 더 많은 프로세스를 향하거나 멀리하는 업계 전체의 경향으로 경험을 일반화 할 수 없습니다. 실제 질문은 프로그래머, 회사, 제품, 고객 및 개인에게 어떤 균형이 가장 좋습니까? 해당 회사에서 일하는 것이 마음에 들지 않으면 변경을 요청하거나 다른 직업을 구하십시오.

로부터 다른 질문 내가 오늘에서 본 것, 당신은 당신의 일에 매우 불행 보인다. 당신은 오랫동안 거기에 없었습니다. 실수를 저지른 것 같다고 감독자에게 알려줄 수 있으며, 예상보다 빨리 길을 나설 시간입니다.

당신이 일에 능숙하다면, 당신은 정말로 새로운 것을 찾는 데 어려움을 겪지 않을 것입니다. 그리고 솔직히,이 과정이 존재해야 할 충분한 이유가 없다면, 아마도 이사를 고려할 것입니다. CVS를 사용하는 것은 실제로 나에게 큰 도움이 될 것입니다. 그러나 항상 인터뷰에서 소스 제어 질문을합니다. 분명히, 나는 당신의 상황을 알 수 없으며, 다른 의무가 있다면 직장을 떠날 수 없습니다.

저는 소프트웨어 엔지니어링에 매우 나쁜 프로그래머들이 어떻게 생겨 났는지에 대해 이야기하려고했지만 여러분이 묘사 한 상황은 끔찍합니다.

필자의 개인적인 경험에서 여러분이 설명하는이 "프로세스"중 일부는 관리 및 시스템 관리와 ​​함께 프로그래머에게 부과하는 시스템의 비 효율성을 완전히 인식하지 못합니다. 운영 체제 선택 제한, 사용 된 소프트웨어 제한, 인터넷 액세스, 개인 데스크탑 관리 권한; 이 모든 것들이 좋은 개발에 필수적 입니다.

또한, 여러 회사에서 사용하는 "매직 솔루션"간의 호환성 요구 사항. 예를 들어 중앙 집중식 소스 제어, 오프 사이트 Outlook 서버 및 코딩 지침 또는 모든 문제에 적합하지 않은 언어를 사용하는 본사가 있습니다.

엔터프라이즈 저글러의 바퀴를 계속 돌리는 것은 그리 재미 있지 않지만 일부 회사에는 혁신, 창의성 및 광채가 거의 없음을 발견했습니다.

아마도 프로세스 지향 회사 에서 일할 것입니다 . 대신 결과 지향적 인 회사 를 찾으려고 노력 합니다.

우리 회사에는 "프로세스"도 있습니다 (그러나 매우 간단합니다). 그러나 방해가되면 규칙을 어 기고 단계를 건너 뜁니다. 내가 결과를 얻었 기 때문에 지름길을 취함으로써 아무것도 끊지 않는 한 아무도 나에게 아무 말도하지 않을 것입니다.

프로세스가 방해를 받고 끝이되는 시점이 있습니까? 심지어 공학적입니까?

말 그대로, 대부분의 엔지니어링 은 특정 문제에 대응하여 잘 정립 된 조각들을 정해진 순서대로 정리하고 있습니다. ME에게 하루 종일 무엇을하는지 물어 보면 가장 분명합니다. 엔지니어링을 아키텍처 또는 초기 제품 개발 (모든 분야)과 혼동하고 있습니다. 귀하의 질문에 대해 두 가지 관찰이 있습니다.

1. 아키텍처 또는 디자인 작업이 아닌 버그 수정 작업에 할당 된 것 같습니다.
2. 동료들이 버그 수정 VM을 결합하여보다 효율적으로 작업 할 수있는 해결 방법이 제한되어있는 것처럼 보이며 합리적인 예를 따르지 않는 것 같습니다.

많은 사람들을 필요로하는 건설적인 노력에서, 어떤 사람들은 디자인을하고, 더 큰 그룹은 구현을 '하게'됩니다. 죄송하지만 두 번째 그룹에 속해 있습니다.

다른 논평가들이 지적했듯이, CVS는 고도로 분기 된 개발 모델에 가장 적합한 도구는 아니지만 병합에 대한 책임은 없습니다. 그래서 걱정하지 마십시오.

귀하의 불만의 대부분은 본질적으로 "개발 전, 도중 또는 후에 테스트하고 싶지 않습니다!" 단계별로 단계를 나누어 봅시다.

• 단일 버그를 해결하기 위해 먼저 깨끗하고 새로운 가상 머신을 얻습니다. 테스트 환경
• 그런 다음 Bugzilla 보고서에 설명 된 다른 분기를 기반으로 해당 단일 버그 수정에 대한 분기를 만듭니다. -당신은 버그가 발견 된 환경을 복제했습니다 ... 어떻게 이것이 합리적이지 않습니까?
• 기계에 지점을 설치하고 설정했습니다. 버그를 수정했습니다. 체크인 -기본 개발 프로세스
• ... 다른 사람이 테스트 할 수 있도록 기기와 기계를 남겨 둡니다. -합병 팀은 합병이 남쪽으로 진행되면 수정 사항을 확인할 수 있기를 원할 것입니다.
• 그런 다음 버그 제어 소프트웨어로 이동하여 내가 한 일을 설명 해야합니다.이 작업을 수행하지 않는 상점에있는 경우 ... 버그를 추적하는 이유는 무엇입니까?
• 모든 단계가 포함 된 테스트 사례를 작성하십시오. -내가 틀렸을 수도 있지만 그것은 모든 '멋진 아이들'이가는 방향 인 것 같습니다.
• 결국 다른 누군가가 그것을 릴리스와 병합합니다. -위의 여러 단계는 작업을보다 쉽게하기위한 것입니다.

다른 사람이 분명히 버그 심사를 수행하여 발견 된 버그가 다른 릴리스에서 수정되지 않거나 이후 릴리스에서 손상되지 않도록합니다 (테스트 사례의 목적).

이 프로세스에서 원격으로 이례적이거나 지나치게 특이한 것은 VM뿐입니다. 귀하가 어떤 도메인에서 일하고 있는지 알면 합리적인 것으로 간주 될 수 있습니다.

흥미 롭군 테스터가 있습니까? 그들은 그 중 일부를 수행해야합니다. 나는 하나이며 내가 일하는 곳에는 알맞은 해결책이 있습니다.

설명하는 것처럼 기능적 결함의 경우 프로세스는 다음과 같습니다.

1. VM에서 결함을 테스트합니다 (고객이보고했거나 탐색 테스트 중 또는 w / e).
2. 버그가 발견되었습니다.
3. 버그를 만듭니다. 버그는 다음과 같습니다.
   • 설치 시점부터 버그 확인 시점까지 전체 재현.
   • VM의 스냅 샷에 대한 링크
   • 시스템 정보, 내가 설정해야 할 특별한 설정.
4. 이 버그는 개발자에게 할당됩니다. 그들이 수정 작업을하는 동안 나는 :
   • 테스트 케이스 만들기
   • 수동 테스트를 자동 테스트로 작성 (또는 변환)

그런 다음 해결책을 기다렸다가 개발자에게 필요한 방식으로 도움을줍니다. 문제가 해결되면 다시 :

1. 자동 테스트 케이스 및 수동 버전 (경우에 따라)을 실행하여 수정 사항을 확인하십시오.
2. 버그를 닫습니다.

TL; DR : 테스터가 없다면 몇 가지가 필요합니다. 당신이 일부를 가지고 있다면, 그들은 '역할을하지 않습니다'.

톰 데 마코 :

... 내 초기 통계 책 ... ... 가장 인용 된 줄은 첫 번째 문장입니다. "측정 할 수없는 것을 제어 할 수 없습니다." 이 줄에는 실제 사실이 포함되어 있지만이를 사용함에 따라 점점 불편 해졌습니다. 인용문에 (그리고 실제로 책 제목에) 암묵적으로 말하면 제어는 모든 소프트웨어 프로젝트에서 가장 중요한 측면 일 것입니다. 그러나 그렇지 않습니다.

... 통제에 집중할수록 상대적으로 가치가 적은 것을 제공하려는 프로젝트에서 작업 할 가능성이 높아집니다.

내 생각에 소프트웨어 프로젝트를 제어하는 ​​방법보다 훨씬 중요한 질문은 왜 지구상에서 그러한 한계가있는 많은 프로젝트를 수행 하는가?

소프트웨어 엔지니어링 : 누구의 시간이 왔고 사라 졌는가?

"그런 다음 단일 버그 수정에 대한 분기를 만듭니다."

단일 버그 수정을 위해 분기를 만들 필요는 없습니다. 먼저 bugzilla에서 버그를 만듭니다. 릴리스 브랜치를 확인하십시오. 수정하십시오. 커밋 메시지에 작성된 텍스트 키워드에 따라 버그를 업데이트하고 버그를 업데이트하고 "고정, 테스트 필요"또는 "고정, 테스트 필요, 병합 필요"로 표시하는 커밋 메시지로 커밋을 수행하십시오. 버그 데이터베이스는 모든 변경 사항과 그 이유에 대한 완벽한 추적 메커니즘입니다. 이 정보를 추출하기 위해 버그 데이터베이스에서 보고서를 실행할 수 있습니다.

버그의 작업을 시작하기 전에 가상 머신 및 브랜치 생성 (컴파일 링 코드, 디버거 설정 등)이 모두 완료되도록 대부분의 프로세스를 자동화 할 수 있다고 생각 합니다.

수행 한 작업과 테스트 방법을 설명하는 것은 모든 버그 수정에 가치가 있습니다. 나는 위험에 대해 생각하게하기 때문에 텍스트를 작성하는 것이 문제를 잡을 수 있다는 것을 알았 습니다 .

따라서 프로세스가 약간“최상위”일 수 있지만 실제 문제는 프로세스를 지원하는 사용자 지정 자동화 도구가 부족하다는 것입니다.

요맨, 당신의 생각 과정은 당신이 묘사 한 것이 완전히 엉터리이며 소프트웨어에서 어떻게 잘못 될 수 있는지에 대한 진정한 데모입니다. 여기 좋은 소식이 있습니다. 진정한 정신으로 애자일을 수행하는 회사가 너무 많습니다. 내가 일하는 회사는 그런 회사 중 하나입니다. 요즘 많은 것들과 thatz 진짜 좋은 소식이 있습니다.

직장에서 실제로 일이 옳지 않다는 것을 느낄 때, 긍정적 인 변화에 영향을 미치거나 그 자리를 떠나 더 나은 곳으로 합류 할 수있는 두 가지 일이 있습니다.

CVS 또는 구성 관리 시스템은 나쁘지 않습니다. 불행히도, 그 목적을 실제로 모른 채 사용되는 방식은 전체 조직에! @ # $에 이런 고통을 안겨줍니다.

애자일이 실제로 무엇에 관한 것인지 빨리 이해하려면 Venkata Subramaniam의 "민첩한 개발자의 실습"책을 숙독하십시오. 쉽게 이해할 수있는 언어로 잘 작성되었습니다.

행운을 빌어 요!