태그 보관물: programming-practices

programming-practices

금도금을 멈추고 작업 개발을 발표하기 위해 만족하는 방법 [닫기] 관행에 따라 업무를 수행하도록

내가 속한 개발 팀은 최근 민첩한 관행에 따라 업무를 수행하도록 적응했습니다. 이것은 개인적으로 금도금 코드 (및 문서)를 막을 수 없다는 사실을 개인적으로 강조했으며 결과적으로 훨씬 일찍 요구 사항을 충족시키는 솔루션을 제공 할 수 있었을 때 원래 추정치를 초과했습니다.

내 윤리는 강박 관념에 접어 들어 코드에 너무 붙어서 리팩토링하고 n도까지 완성하기 전에 발표 할 내용이 거의 없다고 생각합니다. 나는 이것을 깨닫게되어 기쁘지만 어떻게 진도에 만족하도록 태도 / 정신을 바꾸고 정시에 출시 할 수 있습니까?



답변

최고는 선의 적입니다.

항상 더 많은 테스트를 수행하고, 더 나은 문서를 작성하고, 코너 케이스를 제거하고, 누락 된 기능이 있다고 생각되는 것을 채우고, 아키텍처를 더 깨끗하게 만들 수 있습니다. 결코 끝나지 않습니다. 그러나 끝내야합니다. 완료해야하는 기한이 있으며 제품의 완성 된 부분에 따라 외부 제약이 따릅니다. 제품의 작은 부분에서 완벽을 추구하면 제품 전체가 손상됩니다.


답변

우선, 소프트웨어가 예상보다 늦게 릴리스 될 것이 아니라 더 높은 품질의 릴리스 일 가능성이 있기 때문에 더 많은 개발자들이이 문제를 겪기를 바랍니다.

원래의 추정치를 초과하는 경우 추정치의 일부로 “골드 도금”단계를 포함해야합니다. 그들이 당신의 추정치가 아니라면, 아마도 그것들을 공식화하는 데 관여해야 할 것입니다.

어쨌든 릴리스 마감일이 있으면이를 준수해야합니다. “금 도금”은 릴리스를 유지해서는 안되는 최종 단계로 남겨 두어야합니다. 릴리스의 일부로 포함되어야한다고 생각되면 직접 “금 도금”을 추가하십시오 (예 : 근무 시간 외).

당신이해야 할 일은 “골드 도금”단계를 팀 및 / 또는 경영진에게 제기하고 그들이 왜 중요하다고 느끼는지 논의하는 것입니다. 이러한 단계가 도움이된다고 확신 할 수 있으면 향후 릴리스의 일부가되어야합니다.


답변

금도금 소프트웨어

소프트웨어에 대한 설명으로 금도금을 사용한 것을 처음으로 보았을 때 Barry Boehm 은 다음과 같은 근본 원인을 제시했습니다.

금도금. 설계 이전의 고정 된 요구 사항 사양은 소프트웨어 금도금을 장려하는 경향이있었습니다. 사용자는 자신의 요구 사항에 대해 자주 “이 기능이 필요한지 모르겠지만 경우에 따라 지정할 수도 있습니다.”

그의 설명에서, 그는 프로젝트가 사이클 당 하나의 일련의 프로토 타입을 생산하도록 범위가 지정된 스파이럴 소프트웨어 라이프 사이클 모델 을 포함하여 연구에서 설명 된 방법을 사용하는 것이 좋으며 , 나선이 커짐에 따라 완전한 기능을 갖춘 제품입니다. Spiral은 소프트웨어 연구원들 사이에 널리 퍼져 있었고 Waterfall과 Agile의 중요한 다리였습니다. 나선의 중요한 한계는 나선을 돌 때마다 사이클이 길고 비용이 많이 든다는 것입니다.

