페어 프로그래밍 및 솔로 개발자

내가 정보 이점이 무엇인지에 대한, 기사, 사이트 또는 의견 모두의 약점을 찾고 있어요 :페어 프로그래밍 및 솔로 개발자

페어 프로그래밍
솔로 프로그래밍 (단일 개발자)

극한적인 프로그래밍과 같은 민첩한 방법론을 사용하는 이유는 무엇입니까?

그리고 나에게 가장 중요한 질문 :

전통적인 소프트웨어 개발을 사용에 어려움은 무엇입니까?

2010-08-05 maya

이 질문은 [여기에 대해 내가 질문 할 수있는 항목은 무엇입니까?] (http://stackoverflow.com/help/on-topic)에 정의 된대로이 사이트에 적절한 질문의 범위에 포함되어 있지 않기 때문에 논점이되지 않습니다.) [다음 질문을 참고하십시오 :] ([http://stackoverflow.com/help/dont-ask]) [다른 Stack Exchange 사이트] (http : //)에서 도움을 얻을 수 있습니다. stackexchange.com/sites#name) (예 : [pm.se] 또는 [softwareengineering.se]). – Makyen

이것은 매우 직접적인 주제이므로 Google 검색을 통해 수천 개의 리소스를 찾을 수 있습니다. 그러나 나는 충분한 정보를 담고있는 Wikipedia 링크와 다른 기사에 대한 많은 링크를 게시한다.

Extreme Programming

Pair Programming

출처

2010-08-05 08:10:44

내 의견 : 당신이 알고 으로, 모든 것이 달려있다. 저는이 두 가지를 많이 했었습니다. 복잡한 비즈니스 논리로 무언가를 해결해야하는 팀에서 페어 프로그래밍이 가장 효과적이라고 말할 수 있습니다.

쌍 당신은 해커 뉴스 또는 아무것도에 앉아 시간을 낭비하지 않는

1.1 프로그래밍. 그것은 불가능합니다.

1.2 진행하면서 배우는 내용을 공유하고 있습니다.

1.3 두 사람이 글을 쓸 때 코드가 훨씬 더 좋아집니다. 잠재적 비평가 옆에 앉아 있기 때문에 더 간결하고 읽기 쉽습니다.

1.4 코드 검토 필요성 감소.

1.5 다른 사람과 현명한 의견을 나누고 팀을 현명하게 배웁니다.

솔로 프로그래밍

2.1 어떻게 될지 결정합니다.

2.2 교육적 일 수있는 시도/실패 접근 방식이 더 있습니다.

2.3 단순한 작업에 대해 이야기하는 경우 혼자 작업하는 것이 더 효율적일 수 있습니다.

2.4 코드를 소유하고 있다는 감을 느낄 수 있으며, 그와 관련된 모든 좋고 나쁜 것이 있습니다.

웹 사이트의 경우 : 방대한 양의 정보가 있습니다. 나는 parleys.com에 가거나 Kent Becks 블로그를 읽는 것이 좋습니다.

출처

2010-08-05 08:16:57

나는 1.1을 할 수 있다면 +10을 주겠다. 나는 이틀 동안 내 동료와 잘 지 냈습니다. 그는 오늘 떠난다 (플러스 오늘은 금요일이다). 그리고 여기에서 나는 주위에 걸어 돌아 다니고있다. – Amarghosh

쌍 프로그래밍은 명목상으로 생산성을 절반으로 줄 였지만 (2 명으로 1 명을 고용하고 있음), 지지자들은 이점 (더 나은 품질, 즉각적인 피드백)이이를 능가한다고 주장합니다.

에 통신과 조정 오버 헤드 또는 폐기물,하지만 여전히 하나의 개발자가 현실적으로 해결할 수있는 프로젝트의 범위가 매우 제한이 없기 때문에 매우 생산적 일 수있다 매우 유능 인 단일 개발자. 개발자가 극단적으로 유능하지 않으면 도움을 청할 사람들이 없거나 단지 피드백과 아이디어가 문제가 될 수 있습니다.

익스트림 프로그래밍과 같은 민첩한 방법론을 사용하는 이유는 무엇입니까?

불명확하거나 변화하는 요구 사항을 처리 할 때 순차적 프로세스보다 훨씬 우수하기 때문입니다.

전통적인 소프트웨어 개발의 어려움은 무엇입니까?

특히 요구 사항과 관련된 피드백주기가 너무 길다. 최악의 경우, 소프트웨어를 처음으로 고객에게 보여줄 때 소프트웨어가 완벽하고 테스트를 거쳤으며 몇 가지 기본 가정이 잘못되어 핵심 요구 사항을 오해하고 기본적으로 처음부터 다시 시작하여 전체 작업을 낭비 할 수 있습니다.

또한 전통적인 "중량"프로세스에서는 곧 쓸모없는 디자인 문서 및 프로세스 문서와 같이 비생산적인 작업에 많은 시간을 소비해야합니다.

출처

2010-08-05 08:21:28

좋은 지적이지만, 쌍 프로그래밍이 실제로 자원을 반으로 줄지는 모르겠습니다. 나는 다른 곳에서 일할 때 여유 시간이 적기 때문에 60-70 %의 생산성을 기대할 수 있습니다. – UpTheCreek

단지 50 %의 생산성은 난센스입니다. 사람들의 프로그래밍에 대한 사례 연구는 그들이 시간의 80 % 동안 움직이지 않고 (즉, 단지 사고 만) 앉아있는 것을 보여줍니다. 평행하게 생각하는 두 명의 머리가있을 때 이것은 100 % 오버 헤드가 아닙니다. 약간의 오버 헤드가 있지만 이것은 내가 기억하는 한 15 %의 스파크에 더 있습니다. – hlovdal

윌리엄스/케슬 러 쌍 프로그래머가 인용 한 연구에서 솔로 프로그래머의 절반 정도는 오류가 거의 발생하지 않았습니다. 솔로 프로그래밍 (뇌의 잠김, 지연, 산만, 방해, 시각 장애, 눈에 잘 띄지 않는 작은 오류, 과도한 건물 등)의 문제가 아니라면 50 %의 문제가 옳습니다. IME는 훨씬 더 자주 지불합니다. 주어진 시간 동안 더 빨리/더 좋고/더 시원하지는 않을지라도 장거리 (일/주)에 걸쳐 순 승리입니다. 당신은 잃는 것보다 더 많은 내기를 이기고 손실은 덜 비쌉니다. –

나는 개발 접근법에 찬성하여 절대적인 성명서를 작성하는 데 조금 어려움이 있습니다. 나는 다양한 접근 방식을 보았으며 그 가치는 전형적으로 그들이 필요에 부합하는지 그리고 원하는 결과를 얻는 지 여부에 달려 있습니다.

예를 들어 민첩한 접근 방식의 원칙 중 하나는 모든 참여자 간의 의사 소통 수준이 높아진다는 것입니다. 반면에 실질적인 수준의 의사 소통을 제공하는 매우 전통적인 접근 방식을 사용하는 팀을 찾을 수 있습니다. 이것은 민첩성이나 전통에 찬성합니까?

나는 텍스트 북에서 곧바로 개발 방식 "일반 바닐라"를 사용하는 팀을 만난 적이 없다. 모든 성공적인 팀 (선택한 "성공")은 선택한 개발 방식을 어느 정도 수정했습니다.

결론 : 나는 하나 또는 다른 접근법이 '본질적으로'더 좋다고 생각하지 않습니다. 그것은 당신이하는 일에 달려 있습니다. 또는 간단히 말하자면, 세계에서 가장 좋은 해머를 가질 수 있지만 나무 조각에 나사를 넣으려면 스크류 드라이버가 더 나은 도구 일 것입니다.

출처

2010-08-05 08:29:11 Manfred

페어 프로그래밍 및 솔로 개발자

답변

관련 문제