왜 우리는 아무것도 할 수 없습니까?

저는 중소 기업의 소규모 팀에서 일하며 대부분은 소프트웨어 개발에 관여하지 않습니다. 저는 가장 경험이 적은 최신 개발자이며 시작하기 전에 소프트웨어에 대한 전문적 또는 학문적 배경이 없었지만, 내 의견이 얼마나 존중되는지에 매우 만족하며 경력 초기 단계에서 진지하게 받아 들여진 것에 대해 감사합니다.

그럼에도 불구하고, 나는이 많은 양의 방송으로 더 많은 일을해야한다고 생각합니다. 팀으로서 우리는 일을 처리하는 데 어려움을 겪고있는 것 같습니다. 나는 상황을 개선하기 위해 무언가를 제안하고 싶습니다. 그것이 좋은 생각이라면 들었을 것이라고 생각하지만, 제안 할 것이 없어지고 있습니다.

내가 문제라고 식별 할 수있는 것은 다음과 같습니다.

• 당면한 과제의 명세는 드물다. 이것은 부분적으로 관리가 병목 현상이고 우리가 원하는만큼 세부적인 요구 사항을 해결할 수있는 돈이나 인력이 없기 때문입니다. 또한 우리가 개발하고있는 소프트웨어가 조사 적이며 그 효과가 입증되고 입증 될 때까지 정확한 방법이 명확하지 않기 때문이기도합니다.
• Lead Dev는 자신이 '프로토 타이핑 (prototyping)'이라고 부르는 것을 매우 좋아합니다. 많은 경우에 그가이 운동에서 어떤 결과가 나올지 분명하지 않습니다. 그런 다음 '실제'구현은 프로토 타입을 작성하는 데 좋은 연습이 너무 많은 시간이 걸린다는 주장으로 인해 어려움을 겪습니다. 나는이 꼬인 논리를 풀기조차 시작하지 않았으며 시도하고 싶지는 않습니다.
• 모델러는 원하는 방법론에 대한 모든 것을 정확하게 자세하게 알려줄 것으로 예상되며, 이론적으로 완벽하다는 사실을 전적으로 신뢰합니다. 이것은 사실이 아니지만이 상황을 바로 잡기위한 조치는 없습니다. 모델링 측면의 어느 누구도 행동 할 가능성이있는 구조화 된 방식으로 문제를 제기하거나 모범 사례를 적용하기위한 지침을 찾지 않습니다. 그들의 수동성에 대해서는 아무것도 이루어지지 않았습니다.
• 나는 이전에 팀에 TDD를 푸시하려고 시도했지만 새로운 것이 어려워서 내 일을 감독하는 사람들이 그것을 기꺼이 용인했지만 다른 사람에게는 열의가 없었습니다. 나는 기능을 마무리하고 마무리하지 않는 데 걸리는 시간을 정당화 할 수 없기 때문에, 그 아이디어는 당분간 포기되었다. 나는 아무도 자신의 일을하는 방법을 듣고 싶어하지 않기 때문에 다시 데리러 가지 않을까 걱정하고 있습니다.
• 우리는 이제 지속적인 통합 서버를 가지고 있지만 대부분 여러 시간 회귀 테스트를 실행하는 데만 사용됩니다. 전체 커버리지 단위 및 통합 테스트를 실행해야한다는 것은 아직 공개되지 않았지만 현재 아무도 아무도 작성하지 않습니다.
• Lead dev로 품질 문제를 제기 할 때마다 '기능 A 테스트는 간단하고 기능 B는 사용자에게 훨씬 중요하지만 테스트하기가 어렵 기 때문에 기능을 테스트해서는 안됩니다. ㅏ'. 다시 한번 나는이 논리를 풀려고 노력하지 않았다.

.... 조우. 내가 그렇게 말하면 생각보다 훨씬 나빠 보입니다. 나는 그것이 도움이되는 외침이라고 생각합니다.

잠시 악마의 옹호자를하자 :

현재 진행중인 작업의 사양은 드물다 ... Lead Dev는 그가 '프로토 타이핑'이라고하는 것을 매우 좋아한다

