[SE] 4주차 Discussion

첫 번째 디스커션

과제 1: 가장 경험이 많은 팀원이 프로젝트 중간에 떠난다면 어떻게 하겠는가?

• 하나하나 기록하면서 문서화를 진행한다.
• 새로운 팀원을 데려온다.
• 그 사람이 해왔던 일들을 빠르게 파악하고, 남아 있는 인원들에게 역할을 분배한다.

Task 1: What would you do if your most experienced team member leaves mid-project?

• Document everything step by step.
• Bring in a new team member.
• Quickly analyze the tasks the departed member was handling and redistribute roles among the remaining team members.

과제 2: 우리는 정말 모든 위험을 계획할 수 있는가?

• 모든 위험을 계획할 수는 없다고 생각한다.
• 최대한 모든 위험을 인지하고 계획하는 것은 좋지만, 때로는 오히려 더 비효율성이 많을 것 같다.
• 그러나, 우선순위를 세워서 높은 우선순위에 대해서 최대한 준비해보는 것이 좋을 것 같다.
• 행동을 하기 전에 해당 행동이 어느 정도의 리스크를 가져올지 식별하는 것이 필요하다.
• 사례: 공연 때 해야 하는 멘트를 하지 못했던 부분, 마이크를 미리 켜놓지 못하는 점으로 인해 발생한 리스크

Task 2: Can we really plan for every risk?

• I don’t think it’s possible to plan for every risk.
• Identifying and planning for as many risks as possible is good, but sometimes it can lead to inefficiency.
• However, setting priorities and preparing as much as possible for high-priority risks seems like a good approach.
• Before taking action, it is necessary to assess the level of risk associated with it.
• Example: There were cases where small risks occurred, such as forgetting planned remarks during a performance or failing to turn on the microphone in advance.

과제 3: 도메인 지식이 전혀 없는 상태에서 소프트웨어 프로젝트를 계획하는 방법은?

• AI 관련 프로젝트를 진행하려고 할 때, AI를 다룰 수 없는 사람들이 존재할 수 있다.
• 관련해서 알고 있거나 할 수 있는 사람들을 데려온다.
• 관련 지식을 찾거나, 자문을 구할 수 있는 사람들에게 컨택을 진행한다.

Task 3: How would you plan a software project with zero prior domain knowledge?

• For example, when working on an AI-related project, there may be team members who lack AI expertise.
• Bring in people who have knowledge or experience in the field.
• Search for relevant information or reach out to experts for consultation.

---

두 번째 디스커션

과제 1: 이상적인 팀의 조건은 무엇인가?

• 이상적인 팀은 상호 존중과 신뢰를 바탕으로 하며, 각 팀원이 자신의 역할에 책임을 느끼고 적극적으로 참여하는 환경을 조성해야 한다.
• 현실적으로 팀원 간의 갈등, 의사소통 문제 등이 발생할 수 있지만, 이를 해결하는 과정 또한 팀의 성장에 기여한다.

Task 1: What makes an ideal team?

• An ideal team should be based on mutual respect and trust, and create an environment where each team member feels responsible for their role and actively participates.
• In reality, there will be conflicts, communication issues, etc. between team members, but the process of resolving them will also contribute to the growth of the team.

과제 2: 스타트업과 대기업의 차이점은 무엇인가? (애자일 vs 워터폴 포함)

스타트업

• 스타트업의 경우 팀워크가 중요하다.
• 단기간 안에 성과를 보여줘야 하기에 팀워크가 더욱 중요하다.

대기업

• 대기업의 경우 워터풀처럼 정해진 방식과 업무가 있어 기술적인 역량이 더 중요하다.
• 많은 사람과 부서가 존재하기 때문에 업무가 세부적으로 나뉘어 있다.

애자일 vs 워터폴

• 애자일 환경에서는 팀 호환성이 더욱 중요하다. 빠른 피드백과 변화에 대응하기 위해서는 팀원 간의 협력이 필수적이다.
• 반면, 워터폴 방식에서는 초기 계획 단계에서 기술적 역량이 더 중요할 수 있다.

Task 2: Differences between startups and big companies (including Agile vs. Waterfall)?

• Startup: Teamwork is more important because they need to show performance in a short period of time.
• Big company: Technical skills are more important in a large company because there are set methods and tasks like a water pool. Because there are many people and departments, the work is divided into many details.
• Agile vs. Waterfall: In an agile environment, team compatibility is more important. Cooperation between team members is essential for quick feedback and responsiveness to change. On the other hand, in a waterfall approach, technical competence may be more important during the initial planning phase.

---

세 번째 디스커션

과제 1: 오늘날의 빠르게 변화하는 기술 스택에서도 COCOMO 스타일의 모델이 여전히 작동할 수 있는가?

• 과거의 경험을 기준으로 삼을 때 어느 정도까지 과거를 기준으로 삼을지 설정해야 할 것 같다.
• 특히 작은 것도 빠르게 수정하고 변화해 나가는 애자일 방식에서는 COCOMO 스타일의 모델이 작동하기 어려울 것 같다.
• COCOMO는 보편적인 기준으로 판단해서 결과를 내리고 있어 개개인의 특성을 반영하기 어렵다고 생각한다.

Task 1: Can the COCOMO-style model still work in today’s rapidly changing technology stack?

• We think we need to decide how much of the past we want to use as a guide.
• The COCOMO-style model will still be difficult to work with, especially for an agile approach where small changes are made quickly.
• COCOMO uses universal criteria to make decisions. I think it's difficult to identify individual characteristics.

과제 2: 소프트웨어 추정이 거의 항상 잘못되는 이유는 무엇인가?

• 경험 기반 접근법은 개발자의 주관적 판단에 의존하기 때문에 일관성이 떨어질 수 있다.
• 알고리즘 접근법은 정확한 데이터를 필요로 하는데, 데이터가 불완전하거나 불확실할 경우 결과가 왜곡될 수 있다.
• Next.js와 TypeScript를 사용하여 프론트엔드 개발을 진행했지만, 도입하기까지 어려웠다. 이는 새로운 기술을 도입할 때 예측하지 못하는 점이 있기 때문이라고 생각한다.
• 특히 많은 프로젝트들이 빠르게 변화하는 환경에서 실패하게 되므로, 기술 검증과 리서치에 많은 리소스를 할애해야 한다.

Task 2: Why is software estimation almost always wrong?

• Experience-based approaches can be inconsistent because they rely on the subjective judgment of developers.
• Algorithmic approaches require accurate data, which can skew results if the data is incomplete or uncertain.
• We've done front-end development with Next.js and TypeScript, but I found it difficult to adopt. Perhaps this is because there are unpredictable aspects of adopting new technologies.
• Especially since the reasons for many projects to fail are changing rapidly, you need to find a lot of resources for technology validation and research.