애자일은 프로세스란게 없음. 개발자가 개발완료된거 확인하는 용도로 유닛테스트 작성 정도. 테스트나 데이터, 시나리오 Given When Then 먼저 정의하고 개발하는 곳은 거의 없음.
익명(125.191)2018-04-22 20:41
애자일은 "스펙"이 정의되어 있지 않음. 애초에 아니다 싶으면 변경한다는거라 개발종료를 선언하는 시점이 그 시스템의 스펙임. 3달전 개발완료된 거도 뒤엎을 수 있고 그게 당연한거임.
익명(125.191)2018-04-22 20:43
뭐 맨첨 무개념 프로젝트 진행하다가 문제 생겨서 방법론들 발전하기 시작했는데.. 그러다보니 너무 형식적인 산출물들이 많아서.. 최소한의 개발 품질은 지키면서 개발에 집중해서 하자고 나온게 애자일이잖음. 그래서, 개발 - 릴리즈에서 보는 테스트 부분을 선진행 시켜서 뚝딱 만들고, 반응 보고 다시 소규모 프로젝트 반복 진행하고 그런건데.. 개발 후 테스트라면.. 뭐.. 방식은 그쪽 상황 맞게 세팅하는게 맞긴하지만..
☎2.80™(roidz)2018-04-22 20:45
스타트업 처음 프로젝트 할때는 smoke test 만 짜고 했을때도 있구여. 지금은 TDD 는 아닌데 CI/CD 때문에 green-build 만 뜨면 바로 프러덕션 ㄱㄱㅆ 이라 테스트 안짜고 걍 생각없이 푸시 하면 잦되는 구조
Kyle(203.221)2018-04-22 21:37
근데 ephemeral user testing 도 최근에 들여와서 인간이 리뷰해야됨
Kyle(203.221)2018-04-22 21:38
전 TDD 별로 안좋와함 왜냐면 TDD 아이디어가 테스트 먼저 짜고 feature 개발인데 중간에 feature spec 바뀌면 테스트 다시짜야됨
애자일은 프로세스란게 없음. 개발자가 개발완료된거 확인하는 용도로 유닛테스트 작성 정도. 테스트나 데이터, 시나리오 Given When Then 먼저 정의하고 개발하는 곳은 거의 없음.
애자일은 "스펙"이 정의되어 있지 않음. 애초에 아니다 싶으면 변경한다는거라 개발종료를 선언하는 시점이 그 시스템의 스펙임. 3달전 개발완료된 거도 뒤엎을 수 있고 그게 당연한거임.
뭐 맨첨 무개념 프로젝트 진행하다가 문제 생겨서 방법론들 발전하기 시작했는데.. 그러다보니 너무 형식적인 산출물들이 많아서.. 최소한의 개발 품질은 지키면서 개발에 집중해서 하자고 나온게 애자일이잖음. 그래서, 개발 - 릴리즈에서 보는 테스트 부분을 선진행 시켜서 뚝딱 만들고, 반응 보고 다시 소규모 프로젝트 반복 진행하고 그런건데.. 개발 후 테스트라면.. 뭐.. 방식은 그쪽 상황 맞게 세팅하는게 맞긴하지만..
스타트업 처음 프로젝트 할때는 smoke test 만 짜고 했을때도 있구여. 지금은 TDD 는 아닌데 CI/CD 때문에 green-build 만 뜨면 바로 프러덕션 ㄱㄱㅆ 이라 테스트 안짜고 걍 생각없이 푸시 하면 잦되는 구조
근데 ephemeral user testing 도 최근에 들여와서 인간이 리뷰해야됨
전 TDD 별로 안좋와함 왜냐면 TDD 아이디어가 테스트 먼저 짜고 feature 개발인데 중간에 feature spec 바뀌면 테스트 다시짜야됨
ㅇㅇ