[Mendix] Agile 소프트웨어 개발 방법론 1 - Intermediate 자격증 공부 - DevelopMoon

 

1. 애플리케이션 수명 주기 관리(Application Lifecycle Management)

• 애플리케이션 수명 주기 관리(ALM)는 애플리케이션의 시작부터 종료까지 모든 단계를 포괄하는 관리 프로세스이다.
• Mendix는 앱을 처음 시작하는 단계부터 수명이 다할 때까지 모든 단계를 지원할 수 있다.
• Mendix에서 ALM을 구현하는 방법의 단계는 4가지로 분류된다.
  • Capture(포착)
    • 앱의 수명 주기가 시작되는 곳이다.
    •  Mendix는 다양한 협업 기능을 제공하여 아이디어 창출 프로세스를 지원한다.
    •  예를 들어, Buzz를 사용하여 팀원과 브레인스토밍하고, 질문을 하고, 여론 조사를 설정하고, 결정을 내릴 수 있다.
  • Develop(개발하다)
    • Mendix는 모든 팀원이 서로 협업할 수 있는 시스템을 제공한다.
    • Mendix Portal과 Team Server를 사용하여 앱 개발 프로세스를 동기화하고 제어한다.
    • 버전 제어(Version Control)를 사용하면 여러 개발자의 작업을 단일 버전으로 조정할 수 있다.
  • Deploy(배포하다)
    • 앱을 테스트하거나 출시할 준비가 되면 Mendix는 한 번의 클릭으로 배포 단계를 처리한다.
    • 사용자는 모바일(mobile), 랩톱(laptop) 또는 기타 기기에서 직접 액세스 할 수 있다.
  • Interate/Feedback(반복, 피드백)
    • 사용자가 액세스 하면 앱에서 직접 피드백을 제공할 수 있다.
    • 피드백은 개발자가 Mendix Portal에서 보고 처리할 수 있다.
    • 이 단계에서 두 번째 캡처 단계가 시작되는데 앱이 완료될 때까지 필요에 따라 주기가 반복되며 이를 반복(Interate)이라고 한다.
• ALM을 지원하는 이유
  • 혁신적인 애플리케이션을 빠르게 개발하려면 빠른 실험(rapid experimentation), 빈번한 반복(frequent iteration), 비즈니스와 IT 간의 긴밀한 협업(close collaboration between business and IT)이 필요하다. 따라서 Mendix는 배포에 초점을 맞추지 않고, 애플리케이션 수명 주기의 각 단계를 지원한다.

 

2. 프로젝트 방법론(Project Methodology)

수년 동안 소프트웨어 개발자들은 Waterfall과 같은 정의된 작업 및 프로젝트 관리 방법을 사용해 왔다. 하지만 현재 시장의 요구 사항은 빠르게 변하고, 프로젝트 요구 사항은 쉽게 복잡해질 수 있기 때문에, Waterfall 프로젝트의 기간이 길어질수록 위험이 증가한다.

혁신적인 애플리케이션을 개발하려면 빠른 실험, 빈번한 반복, 그리고 비즈니스와 IT 간의 긴밀한 협업이 필수적이다. 이런 이유로 Agile 방법론이 중요하게 자리 잡고 있다.

 

Agile 방법론의 장점

• Agile은 속도와 민첩성을 우선시하여 프로젝트의 생산성과 결과를 향상시킨다.
• Agile은 여러 개의 짧은 개발 주기를 활용하는 여러 반복적이고 점진적인 소프트웨어 개발 접근 방식을 포괄하는 용어이다.

Agile 프레임워크의 예시

• 스크럼(Scrum): Agile 방법론 중 가장 인기 있는 방식이며, Mendix에서 사용하도록 설계된 방법이다.
• 칸반(Kanban), 익스트림 프로그래밍(Extreme Programming) 등도 Agile의 다양한 프레임워크이다.

스크럼(Scrum) 방법론

• 스크럼은 Agile 방법론 중 가장 많이 사용되는 방법으로, 이벤트 주기, 작업 흐름, 그리고 팀 역할에 대한 명확한 정의를 기반으로 한다.
• Mendix는 스크럼 방식에 맞춰 설계되어, 팀들이 효율적으로 협업하고 빠르게 개발할 수 있도록 돕는다.

 

3. 앱 역할(App Roles)

스크럼에서는 소규모의 교차 기능 팀을 갖는 것이 중요하다.

• 이는 더 효과적인 커뮤니케이션, 더 쉬운 문서화, 그리고 더 빠른 지식 전달을 가능하게 하기 때문이다.
• 각 Scrum 프로세스는 성공하기 위해 몇 가지 중요한 역할이 필요하다.
• 제품 소유자, Scrum 마스터, 개발 팀이다. 이러한 역할은 모두 Scrum 팀을 구성한다.

 

Scrum 팀의 구성 및 역할

• 제품 소유자(The Product Owner)
  • 제품 소유자는 이해관계자의 기대치를 추적하고, 앱에 대한 비전과 요구 사항을 정의한다.
• Scrum 마스터(The Scrum Master)
  • Scrum 마스터는 스크럼 팀이 스크럼 방법론에 따라 작업할 수 있도록 돕고, 팀 내의 프로세스를 최적화하는 데 집중한다. 또한, 팀이 통제할 수 없는 일로 인해 막히면, 장애물 제거를 담당한다.
• 개발팀(Development Team)
  • 개발팀은 실제로 앱을 빌드하는 사람들로 구성된다. (Mendix에서는 보통 엔지니어, 디자이너, 아키텍트, 테스터 등 2~3명으로 구성된다.)

