금도금 소프트웨어

소프트웨어에 대한 설명으로 금도금을 사용한 것을 처음으로 보았을 때 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를 사용하는 경우 가장 잘 수행하는 사람에게 코치를 의뢰하십시오. 상사 나 관리자가 문서 접근 방식에 문제가있는 경우, 자신이 좋아하는 것 또는 누가 좋아하는 방식으로 행동 하는지를 찾아 내고 그들의 접근 방식을 따르십시오. 원시 코딩 속도로 줄어들면 더 빨리 코딩하는 데 필요한 사항을 조사하십시오.

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

---

답변