왜 소프트웨어 개발 프로세스를 채택합니까?

Question

애자 일 (SCRUM, XP, FDD, ...), Waterfall, RUP, ... 왜 소규모 회사는 처음부터 하나를 채택 할까. 왜 각 프로젝트를 완성 해 버릴 수 있을까요? (일반적인 팀 사이즈는 1 ~ 2).

나는 논쟁에 대해 짧은 프레젠테이션을 준비하고 있지만 모든 사람이 생각하는 것을 듣고 싶습니다.

Answer 1

오, 가장 좋아하는 질문입니다. SDLC가 올 때마다 적절한 대답은 항상 "의존합니다!"입니다. :) 나는 그 답을 모두만큼 싫어하므로 더 깊이 파고 들자.

프로젝트를 한 사람이 관리 할 수 ​​있고 매우 짧으면 (즉, < 3 개월) 공식적인 프로세스가 적절하지 않을 수 있습니다. 일부 프로세스의 원칙은 중요하지만 대부분의 의식은 안전하게 삭제 될 수 있습니다. 예를 들어, Agile-y와 같은 방식으로, 기술적 인 이야기 (한 문장 정도), 사용자 이야기 (문장 또는 두 문장), 작업 등이있는 카드를 추적하므로 아무 것도 볼 수 없습니다. . 필자는 필연적으로 반복을하지 않을 것이다. 베타/미리보기/기타에 대한 어려운 데이트가 있다는 것을 알고 계시면 주당 일하는 카드의 우선 순위를 선택하여 적절하게 웨이브를 계획 할 수 있습니다.

일부 프로세스를 사용하면 얻을 수있는 이점 중 하나는 계획/관리 아티팩트 (카드 취소, 백 로그 등)를 남겨두기 때문에 귀하 또는 다른 사람이 프로젝트 개발을 재개해야하는 경우 더 많이 선택할 수 있습니다 용이하게.

6 명 이상 2 명 이상으로 구성된 프로젝트는 분명히 일이 너무 혼란 스럽거나 팀 구성원간에 동기화되지 않도록 유지해야합니다. 작업 카드와 책임감과 같은 스탠드 업이 중요합니다.

이 모든 것들은 프로젝트 관리/프로세스입니다. 1 인 팀이라 할지라도 나는 여전히 소스 컨트롤, Continuous Integration, TDD 등을 사용할 것입니다. 이것은 작업 할당을 위해 어떤 프로세스를 사용하고 있든지 관계없이 양질의 소프트웨어에 대한 필요성입니다.

Answer 2

"hacking away"은 개발 프로세스이며, 쉽게 추적하거나 예측할 수있는 것은 아닙니다.

방법의 포인트는 일관성 및 예측

Answer 3

일관성 키이다. 프로젝트를 진행하면서 "해킹"하는 경우, 표준 및 협약이있는 경우보다 동료 (또는 특히 신입 사원)에게 프로젝트 수행 속도를 높이는 데 더 많은 시간이 소요됩니다. 팀에 적합한 표준/방법론을 선택하고 일관성있게 사용하는 한 실제로는 어떤 표준/방법론을 선택하든 상관 없습니다.

Answer 4

"hacking away"프로세스를 통해 중소기업이 고객이 원하는 것을 제공하고 고객이 만족하는 비용을 제공 할 수 있다면 회사는 분명히 다른 프로세스를 채택해서는 안됩니다.

물론 문제는 소규모 회사에서라도 해킹을하면 이러한 결과가 더 어려워집니다. 또한 회사 나 응용 프로그램이 성장하기를 원하면 해킹이 급속하게지지 될 것입니다.

Answer 5

