A-RMS By 313DEVGRP

요구사항에 대한 이해도가 낮은 개발자, DBA, 기타 IT 프로젝트 관련 작업자들에게서 나타나는 전형적인 문제나 현상은 다음과 같습니다: 🔴 1. 잘못된 방향의 개발 (Misaligned Implementation) 기능 오해: 사용자 요구와 다른 기능을 구현함 (예: 입력폼은 만들었지만 저장이 안 됨). 과잉 개발 / 과소 개발: 필요 이상의 복잡한 기능을 만들거나, 중요한 기능을 빠뜨림. 🔴 2. 반복적인 수정과 재작업 […]

요구사항(Requirements)과 ALM(Application Lifecycle Management) 내의 이슈(Issue)를 연결하여 관리하는 것은 프로젝트 관점에서 다음과 같은 중요한 장점들을 제공합니다: ✅ 1. 추적 가능성(Traceability) 확보 요구사항이 어떤 이슈(버그, 개선, 작업 등)로 이어졌는지, 그리고 그 이슈가 어떻게 해결되었는지를 전 과정에 걸쳐 추적할 수 있습니다. 이는 특히 감사(Audit), 품질 보증(QA), 규정 준수(Compliance) 측면에서 매우 유리합니다. ✅ 2. 변경 영향도 분석(Change Impact […]

프로젝트의 성공은 단순히 일정 준수나 예산 관리에 그치지 않습니다. 진정한 성공은 핵심 역량에 집중할 수 있는 환경을 만드는 것에서 시작됩니다. 복잡하고 반복적인 프로젝트 관리 업무에 발목 잡히고 있다면, 지금이 바로 전환점입니다. A-RMS가 제공하는 본질적 가치 A-RMS(Advanced Resource Management System)는 단순한 프로젝트 관리 도구가 아닙니다. 기업의 전략적 사고와 실행력을 연결해주는 스마트한 운영 파트너입니다. 자동화된 일정 및 […]

요구사항을 정의하다 보면 너무 크거나 추상적인 요구사항(epic)도 생기고, 반대로 너무 작고 세부적인 요구사항(micro task 수준)도 생깁니다. 이런 경우엔 요구사항의 크기(granularity)를 적절히 조절해서 계층적으로 정리하는 레벨링 작업이 필요합니다. 아래는 과도하게 큰 요구사항과 과도하게 작은 요구사항을 레벨링하는 방법을 정리한 거예요. ✅ 1. 과도하게 큰 요구사항 → 분할하기 (Decomposition) 문제 너무 포괄적이고 모호해서 개발하거나 테스트하기 어려움 흔히 Epic(에픽) […]

IT 프로젝트에서 PM이 요구사항의 개별 진척도를 ISSUE 기반으로 확인하는 것이 어려운 이유는 여러 가지가 있습니다. 1. ISSUE 단위와 요구사항 단위의 불일치 요구사항은 일반적으로 큰 단위(Feature, Epic 등)로 정의되지만, ISSUE는 더 작은 작업 단위(Task, Bug, Story)로 관리됩니다. 하나의 요구사항이 여러 개의 ISSUE로 쪼개지면서, 개별 ISSUE의 상태를 보고 요구사항 전체의 진척도를 파악하기 어려울 수 있습니다. 2. ISSUE의 […]

나는 아래글의 내용에 몇가지 의문을 제기한다. 개발자의 성과를 측정하는 지표가. Code 에 한정되어 있다는 것이다. 물론 틀린말은 아니다. 아니. 틀렸다. 우리는 생각을 확장 시켜야 한다. 이런 생각을 해 보았는가? ” 개발자가 목표하는 바가 무엇인가? “ ” 어떤 지시를 받고, 이런 코드를 생산하고 있는가? “ 코드의 생산성이 개발자의 성과가 아니다. 회사의 성과 기준은. 개발자에게 지시했던 요구사항이 […]

PLE의 정의 소프트웨어를 개발할 때 체계적인 재사용 기법을 적용함으로써 동일 영역에서 다양하게 특화된 소프트웨어를 신속하게 개발할 수 있는 효과적인 매커니즘을 제공하는 접근 방법 컴포넌트가 플러그인 될 수 있는 프레임워크를 제공하는 아키텍처를 기반으로 필요한 컴포넌트를 선택적으로 조립함으로써 시장의 요구사항에 맞는 시스템을 생산하는 방식PLE의 등장 배경 컴포넌트 기반의 개발 자체가 재사용성을 높여주지 않음 재사용성을 고려해 주의 깊게 […]

A-RMS 솔루션 개발을 완료 했습니다.지난 10년간의 노력으로 IT 현실을 바로잡을 소프트웨어 이며,요구사항 기반의 ( requirement ) 프로젝트 관리 시스템 입니다.많은 관심을 부탁드리며, 곧 실제 사례를 기반으로어떻게 IT 회사의 고질병을 고쳐서 경쟁력을 확보하는지 증명하도록하겠습니다. 많은 기대 부탁드립니다.

출처 : A Three-Step Framework For Solving Problems 문제 해결을 위한 3단계 프레임워크 에어비앤비에 입사해 배운 점 중 하나는 무엇보다도 문제 정의를 올바르게 하는 것이 중요하다는 것입니다. 프로젝트를 실패로 이끄는 많은 요인이 있지만 해결 중인 문제를 오해하는 것보다 더 확실한 건 없습니다. 에어비엔비에서 저와 팀이 해결해야 할 진짜 문제는 “여행자가 다른 여행자와 어울리고 싶어한다”가 아니라 […]

출처 : https://www.thestartupbible.com/2024/03/business-before-technology.html참조 : https://313.co.kr/php/gnuboard5/bbs/board.php?bo_table=notice&wr_id=16&page=2 회사의 가장 중요한 목표는 돈을 벌 수 있는 제품과 서비스를 만드는 건데, 굉장히 많은 개발자들이 자신에게 월급을 주는 회사의 목표와는 상관없는 생각과 행동을 한다는 것이었다. 개발자들이 항상 명심해야 하는 건 바로 이들이 해결하고자 하는 문제의 솔루션이 본인들이 소속된 기업의 비즈니스 목표와 매출에 직접적으로 기여해야 한다는 점이다. 개발자들도 회사의 조직원이고, 모든 스타트업 조직원의 목표는 단 […]