방금 Scrum으로 일을 시작했는데 뭔가 빠진 것 같습니다. 저는 스크럼을 처음 사용합니다

이 코드는 고전적인 ASP / ASP.NET 조합의 완전한 혼란입니다. 스크럼은 우리가 큰 혼란을 패치하거나 그것에 추가하는 것으로 구성됩니다. 우리 모두 다시 쓰기 시작하기에 너무 바빠서 궁금합니다 ..

스크럼에서 개발자가 충분히 충분하다고 말할 수있는 부분은 어디에 있으며, 큰 재 작성을 시작할 시간이 필요합니까? 우리는 '스토리'로 오래된 코드를 패치하는 끝없는 루프처럼 보입니다.

따라서 코드베이스가 얼마나 나빠 졌는지 이해하지 못하기 때문에 재 작성을 원치 않는 비전문가들이 일을하고 있습니다.

그렇다면이 큰 재 작성 변경을 담당하는 사람은 누구입니까? 개발자? 스크럼 마스터?

현재의 전략은 단지 시간을 찾아서, 우리가 겪고있는 현재의 혼란에 대해 대부분의 책임을지고 있기 때문에 관련된 고가들없이 스스로 <-하는 것 ->입니다.

왜 이것이 사람들에게 그렇게 어려운지 잘 모르겠습니다. 그의 사업 사례는 다음과 같습니다.

We seem in an endless loop of just patching old code with 'Stories'.

개발자 시간은 돈이다. 돈이 많다. 나는 1 년 전에 UI를 개선 할 계획을 가진 회사를 떠났고 스크럼을 채택하면 휠 회전을 멈추는 데 도움이되기를 희망했습니다. 어떻게 된 거예요? 같은 ol '같은 ol'. 그들은 새로운 기능을 계속 강화했으며, "기술 부채"는 비즈니스 코드가 없었지만, 기본 코드베이스가 완전히 오래된 엉망으로 인해 우리가 작성한 코드의 절반이 의미가 없어졌습니다. 내가 떠난 이래로 프론트 엔드에 변화가 없었으며, 완전히 개조 할 목적으로 생겨났습니다. 두 달 동안 나는 CSS 나 JavaScript를 실제로 만지지 않았습니다. 나는 1990 년대 후반부터 HTML과 고대 자바 템플릿 시스템을 엉망으로 만들었습니다.

내 대답은? 할 수있는 일을하되, 다른 개발자들이 이미 실질적인 기한을 지키기보다 스프린트 목표를 달성하기 위해 늦게 일하고 늦게 노력하고 있고 기술 부채가 실제로 블로킹 문제라고 주장하면 최악의 상황을 가정하고 새로운 일자리를 찾기 시작하십시오 지금. 개발자가 우려 사항을 전달할 수 없거나 의사 소통이 불가능하거나 비즈니스가 너무 돈이 얼마나 많은지 이해하기에는 근시안적입니다.

이러한 문제를 무시하면 항상 비용이 더 많이 든다. 그리고 조금 더가 아니라 더 많이. 개발 시간이 걱정되는 가슴 상처뿐 아니라 더 나은 지식과 다른 옵션을 가진 개발자가 회사를 전염병처럼 피할 수 있기 때문에 필연적으로 재능 수준을 낮추게 될 것입니다. 내 현재 상사는 개발자이자 회사의 소유자입니다. 다른 우선 순위에 초점을 맞추기 위해 다시 작성하지 않을 내용이 있지만 일관된 타임 싱크로 인해 실제로 리 팩터가 필요한 경우 적절한 리 팩터를 얻습니다. 그리고 결과는 분명합니다. 여러 가지 요인으로 인해 새로운 것을 수정하고 추가하는 것이 더 쉽고 빨라집니다. 한 번에 몇 시간이 걸리던 작업은 적절한 아키텍처로 몇 분이 걸릴 수 있습니다. 비즈니스는 그 말을 듣지 않으려하지만이를 위해 가치를 두는 것이 좋습니다.