Agile과 마찬가지로 스파이럴은 팀이 요구 사항을 완료 할 수있을만큼 충분히 좁게 범위를 정하고 프로젝트를 제공 할 수 있도록 일정을 계획하여 금도금을 피하려고합니다. 스크럼과 같은 애자일 방법이 우수한 방법 중 하나는 반복으로 더 이상 시간이 걸리지 않는 시간 동안 스크럼이 스프린트하는 것입니다. 이 논문에서 프로젝트 관리는 개별 개발자보다 금도금에 더 큰 영향을 미치는 것으로 보입니다.

시간 권투를위한 재능

타임 박스를 만드는 것은 매우 중요하지만 이진 기술은 아닙니다. 당신은 그것을 가지고 있지 않거나 부족합니다. 당신은 그것으로 더 좋거나 덜 좋습니다. 그것이 당신의 상사이든 당신에게서 왔든, 아무도 당신이 금도금을 멈출 수 없다고 말하지 않는 것을 선호합니다. 그것은 개인적이고 널리 퍼져 있으며 영구적으로 들립니다.

근본 원인 분석은 여러 문제를 식별하는 데 도움이 될 수 있습니다. 나는 그들이 모두 당신을 가리 키지 않을 것이라고 확신하며, 당신이 정신병자와 함께 일하지 않는 한, 팀의 다른 사람들도 그들의 민첩한 기술을 향상시켜야 할 유사한 요구를 보게 될 것입니다. 문제가없는 사람을 알고 있다면 잘 알지 못합니다. 개선 할 필요가 없다고 생각하는 사람을 알고 있다면 자신을 잘 알지 못합니다.

본인이 파악한 개선이 자신의 인식과 팀의 도움으로 해결할 수있는 것이기를 바랍니다. 그러나 나는 이것이 끝나는 곳이 아니라고 생각합니다. 귀하의 리뷰를 작성하는 감독자 또는 관리자의 기대는 그들이 부하 직원들에게도 성공하도록 코치 할 수 있다는 것입니다. 이는 조직이 계획된 것에서 민첩한 (또는 임시로) 전환하는 등 혁신적인 변화를 겪을 때 특히 중요합니다.

빠르고 더러운 또는 위험 관리 프로토 타입?

작업을 특정 방식으로 수행하도록 요청한 관리자가있었습니다.

빠르고 더럽지 만 아름다움.

그는 이것의 어리 석음을 알고 있었고, 그것은 그의 유머 감각의 일부였습니다. 많은 사람들이 이와 같은 말을하고 심각하게 죽었습니다. 어딘가에는 개선 된 기술이나 접근 방식으로 문제를 완화 할 수있는 절충안이나 기회가 있습니다.

타임 박스에 맞추기 위해 무엇을 희생 할 수 있습니까?

Kent Beck 은 Extreme Programming Explained , 2 판의 1 장에서 빠르게 움직이기 위해 필요한 것에 대해 이야기합니다. 그의 대답은 “고객에게 가치를 창출하기 위해해야 ​​할 일만하면된다”는 것입니다.

위험

같은 책의 첫 번째 판에서 Beck은 다음과 같이 말함으로써 방법을 결정하는 데있어 위험을 통제하는 것에 대한 Boehm의 견해를 좀 더 자세히 설명합니다.

“위험은 소프트웨어 개발의 기본 문제”

두 판에서 Beck은 여덟 가지 일반적인 위험을 나열하고 설명하고 XP (또는 확장, Agile)가 특정 방식으로 각각을 해결한다고 주장합니다. 저에게있어 대부분의 설명은 더 작은 증분을 사용하고 더 빠른 반복을 사용하여 위험을 처리하기에 너무 커지기 전에 과정을 되돌릴 수있게합니다.

충분 성의 정신

Beck은 산악인과 산림 인 에 관한 이야기의 맥락에서 자원을 논의 하고 “충분한 정신”이라는 개념을 소개합니다. 당신 상황의 상황에서 그는 “시간이 충분하다면 어떻게 하시겠습니까?”라고 묻습니다. 책 미리보기로 제공되는이 첫 번째 장만으로 XP (및 기타 민첩한 방법)가 시간과 같은 제약 조건에 대해 어떻게 생각하는지에 대한 많은 음식을 제공 할 수 있습니다.

강박증은 질병이 아니라 증상 일 수 있습니다

