내가 만난 적이없는 사람들과 프로그래밍하기

AP 컴퓨터 과학 수업에서 그룹 프로젝트를 배정 받았으며 다른 세 사람과 함께 일해야합니다. 나는 이전에 그들과 이야기 한 적이없고, 그들의 기술 수준을 모른다. 내가 가진 모든 것은 그들의 이메일 주소이다. 과제는 다음과 같습니다.

"한 팀으로서 최소한 3 개의 모듈을 한 클래스에 완료해야합니다."

그들 중 누구도 서로 연락을 시도하지 않았지만 궁금한 점이 있기 때문에 "팀 주장"이 되려고합니다. 어떻게해야합니까? 나는 그들에게 이메일을 보내고 서로에게 이메일을 보내는 것보다 선호하는 의사 소통 방법이 있는지 물었지만, 실제로 프로젝트를 시작하면 누가 무엇을하고 있는지 알아 내야합니다.

어떻게해야합니까? 내가 만난 적이없는 세 사람을 어떻게 "책임"하고 이끌 수 있습니까?

실제 과제는 다음과 같습니다.

따라서 일주일 초에 각 팀 구성원이이 프로젝트에서 수행 할 다양한 역할에 대해 논의해야합니다. Pronto (또는 Blackboard IM), 이메일, Wiki, Google 그룹, 블로그 또는 기타 적합한 방법을 통해 커뮤니케이션 할 수 있습니다. 그룹 구성원이 주말까지 그룹에 참여하지 않으면 강사에게 알리면 추가 지침을 제공 할 것입니다.
...
또한 프로젝트가 끝나면 각 팀 구성원이이 프로젝트 완료에 대한 기여도와 제안 된 등급을 평가하는 팀 평가가 제공됩니다.

편집 : 많은 사람들이 내가 커피 숍이나 그와 비슷한 것을 만나기를 제안했습니다. 문제는 우리 모두가 다른 주에 있다는 것입니다. 나는 또한 그들 중 하나가 Facebook / Skype / Twitter를 사용할 수 없다는 것을 알았으므로 야후 메신저와 이메일을 통해 메시지를 보내야합니다.

이 프로젝트의 리더가 될 것이다 단계까지와 담당하는 사람 시작 부분에.

이것은 소프트웨어 개발뿐만 아니라 인생의 대부분의 것들에 적용됩니다. 다른 사람들이 더 머리를 통해 일을 생각 앞으로 단계와, 말하는 사람과 닭처럼 주위를 실행하면 " 이것은 우리가하려고했던 것입니다이 어떻게 우리가 그것을 할 겁니다 ." 일반적으로 프로젝트의 나머지 부분에서 리더로 여겨지는 사람입니다. 이 작업을 수행하면 프로젝트의 궁극적 인 성공 또는 실패에 대한 책임이 있음을 명심하십시오.

이 프로젝트를 이끌고 싶습니까? 큰 영향을 미치기 위해 바로 시작할 수있는 몇 가지 작업이 있습니다 .

1. Trello 와 같은 프로젝트 관리 도구를 사용하여 모든 사람에게 초대를 보내고 프로젝트의 일부를 사람들에게 할당하기 시작하십시오.
2. 버그 데이터베이스를 생성하고 작업 및 버그 추가를 시작하십시오. 다시 할당을 시작하십시오.
3. 버전 제어 저장소를 설정하고 모든 사람이 작업 할 수있는 좋은 초기 코드를 체크인하십시오. 다른 형태의 코드 제어를 다루지 마십시오.
4. 버전 관리 시스템과 버그 데이터베이스를 사용하는 방법을 보여줌으로써 사람들이 개발을 시작할 수 있도록 도와줍니다.
5. 프로젝트 상태 및 이전주의 진행 상황을 설명하는 주간 이메일을 발송하십시오.

이러한 단계 중 어느 것도 특히 어렵거나 시간이 많이 걸리지는 않지만 도로에서 시간을 크게 절약 할 수 있습니다 . 또한 팀이 서로 대화하고 담당자를 만나는 데 익숙해집니다.