스크럼은 개발자가 IMO를 많이 보유하지 않는 환경에서 실패합니다. 비즈니스 유형이 유지 보수 및 업데이트를 무시하기가 너무 쉽기 때문에 "성공적인 이니셔티브"목록에 올릴 수있는 글 머리 기호를 선호하기 때문입니다. 평가 시간이 다가옵니다. 그들은 항상 이러한 문제를 무시하기 위해 엉덩이에 지속적으로 물린 경우에도 항상 자신의 가죽과 승진 가능성을 선호합니다.

스크럼은 또한 이익을 얻는 산업이기도합니다. 회사는 스크럼 훈련에 많은 돈을 지불합니다. 입양을 원하는 사람들은 시장에 누가 팔리고 있는지, 그리고 그것이 실제로 주어진 문화에 얼마나 현실적 일지에주의를 기울여야합니다.

그럼에도 불구하고 실제로 개발, 엉뚱한 코드베이스, 귀에 왁스를 사용하고 가시가없는 개발자를 관리하는 것은 불행과 레시피를위한 유용한 방법입니다. 문제를 해결하려는 노력이 실제로 성과 를 내고 있는지 실제로 발견하기 전에 주저하지 말고 GTFO에 발걸음 을 옮기 십시오.

의심 할 여지없이 Scrum을 수행하는 경우 제품 소유자가 재 작성을 결정할 책임이 있습니다. 대부분의 경우 재 작성은 좋은 생각이 아닙니다. btw는 새로운 기능을 생성하지 않고 새로운 버그만 도입하기 때문입니다.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

"다시 쓰기는 좋은 생각이 아닙니다"로 확장하려면 :

점진적으로 개선하는 것이 거의 항상 좋습니다. Jarrod Robertson이 의견을 썼 듯이, 개선이 필요한 모듈을 해당 모듈의 전문가가되고 특정 모듈을 개선하기위한 다음 스프린트에 대한 기사를 작성하십시오. 해당 모듈이 작동해야하는 이유를 제품 소유자에게 설명하십시오.

난 정말 무딘거야 ...

• 이 직무의 개발자를 담당하고 있습니까?
• 당신은 프로젝트 리더입니까?
• 개발자가 프로젝트에서 얼마나 "지분"을 보유하고 있습니까?
• 재 작성에 대한 귀하의 비즈니스 정당성은 무엇입니까?
• 코드베이스가 완전히 쓸모없고 회복 불가능한 이유는 무엇입니까?

당신은 당신이 직업을 시작했다고 말했지만, 당신은 이미 그곳의 상황의 대가 인 것처럼 보입니다. 아마도 나는 당신의 질문의 의도를 오해했을 것입니다. 그러나 당신이 많은 문제를 겪는 직장에 들어갔다는 느낌을 얻었습니다. 다시 작성하지만 실제로 고용주가 비용을 고려한 적이 있습니까?

상태가 아무리 빈약한지에 관계없이 기존 코드 기반을 사용하면 소유자는 일반적으로 코드가 나타내는 제품에 상당한 투자를 할 수 있습니다. 코드베이스와 관련된 직접 및 간접 비용이 모두 있으며, 코드 자산을 평가 절하하여 이전의 모든 제품에 대한 수익을 낮추기 위해 소프트웨어 개발자로서 가장 최근에 다시 작성하는 것이 종종 재 작성입니다. 노력.

창의 운영 체제를 예로 들어 보겠습니다. 각각의 새로운 버전이 만들어 짐에 따라, 이전 버전에서 많은 양의 코드가 전달되었습니다. 때로는 전체 라이브러리와 API가 여러 세대의 OS로 끌어 오기도합니다. 왜? 개발자는 이러한 요소가 작동하고 테스트되었으며 보안 및 메모리 문제를 방지하기 위해 패치 및 수정되었으며 그 상태에 들어가는 데 많은 비용이 들기 때문에 알고 있습니다. 유지 보수 비용이 상대적으로 높더라도 처음부터 시작하는 비용은 항상 더 높을 것입니다 .Microsoft의 경우와 같은 회사의 경우 은행에 수십억 달러가 있습니다. 원한다면 처음부터 시작할 수 있지만 그들은 투자로부터의 수익을 극대화하기를 원하기 때문에. 프로젝트에 수십억 달러의 현금을 버는 것을 제외하고는 고용주가 Microsoft와 다르지 않습니다.

