솔로 프로젝트에서 피처 크립을 피하려면 어떻게해야합니까?


12

2011 년부터 2012 년까지 일한 프로그램이 있지만 마지막 릴리스는 2011 년 12 월이었습니다 . 나는 적극적으로 노력하고 있지만 기능 크리프는 못생긴 머리를 유혹했으며 이제는 완성되지 않은 기능에 톤이 가득합니다.

나쁜 부분은 기능을 구현할 때 새로운 기능이 등장한다는 것입니다. 향후 기능 크립을 피하기 위해 실제로 1 년 이상 릴리스 할 수있는 방법은 무엇입니까?

이 프로젝트는 iOS를 기반으로하며 각 iOS 버전 업데이트를 릴리스하는 데 사용되었지만 마지막 버전은 5.1 (2011)로 돌아 왔습니다. 꾸준한 릴리스주기를 되찾고 싶지만 너무 어려운 것으로 판명되었습니다.


8
기능의 출처 에 대한 질문을 좀 더 구체적으로 설명해 주 시겠습니까? 기능 크리프를 담당하는 사람은 누구입니까? 당신? 비즈니스 분석가? 회사 회장? 사용자의 요구는? 소스가 무엇인지 모르고 기능 크리프를 관리하는 방법에 대한 조언을 제공하기는 어렵습니다. 또한, 딜버트 같은 I 이유는 search.dilbert.com/comic/Feature%20Creep )
FrustratedWithFormsDesigner

1
이 프로젝트의 유일한 개발자입니까? 대규모 팀 프로젝트는 배송 일정을 관리 할 수 ​​있도록 이정표를 마련하는 데 없어서는 안될 필수 요소이지만, 솔로로 비행하는 사용자는 기능 중심 개발 과 같은 방법론을 활용할 수도 있습니다 .
hardmath

@FrustratedWithFormsDesigner 저는 유일한 개발자입니다
Cole Johnson

1
@FrustratedWithFormsDesigner no. 나 혼자 야 당신이로 소스 포지를 계산하지 않는 사람이 프로젝트에서 작동 , 나는 유일한 사람입니다.
Cole Johnson

4
배송도 기능입니다 ... 때로는 다른 기능을 고려할 때이를 염두에 두는 것이 도움이됩니다.
Marjan Venema 2013

답변:


21

내 경험상, 원하는 작업을 방해하지 않는 개발 및 릴리스 케이던스를 보유하는 것이 가장 쉬운 방법입니다. 내가 한 방법은 다음과 같습니다.

  1. 기능을 적어두고 작업하려는 금액과 사용자에게 얼마나 도움이 될지 반영하는 등급을 지정하십시오 (실제 사용자를 참여시킬 수 있음). 그런 다음 순서대로 작성하십시오.
  2. 기능을 체크인 / 푸시하기 전에 안정적으로 배포 할 수있는 빌드가 있는지 확인하십시오 (CI 시스템을 강력하게 고려하십시오).

이 방법으로 원하는 경우 각 기능 다음에 릴리스를 푸시하거나 릴리스에 원하는 값을 제공하는 롤업을 기다릴 수 있습니다.

노트 :

  • 기능은 작업중인 기능보다 우선 순위가 높을 수 없습니다 (또는 작업중인 기능을 중단 할 수는 없습니다). 다음에 올 수 있지만 지금 결코 없습니다 . 즉, 지금부터 다음으로 갈 때 원하는 경우 릴리스 빌드를 줄일 수 있습니다.

매우 도움이되었습니다! 나는 그것의 다소 엄격함을 좋아합니다.
Cole Johnson

새 기능을 완료하기 전에 새 기능을 시작하지 마십시오. 그렇지 않으면 아무것도 할 수없는 느슨한 끝의 코드베이스로 끝납니다.
Tyanna

@Tyanna : 이것이 제가 의미하는 바입니다. "기능은 현재 작업하는 것보다 높은 우선 순위를 부여 할 수 없습니다. 현재 작업중인 것을 방해 할 수 없습니다 ..."
Steven Evers

7

답은 간단하고 종종 불가능합니다. 추가 기능 추가를 거부하십시오.

좀 더 깊이 대답하면 실제로 새로운 기능이 기능 크립 빈에 빠지게 만드는 원인이 무엇입니까? 크리프 기능이 프로젝트의 의도 된 용도와 접할 뿐이며 크리핑 기능이 불필요한 것이 아니라 유용하다는 사실에도 불구하고 크리프 기능이 프로젝트에 추가 된 기능이라고 가정 할 경우, 해답은 별도의 기능으로 이동하는 것입니다 관련 도구가 있습니다. 직교 도구를 작성하고 함께 붙이는 유닉스 철학을 사용하십시오.

