애자일 팀은 매일 새로운 기능을 제공해야합니까?

우리 회사는 폭포 스타일 개발에서 애자일 / 스크럼으로 전환하는 중입니다. 무엇보다도, 우리는 우리가 가지고에 대한 기대이라고 말했다있어 새로운 작업, 검증 (QA에 의해)을 각각 하루의 끝에 있습니다.

대부분의 개발자들은 회의 및 기타 기업의 오버 헤드로 하루에 약 2 시간을 잃습니다. 즉, 6 시간 (최상의)에 QA가 사용할 수있는 완전한 기능을 생성하기에 충분한 코드를 설계, 작성, 단위 테스트, 빌드 및 배포 (릴리스 노트 포함)해야합니다. 올바른 CI 설정으로 빌드 / 배포 / 릴리스 정보를 자동화 할 수 있지만 아직은 없습니다.

또한 우리는 서버 측 코드를 작성하는 큰 규모의 해외 우발 사고를 가지고 있으며, 12 시간의 시차로 인해 더욱 어려워집니다.

Google은 가능한 한 빨리 엔드 투 엔드 기능을 완성하기 위해 좁고 깊은 세로 조각으로 스토리를 작성하려고 시도하지만 대부분의 날은 다소 혼란스럽고 QA가 빌드를 보장하기 위해 어리 석고 연약한 지름길을 취하는 사람들을 종종 사로 잡습니다. 이 문제는 불가피한 결함이 발생하기 시작하고 동일한 6 시간 창에 맞춰야하는 스프린트가 며칠 동안 진행된 후에 더욱 복잡해집니다.

이것이 애자일 팀에게 정상적인 속도입니까? CI 설정을 구현하더라도 이러한 속도를 유지하면서도 우수한 소프트웨어를 어떻게 만들 수 있는지 알 수 없습니다.

편집 : 여기에 몇 가지 좋은 답변이 있습니다. 애자일 팀이 매일 새로운 기능을 제공해야한다는 사실을 알게되었습니다 . 그에 따라 제목을 업데이트했습니다.

요즘 애자일이라는 이름으로 저지른 범죄는 나를 슬프게합니다. 많은 사람들이이 전환을하는데 어려움을 겪고 있습니다.

민첩한 선언 : "우리는 프로세스와 도구보다 사람과 상호 작용을 중요하게 생각합니다." 사람들이 분명히 아프면 과정이 잘못되었습니다. 나는 당신에게 그것을하는 방법을 말하고 싶지 않지만 어떻게하는지 공유 할 것입니다.

우리 팀에서 중요한 부분은 팀의 나머지 시간을 낭비하는 방식으로 손상된 공유 리포지토리 코드에 커밋하지 않는 것입니다. 이런 의미에서만 '매일 작업 코드를 전달'하려고 노력합니다. 품질 관리를 중단하지 마십시오. 다른 개발자를 차단하지 마십시오. 이상적으로는 버그를 확인하지 않습니다. (하하).

그 의미는 매일 무언가를 커밋해야한다는 의미는 아닙니다. 그 의미는 당신이 좋은 물건 만 커밋해야하므로 매일 누군가가 저지른 모든 좋은 물건을 쌓을 수 있다는 것입니다. 이런 식으로 팀은 모든 실린더에서 계속 발사됩니다.

우리 팀에서는 QA가 일정합니다. 상용 제품을 제작하므로 제품이 더 이상 사용되지 않을 때까지 프로젝트는 끝나지 않습니다. 품질 보증 엔지니어는 테스트 할 수있는 기능을 테스트합니다. 품질 보증 엔지니어에게는 항상 백 로그가 있습니다. 이상적으로 원하는 모든 것을 테스트하거나 자동화하기에 충분한 QA 시간이 없습니다.

개발자가 기능 또는 수정 사항에 대한 변경 사항을 병합하기 전에 며칠이 필요한 경우 시간을 위험에 빠뜨리기 전에 코드를 바로 얻는 것이 좋습니다. 개발자는 팀이나 QA에 영향을주지 않고 개인 리포지토리 또는 지점에 코드를 커밋 할 수 있습니다. 개발자는 개발자의 리포지토리 또는 개인 지점에서 빌드 한 코드에서 단위 테스트 또는 회귀 자동화를 실행할 수 있습니다. 특히 위험한 경우 QA 엔지니어는 개발자와 협력하여 병합 전에 테스트하여 팀의 지연을 방지합니다.

이런 점에서 저는 관리자가 원하는 것을 실천합니다. 지난 12 년 동안 거의 매일 개발 팀은 공유 저장소에서 작동하는 코드를 가지고있었습니다. 우리는 항상 거의 출하 준비가되어 있습니다. 때때로 우리는 이것을 달성하지 못하지만 그것에 대해 너무 걱정하지 않습니다. 때로는 주요 도구 변경이나 어려운 병합을 수용하는 것이 의도적 인 것입니다.