따라서 코드는 혼란스럽고 회사의 여러 영역 사이에 통신 및 경계 문제가있는 것처럼 들립니다. 당신이나 당신의 동료들은 이것에 대해 무엇을 할 수 있습니까?

한 가지 방법은 팀이 계속 진행하면서 미래에 기적을 기대하는 것입니다. 아마도 좋은 생각이 아니며 좌절과 스트레스 만 증가시킬 수 있습니다.

더 나은 옵션은 단순히 작업을 방해하고 작업을 수행하는 것이지만,이 과정에서 가장 취약한 것으로 보이는 코드 영역을 지원하는 테스트를 추가 할 기회를 찾고,보다 안정적으로 될 때까지 리팩토링합니다. 단순히 모든 것을 버리지 말고 논쟁하는 대신 회사의 투자를 개선하기위한 강력한 주장을하기가 더 쉬울 것입니다.

더 나은 옵션은 팀으로 구성하고 팀이 코드 기반을 개선하기 위해 시간을보다 유연하게 예약 할 수있는 충분한 사례를 만들 수있는 충분한 선임자가있는 사람을 확보하는 것입니다. 나는 회사가 얼마나 바쁘거나 일정이 얼마나 엄격한 지 상관하지 않습니다. 항상 개선에 두 가지를 짜는 데 사용할 수있는 활동이 가끔씩 발생합니다. 그러나 다른 작업을 완료하는 동안 개선 할 수 있다면 더 좋습니다. 그것이 저라면 매니저에게 아늑하고 소프트웨어 개발자가 읽는 표준 책의 개념을 소개 할 것입니다. 깨끗한 코드아마도 당신 팀이 가장 필요로하는 것입니다. 코드를 개선하는 방법에 대한 몇 가지 씨앗을 심고 의미의 몇 가지 예를 제공하십시오. 좋은 관리자는 특히 기술 부채 개념을 설명 할 수있는 경우 코드에 점진적 개선을 추가하는 것의 가치를 알게 될 것 입니다. 팀 리더 나 관리자가 코드를 개선하기위한 훌륭한 비즈니스 사례를 만들도록 도와 주면 더 나은 동기 부여를받을 수 있습니다.

"코드가 어수선하지 않다"고 말하는 것만으로는 충분하지 않습니다. 동료들은 항상 코딩을 깨끗하게 연습하고 깨끗한 코딩 기술을 사용하여 약간의 정리를 권장해야합니다. 새 직장을 가질 때마다 인쇄하고 사무실 벽에 매달리는 작은 포스터가 있습니다. "항상 코드를 찾은 것보다 조금 더 아름답게 남기 위해 노력합니다"라고 말합니다. 바로 옆에 "부 계절을 금칠 필요가 없습니다"라는 문구가 추가되었습니다. 그들은 항상 내가 찾은 것을 개선하려고 노력해야한다는 것을 상기시키는 역할을하지만, 한 문제를 다른 문제와 금 도금하는 것을 피합니다. 대규모 재 작성은 종종 잘못된 이유로 수행되기 때문에 최악의 "금 도금"입니다. 완전히 새로운 제품 버전이 어느 시점에서 정당화 될 수 있는지 확인하십시오.

공식 Scrum Guide 에서 Scrum Development Team 의 공식 정의는 다음과 같습니다 . 나는 당신에게 직접 관련된 부분에 중점을 둡니다.

