스크럼에서 임의로 리팩토링 코드가 허용됩니까?

배경

• 우리 팀은 스크럼을 사용합니다
• 현재 할당 된 작업이 없습니다
• 백 로그에 더 이상 보류중인 작업이 없습니다.
• 오늘은 내 고객을위한 노동절 입니다.

오늘해야 할 일이 많지 않아서 현재 작업중인 프로젝트에서 계속보고있는 일부 코드를 리팩토링하기를 원했지만 현재 대규모 리팩토링을 수행하는 스프린트 작업에 할당되지 않았습니다.

내가 항상 귀찮게하지만 작성하지 않은 코드를 무작위로 리팩토링하기 시작하면 다른 날 할당으로 인해 수정하는 데 며칠이 없다면 스크럼 에서 괜찮습니까?

스프린트 사이에 여가 시간이있는 다른 날은 어떻습니까?

나는 실제로 지속적인 리팩토링을하고 믿습니다. 나는 항상 이야기를 할당 할 때 작업하고있는 코드 조각 에서이 작업을 수행하지만 현재 내가 현재 진행중인 작업과 관련이없는 다른 코드는 무엇입니까?

나는 실제로 다른 답변을 공격한다는 의미는 아니지만 다른 사람이 자동 테스트를 작성하는 사람은 없습니까? 여기에 '적절한 소프트웨어 엔지니어링 관행없이 스크럼을하는 사람을 위해 마틴 파울러에서 읽는 재미에요. Robert C. Martin도 여기 에 대해 많은 것을 말합니다 .

그래서 내 대답에 따르면 ... 간단히 말하면 다음과 같습니다.

예, 팀이 결정해야하는 한 Scrum에서는 "임의로"리팩토링 코드가 허용 됩니다. (결국 자체 구성)

그리고 지금 긴 대답을 위해 :

각 스프린트 후에 점점 더 많은 기술적 부채를 남기는 것이 재난을위한 레시피임이 분명합니다. 곧 코드가 더 복잡해지면서 모든 사람의 속도가 느려질 것입니다. 코드가 너무 복잡하고 어지럽기 때문에 실제 변경보다 변경 지점을 찾는 데 시간이 오래 걸리기 때문에 모든 변경을 수행하기가 더 어려워집니다. 알지 못하는 크고 복잡한 모듈을 변경해야 할 경우 프로젝트에 사람을 추가 / 전환 할 때 생산성을 얻는 것이 불가능 해집니다.

팀이 속도를 일정하게 유지하려면 소프트웨어를 지속적으로 증가시키기 위해 코드베이스를 깨끗하게 유지할 수 있어야합니다. 리팩토링은 프로젝트 수명주기 내내 속도를 유지하고 프로젝트에 사람을 추가 / 전환 할 위험을 완화하고 모듈을 변경하려는 경우에는 아무것도 모른다 는 필수 관행 입니다. 약 등등.

그러나 리팩토링은 매우 위험한 활동입니다. 나는 반복한다-그것은 매우 위험한 활동이다. 즉, 코드베이스를 안전하고 자유롭게 변경할 수있는 충분한 테스트 범위가없는 한입니다. 아무 것도 깨지지 않았는지 확인하기 위해 버튼을 누를 수 있다면 리팩토링은 매우 안전한 활동이됩니다. 실제로 TDD주기의 일부이기 때문에 이러한 테스트 스위트를 처음에 작성할 수있는 관행입니다.

그러나 스크럼의 팀이 자체 구성되므로 결국 팀은 올바른 일을 결정해야합니다. 나는 당신이 누군가를 설득해야 할 경우에 당신에게 몇 가지 주장을 해주기를 희망합니다. (첫 번째 단락의 링크와 그들이 가리키는 다른 모든 기사에 특별한주의를 기울이십시오)

스크럼은 리팩토링에 대해 아무 말도하지 않습니다.

스크럼이 말하는 것은 스프린트 내에 어떤 작업이 없다면 스프린트 목표에 도달하도록 나머지 팀을 지원해야한다는 것입니다. 그것이 커피를 가져 오는 것을 의미하더라도.
팀에서 코드 리팩토링이 코드를 지원할 수있는 최선의 방법이라는 데 동의하면 (그리고 리팩토링으로 인해 너무 많은 새로운 버그가 발생하지 않도록 인프라를 갖추는 것도 포함됩니다), 반드시 진행하십시오.

나는 아니라고 대답했다. 이는 작업 유형 (리팩토링 등)과 관계가 없습니다.

