굶주린 개발 팀과 어떻게해야합니까? [닫은]

10

특히 개발자가 늦는 경우 일반 개발자로서 중요한 길을 가고 있습니다. 선임 개발자 인 경우 팀이 리더십을 찾고 있다면 더 나쁩니다.

대부분의 팀에 대한 작업이 중요한 부분을 기다리며 실속되면 나머지 팀은 어떻게해야합니까? 우리는 중요한 부분에 대한 접근이 제한되어 있으므로 다른 사람들이 우리가 무엇을하든간에 기다리고 있습니다. 다른 사람들이 무엇을해야하는지에 대한 조언을 구할 때 좋은 대답은 무엇입니까?

team team-leader project-planning

— 설탕에 절인 _ 오렌지
소스

10

지불해야 할 기술 부채가 없습니까? 앞으로 스파이 기능을 사용할 수있는 기능이 있습니까? 기존 기능 내에서 시도하고 싶은 새로운 기술이나 패러다임?

— jonrsharpe

27

@StudentT 차단기가 해결되면 팀을 다시 세우는 데 어려움을 겪을 수 있습니다.

— jonrsharpe

8

@StudentT 오히려 미래를 계획하지 않기 위해 리더를 해고해야합니다.

— jwenting

13

굶주린 개발자? 한마디 : 피자.

— 메이슨 휠러

3

OP가 지불해야 할 기술적 부채가없고 쓰기 / 개선 할 단위 / 기능 테스트 또는 배포 스크립트가 없는 경우 Deaven (Dev Heaven)에게 확실히 불만을 표시하고 갑자기 슬퍼합니다. <

— xDaizu

29

단위 테스트, 기능 테스트, 문서, 도구 등을 향상시킵니다. 중요한 경로를 따라 잡을 때까지 다운 타임을 수행 할 수있는 많은 것들이 있습니다.

— Maybe_Factor
소스

2

이. 평균 개발자 (포함)는 지속적으로 개선 할 시간이 부족하다는 소리를냅니다. 그들을 잡아라.

— Traubenfuchs

4

나는 "일반적으로 당신이 얻지 못한 것을하라"는이 일반을 좋아한다. 코드 리뷰와 리팩토링을 추가하겠습니다. 기름칠이 잘 된 기계처럼 작동하고보기 좋은 즐거움을주는 정말 깔끔한 소프트웨어입니다. 그것은 개발자들에게 만족 스럽습니다.

— 피터-복원 모니카

전에해야 할만큼 중요하지 않은 일들은 아마도 지금 할 가치가 없을 것입니다. 그것의 '일하기'

— Ewan

16

테스트, 문서화 등의 개선에 대한 답변이 마음에 들지만 다음과 같이 볼 수도 있습니다.

중요한 경로 구성 요소를 지원하면 팀 / 버디 프로그래밍이 더 빨라 집니까?
중요한 구성 요소를 모두가 작업 할 수있는 여러 하위 구성 요소로 재구성
기본적으로 동일한 작업을 수행하지만 생산에 충분히 빠르지 않은 거친 부품으로 중요 부품을 더미로 만듭니다.
중요한 구성 요소에 대한 API를 설정하고 다소 수정하고 해당 구성 요소에 대한 기본 기능을 구현하는 데 도움이됩니다 (구현 변경에 따라 다르지만 API는 아님).
기능이 "현재 충분"한 나머지 시스템에서 작동하기 위해 알려진 알려진 문제가있는 중요한 버전의 초기 버전을 사용할 수 있는지 확인하십시오.

또한 이러한 중요한 구성 요소를 개발 프로세스 초기에, 아마도 팀의 나머지 팀이 모이기 전에 시작해야한다는 것을 기록하여 "레슨 학습"단계를 시작하는 것이 좋습니다.

— 스티브 반스
소스

2

나는 "항상 개선해야 할 것이있다"는 대안을 좋아한다. 그것들이 충분히 좋으면 현재 문제에 집중하고 적절한 해결 방법을 찾는 것이 좋습니다.

— Walfrat

15

늦은 배송을위한 백업 계획이 필요합니다

중요한 부분이 이미 늦었다면 더 이상 미끄러지지 않을 것이라는 보장은 없습니다. 그럼 뭐야? 당신은 영원히 기다립니다? 그것은 상급 경영진에게 말하려는 답변이 아닙니다.