개발 팀은 각 스프린트가 끝날 때“완료”제품을 출시 할 가능성이있는 전문가로 구성됩니다. 개발 팀의 구성원 만 증분을 만듭니다. 개발 팀은 조직이 자체 작업 을 구성하고 관리 할 수 ​​있도록 구조화되고 권한을 부여받습니다 . 결과적인 시너지 효과는 개발 팀의 전반적인 효율성과 효과를 최적화합니다. 개발 팀은 다음과 같은 특징이 있습니다.

• 그들은 스스로 조직하고 있습니다. Scrum Master조차도 개발 팀에 제품 백 로그를 잠재적으로 출시 가능한 기능의 증분으로 바꾸는 방법을 알려주는 사람은 없습니다.

• 개발 팀은 제품 증분을 생성하는 데 필요한 팀으로서의 모든 기술을 갖춘 교차 기능입니다.

• 스크럼은 개인이 수행 한 작업에 관계없이 개발자 이외의 개발 팀 구성원에 대한 타이틀을 인정하지 않습니다. 이 규칙에는 예외가 없습니다.

• 개별 개발 팀 구성원에게는 전문 기술과 초점 영역이있을 수 있지만 책임은 개발 팀 전체에 속합니다. 과,

• 개발 팀에는 테스트 또는 비즈니스 분석과 같은 특정 도메인 전용 하위 팀이 없습니다.

따라서 개발 팀은 자체 혼란에 대한 책임이 있으며 팀 외부의 누군가에게 묻지 않고 자체적으로 해결해야합니다.

추후 각각의 추정에 기술 부채 수정 시간을 포함시키고 제공하는 소프트웨어의 품질이 최고 수준인지 확인하십시오.

실제로 완전히 다시 작성해야하는 경우 Scrum Restrospective에서 문제를 해결해야합니다. 제품 소유자는 결국 프로젝트를 취소하고 새 프로젝트를 시작할 수 있습니다. 스프린트를 취소 할 수있는 유일한 제품은 제품 소유자입니다.

이 내용 을 설명 할 때 SCRUM과 관련이 있거나 제품 개발 팀이 현재 문제가되는 것은 없습니다 .

이것은 정상입니다

당신이 설명 하는 것은 코드베이스 의 정상적인 엔트로피입니다. 귀하의 경우 팀은 아마도 이상에서 멀어지기 시작했지만 여전히 모든 코드베이스는 결국 Big Ball of Mud가 됩니다.

완벽 하게 완벽한 그린 필드 시나리오에서, 당신이 할 수있는 모든 것은 절대 엔트로피에서 더 멀리 시작하여 느리게 진행하는 것입니다.

나는 다른 사람들과 동의합니다. 코드베이스 혼란은 개발자 때문입니다. 나는 그것이 몇 년 전부터 SCRUM의 채택보다 앞서 있다고 확신합니다.

다시 작성하려는 기술적 또는 개발자의 결정이 아니라 비즈니스 결정입니다.

제품 소유자가 재 작성을 원하지 않는 이유에 대해 확신하지 않습니다. 개발자로서 필요하다고 생각하지만 실제로 비즈니스 사례 가 있습니까?

진정한 비즈니스 사례 가 있다면 손을 흔들며하는 것만이 아닙니다. "코드는 내가 원하는 것이기 때문에 그린 필드를 시작하고 싶어하는 레거시 엉망이다"라고 하면 경영진은 그 투자에 대한 수익을 고려할 때 재 작성 비용을 즐겁게 할 것이다.

당신은 하나의 고체 부여하지 않은 비즈니스 케이스를 , 다시 쓰기 위해 단지 호언 장담을 당신에 대해 의견을 다른 사람들이이 혼란을 야기 방법 및 당신은 그것을 처리하고 싶지 않아요.

Proof-Profit 은 깨끗한 코드 기반이 필요한 일부 OCD 가 아니라 작동중인 소프트웨어를 버리기 위해 비즈니스 결정을 내립니다.