최소한 작업을 작성하여 현재 스프린트로 푸시해야합니다. 시간 추적의 목적은 미래의 스프린트를 효과적으로 계획 할 수 있도록 속도를 캡처하는 것입니다. 추적하지 않고 사물을 작업하는 경우 속도에 영향을 미치며 적절한 추적을 위해 의도 된대로 시간이 지남에 따라 더 나아지지 않을 것입니다 (예상 속도가 실제 속도보다 낮기 때문에 정기적으로 충분한 작업이 없을 것입니다) ).

리팩토링 작업 자체에 관해서는, 나는 그것에 대해 논쟁을 할 수 있지만, 그것이 당신이 대답하려는 핵심 질문이라고 생각하지는 않습니다.

나는 아니라고 말할 것입니다. 리팩토링은 의도하지 않은 버그가 올바른 방법으로 관리되지 않는 경우 종종 발생합니다.

GM으로서 저는 정기적으로 모든 사람을 다른 프로젝트에 참여시키고 일주일 동안 코드 검토 / 리팩토링 / 이름 변경 및 프로젝트에 관한 규칙을 시행했습니다. 이러한 리팩토링 스프린트는 사실상 거의 항상 화장품입니다. 모든 기능적 리팩토링은 미리 계획되며 원래 개발자와 관련이 있습니다.

기능적 리팩토링은 항상 스크럼 프로세스의 일부로 계획되고 조정되므로 시간을 추적하고 프로세스를 검증하는 데 필요한 모든 팀원을 사용할 수 있습니다. 한 개발자가 다른 오프 트랙이 작성한 코드를 변경하지 않아야합니다. 대부분의 사람들이 현재 스프린트를 엉망으로 만들 가능성이 높기 때문입니다. 특히 코드 병합 시간과 관련하여.

자신이 유일하게 유지 보수하는 프로젝트이고 자신의 자유 시간 인 경우 현재 스프린트에서 불필요한 지연이 발생하지 않도록 조치를 취하는 것으로 가정하면 다를 수 있습니다.

확실하지 않은 경우 관리자에게 문의하십시오.

편집 : 또한 원하지 않는 특정 코드 조각에 특정 성능 목표가있을 수 있다고 언급하고 싶습니다. 당신은 그것을 좋아하지 않을 수도 있지만 그것을 사용하는 방법에 맞는 빌드 할 수있는 것보다 빠를 수도 있습니다. 기능적 리팩토링이 항상 관리되는 프로세스 여야하는 또 다른 이유입니다.

스크럼은 리팩토링에 대해 아무 말도하지 않습니다 (로버트 C. 마틴의 강의, "스크럼을 잊어 버린 땅"참조).

스크럼 작업은 리팩토링을 통해 상환 할 기술적 부채가 아니라 고객이 지정한 소프트웨어 기능을 대상으로합니다. 이것들은 완전히 다른 추상화 수준입니다. 고객은 대부분 필요성을 평가할 수 없습니다.

스크럼은 통계 프로젝트 관리입니다. "얼마나 오래 걸립니까"의미있는 측정 값을 얻으려면 성능 (스프린트 당 출력)을 알아야합니다. 통계에 들어가기 위해 1 회 이상의 스프린트에 대한 기능의 추정 및 실제 지속 시간을 비교합니다. 스프린트 5 개를 권장합니다. 그러나 그것은 당신의 팀에 달려 있습니다.

중요한 것은 모든 예측을 가능하게하는 수단을 의미 있고 비교할 수있게 유지하는 것입니다. 기술적 부채로 인해 성과가 감소하는 경우에는 그렇지 않습니다.

여전히 리팩토링 태스크를 생각하면 다음 두 가지 문제점이 있습니다. 1. 이해하지 못하는 고객, 새로운 기능을 생성하지 않는 태스크를 수락해야하는 이유 2. 통계를 완전히 왜곡하여 예측 능력 이전 스프린트에서 고려되지 않은 다른 변수를 갑자기 변경하면

두 경우 모두 고객과의 기능에 대해 이야기하고 "시간이 얼마나 걸립니까?" 통계적인 방법으로. 안전을 위해 코드베이스를 일정한 품질로 유지해야합니다.

리팩토링은 대부분 지하 작업입니다. "훌륭한"리팩토링은 "작은"리팩토링이 과거에 처리되지 않았 음을 의미합니다.

마지막 참고 사항 : 리팩토링을 수행하는 경우 리팩토링중인 테스트중인 구성 요소가 있는지 확인하십시오. 시험이 없습니까? 테스트 작성 작업을 수행하십시오. 고객은 현재 사용중인 소프트웨어의 테스트 범위가 충분하지 않다는 것을 알게되어 기쁩니다 ...

고객에게 기술적 인 내용을 멀리하고 전문 개발자로서 업무를 수행하십시오.

