Agile 프로세스로 업무 효율성 향상

Source: Dev.to

Agile란

Agile은 짧은 주기(Sprint)로 작업을 진행하는 소프트웨어 개발 방법론으로, 고객의 요구에 지속적으로 그리고 유연하게 대응할 수 있도록 설계되었습니다.

Waterfall과 Agile의 차이점

Waterfall

• 작업 단계가 순차적으로 진행됩니다: Analysis → Design → Implementation → Testing → Deployment → Release & Maintenance
• 최종 결과물은 전체 프로세스가 끝난 뒤에 고객에게 보여집니다.
• 시간과 비용이 고정되지 않으며, 고객이 변경을 원할 경우 시간과 비용이 추가될 수 있습니다.

Agile

• 작업을 짧은 주기(Sprint)로 나누고, 각 주기마다 Re‑plan을 반복합니다.
• 테스트와 개발이 동시에 이루어져 고객 요구에 지속적으로 대응합니다.
• 각 Sprint의 결과물은 “Knowledge”와 “Practice”이며, 팀이 학습하고 개선하는 데 활용됩니다.

Agile의 역사

• Individuals and Interactions – 사람과 커뮤니케이션을 최우선으로 합니다.
• Agile Manifesto는 12가지 원칙(Agile Principles)을 포함하고 있으며, 예를 들어 Continuous Delivery: 고객 가치를 지속적으로 제공합니다.

Agile 프레임워크

Scrum (가장 인기 있는 1위)

• 1‑4주 길이의 Sprint로 작업합니다.
• 역할
  • Product Owner (PO) – “무엇을 할지”를 정의하고 작업의 우선순위를 정합니다.
  • Scrum Master – 장애물을 제거하고 팀이 Scrum 프로세스를 따르도록 관리합니다.
  • Development Team – 실제 작업을 수행하는 팀(예: Go 개발자).
• 핵심 의식
  • Daily Stand‑up (15분 아침 회의)
  • Sprint Planning
  • Sprint Retrospective

Kanban

• Sprint와 같은 시간 구분 없이 작업 흐름(Flow)에 초점을 맞춥니다.
• Work in Progress (WIP)를 과도하게 늘리지 않도록 관리합니다.
• Kanban Board 사용: To Do → Doing → Done
• Support, Maintenance 혹은 높은 유연성이 요구되는 팀에 적합합니다.

XP (Extreme Programming)

• 코드 품질을 극대화합니다.
• 기법
  • Pair Programming – 2명이 한 화면에서 코딩
  • Test‑Driven Development (TDD) – 실제 코딩 전에 테스트를 작성 (Go의 testing 패키지가 우수)
  • Refactoring – 지속적인 코드 개선

Lean Software Development

• 고객에게 가치를 제공하지 않는 낭비(Eliminate Waste)를 제거하여 가장 빠르게 전달합니다.

Scaling Agile (대규모 조직용)

• SAFe (Scaled Agile Framework) – 대기업 수준에서 Agile을 관리합니다.
• Spotify Model – 팀을 Squads, Tribes, Chapters, Guilds로 나누어 팀 자율성을 높입니다.

제품을 고객에게 전달하는 원칙 (Release Product)

• 지속적으로 가치를 전달하고 각 주기마다 고객 만족도를 검증합니다.
• 테스트와 피드백을 활용해 제품을 지속적으로 개선합니다.

Agile 작업 계획

1. Product Owner (PO) 가 고객/사용자와 대화하여 요구사항을 수집합니다.
2. PO는 요구사항을 팀과 논의하고 Product Backlog / Sprint Backlog 를 작성합니다.
3. Agile Project Charter 를 작성하여 Vision, Mission, Success Metrics 를 포함합니다.
4. PO는 사용자의 관점에서 User Story 를 생성합니다.
5. Kanban Board (Todo / Doing / Done) 를 만들어 작업을 관리합니다.
6. Sprint 시작 시 PO는 Product Backlog에서 User Story를 선택해 Todo 칸에 배치하고 우선순위를 정합니다.
7. PO가 Sprint Goal 을 선언합니다 – Sprint 내에 테스트하고 전달할 내용.
8. 팀은 각 User Story에 대해 Task 를 세분화합니다.
9. Story Points 를 Estimate(예: Planning Poker) 로 지정합니다.
10. Sprint Burndown Chart 를 작성합니다
    • X축: 남은 Task 수
    • Y축: 작업 일수
    • 파란선은 Benchmark, 빨간선은 실제 진행 상황
    • 빨간선이 Benchmark보다 크게 위에 있으면 작업이 많이 남은 것이므로 계획을 조정해야 합니다.
11. Sprint 중간에 Backlog Refinement 를 진행해 검토하고 필요 시 Re‑plan 합니다.
12. 매일 Daily Stand‑up 을 15분 이내로 진행합니다.
13. Sprint 종료 후 Sprint Review (Product Demo)를 진행합니다.
14. Retrospective (Less of / More of / Keep doing / Start doing / Stop doing)를 통해 학습 내용을 정리하고 프로세스를 개선합니다.