당신이 정말로 보여줄 수있는 경우 증거 , 단지 이론 만 열심히 증거 지출하는 X그린 필드의 다시 쓰기에 달러하는 것은됩니다 MAKE의 보장 X * N 의 비즈니스를위한 달러 Y(기간 N높고 Y짧은)을, 당신은 관리에서 일부 견인을 얻을 수 있습니다 . 당신이 제시하고 증명할 수있는 가능성은 거의 없습니다.

그렇지 않으면 당신은 그것을 처리해야합니다, 이것은 현실입니다. 이 끔찍한 재 작성 없이는 앞으로 나아갈 길이 전혀 없다는 단호한 주장과는 달리, 5 년 이상 당신이 불평하는 코드베이스는 여전히 누군가에게 기능과 가치를 제공하는 곳에서 여전히 작동하고 실행되는 돈을 걸었습니다. 당신은 회사를 떠났습니다.

나는 사람들이 "큰 재 작성"을 강요 할 때 보통 회의적이다. 레거시 코드가 가치를 가지고 있다는 사실은 분명히 의미가 있지만 대부분의 경우에는 이미 프로덕션 환경에 있으며 제작에 영감을 준 목적으로 사용되는 경우가 있습니다. 큰 재 작성을 수행하는 것은 민첩성과 반대되는 경우가 많습니다. 새 버전의 애플리케이션을 기존 애플리케이션을 대체 할 수있는 시점으로 가져 오는 데 얼마나 걸립니까?

내가 선호하는 접근법은 Martin Fowler가 교살하는 포도 나무 라고 부르는 것 입니다. 새로운 접근 방식을 사용하여 새로운 기능 (기존 기능 변경 포함)을 구현하지만 기존 기능을 새로운 기능으로 확장 할 수있는 격자로 사용하십시오. 이를 통해 두 가지 이점을 모두 누릴 수 있습니다. 큰 재 작성이 스 너핑되는 동안 모든 것을 중지 할 필요는 없지만 업데이트 된 프레임 워크를 활용하는 새 코드를 작성할 수 있다는 이점이 있습니다. 그것은 깨끗하게 시작하는 것보다 확실히 어려운 접근법이며 섹시하지 않을 수도 있지만 구식이기 때문에 거기에있는 모든 것을 버리는 것보다 비즈니스에 더 많은 가치를 제공합니다.

현재 위치와 작업 방식은 다음과 같습니다. 새로운 스토리를 작성하여 제품 소유자에게 건네면 우선 순위 결정 방법을 결정합니다. 예를 들면 다음과 같습니다. "제품 X의 개발자로서이 영역에서 코드를 다시 작성하여 향후 개발의 효율성을 높이고 싶습니다"승인 기준은 다음과 같은 라인을 따라야합니다. 이런 식으로 더 좋습니다.

나는 당신이 처한 상황에 대해 잘 모르지만 여기에서 처음부터 다시 시작하고 싶다면 제품 소유자와 함께 앉아서 이유를 설득 한 다음 기존 이야기를 다시 작성하는 이야기 더미를 작성하는 경우입니다 기능.

잘못된 코드 및 / 또는 레거시 코드를 처리하기 위해 수행 한 다른 작업에는 사용자 스토리를 처리 할 때 재 작업을위한 작업이 포함되었습니다.

큰 재 작성을 결정하는 것은 비즈니스 결정입니다. 비즈니스의 일부를 담당하는 사람들에게 자신의 관점에서 판매함으로써 비즈니스 의사 결정에 영향을 줄 수 있습니다.

하나; 한 반복에서 다음 반복으로 코드 품질의 변화는 개발자의 결정입니다. 코드 품질이 떨어지도록 허용하면 제품 소유자의 기대를 충족시키기 위해 기술 부채가 추가됩니다. 당신이 할 수있는 일은 작성하는 코드에 대한 책임을지고 시작하여 코드베이스를 개선하는 것입니다. 이제 기술 부채가 지속적으로 줄어들 기 때문에 속도가 떨어지고 제품 소유자는 반드시 실망하게됩니다. 귀하는 간절히 원한다면 코드 품질이 저하되었으며 이제이 문제를 해결하기위한 조치를 취하고 있다고 설명 할 수 있습니다.