Jarrod Nettles의 답변은 내가 제안 할 내용을 많이 요약 한 것이므로 비슷한 상황에서 최근의 경험에서 효과가 있었던 부분을 던져 보겠습니다.

이메일이 아닌 음성으로 대화 할 수있는 방법을 찾는 것이 좋습니다. 같은 지역에 있지 않다면 모두 Skype에서 구입하십시오. 당신이 그 지역에 있다면, 커피 숍이나 무언가에서 그들을 만나십시오. 첫 만남에서 직접 이야기하면 실제로 의사 결정을 내리고 그 때와 거기서 작업을 수행하게됩니다. 수줍음이 많거나 컴퓨터를 자주 사용하지 않는 사람들은 전자 메일 스레드를 통해 프로세스를 보류 할 수 있습니다. 우리 모두 게으른 학생이 될 수있는 방법을 알고 있습니다!

첫 만남에서, 나는 프로젝트를 시작하려고 시도하는 것에 대해 당신의 그룹을 알게하려고 노력하지만 프로젝트를 무시하지 마십시오! 얼음을 깨는 데 10 ~ 20 분은 아마 4 명 정도면 충분할 것입니다.

이 프로젝트에 대해 이야기에 올 때, 나는 무엇을 통해 실행 제안 이 프로젝트가 포함 생각합니다. 나는 이것이 당신의 이해라는 것을 분명히하는 것이 중요하다고 생각하며, 당신이 그들에게 정확히 무엇을해야 하는지를 말하는 것은 아닙니다. 모든 사람들은 자신의 생각과 아이디어가 있다면 반지에 던질 수 있어야하며, 그룹으로서 프로젝트가 수반한다고 느끼는 것을 충분히 이해하면서 그 초기 회의에서 벗어나야합니다.

향후 (정규) 회의에서는 프로젝트의 다른 부분을 더 자세히 볼 수 있습니다. 정확히 무엇을해야하는지, 필요한 자원과 시간이 얼마나 필요한지, 누가 무엇을 할 수 있는지 살펴보십시오. 필요한 경우 조각을 더 나눕니다. 어쩌면 약간의 마감일을 정해보십시오.

온라인에서 한 번도 만나지 못한 사람들과 함께 일한 경험이 있습니까? 직접 만나지 않고 함께 프로젝트를 완료해야합니까?

마케팅을 통해 예산 부족, 어리석은 마감일 및 강물을 팔아 올리는 것은 실제 소프트웨어 개발 프로젝트의 약 65 %에 해당합니다.

일방적으로 책임을 맡고 업무를 배정하는 대신 관심있는 부분에 대해 사람들이 자원 봉사하도록하는 것이 가장 좋습니다. 그들은 모두 책임을 져야 할 방법에 대해 생각하고있을 것입니다. 또는 그룹 활동에 너무 많은 관심을 가진 불쌍한 잔디를 어떻게 구할 수 있을까요?

이와 같은 경우에 가장 먼저해야 할 일은 이슈 트래커 를 설정하고 사용 방법을 배우는 것입니다.

설명하는 것처럼 개발을 처리하는 방법에 대한보다 근본적인 소개를 위해 Martin Fowler의 기사 인 Offshore Development와 함께 Agile Software Process 사용을 참조 합니다. 이 기사에서는 분산 팀 커뮤니케이션 설정의 기본 및 고급 개념을 간략하게 설명합니다.

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

프로젝트를 위해 당신은 거기에 언급 된 모든 팁과 트릭을 따를 수는 없습니다 (예 : 대사 또는 연락 방문이 없을 것입니다).하지만 어쨌든 공부할 가치가 있습니다.

• 위의 모든 것을 가진 많은 팀에게는 확실히 과잉 일 것입니다. 그럼에도 불구하고 건너 뛴 항목도 확인하고 거부 사유를 명확하게 문서화하기 위해 이와 같은 포괄적 인 체크리스트를 작성 하는 것이 정말 도움이된다는 점을 발견했습니다 .

당신은 이것에 대해 얼마나 많은 시간을 가지고 있는지, 또는 당신이 일하고있는 언어를 우리에게 말하지 않았습니다.

우선, 모든 비용으로 작동하는 제품을 구입하십시오.