민첩한 선언문은 1990 년대에 등장한 개발 과정에 대한 새로운 사고의 최고를 요약합니다. 나는 그 원칙을 믿는 사람이 많지만 프로세스 세부 사항은 다를 수 있습니다. 내가 알다시피, 애자일의 요점은 프로세스의 노예가 아니라 제품 및 고객의 요구에 맞게 프로세스를 조정하는 것입니다.

어제 소프트웨어를 사용했다면 왜 오늘날 작동하지 않습니까? 오늘 작업을 완료하지 않은 경우 오늘 빌드는 어제와 동일합니다. 일일 빌드와 개발 속도는 별개의 것입니다. 일일 빌드가 있다고해서 모든 빌드에 새로운 기능이있는 것은 아닙니다.

마지막으로 일부 기능이 메인 지점에서 완료되고 체크인되면 소프트웨어를 빌드하고 테스트를 실행하는 자동화 된 프로세스가 있어야합니다. 테스트 빌드 또는 실행에 문제가있는 경우 팀에 알리고 다시 작동하기 위해 노력합니다. CI가 작동하는 방식과 작동하는 소프트웨어를 항상 릴리스하는 데 도움이됩니다.

짧은 답변 : 아니요 . 단순히 매일 달성 할 수 없습니다.

그러나 애자일 팀은 각 스프린트 에서 작동하는 소프트웨어 조각이나 사용자 스토리를 제공해야했습니다 . 일반적으로 현황 회의는 진행 상황과 장애를 확인하기 위해 매일 개최됩니다.

품질 소프트웨어 와 관련하여 , 지속적인 통합 (CI) 프로세스는 품질 관리가 작은 노력 (체크인)에 적용되고 구성된대로 자주 수행되도록합니다. 또한 quality of software모든 개발을 완료 한 후 품질 관리를 적용하는 전통적인 관행을 대체함으로써을 개선하고 제공하는 데 걸리는 시간을 단축하는 것을 목표로합니다 .

아니요, 매일 새로운 기능을 제공 할 것으로 기 대해서는 안됩니다. 개발자가 6 시간의 개발 시간 내에 기능을 완성 할 수 있도록 모든 기능을 작은 크기로 나눌 수는 없습니다.

스크럼을 수행하는 경우 완료하는 데 대략 0 일에서 8 일 정도의 기능이있는 최소 2 주 스프린트에서 수행해야합니다. 제품 소유자에게 약속은 스프린트 종료시 생산에 투입 될 수있는 새롭고 테스트되고 검증 된 올바른 작업 코드를 제공하는 것입니다. (참고 : 실제로 제작에 넣을 필요는 없지만 원하는 경우 목표가 될 수 있습니다)

좋은 방법론은 하루에 최소한 하나의 작업 소프트웨어 빌드 작성을 자동화하는 CI (Continous Integration) 서버를 설정하도록 제안했습니다. 기능을 완료하자마자 코드를 체크인하여 다음 빌드주기에 들어가고 테스트를 위해 QA가 할 수 있다는 아이디어.

목표는 스프린트가 끝날 때까지 기능을 수행하고 테스트하는 것입니다! 스프린트 마지막 날까지 QA에서 빌드를 한 다음 모든 기능을 테스트하도록 할 필요는 없습니다. 그들은 그것을 모두 테스트 할 시간이 없으며 버그를 수정할 시간이 없습니다 ...

CI 서버를 설정할 수없는 경우 개발자가 완성 된 코드를 확인하고 기능이 완료되어 QA로 전달할 수 있다고 주장 할 때마다 QA에 대한 새 빌드를 수동으로 작성해야합니다.

실제로 프로젝트의 크기에 따라 다릅니다. 프로젝트가 큰 프로젝트라면이를 달성 할 수있는 방법이 없습니다.

지속적인 통합 도구에서 나오는 매일 (또는 더 자주) 빌드는 소프트웨어 작동을 의미하지 않습니다. 컴파일 가능한 코드를 거의 의미하지 않습니다.

지속적인 통합 덕분에 매일 빌드를 제공하는 많은 프로젝트가 있습니다. 적어도 이론 상으로는.

새로운 기능이 반드시 포함되어 있지는 않습니다. 사소한 버그 수정이 거의 없거나 전혀 없습니다.

이론적으로 QA에 매일 더 많은 작업을 제공 할 수없는 경우 개발자 수를 늘리거나 테스터 수를 줄여야합니다. 끔찍한 생각!

당신의 일은 일을 끝내는 것입니다.

품질 보증팀에 테스트가 완료되면 테스트 할 것이 있다고 말합니다. 이유를 설명해야합니다.

나는 당신이 "CI"의 아이디어에 대해 혼란스러워한다고 생각합니다. CI가 실제로 어떻게 작동하는지 Martin Fowler의이 훌륭한 기사 를 방문 하고 싶을 것입니다.