이제는 끔찍한 조치이며, 단 한 번의 스프린트를 지연 시켜서 중요한 마감 시간 전에 기능 X를 얻을 수 있다는 유혹을 느낄 수 있습니다. 불행히도, 기다릴수록 더 어려워 질 것입니다.

그건 그렇고, 이것은 엄격하게 Scrum 문제가 아니며 Scrum에만 해당되는 솔루션을 제안하지도 않습니다. 이것은 코드의 소유권을 가진 개발자에 관한 것입니다.

개발자는 코드베이스의 현재 상태를 세계에 경고 할 책임이 있습니다. 이것은 일상적인 스크럼 동안, 회고 적이거나 비공식적으로 발생할 수 있습니다. 명백한 것처럼 보이지만 엉망이 무엇인지, 그로 인해 얼마나 많은 시간을 낭비하는지 명확하게 표현하지 않으면 아무도 눈치 채지 못할 것입니다. Scrum Master는 일반적으로 정보를 PO와 프로젝트 책임자에게 전달하고이를 수행해야 할 것을 설득 한 다음 팀의 솔루션 구현을 촉진 할 책임이 있습니다.

부수적으로, 빅뱅 다시 쓰기는 IMO가 반드시 이런 종류의 문제에 대한 정답은 아닙니다. 그러나 개발자는 현재 코드베이스를 사용하고 있습니다. 깨끗한 아키텍처를 향한 작은 측정 가능한 단계를 취하는 것이 더 나은 아이디어입니다. 프로세스를 정기적으로 보여줌으로써 진행 상황을 확인하고 작업을 정당화하고 새로운 사용자 구현의 흐름을 계속합니다 끝없는, 자원 독점적 인 화장에서 길을 잃는 것과는 대조적으로 이야기.

당신은 물었다 :

스크럼에서 개발자가 충분히 충분하다고 말할 수있는 부분은 어디에 있으며, 큰 재 작성을 시작할 시간이 필요합니까? 우리는 '스토리'로 오래된 코드를 패치하는 끝없는 루프처럼 보입니다. 따라서 코드베이스가 얼마나 나빠 졌는지 이해하지 못하기 때문에 재 작성을 원치 않는 비전문가들이 일을하고 있습니다.

관리자이자 개발자 인 사람으로서 귀하의 질문에 대한 가장 간단한 답변은 Scrum이나 다른 방법론 또는 비즈니스 시나리오에 개발자가 충분하다고 말할 힘이 있고 고쳐 쓰기. 여기서 많은 사람들이 재 작문이 왜 자주 나쁜 생각인지 설명하고 변화가 점진적이고 민첩한 방식으로 어떻게 이루어질 수 있고 설명해야하는지 설명하기 위해 훌륭하고 타당한 주장을했습니다. 그리고 나는 그들 모두에 동의합니다.

그러나 결론은 훨씬 간단합니다. 그 결정을 내릴 수는 없습니다. 당신은 직원이며, 당신이 실제로 내려야 할 유일한 결정은 "이러한 주장을 위해 계속 일하거나 나의 미친 기술을 두려워하는 새로운 직업을 찾을 것인가"입니다. 당신의 새로운 직업은 당신이 그 결정을 내릴 수는 없지만, 적어도 일을 할 때마다 당신이 운명을 통제하고 있다고 느끼게 될 것입니다.

나는 당신의 고통을 느낍니다. 그러나 그것이 스크럼과 어떤 관계가 있는지 잘 모르겠습니다. 코드를 다시 작성할지 여부는 개발 프로세스에 따라 결정되지 않습니다.

무엇을 기다립니다?

당신은 패치하고 있습니까? 리팩토링 해야합니다 . 민첩한 가치를 고수하십시오. TDD와 적절한 관행을 사용하면 상황이 더 좋아질 것입니다.