프로젝트 관리 관점에서 대답은 비슷합니다. 다음 릴리스에 얼마나 많은 시간을 할애 할 것인지 결정하고 기한을 정하십시오. 기능을 추정하고 마감일을 정할 수 있도록 충분히 자릅니다. 본인 이외의 이해 관계자가있는 경우 가장 중요한 것을 선택하도록하십시오.

스케줄링에 대한 좋은 개요는 소프트웨어의 Joel에서 찾을 수 있습니다.

http://www.joelonsoftware.com/articles/fog0000000245.html


9
그는 프로젝트에 전적으로 독창적이므로 기능 요청자를 때리는 작업을 아웃소싱해야 할 수도 있습니다.
Philip

2

개발에서 가장 중요한 교훈 중 하나는 언제 중지해야하는지 아는 것입니다.

일반적으로 발생하는 것은 개발자가 기능을 추가하는 것입니다. 그것은 더 많은 아이디어를 불러 일으킨다. 더 많은 기능이 추가됩니다. 즉, 당신이 말했듯이, 프로젝트가 증기 시스템이되는 방법 중 하나입니다. 개발자는 프로젝트를 '완료된'것으로 보지 않으므로 출시되지 않습니다.

당신이 들어가고 싶은 습관은 '완료된'프로젝트로 출시 / 버전 측면에서 생각을 멈추는 것입니다. 오히려 개발을 장기적인 과정으로 생각하십시오. 릴리스 가 프로그램의 희망 사항에 대한 이정표 로 생각하십시오 . 따라서 릴리스 / 버전은 장기 프로세스에있는 스냅 샷일뿐입니다. 잘 정리되고 테스트 된 스냅 샷입니다.

실용적인 측면에서 할 수있는 일은 앉아서 다음 릴리스를 지정하는 것입니다. 심하게 철저 할 필요는 없습니다. 다음 릴리스에 필수적이라고 생각 되는 3-5 가지 주요 주요 기능을 적어 두십시오 . ( 실제 기능 수는 버그 수정이나 사소한 GUI 변경 사항을 제외하고 앱 유형에 따라 다를 수 있습니다.) 해당 기능에 대해 작업하십시오. 다른 아이디어를 생각해 내면 괜찮습니다 ... 다음 릴리스에서 메모를 작성하고 구현하십시오. 3-5 개 항목을 완성하면 릴리스를 베타 할 수 있습니다.

새 애플리케이션을 시작할 때 일반적으로 앱의 최종 '비전'에 대해 생각합니다. 그것은 나에게 앱의 버전 3에서 원하는 것입니다. 그 벤치 마크를 사용하여 견고한 버전 1을 만드는 것의 기본 개념을 알았습니다.

요약:

각 릴리스는 프로젝트의 완성 된 '비전'일 필요는 없습니다. 그 비전을 향한 이정표입니다.


2

아이디어를 얻을 수있는 브랜치를 만드는 것이 저렴한 버전 관리 시스템을 사용하여 릴리스 경로에서 벗어나십시오. 예를 들어에서 git, 당신은 어떤 아이디어를 "크리핑"할 수 git stash있습니다. 나중에이 보관함을 검토하고 흥미로운 순서대로 체리를 선택할 수 있습니다.

더 큰 기능의 경우 실제 분기를 만듭니다 (여러 커밋을 수행 할 수 있음). 예를 들어 가비지 수집기에 세대 지원을 추가하고 싶을 때 지점을 만들었습니다. 은신처는 산만 작은 물건을 아주 잘 캡처합니다. 큰 기능은 숨김으로 시작한 다음 분기로 전환 한 다음 준비가되면 병합 할 수 있습니다.

숨김 및 분기를 사용하면 관리되는 팀 프로젝트와 마찬가지로 아이디어를 재고로 가져 와서 우선 순위를 정하고 솔로 프로젝트의 릴리스 범위를 설정할 수 있습니다.

아이디어를 얻을 때 어딘가로 가야 하고 가장 좋은 곳은 코드 : repo입니다. 크리핑 기능은 좋은 아이디어를 잊어 버리는 것보다 낫습니다. 그러나 모든 기능을 동일한 메인 라인으로 크롤링하는 경우 사용자에게 사용하지 말라고 경고해야하는 반제품으로 가득 찬 어수선한 릴리스를 잘라 내지 않으면 릴리스가 계속 지연됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.