몇 년 전 저는 지연에 관한 책을보고 많은 지연이 두려움에서 비롯되었다고 말했습니다. 시작하지 않으면 실수하지 않으며 비판을받지 않을 수도 있습니다. 강박과 완벽주의는 우리의 도덕적 감각이 미루는 것보다 낫다고 말하지만, 아마도 같은 결과를 가져옵니다. 아마도 다른 형태의 지연에 문제가 있다고 생각하십니까?

비판과 경쟁

스크럼과 같은 민첩한 방법론에서 미루거나 비난받을 수있는 기회는 결코 높지 않았습니다. 그것은 악순환입니다. 나는 비난을 받아 미루고, 미루기 때문에 비난을받습니다. 우리는 매일 스크럼 회의를 통해 항상 달성 한 내용을 팀에보고하는 날로부터 하루가되기 때문에 항상 경계합니다.

이상적인 팀에서 Scrum은 매일 미루는 것을 바로 잡을 수있는 기회를 제공합니다. 도움이 도착하기 전에 실수가 커질 시간이 없어야합니다. 팀이 항상 신뢰할 수있는 곳에있는 것은 아니므로 팀 내 리더는 상황을 진전시키기 위해 비판이나 비판에 대한 두려움을 적극적으로 해결해야 할 수 있습니다.

우리의 업무 세계에서 팀의 각 사람은 다른 사람과 경쟁해야합니다. 성과를 위해 일과 영광을 공유하는 팀이 있다고 믿지만, 구성원의 20 %를 보상하고 10 % 이상의 구성원을 처벌하거나 추방하는 연례 성과 관리 프로세스를 사용하는 것은 약간 정신 분열증입니다. 70 %의 대다수가 인센티브없이 최선을 다한다고 주장합니다. WRT 팀워크를 홍보하는 방에 큰 코끼리라고 생각하며, Kent Beck의 이야기를 참조하면 Mountain People과의 깊은 문화적 유대를 보여줍니다.

앞으로 나아가는 길

애자일 팀의 구성원으로서 무엇이 효과가 있는지 연구하고 다른 사람들과 대화하는 것이 좋습니다. 팀에서 도구를 사용하여 단위 테스트를 자동화하기 위해 TDD를 사용하는 경우 가장 잘 수행하는 사람에게 코치를 의뢰하십시오. 상사 나 관리자가 문서 접근 방식에 문제가있는 경우, 자신이 좋아하는 것 또는 누가 좋아하는 방식으로 행동 하는지를 찾아 내고 그들의 접근 방식을 따르십시오. 원시 코딩 속도로 줄어들면 더 빨리 코딩하는 데 필요한 사항을 조사하십시오.

리더는 자신의 문제 (다른 사람이 아닌)에 대한 솔직한 대화, 도움을 제공 및 추적, 팀이 애자일 마린 스타일로 전환 할 수있는 방법에 대한 대화 상자를 통해 원하는 행동을 모델링함으로써 올바른 방향으로 단계를 밟을 수 있습니다 뒤에 남았습니다). 팀의 모든 사람이 같은 능력을 가지고있는 것은 아닙니다. 짝을 이루는 팀원을 탐색하거나 관련된 사람들의 보완 적 강점을 강조 할 수있는 작업과 역할을 할당하는 것이 적절할 수 있습니다. 기술의 성장 또는 개선을위한 계획은 감독자와 부하 직원 모두에게 보람있는 일이어야하지만, 일찍 그리고 종종 효과적이어야합니다.


답변

당신도 재미를 위해 프로그램을합니까? 나는 또한 프로그래밍의 재미를 빼앗아가는 직장에서의 제한에 짜증이 났으며 보상하기 위해 집에서 새 프로젝트를 시작하여 “올바로 수행”할 때도있다. 이 분할을 통해 내 요구와 회사의 요구를 모두 충족시킬 수 있습니다.

또는 업무 외 시간에 작업이 제공 할 수없는 것을 충족시키는 프로그래밍 이외의 새로운 기술을 개발할 수 있습니다. 😉


답변