프로젝트가 2 주 이하로 지속되는 경우, 귀하가 유일하게 일을하고 있고 귀하가 얻는 도움에 매우 만족한다고 가정하십시오. 모든 사람을 위해 일정을 잡으십시오. 그러나 아무 것도하지 않으면 여전히 작동하는 제품이 있는지 확인하십시오. 누군가가 무언가를하더라도 계속 의존하지 말고 언제라도 누군가가 빠져 나갈 수 있도록 준비하십시오.

일주일 이상인 경우 제품을 마일스톤으로 표시하고 가능한 한 그에 충실해야하는 요일을 예약하는 것이 좋습니다. 당신이 쫓아 낼 수있는 무언가가 있는지 확인하고 부족한 점을 확인하십시오 : 최악의 상황이 최악의 경우, 이것이 당신이 맡은 일이 될 것입니다. 당신이 만드는 각각의 일, 당신은 당신이 일을 얼마나 많이 향상시킬 수 있는지, 당신이 갈 수 있도록 동기를 부여 할 것입니다 의 위에. 너무 멀리 계획하지 마십시오. 물론, 당신은 무엇을 끝내게 될지에 대한 아이디어가 필요하지만 가장 구체적인 계획은 단기적으로 유지해야합니다.

그 두 가지가 약간 겹친다는 점에 주목하십시오 .2 주가 2 번의 반복을 끝내는 것이 어려운 회색 영역이기 때문에 의도적입니다.하지만 한 번만 반복하면 위험합니다.

나는 프로그래밍을 처음 접하는 사람들과 함께 일할 최악의 경우를 가정합니다. 내 일반적인 조언은 다음과 같습니다.

• 곧 구현할 기능과 그 기능을 수행 할 기능 목록을 유지하십시오. Jarrod는 Trello를 제안했으며, 전적으로 다음과 같이 지원합니다. 팀원이 경험이 많지 않으면 많은 도움이 될 것입니다. 버그를 유지하려고 할 수도 있습니다.
• 4 명으로 구성된 팀에서는 버전 관리가 필요합니다. 다른 사람들이 일하는 법을 모른다면 기여하기를 꺼려 할 수도 있지만 그만한 가치가 있습니다.
• 외부 의존성으로 인해 초보자를 두려워 할 수 있습니다. 단위 테스트를 작성하는 경우 사람들에게 테스트 중단에 대해 걱정하지 않아도된다고 말합니다. 사람들에게 특히 처음에는 빌드를 깨는 것에 대해 걱정하지 않아도된다고 말합니다. 버그가있는 코드를 저지르는 사람보다 코드를 저 지르지 않는 사람을 수정하는 것이 훨씬 어렵습니다.
• 여기에 제안 된 사항이 실제로 적용되는지 확인하십시오. "연속 통합"은 소규모 프로그램의 경우 "이 프로그램이 실행되고 모든 기능을 사용할 수 있음"을 의미하는 멋진 용어입니다. 사이트가 있습니까? 팀으로 나누는 것이 도움이됩니까?
• 야 그니, 백 번 이상 정말로해야한다면, 스스로 만들 기능에 대해 미리 글을 쓰십시오. 작동하게 한 다음 리팩터링하십시오. 그렇지 않으면 작동하지 않습니다.
• 리 팩터 작동하면 시간을내어 수정하십시오. 팀원들도 코드를 읽어야한다는 것을 잊지 마십시오. 추악한 부분을 수정하고 간단한 솔루션을 더 나은 성능으로 바꾸는 데 하루가 낭비되지 않습니다.
• 모든 부분을 주시하십시오. 변경 기록을 훑어 보거나 때때로 다른 사람의 코드를 읽으면 모든 것이 당신이 시행해야한다고 생각하는 품질 표준에 부합하고 사람이 빠져 나가는 데 어려움을 겪지 않는지 확인하는 데 도움이됩니다.
• 지정된 것과는 반대로 가장 중요한 일을 주저하지 마십시오. 누군가 일정이 늦어지면 어딘가에 메모 해두고 직접 작성하십시오. 먼저 물어보십시오. 대답하지 않거나 한두 번 물어 본 후에도 여전히 그렇게하지 않을 것 같은 느낌이 든다면 계속하십시오.
• 당신이 자랑스럽게 생각하는 것에 집중하십시오. 과제에서 벗어난 경우에도 마찬가지입니다. 더 부드러운 것을 만들기 위해 큰 기능을 잘라야하는 경우에도 마찬가지입니다. 모든 반복은 "이것이 자랑 스럽습니까?"라고 생각하고 다음 반복에서는 그 문제를 해결하려고 노력하십시오.

