나는 항상 소프트웨어 개발을 위해 민첩한 프로세스 Feature Driven Development을 사용 해왔다. 다른 사람들은 무엇을 사용합니까? 왜 그것을 선호합니까? 나는 FDD를 선호하는데 왜냐하면 그것이 내가 대학에서 새로 시작한 것이기 때문입니다. 대학에서는 모든 것이 매우 자유로운 형태 였고 나의 "고객"은 대개 대학교의 연구를하지 않고서는 많은 업계 경험이 없었던 내 교수였습니다.어떤 소프트웨어 개발 프로세스를 사용합니까?
이제 내 고객은 용서하지 않으며 의료 분야에서 많은 일을합니다. 민첩성과 높은 수준의 품질은 필수입니다!
직장에서 우리는 ICONIX 프로세스를 사용합니다. 이것은 AGILE 기술의 하위 집합이며 작동 요구 사항입니다. ICONIX 프로세스는 최대한 최신 정보를 유지할 수 있도록 가능한 한 적은 양의 문서를 가지고 가능한 한 축하를 줄이는 것을 목표로합니다 (예 : XP 실무자는 다른 AGILE 프로세스와 큰 차이가 있습니다. 1 차 초안 이후에 자신의 코드 이 인 문서라고 주장하면서 문서를 최신 상태로 유지하는 것 같지 않습니다.여기
프로세스의 실제적인 개요입니다 : 기능 요구 사항의을 구현 각 사용 사례
당신이 기능을 추가해야하는 경우, 새로운 사용 사례를 추가하고 전체 프로세스를 따르십시오.
자료 :
Iconix Software Engineering website
책 참고 :
와우, 훌륭한 글. 질문 - 그래도이 접근 방식은 "대규모"프로젝트에서 잘 작동합니까? 내 프로젝트의 평균 수명은 1 년 조금 넘습니다. 이것은 작은 작업을위한 훌륭한 프로세스 인 것 같습니다. 그러나, 나는 전체 프로젝트를 위해 내 머리를 감싸는 데 어려움을 겪고있다. 참고 문헌 – MaTT
내 경험에 의하면 프로젝트의 크기에 관계없이 작동합니다. 대규모 프로젝트에서는 반복되는 기능 구현을 AGILE 방식으로 분할합니다. 기능을 추가 할 때마다 프로세스를 다시 진행합니다. 분명히 - 프로젝트가 커질수록 더 많은 문서화가됩니다. – JohnIdol
가장 기본적인 애자일 기반 소프트웨어 개발 프로세스는 서로 비슷합니다 ... 문서화되는 양과 각 반복의 길이가 대부분 다릅니다 ... – RWendi
이 테스트 기반 디자인 TDD
당신이 코드 변경이 미묘한 무언가를 파괴하지 않았 음을 알고에서 얻을 신뢰 내가 애자일 스크럼로 이동
나는 프로세스가 아닌 개발 연습 (중요한 작업 임에도 불구하고!)으로 TDD를 수업 할 것입니다. XP, Scrum, Lean, RUP, FDD는 모두 개발 프로세스라고 부르는 예제입니다. TDD, 쌍 프로그래밍, 반복 등은 내가 관행이라고 부르는 것의 예입니다. – Kief
몇 년 전, Kent Beck은 XP를 시험 주도 개발로 이름을 바꾸려고했습니다. 표면적으로, TDD는 개발 관행이지만 원칙적으로 더 넓은 관점으로 보아 그에 따라 적용되는 것은 실제로 과정입니다. 린 (Lean)과 칸반 (Kanban)과 공통점이 있습니다. 여기서 우리가 말할 수있는 가장 좋은 점은 TDD 개발 과정이지만 TDD 과정은 그렇지 않다는 것입니다. –
중대하다, 그것은 나를 연결 '의 느낌을 준다 팀. 그리고 이정표와 개별 타크를 잘 제어하십시오. 아침 스크럼은 매우 유용합니다. 사용하고 있습니다 Agile Scrum project template in Team Systemhttp://www.scrumforteamsystem.com/en/default.aspx
예, 저는 Agile 개발의 큰 팬입니다. 귀하가 사용하는 모든 프로세스 (예 : Kanban 접근 방식 또는 FDD 접근 방식) 또는 마일스톤을 사용하여 기민한 마일스톤을 수행합니까? 애자일/린 처리가 새로운 방식 인 것처럼 보입니다. 제가 성장함에 따라 애자일 개발에 대해 점점 더 많이 읽고 있습니다. – MaTT
우리는 Agile Scrum- 반복 접근법을 사용합니다. VS2008에 설치할 수있는 프로젝트 템플릿이 있으므로 팀을 완전히 통제하고 추적 할 수 있습니다. http://www.scrumforteamsystem.com/en/default.aspx –
스크럼은 위대한 과정입니다 – JohnIdol
Code and Fix !!
농담 그냥, TDD 정말로 멋진 방법입니다.
하하! 좋은 'C-n-F! 그것이 대학에서의 수업이었습니다. 나는 TDD에 익숙하므로 매우 효과적 일 수 있습니다. – MaTT
코드를 사용하고 접근 방식을 사용할 때도 우연히 프로그래밍의 대시에 뿌리면 정말 도움이됩니다. :) –
애자일에 대한 투표가 두 번째입니다. 요즘에는 린 (Lean)을 탐구하고 있지만 개발 프로세스가 그렇듯이 현재 그룹에 속할 수있는 것이 아닙니다. 그러나 Lean과 Agile의 기능은 현재 프로세스에 적용되어 즉각적인 가치를 얻을 수 있습니다.
이전 프로젝트에서 Waterfall 메서드를 사용하여 자랑스러워했습니다. 그들은 폭포에서 떨어져 나갔고 프로토 타입으로 나아갔습니다. 이것은 좋은 발걸음입니다. XP 엔지니어링 사례의 조합으로
그것은 굉장합니다! 변화는 힘들고, 좋은 일을 계속하십시오 !!! – MaTT
애자일 개발 방법론 :
현재 프로젝트에 필요한 것이 무엇이든간에.
저는 다양한 시간대 (대부분 PHP 기반) 웹 개발자를 위해 많은 컨설팅을하고 있습니다. 나는 아직 그 프로젝트를 위해 TDD에 갈 시간을 쏟지 않았으며, 많은 사람들이 TDD를 그렇게 쉽게 만들지 않는 기존의 프레임 워크를 사용하고 있습니다.
우리는 아직 TDD에 적합하지 않으므로 민첩하고 오래된 스타일의 사양 기반 프로세스를 사용합니다. TDD를 향한 운동을 시도하고 있지만, 우리는 잘 정비 된 기존 프로젝트 (유지 보수 작업이 많음)와 ERP 시스템과의 통합 작업을 수행하는 작은 상점입니다. 나는 TDD가 내 자신의 통합 작업을 할 수 있다고 생각하지만, 다른 것들은 대부분 잃어버린 원인이다.
TDD는 소프트웨어 프로젝트의 전반적인 개발 관리에 대한 당신이 코드를 구현 방법에 대한 자세한 및되지 않습니다 : 단위 테스트의 보완과 계약에 의해
디자인
계약서에는 무엇을 사용합니까? –
여기에 약간의 혼동이있는 것 같습니다 . TDD는 어떤 기능을 스케줄링 할 것인지, 언제 전달할 것인지, 우선 순위를 설정하는 방법을 결정하는데 도움이되지 않습니다.
대조적으로 Lean/Agile 또는 Waterfall과 같은 항목은 이러한 상위 수준 문제에 관한 것입니다. (내 표결은 Scrum이 Lean/Agile 영역으로 단단히 떨어지는 것입니다.)
XP (Extreme Programming)는이 두 영역의 블렌드 아이디어가 흥미 롭기 때문에 흥미 롭습니다.
XP : 문서가 전혀 없습니다. 너무 조금 힘듭니다! – JohnIdol
저는 웹과 시스템 개발 모두를하는 회사에서 일합니다. 우리의 개발 모델은 신속 개발입니다. 우리는 더 현대적인 정의를 사용하기 때문에 Agile Development와 유사합니다. XP 개념없이. 우리는 스크럼을 사용
너무 ... 나는 standups 어떤 점에서 좋은 될 수 있다고 생각하지만, 때로는 빠른 15 분 이상 30
나는 오래된 학교입니다 추측된다. 클라이언트 사양 개발. 활발한 디자인 단계, 헤드 다운 개발, 테스트, 버그 수정주기. 그런 다음 구현하십시오.
일단 사양이 정의되고 동의되면 더 이상 변경이 발생할 수 없습니다. 모든 변경 사항은 개발 및 버그 수정이 완료 될 때까지 기다리는 것입니다. 이것은 스코프 크립을 방지하고 소프트웨어가 작성, 테스트, 디버깅 및 구현되도록합니다. 그 시점에서 변경 사항은 기능 향상, 새로운 기능 등이되었습니다.
저는 지난 10 년 동안 거의 모든 고객에게 개발 과정에서 "던져 넣을"것 중 약 90 %를 발견했습니다. 범위 - 크립을 만드는 것은 필요하지 않은 것으로 생각됩니다. 얼마나 많은 고객이 저를 지키기 위해 고맙다고 말했습니까? 그래서 나는 당신이 어떤 프로세스를 호출할지 모르지만 그것은 나와 다른 많은 개발자들에게 잘 알려져 있습니다.
나는 Poppendiecks에 의해 추진되는 Lean Software development의 팬이야, 주로 기반으로 토요타와 함께 린 (lean) 제조 원칙 포스터 아이. 다른 애자일 방법론과 공통점이 많으며, 낭비를 없애고, 대기 이론을 사용하고, "적절한 시간에"사고 방식을 취합니다 (예 : 마지막 순간의 이야기 지정).
린은 종종 파이프 라인을 통해 작업을 추적하는 방법 인 Kanban과 연결됩니다.
오른쪽. 칸반 (Kanban) 접근 방식은 어떻습니까?당신은 도구를 사용하여 진행 상황을 모니터링합니까? 우리는 여기에 거대한 화이트 보드를 사용하고 Kanban 보드에 노트/자석을 물리적으로 사용하는 그룹을 만들었습니다. 그것은 정말로 산뜻하고 매우 효과적이었다! – MaTT
우리는 내가 일하는 곳에서 폭포를 사용하지만, 일부는 내 새 프로젝트를 위해 민첩한/TDD/CI 하이브리드 모델을 향해 움직이고 있습니다. 신의 의지, 우리는 폭포 방법을 버릴 수있을거야. 우리가 수행하는 모든 유지 관리 릴리스에서는 주 고객이 마감 기한을 무시하고 마지막 순간에 요구 사항 변경 사항을 즉시 처리 한 다음 그 이유를 설명하는 동안 우리를 빈틈없이 바라 봅니다.
아참! 마이그레이션과 행운을 ... 변화는 쉽지 않습니다. 귀하의 회사가 민첩한 개발에 잘 부합하기를 바랍니다. 그것은 내 일에 큰 일을하고있다 !!! – MaTT
지난 몇 년 동안 내 개인적인 기대는 린 개발에 대한 것이 었습니다. XP에서 배운 모든 것에 큰 영향을 받았습니다.스크럼은 소프트웨어 개발 작업을 알리지 않고 개발 프로세스로서 불충분하지만 소프트웨어 개발 작업의 흐름을 관리하려고 노력한다는 점을 강조하는 것이 중요하다고 생각합니다. ICONIX에서도 내 생각에 대한 정보가 전달되었습니다. 저는 이것이 비생산적인 관료주의에 허덕이는 일이없이 유스 케이스와 다이어그램 중심 환경에 접근하는 좋은 방법이라고 생각합니다.
죄송합니다. 지연된 태그에 대해 죄송합니다. 시스템에 이미있는 태그를 정리하고 추가하고 싶었습니다. ;) – macbirdie