리드 개발은 사양이 희박 하기 때문에 프로토 타이핑을 좋아 합니다. 이것은 아마도 좋은 것입니다; 이것이 반복 상점이 작동하는 방식입니다.

모델러는 원하는 방법론에 대한 모든 것을 정확하게 자세하게 알려줄 것입니다

반복 상점에서는 작동하지 않습니다. 반복 개발의 본질은 요구 사항이 불완전하다는 것입니다. 반복은 요구 사항을 해결하기 위해 필요한 것입니다.

이전에 팀에서 TDD를 푸시하려고 시도했지만 새로운 것이 어렵습니다.

이것도 작동하지 않습니다. 전도하기 전에 기술을 이해해야합니다. 또한, 스캔 요구 사항이 반복적 인 상점에서는 TDD가 너무 많은 오버 헤드 일 수 있습니다. 적절한 단위 테스트 범위를 장려하는 것이 좋습니다.

우리는 이제 지속적인 통합 서버를 가지고 있지만 대부분 여러 시간 회귀 테스트를 실행하는 데만 사용됩니다.

작고 반복적 인 상점에서 적절할 수 있습니다.

Lead dev로 품질 문제를 제기 할 때마다 '기능 A 테스트는 간단하고 기능 B는 사용자에게 훨씬 중요하지만 테스트하기가 어렵 기 때문에 기능을 테스트해서는 안됩니다. ㅏ'

상점에 시간 제약이있는 것 같습니다. 좋든 싫든 그 제약 조건에 구속됩니다.

또한 소프트웨어 업계의 일원이 시장에 물건을 가져 오는 것보다 "올바른 방법"을하는 것을 중요하게 생각하는 것 같습니다. 버그가있는 소프트웨어를 시장에 내놓는 최초의 제품이 종종 승자가된다는 점을 제외하고는 아무런 문제가 없습니다. 공평하지는 않지만 그렇게되어 있습니다.

여기서는 프로토 타이핑에 집중하겠습니다

프로토 타입의 주요 문제는 개념 증명의 의미로 사용됩니다.

그러나 프로토 타입을 더 이상 빌드 할 수없고 최종 제품을 처음부터 다시 빌드해야하는 경우 프로토 타입을 빌드하지 않았을 수 있으며 프로토 타입을 작성하는 데 시간을 낭비한 것입니다

귀하의 팀에게 조언하는 것은 프로토 타입의 품질과 유연성을 얻는 것입니다. 처음에는 완벽한 물건을 만들 수는 없지만 향후 요구 사항에 따라 확장 성을 유지하려고 노력합니다.

이것들이 좋은 답변입니다. 나는 단지 "의사 소통을 시도하는 것"이 ​​최선의 제안이라고 덧붙일 수있다. 조직의 작동 방식에 변화가 생기지 않습니다. 그것이 일어날 때 그것은 종종 조수와 같으며, 운동량은 아래에서 그리고 위로부터 쌓입니다. 따라서 기대치를 낮게 유지하고 상황이 어떻게 진행 될지 말할 때까지 기다리거나 다른 조직과의 협력을 기대하면 더 행복해질 것입니다.

그렇다면 회사에서 "이를 얻는"사람을 확인한 후이 사람을 사로 잡아 가능한 많은 사람에게서 배우십시오. 그렇지 않다면 시간을내어 스스로 학습하고 성장하기 시작하고 (오픈 소스 프로젝트에 참여하거나 자신의 프로젝트를 시작) 성장을 촉진 할 수있는 곳을 찾으십시오.

일어날 수있는 최악의 일은 당신이 거기에 머물러서 잘못된 일을하는 법을 배우는 것입니다. 그렇습니다. 실용주의가 필요하지만, 진정한 숙련 된 팀은 올바른 방법으로 일을 수행 할 수 있으며 여전히 양질의 제품으로 정시에 할 수 있습니다. 현재 팀에 필요한 것이 없기 때문에 새 팀을 찾기 시작해야합니다.