일할때 현타오는 부분

구현보다도 이슈가 터지면 어떤 이유에서 터진건지 개선점 모색. 다만 개선한줄 알았는데 개선이 아닌경우도 있음. 백프레셔가 생길수도 있고 (어떤 경우에서든지) 여러 문제점이 있는데 그중 하나만 인지하는 경우도 있음. 로드테스트 하지 않는 이상 스케일링 관련한 이슈일 때 테스팅/스테이징 환경에서 프로덕션 비슷한 레벨의 트래픽 구현하기가 어려움. 다만 하이레벨에서의 구조적인 이슈는 인지하는 경우는 많음. 그래도 선뜻 고치기 보다는 어떻게 고칠지 RFC라던지를 통해서 팀원이나 아키텍트들한테 코멘트 요청하는게 좋음. 본인이 간과한 부분이 있을수도 있고. 본인의 구현방식에 대해서 추후에 생길수 있는 이슈들에 대해서 질문을 할수도 있기때문임.

그리고 여러팀이 협동하는 경우 일정 맞춰서 개발및 프로젝트 진행 (여기에 마이그레이션 같은거 끼어져있으면 골치아픔)

스크럼보다 좀 더 안정적인건 워터폴이 맞는듯.. 다만 워터폴은 유연하지가 않음. 외주회사에서 계약주고 할때 괜찮음. 이번 계약은 여기까지 개발 이런식으로..

서비스 회사면 스크럼 나쁘지는 않은듯 한데 뭔가 중구난방임. 에픽단위로 나누면 큰 틀에서 보이기는 하는데 뭔가 세세하게 안보임. 지라 + 에어테이블/노션 등등 정보가 나뉘어져있을때도 많음.