최근에 끔찍하게 실패한 프로젝트가있었습니다. 원하는 경우 실패한 이유에 대한 내 생각 을 읽을 수 있지만, 다른 기회가 있다면 어떻게 이런 일을했는지 ​​요약합니다.

Jarrod Nettles의 답변이 좋습니다. 나는 이것을 추가 할 것이다 :

1. 다른 세 사람 중 최소한 한 명은 완전히 쓸모가 없을 것으로 예상하십시오.
2. 대부분의 (또는 모든) 일을하고 있다고 느끼지만 모든 사람이 동등한 신용을 얻게된다는 사실 만 인정하십시오. 물건을 "공정하게"만들려고 시도하면 불필요한 충돌이 발생하고 속도가 느려집니다.
3. 좋은 팀원들과 연락을 유지하십시오. 그러한 사람들은 찾기가 어렵 기 때문에 다시 일하기를 원할 것입니다.

나는 많은 사람들이 있다고 확신하면서 몇 번 비슷한 위치에 있었다. 가장 중요한 것은 모든 사람을 만족시키고 행복하게 유지하기 위해 최선을 다하는 것이므로 위에서 언급 한 사람과 마찬가지로 팀 리더의 임무를 수행하는 것이 좋습니다. 다른 사람처럼 조심스럽게 접근해야합니다. 대신에 일을해야한다고 느낄 수도 있습니다.

나는 당신이 서로 연락하기 위해 스스로를 취한 사람은 없다는 것을 알고 있지만 때로는 당신이 만난 적이없는 사람들과 일하고 있고 의사 소통하기가 어려울 수있는 것처럼 사람들에게는 이러한 상황이 어려울 수 있습니다.

저는 모든 사람에게 이메일을 보내서 프로젝트를 어떻게해야한다고 생각 하는지를 사람들에게 알리고 역할, 목표, 마감일, 의사 소통 시간, 모임을 책임지고 프로젝트를 이끌고 싶다고 알리도록하겠습니다 ( 원할 경우) 및 프로젝트 업데이트.

다른 사람에게 완전히 영향을 줄 수는 없지만 누가 누가 무엇을하고 있는지, 누가하지 않는지를 추적 할 수 있습니다. 직무를 위임하면 업무를 기술 수준이나 수준이 다른 사람들에게 고르게 또는 적절하게 분할 할 수 있습니다.

이런 식으로 특정 작업이 완료되지 않은 경우 실제로 작업을 수행하려는 사람들 사이에서 작업을 나눌 수 있습니다. 이렇게하면 마지막에 실패한 프로젝트로 끝나지 않으며 날짜, 시간 및 일이 잘못 될 경우 마지막에 표시 할 수있는 모든 관련 정보를 전달하려는 기록이 있습니다. 어떤 사람들이 자신의 몸무게를 당기지 않으면 올바른 자세를 유지하는 ALl 것들.

팁 측면에서 :

https://docs.google.com/에 있는 공동 작업 환경을 개인적으로 좋아합니다.

이를 통해 단어 문서, 스프레드 시트 등을 공유 할 수 있습니다. 공동 작업을 수행하는 좋은 방법입니다. 나는 이것이 때때로 얼마나 유용한 지 강조 할 수 없다. 나는 현재 나라에 있지 않은 사람들과 함께 사용합니다.

이것이 누군가에게 도움이 되었기를 바랍니다. 우리가 영원히 갈 수있는 프로젝트를 이끌어내는 데는 많은 측면이 있지만 너무 많은 것들에 달려 있습니다. 최소한 이것은 조금 도움이됩니다.