Mendix 프로젝트의 스크럼

Mendix 앱 프로젝트 내에서는 기본적으로 사용할 수 있는 몇 가지 프로젝트 역할이 있다.

Mendix에서 개발자는 Business Engineers라고 한다.

• 스크럼 마스터(Scrum Master)
  • Scrum Master는 일반적으로 앱 내에서 가장 많은 관리 권한을 갖는다.
  • 팀이 작을 때 일반적으로 팀원 중 한 명이 개발자 외에도 Scrum Master 역할을 맡는다.
• 성능 엔지니어/테스터 및 애플리케이션 운영자
  • 팀에는 성능 엔지니어 또는 테스터, 애플리케이션 운영자를 둘 수 있다.
  • 이들은 앱이 원활하게 작동하는지 모니터링하여 최신 버전을 배포할 수 있는 역할을 맡는다.
  • 다만, 이들은 앱을 직접 개발하지는 않으며, 앱의 성능 및 안정성을 보장하는 데 중점을 둔다.
• 이해 관계자와 최종 사용자 역할
  • 이해 관계자에게 최종 사용자 역할을 할당하여 초기 아이디어 단계부터 참여할 수 있도록 할 수 있다.
  • 최종 사용자는 앱의 기능을 경험하고 피드백을 제공하는 중요한 역할을 담당하지만, 앱을 직접 편집하거나 수정할 권한은 없다.
• 역할 관리 및 커스터마이징
  • Mendix에서는 프로젝트의 요구 사항에 맞춰 추가적인 프로젝트 역할을 설정하거나 기존 역할의 권한을 수정할 수 있다.
  • 하지만 일반적으로는 기본 제공 역할만으로도 충분히 프로젝트를 운영할 수 있다.
• Mendix Portal의 Team 페이지 관리
  • Mendix Portal의 Team 페이지에서는 프로젝트 팀과 관련된 모든 작업을 수행할 수 있다.
  • 여기에서 새 멤버를 초대하고, 기존 멤버를 삭제하며, 각 멤버의 역할과 권한을 관리할 수 있다.
  • 이를 통해 팀이 유연하게 협력할 수 있도록 돕고, 역할에 따라 프로젝트 진행을 효과적으로 분배할 수 있다.

사용자 스토리(User Stories)

사용자 스토리는 사용자의 요구를 작업할 수 있는 항목으로 변환하는 방법이다.

사용자 스토리의 목표는 개발팀이 작업을 시작하기 전에 무엇을 작업해야 하는지 결정하는 데 있다.

이 사용자 스토리는 여러 스토리를 포함하는 에픽(더 큰 단위나 큰 범위의 작업 묶음)으로 그룹화할 수도 있다.

• 제품 백로그(Product Backlog)
  • 새로운 사용자 스토리는 제품 백로그에 추가된다.
  • 제품 백로그는 수행할 수 있는 작업 항목 목록이다.
  • Scrum 팀의 모든 사람이 제품 백로그에 항목을 추가할 수 있지만, 이해 관계자와 협의하여 항목의 우선순위를 정하는 것은 제품 소유자(Product Owner)의 책임이다.
• 스프린트(Sprint)
  • 스프린트는 팀이 특정 목표를 달성하려고 하는 고정된 기간이다.
  • 스크럼 방식에서는 정해진 시간 상자인 스프린트가 있기 때문에 별도로 마감일을 추정하거나 시간을 할당하지 않는다.
  • 보통 스프린트는 2주 동안 진행된다.
• 에픽(Epic)
  • 에픽은 사용자 스토리를 체계화하는 좋은 방법이다.
  • 에픽에서는 사용자 스토리를 추가 및 제거할 수 있으며, 에픽 소유자를 지정하고 완료된 스토리의 진행 상황을 확인할 수 있다.
• 사용자 스토리 작성 시 고려해야 할 세 가지 사항
  • 사용자 스토리 작성 시 "[사용자 유형]으로서 [무엇]을 원하므로 [비즈니스 가치]가 필요하다"라는 형식을 사용한다. 
  • 내 앱의 최종 사용자는 누구입니까? [사용자 유형]
    • Who is my app’s end-user? [user type]
  • 최종 사용자는 무엇을 해야 합니까? [비즈니스 가치]
    • What does the end-user need to do? [business value]
  • 그들이 그렇게 할 수 있도록 어떻게 도울 수 있나요? [무엇]
    • How can I help them do that? [what]

와이어프레임(Wireframe)

와이어프레임은 사용자 스토리처럼 작업을 시작하기 전에 무엇을 작업할지 결정하는 방법이다.

이는 개발하려는 앱의 기본 기능을 설계하는 쉬운 시각적 방법이다.

와이어프레임을 작성하는 매체는 중요하지 않으며 화이트보드, 디자인 소프트웨어, 또는 간단한 종이를 활용해도 충분하다. 완벽하거나 세부적인 구조까지 필요하지 않으며, 기본적인 인터페이스 구조만 구상해도 된다.

• 와이어프레임의 목적
  • 와이어프레임은 개발을 시작하기 전에 인터페이스 디자인의 불확실성을 줄일 수 있는 시각적 도구이다.

 

2024.11.08 - [IT/Mendix] - [Mendix] Agile 소프트웨어 개발 방법론 2 - Intermediate 자격증 공부 - DevelopMoon

[Mendix] Agile 소프트웨어 개발 방법론 2 - Intermediate 자격증 공부 - DevelopMoon

 

---

Reference

https://academy.mendix.com/link/paths