소프트웨어 프로세스를 사용하여 프로젝트의 시간과 리소스를 관리합니다. '해킹 거리 (Hacking away)'는 당신이 생산하는 물건이 과다 예산이며 과거의 모든 마감 시간을 배달하고 실제로 고객 요구 사항을 충족시키지 않는다면 상관하지 않는 한 사람의 프로젝트에서 좋습니다. 이들에 관심이있는 프로젝트의 경우 소프트웨어 프로세스가 관리 계층으로 도입됩니다.매니저는보다 효율적으로 개발하지만, 관리자와에 중요하지 않은 것 같다 다른 모든 물건을, 등, 중요한 중요한으로 확인 작업에 노력을 집중 개발 라이프 사이클을 모니터링 어떤 단계가에있는로서 고객에게 피드백을 제공 할 수 우리가 실제로 내가이 멀리 해킹 또는 더 구조화 된 프로세스를 제거 그 결과가 항상 것을 건의하고 있지 않다 *

:) 유용하다 생각하는 일을하고 있다는 것을 보여주기 때문에 고객은 사랑 해요. 그들은 해커를 없애는 방법의 '위험도가 높은'영역이라고 불리우므로 해킹과 해킹 및 해킹 만 발생해도 상관하지 않는 프로젝트입니다. :)

Answer 6

왜 그곳과 같은 이유일까요? 자동차를 짓고 집을 짓는 과정입니까? 당신이 "아, 그 생각해야"라고 얼마나 많은 시간을 줄일 수있는 개발 프로세스를 채택

. 는 "멀리 해킹"프로젝트가 실패 할 경우

Answer 7

이 발생합니다

• 관리자는 생각 : "lazy programmers, they should work harder"
• 프로그래머가 생각 : "next time I will really do unit testing" 또는 "we should have taken *this* tools or *that* language..."는
이
• 좋은 프로그래머가 생각 :

그리고 만약 "Bye everybody, I'm leaving" 실행 "해킹 거리"프로젝트 지연, 관리자는 프로젝트에 더 많은 사람들을 추가하는 경향이 있습니다. 당신이 어떻게 프로세스의 구성 요소를 분석하고 이해

2. 계획 과정
3. 을 : "I need this baby in a month send me nine women!"이

   까다로운 것은 당신의 회사와 팀에 기존의 프로세스를 적용하는 것입니다 there에서 속담이다 하나 개 또는 두 개의 매일 회의와 같은 핵심 구성 요소 (또는 한 시간 쌍 프로그래밍 하루, 또는 코드 리뷰를 통합, 또는 고객을 얻기 위해 프로세스 통합을

4. 시작 kiss을 소개하고 측정 할 당신이 그것을 실현 여부에 상관없이 계획

Answer 8

) 사무실에서

측정 및 재구성, 당신은 이미 개발 프로세스를 가지고있다. 프로세스의 넓은 세계로 보는 가장 두드러진 점은 다른 사람이 자신의 작업의 생산성을하는 발견 방법을 배울 수 있습니다. 어쩌면 너도 할 수있어!

프로세스 개선 프로세스의 기초입니다. 프로세스를 채택하는 요점은 개선을 통해 작업을 조각으로 흔들지 않도록 체계적으로 개선하는 방법을 학습하는 것입니다.

팀에 2 명 밖에 없다는 사실은 진입 장벽이 아닙니다. 나는 한 사람의 팀으로하는 프로젝트에도 린 원칙과 칸반을 사용합니다. 내가 그들에게서 배웠기 때문에 나는 이것들로부터 유익을 얻을 수있다. 그리고 그 학습에서 내 마음은 내가 과거에 생각하지 못했던 더 생산적인 방법으로 열렸다.

이미 개선해야 할 것이 없다고 생각되면 이미 수행 한 작업 이외의 프로세스를 조사 할 필요가 없을 것입니다. 그렇게 느낀다면, 개발 과정을 탐구 할 생각을 가질 때 감정적 인 상태를 자세하게 관찰하십시오.그렇게 할 때 가장 작은 순간까지도 스트레스를받는다면, 다른 사람들의 작업과 탐구로부터 얻는 이익보다는 관련된 작업에 대한 인식에서 벗어날 수 있습니다. 그러한 내재적 인 심리적 반동은 드문 일이 아니지만 의미있는 질문에 직면했을 때 거의 도움이되지 않습니다.