2010-01-21 11 views
3

제 질문은 직접 코딩 문제가 아닌 개발 팀의 일반적인 워크 플로에 대한 질문입니다. 이러한 유형의 질문이 여기 허용되는지 여부는 알 수 없습니다.작업 스타일에 대한 제안

우리는 다중 브랜드 회사에서 디지털 에이전시와 유사한 브랜드를 만들었습니다. 우리 모두 (현재 4 명)는 프리랜서 경험이 있지만 우리 중 누구도 코딩 표준, 절차, 프로젝트 관리 스타일 등을 갖춘 심각한 개발 팀에서 일하지 않았습니다.

현재 우리는 잘하고 있습니다. 그러나 우리는 일하는 방식을 개선해야한다고 절대적으로 생각합니다. 왜냐하면, 우리는 단지 마감일을 잡습니다. 심지어 대부분의 경우 마감일을 놓치거나 프로젝트의 멋진 측면에서 벗어날 수 있습니다. 우리가 열심히 노력하고 있지만, 우리는 거의 성취하지 못합니다.

이제 감독자가 개선하지 않는 이유에 대해 정당하게 질문 할 수 있습니다. 사실, 우리는 이상한 그룹입니다. 아니면 적어도 그렇게 생각합니다. 우리는 우리 자신의 상사입니다. 대부분의 경우, 아무도 우리에게 지시 또는 명령을 제공하지 않으며 우리가 원하는 모든 것을 자유롭게 할 수 있습니다. 이제 내가 그들에게 가서 내가 가진 소동에 대해 이야기하기 전에, 나는이 일을 올바르게하는 몇 가지 방법을 배우고 싶습니다. 아니면 다른 사람들이 그것을 어떻게하고 먼저 적용하려고 하는지를 배우고 싶습니다.

죄송합니다. 계획보다 긴 메시지입니다.

미리 감사드립니다. 나는 단순히 링크에서 당신을 가리 키도록 미워하는 동안

+0

아마도 당신은 할 수있는 일의 양을 과대 평가하고 있습니까? –

+0

무엇을 구체적으로 개선하고 싶습니까? 특정 날짜에 무엇을했는지 예측할 수있는 능력? 또는 다른 것? –

+0

@Anon : 아마도. 저는 때때로이 생각에 빠지 긴하지만 상사는 항상 우리가 할 수있는 것을 우리에게 납득시킬 방법을 찾습니다. – frbry

답변

1

아직 코딩 표준이 없으면 제안 할 것입니다. 이렇게하면 코드를 더 쉽게 공유 할 수 있으며 각 코드를 해독하는 것보다 기능에 더 많은 시간을 할애 할 수 있습니다. 사용하는 언어는 언급하지 않지만 유사한 프로젝트에서 하나를 빌려 자신의 필요에 맞게 조정할 수 있습니다. 다른 사람들의 코드로 작업하는 경우이 작업을 유연하게해야 할 수도 있습니다.

저는 민첩한 방법론, 특히 당신과 같은 작은 동기 부여 된 팀에서 매우 좋은 경험을 가지고 있습니다. 기능 목록을 보유하는 것이 중요합니다. 그러면 가장 위험한 프로젝트 및 프로젝트에서 가장 중요한 작업에 집중하고 싶을 것입니다. (본능은 종종 우리에게 더 쉬운 일로 시작됩니다. 결국 나쁜 것).

기능을 작은 작업으로 분할하여 그룹으로 수행하면 작업이 어떻게 완료 될지 명확히 알 수 있습니다.더 작은 작업을 평가하는 것이 더 쉽습니다. 포커 팀에서는 미숙 한 팀이 있어도 팀이 더 나아질 때마다 최고의 견적을 제공했습니다. 모든 사람이이 과정에 참여해야하며, 특히 많은 것을 배우는 중학교 사람들이 있어야합니다.

코드가 서로의 코드를 검토하면이 방법을 많이 배우게되고 디버깅 시간을 절약 할 수 있습니다. 이것은 매일 한 번씩 한 짝을 이루어 할 수 있으며 그룹 코드 검토에 가장 큰 어려움을 가져옵니다.

열심히 노력하면 열심히 일하는 진정한 해결책이며, 인내심이 중요합니다.

1

는 소프트웨어 개발 방법론에서 다음 위키 백과의 문서

http://en.wikipedia.org/wiki/Software_development_methodology

당신은 당신이 가지고있는 경험의 수준을 언급하고 동안하지 않는 훌륭한 출발점이 될 것입니다 많은 정보가 여러분에게 주어질 수 있습니다. Extreme 프로그래밍, Agile 등과 같은 현재의 방법론에 대한 추가 정보에 대한 링크를 제공합니다.이 정보는 프로젝트 관리를 향상시킬 수있는 방법을 찾을 때 유용하게 쓰일 수 있습니다./팀 내의 개발 관행.

+0

먼저 감사드립니다.모든 링크는 어디서부터 시작해야할지, 무엇을 검색해야 할지를 알지 못하기 때문에 현재로서는 나에게 좋은 출발입니다. – frbry

1

나는 당신이 민첩한 방법론 (http://en.wikipedia.org/wiki/Agile_software_development) (예 : scrum.Your)을 살펴 봐야한다고 생각한다. 당신은 4 명으로 구성된 작은 팀으로 서로의 힘과 능력을 알기 때문에 모든 유형에 대해 매우 유용 할 수있다. 프로젝트 관리.
대부분의 사람들이 처음 개발 (< 1 년 경험) 한 작은 팀에서 일하면서 민첩한 경험을 쌓은 애자일은 매우 작은 학습 곡선을 가졌으며 우리는 스크럼과 XP와 같은 다양한 민첩한 방법론을 사용하여 우리의 효율성을 크게 향상시키고 마감일을 지키는 데 도움이되는 일을합니다.
감사합니다.
Shivam

2

처음에는 "매우 무책임한"하지만 그럼에도 전설적인 Joel Test을 사용하여 팀을 평가하는 데 10 분 미만의 시간을 소비하는 것이 좋습니다.

주어진 시점에서 계획하고 수행 한 작업량에 대한 좀 더 강력한 개요가 필요하고 팀 기능에 대한보다 현실적인 시각이 필요합니다. 사용하기 쉽고 배우기 쉬운 프로젝트 관리 소프트웨어는 좋은 출발점이 될 수 있습니다.

이와 같이 FogBugz는 훌륭합니다. 견적과 실제 시간을 추적 할 수 있으므로 적어도 시도해 보는 것이 좋습니다. 그리고 나는 어떤 식 으로든 Joel과는 관련이 없습니다.

2

민첩한 방법론을 완전히 포용하지 않아도 일부 아이디어가 도움이 될 것으로 생각합니다. 예를 들어.

  • 모든 사람들이 그 일 동안 할 것입니다 무엇을 명확 & 유형 목표에
  • 목표로
  • 가지고 짧은주기 (예를 들어 이주) 전에 일을 수행 있었는지 알 수 있도록 초기 스탠드 업을 수행 a는 과정 "배달을 개최"
  • 프로세스 초기 테스트 주도 개발을위한
  • 목표에
  • 통합하십시오 고객의 피드백, 쓰기 시험없이 작성하지

이 방법으로는 효과가 없을지라도, 어떤 것을 개선하기 위해서는 어떤 프로세스를 채택해야합니다. 진짜 실수는 그들 모두를 채택하지 않는 것입니다.

유기적으로 성장함에 따라 작동하는 것, 그렇지 않은 것 등을 찾을 수 있습니다. 맹목적으로 어떤 방법론도 따르지 마십시오.