한 가지 방법이 있습니다 : 둘 다 수행하십시오!

리팩토링은 종종 @misterbiscuit가 지적한 것으로 추정되는 오류가 발생하기 쉽거나 더 많은 시간이 소요됩니다.

따라서 드래프트 또는 스파이크를 시도하십시오. 이 단계에서는 승인을 받거나 광고하지 않습니다.

그런 다음 두 채널 중 하나를 통해 포함 시키십시오.

• 합리적으로 포장 할 수있는 동일한 코드 / 기능을 다루는 기존 티켓. 동료 팀원과 합의한대로.
• 다음 티켓 정리 (또는 폭포 인 경우 매주 회의 등)에서 검토 할 수 있도록 티켓 전체를 제출하십시오. 그때 당신은 그것을 위해 사건을 만들 수 있습니다.

실제 바이 인을 받으면 스파이크를 적용하거나 다시 실행하고 실제 코드를 메인 라인 (마스터 등) 브랜치에 병합 할 수 있습니다.

몇 가지 장점이 있습니다.

• 동일한 프로세스를 통한 모든 코드 코드, 테스트, QA, 릴리스 파이프 라인 등
• 리팩토링은 크래프트의 일부이며 휴일에 '몰래 들어올 필요'가 아니라 제품 관리자를 포함한 공식적인 바이 인을받습니다. 실제 기능이 '몰래 들어 가지 않는'이유를 자문 해 보는 것이 도움이 될 수 있습니다.
• 팩토링 코드 변경에 필요할 수있는 페어링, 코드 검토, qa, devops 및 기타 모든 지원을 요청할 수 있습니다. 정책 및 절차 및 위의 보드에 따르면 모두 공식적입니다.
• SOX 규정을 준수하는 공개 거래 회사 인 경우 이러한 종류의 공식 프로세스를 수행 / 필요할 수 있습니다 (예 : 문서화 한 후 수행).
• 제품 관리자 (변경이 신속하게 완료 됨)와 개발 팀 (코드베이스가 개선됨) 모두에 대해 더 나은 평판을 얻습니다.
• 조직은 생산성, 사기, 직원 유지 및 기타 여러 가지 이유로 좋은 코드 품질을 관리하려고합니다.
• 모든 작업이 포함되면 프로젝트 속도에 대한 영향을보다 쉽게 ​​추적 할 수 있습니다. 존재 자체가 속도에 영향을주기 위해 사용될 수 있으므로 점을 지정하지 않는 것이 좋습니다.
• 개발자는 Fisheye, Github 등과 같이 더 쉬운 코드 검토를 장려하는 도구를 보게 될 것입니다.
• 개발자는 코드 공유 및 리팩토링을보다 쉽게 ​​해주는 몇 가지 기본 표준 (때로는 문서화되거나 때로는 문서화되지 않음)을 보게 될 것입니다. 때로는 리팩토링의 큰 부분이 스타일을 선택한 다음 광범위하게 적용하는 것입니다 (접근 방식을 혼합하여 대체).

최종 설명 : 제품 관리자가 '무작위'라는 단어를 듣지 마십시오. '타겟 형, 전략적, 성능 향상'코드 업그레이드로보다 유리하게 대응할 수 있습니다. 또는 응용 프로그램 서비스 팩. 또는 어떤 언어가 당신에게 적용됩니다.

랜덤 리팩토링은 의미가 없습니다. 이해가되는 것은 대부분의 이점을 가져올 코드를 리팩토링하는 것입니다. 그 의미는 :

• 디자인 또는 아키텍처 문제 해결
• 구현 개선

내가 항상 귀찮게하지만 작성하지 않은 코드를 무작위로 리팩토링하기 시작하면 다른 날 할당으로 인해 수정하는 데 며칠이 없다면 스크럼에서 괜찮습니까?

에서 이 대답 :

코드를 유지 보수 가능하게 유지하려면 번 다운 목록의 항목이어야합니다 (Scrum을 사용하는 경우). 새로운 개발만큼이나 중요합니다. "사용자에게 보이는"것처럼 보이지는 않지만 무시하면 기술 부채가 증가합니다. 기술 부채가 쌓여 코드의 유지 관리 능력이 부족하여 개발 속도가 느려지면 새로운 기능 개발 지연이 고객에게 보일 것입니다.

이전의 연구에서, 우리는 더 큰 스프린트 (2-3 개월)를 가진 일종의 스크럼을 가지고있었습니다. 스프린트 (1 개월) 사이에 약간의 지연이 있었으므로 이번에는 소프트웨어를 분석하고 코드를 리팩터링하는 데 사용했습니다.