2024-10-10 QA TIL

애자일 선언문의 바탕에 깔려있는 원칙들 우리는 다음과 같은 원칙들을 따른다.

• 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전 달함으로써 고객을 만족시키는 것이다.
• 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
• 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다.
• 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해 야 한다.
• 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요 로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있도록 신뢰하라.
• 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, (서로 간의) 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.
• 작동하는 소프트웨어가 진척 측정의 주된 척도이다.
• 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다. • 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.
• 간결함-하지 않아도 되는 일의 양을 최대화하는 기술-은 필수적이다.
• 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화(self-organizing)되어 있는 팀에서 나온다.
• 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보 며 자신들의 행동을 이에 따르도록 조율하고 조정한다.

애자일은 신뢰성 높은 소프트웨어를 빨리 개발하자는 가치를 공유하고 있습니다.

워터폴 vs 애자일

• 계획 중심 vs 고객 중심
  • 워터폴은 프로젝트를 시작하기 저넹 프로젝트 기간 전체에 대한 일정을 수립하며, 계획에 따라 프로젝트를 진행 합니다.
  • 애자일은 계획을 수립하되 불확실한 프로젝트 기간 전체를 감안하여 무리하거나 현실성 없는 계획을 수립하는 것이 아니라 현재 시점에 고객에게 중요하거나 확정된 내용을 중심적으로 수립합니다.
• 빅뱅 릴리즈 vs 작은 릴리즈
  • 워터폴은 프로젝트가 종료가 되는 시점에 한꺼번에 모든 기능을 릴리스 한다
  • 애자일 방법론은 이터레이션이라는 일정 기간 단위로 작은 규모 크기의 릴리즈를 반복합니다. 이로 인해 요구사항에 맞지 않아 재개발을 할 경우를 방지 할 수 있습니다.
• 산출물 중심 vs SW 중심
  • 워터폴은 계획된 단계별로 지정된 산출물이 작성되었는지 여부를 확인함으로써 프로젝트가 제대로 진행되고 있는지 확인
  • 애자일은 소프트웨어가 제대로 동작하는지, 얼마나 요구사항에 맞게 개발되었는지 중요
• 애자일을 도입하는 이유
  • 팀의 생산성을 높이고 제품을 적기에 출시하기 위해
  • 개발에 들어가는 비용을 줄이기 위해
  • 소프트웨어 품질을 향상시키기 위해
  • 팀의 사기와 업무 만족도를 위해

 

스크럼?

스크럼은 애자일 방법론은 추정 및 조정 기반의 경험적 관리기법입니다.

스크럼에는 크게 3가지 역할자로 제품 책임자, 스크럼 마스터, 스크럼 팀이 있습니다.

스크럼 프로세스의 구성으로는 스프린트, 미팅, 산출물이 있습니다

스프린트 : 1~4중 단위의 반복 개발기간

미팅 : 일일 스크럼, 스프린트 계획, 스프린트 리뷰

산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트

 

현장고객

최종사용자 : 구현된 제품을 실제로 사용하는 사람

고객 : 제품을 구입하는 사람

내부 고객 : 개발팀에게 방향을 제시하거나 결과물을 전달 받는 관련 부서

개발팀 :  제품을 개발하는 사람

 

 

숙제:

프로그래머스 : 문제 풀이 

ISTQB 실러버스 읽어보기 

 

느낀점

개발을 발전을 해 나가면서 팀원과 의사소통을 하면서 각자의 부분을 공유하기 위해서는 자신의 생각을 공유하고 맞추는 것이 중요하다는 것을 경험했으며 내가 하고 의견을 당당하게 말할 수 있는 용기가 있어야하며 주장할 수 있어야 한다는 것을 알았습니다. 좋은 SW를 만들기 위해서는 지속적인 피드백을 받아야하며 우리는 매일  저녁에 10~20분정도 서로의 파트를 공유하므로 피드백을 받고 보완해 가면서 내가 생각하지 못했던 부분을 알수 있었으며 다음 부분을 생각 할 수 있었습니다. 그리고 새로운 것들이 추가 되면서 복잡해지기 쉬운데 이것을 단순하게 정리하고 만드는 것도 필요하다고 생각이 들었습니다.