Software Engineering(10)
-
Project Management ZenHub
ZenHub Private Repository 사용 시 비용 지급이 필요합니다. 관련 툴 Github Project Beta (https://docs.github.com/en/issues/trying-out-the-new-projects-experience/about-projects) Azure DevOps Board (https://azure.microsoft.com/en-us/services/devops/boards/) Zenhub (https://www.zenhub.com/) 설치 및 사용방법 Chrome web store에서 ZenHub for GitHub를 설치합니다. (즉, Safafi browser 등에서는 사용할 수 없습니다) 설치하게되면, repository에 다음과 같이 Zenhub t..
2023.01.30 -
WBS (Work Breakdown Structure)
작성 시기 요구사항 정의 완료 후 작성 실제 작업에 들어가기 전에 작성하게 됨 WBS 작성자 PM or PL or 기획자가 작성에 대한 기획 상세 항목은 담당자가 작성 - 문서 양식을 배포하여 작성 요청 WBS 작성 항목 작업항목 및 내용 작업자, 일정
2022.11.30 -
Agile scrum
PMO Project Management Office 전체 프로젝트 관리 PM (Project Manager) 프로젝트 관리 이해관계자 간의 커뮤니케이션을 통한 조율 업무별 일정/이슈 관리 관리자의 필요 역량 리더십 동기부여 명확한 업무 수행 의사소통능력 이해일치를 위한 의사소통 관리 적절한 위임 문제 예방 및 해결 프로세스 구축 요구사항 목표 설정 요구사항 도출 acceptance test 도출 업무 처리 프로세스 agile scrum을 통한 build up (continuous development) 회의 daily scrum daily or (bydaily) scrum 진행 scrum 진행 진행중인 업무 진행 사항(done or doing), 진행할 업무(todo) 사항에 대해서만 간단히 논의 문제..
2022.11.11 -
Project Manager 역할
PM의 역할 제품, 서비스와 같은 결과물을 정해진 일정과 리소스를 활용하여 결과를 만들어 내는 것 PMBOK(Project Management Body of Knowledge)에서 정의하는 PM의 역할 통합 관리: 통합 관리 계획을 수행 범위 관리: 요구사항을 수집, 정의 및 변경 관리 일정 관리: 활동 정의 및 일정 관리 비용 관리: 비용 측정 및 예산 책정 관리 품질 관리: 품질 관리 계획에 따른 품질 관리 자원 관리: 자원을 확보 및 팀 관리 의사소통 관리: 의사소통 관리 리스크 관리: 리스크 식별 및 대응 조달 관리: 결과물 조달 계획 관리 이해관계자 관리: 이해관계자 식별 및 관리 요구사항의 수집부터 개발 자원 및 품질 확보를 관리하고 최종 결과물을 조달하는 과정까지 총체적인 관리를 수행한다. ..
2022.01.09 -
좋은 가독 방법 (code reading, 코드 리딩)
코드 reading 방법 코드의 reading 시에는 핵심부분만 이해하도록 한다. 리눅스 토발즈 역시 “How to work”가 아닌 “What to do”만 파악함을 강조 했다. What to do는 전체 code의 30% 이하 Interface를 통한 design을 통해서 전체의 흐름과 관련있는 부분만 파악한다. Encapsulation으로 abstraction을 강조한다. Static function, private member와 같은 것들은 전체 흐름과는 크게 상관없는 코드인 경우가 대부분이다. 여러 coding pattern을 익혀 놓는다. (e.g., Design pattern, Refactoring by Martin Fowler) ex. Iterator, document-view patter..
2021.12.19 -
UML은 언제 사용하는가?
UML vs. code UML의 작성이 code의 작성보다 더 쉬운가? 소스 코드를 변경하는 것이 오히려 더 쉬울때도 있다. 그러니, UML을 남용하지 말자! test하기에 definitive한 것을 얻고자 할때 UML을 사용한다. code의 test보다 UML의 test가 더 쉽다. -> 디자인의 review를 coworker와 함께 할때, 당연히 abstract한 UML이 용이함 Why UML? Coding 전에 comprehensive한 design을 해야 하는 이유? blueprint의 잘못을 design 단계에 발견하여 수정하는 것이 휠씬 cheaper! 그런데.. software에서도 같은가? 사실 UML design에 더 많이 시간을 쏟는 경우가 많음 그러니, structural engine..
2021.12.19