시뮬레이터 구축

위험을 관리하는 한 가지 방법은 시뮬레이터에서 작업을 시작하는 것입니다 (하네스, 심, 스터브, 호출하려는 모든 것)는 누락 된 중요한 부분을 대신합니다.

정의 된 인터페이스가 있습니까? 그것을 구현하십시오.

자세한 문서가 있습니까? 최선을 다해 모방하십시오.

누군가의 아이디어일까요? 프로토 타입을 얻을 수 있는지 확인하십시오.

그런 다음 다시 일정을 잡을 때 ...

이렇게하면 일정이 다시 미끄러질 때 백 포켓에 에이스가있어 차이를 막을 수 있습니다. 팀의 차단을 해제 할뿐만 아니라 (시뮬레이터와 통합 할 수 있음) 귀중한 소프트웨어 자산을 얻게됩니다.

일정이 훨씬 더 단축되면 시간을 사용하여 자동 통합 테스트 를 작성 하십시오 (현재 시뮬레이터에 대해). 그렇게하면 실제 제품을 제공 할 때 테스트를 실행하고 모형과 결과물 간의 동작 차이를 탐지 할 수 있습니다. 이를 통해 수정해야 할 지점을 제로로 만들 수 있습니다. 보너스로, 시간이 다했을 때 코너를 얼마나 많이 자르는 지 빠르게 알 수 있습니다.

— 존 우
소스

시뮬레이터는 완벽하거나 환상적 일 필요는 없으며 진행할 수있을 정도로 충분합니다.

— Thorbjørn Ravn Andersen

1

나는 이것이 매우 건전하고 즉각적인 조언이 아니라고 생각합니다. 특히 코딩 이상의 관점, 즉 테스트. 모의는 두 배의 가치입니다.

— 피터-복원 모니카

4

중요한 구성 요소에 알려진 인터페이스가 있고 짧은 시간 내에 완료 할 희망이 없다면 테스트를 두 배로 구축하지 마십시오 (예 : mock )?

테스트 결과가 약간 덜 중요하지만 팀은 코딩을 계속할 수 있습니다.

— 크리스토프
소스

2

명백한 "지금까지 수행하지 않은 모든 작업을 수행하십시오"외에도, 프로젝트와 관련이없는 작업을 수행 할 마음의 평화가 부족한 것 같습니다. 이해할 수는 있지만 도움이되지 않습니다.

따라서 실제 문제는 완화 될 수 있습니다. 나는 무관심한 말이 아닙니다. 당신의 책임, 당신이 도울 수있는 일에 대해 자긍심을 갖고 시간이 남으면 그것을 즐기십시오. 항상 발가락에있을 필요는 없습니다. 당신이 지도자라면, 나는 이것이 당신의 메시지가되어야한다고 말합니다. 긴장을 팀으로 이전해도 더 생산적인 팀이되지는 않습니다.

— 마틴 마트
소스

0

어떤 방법론을 사용하고 있는지 정확하게 말하지 않는 것은 아닙니다.

차단제가있는 경우 내가 일하는 곳에서 개발을 촉진하기 위해 가능한 모든 일을하는 것은 펌프의 손입니다.

리드가 너무 많이 취해서 당신에게 더 넓은 문제가 있는지 고려하십시오. 그렇습니다. 사람들이 기술 리더십을 요구할 것입니다. 그러나 이것이 더 유능한 팀원 중 일부가 멘토링을받는 경우 워크로드를 공유 할 수 없다는 것을 의미하지는 않습니다.

이것 외에, 그들이 앞으로 나아갈 수있는 다른 중요하지 않은 작업이 있습니까? 또한 완료 한 작업 (리팩터링, 기술 부채 제거, 문서화, 테스트 추가 등)이 있습니까?

실제로 아무것도 없다면 로그, 빌드, 문서, 테스트 계획, 디자인, 다이어그램, 의제 작성, 회의 준비, 브라운 백 세션 개최, 지식 공유 등을 통해 무언가를 제공하십시오. 항상 해야 할 일이 있습니다. 사람들이 기꺼이 회사 동전에 아무것도하지 않고 앉아 있다면 분명히 팀 선수가 아니기 때문에 에스컬레이션해야합니다.

— 로비 디
소스