Scrum은 어떻게 학업 환경에 적응할 수 있습니까?

저는 현재 대학 교수와 협력하여 대학에서 제공하는 소프트웨어 엔지니어링 및 캡 스톤 디자인 과정을위한 새로운 커리큘럼을 개발하고 있습니다.

최근까지 두 코스는 모두 폭포수 모델을 독점적으로 사용했기 때문에 학생들은 대부분의 시간을 긴 보고서를 작성하는 데 보냈습니다. 저로부터 많은 압력을받은 후, 교수님은 지난 학기 소프트웨어 엔지니어링 커리큘럼에 스크럼을 포함 시키기로 결정했습니다.

학기 전반기는 여전히 폭포 식으로 구성되어 있으며 학생들은 40 페이지 분량의 디자인 보고서와 소프트웨어 사양 문서를 작성합니다. 학기 중반에 모든 팀은 애플리케이션 데모를 공개해야했습니다. 이 시점에서 코스는 3 주 동안 두 번의 스프린트로 스크럼으로 전환되었습니다. 우리는 이제 폭포를 완전히 제거하고 독점적으로 스크럼 기반 커리큘럼을 만드는 방법을 알아 내려고 노력하고 있습니다.

불행히도, 우리는 Scrum과 학생들 사이에 비 호환성이 발생했습니다.

• 학생들에게는 일일 스크럼 회의가 거의 불가능합니다. 수업 중에도 교수가 강의를하기 때문에 학생들이 스크럼 회의를 개최하는 것은 불편합니다.
• 학생들이 경험이 없어서 시간이 얼마나 걸리는지 정확하게 예측할 수 없기 때문에 포인트 / 시간을 추정하는 것은 어렵습니다.
• 스크럼은 함께 배치 된 풀 타임 개발자와 가장 잘 작동하지만 학생도 마찬가지입니다. 대부분의 학생들은 일주일에 15-20 시간을 코스에 전념하며 업무 회의를 조직하는 것은 매우 어려울 수 있습니다. 팀에는 최대 10 명의 학생이있을 수 있습니다 (그리고 항상 한두 개의 슬랙 커가 있습니다).
• 교수들은 문서를 갈망합니다! 나는 Scrum 보고서에 대해들은 적이 없다. 백 로그와 번 다운 차트 만 (학계를 달래기에 충분하지는 않다).
• 학생들은 종종 애자일이 "바로 들어 가지 않고 코딩을 시작합니다"를 의미한다고 가정합니다. 이것은 상상할 수있는 가장 끔찍한 코드로 이어집니다. 따라서 50 페이지짜리 문서 나 UML 다이어그램을 요구하지 않고 적절한 디자인을 적용 할 수있는 방법을 찾고 있습니다.

이러한 문제를 감안할 때, 교수님과 저는 학문적 환경에서 기능하도록 스크럼을 어떻게 조정할 수 있다고 생각하십니까? 또한 폭포 모델을 가르치는 데 여전히 가치가 있습니까?

모든 의견에 미리 감사드립니다!

폭포를 너무 빨리 버리고 버리는 것을 망설 이겠습니다.

실제로 소프트웨어 시스템을 구축하기위한 결함이있는 모델이지만 수명주기의 각 단계에 대한 모범 사례를 가르치는 것은 나쁜 교수 모델이 아닙니다. 프로젝트에 적용하는 프로세스 모델에 관계없이 엔지니어링, 시스템 아키텍처 및 설계, 구현, 테스트, 릴리스 및 유지 관리 (리팩토링 및 향상 포함) 요구 사항을 계속 수행합니다. 차이점은 이러한 단계가 어떻게 구성되고 수행되는지에 따라 다르지만 모든 활동이 여전히 발생합니다.

프로젝트 중간에 Waterfall에서 Scrum으로 전환하는 것이 최선의 아이디어는 아니라고 주장합니다. 스크럼의 성공 비결은 장기 프로젝트입니다. 처음 3 ~ 5 개의 스프린트는 팀이 속도를 결정하고 프로세스를 학습하며 팀 개발을 진행하는 것입니다. 모션을 수행하고 있지만 실제로는 스크럼이 아닙니다. 또한 독점적으로 Scrum 기반 커리큘럼을 만들려고하는 것은 아마도 은총 알이 아니라 Scrum처럼 나쁜 생각 일 것입니다. 단일 방법론보다는 모범 사례를 가르치는 것이 좋습니다. 노동력에서 모든 프로젝트가 Scrum을 사용하지는 않습니다. 실제로 일부 환경에서 Scrum은 프로젝트의 성공에 해를 끼칠 수 있습니다.

학업 환경에서 이미 스크럼 관련 문제를 발견했으며 그 중 일부는 적절하게 다루기가 어렵습니다.

비 호환성 목록에서 비 문제는 추정이 어렵다는 것입니다. 그렇습니다. 그러나 견적을 더 잘 얻는 유일한 방법은 추정값과 실제 값을 추정하고 비교하는 것입니다. 학생들은 다양한 방법 (스토리 포인트, 소스 코드, 시간, 페이지, 인적 시간)을 사용하여 규모, 시간 및 노력을 조기에 예측하여 직원을 졸업하고 입학 한 후에 더 준비 할 수 있도록해야합니다.

문서화의 필요성은 교수의 관점과 학생들의 관점 모두에서 다룰 수있는 것입니다. 린 접근법은 팀이나 고객에게 가치를 더하지 않는 문서가 낭비된다고 말합니다 (시간과 비용 측면에서). 그러나 다양한 목적으로 학생과 교수 (고객 / 고객) 모두의 목표를 달성하기 위해서는 일부 문서가 필요합니다. 전반적으로 프로세스 맞춤 및 정량적 프로젝트 관리 (민첩한 방법에서도 역할을 수행함)를 가르 칠 수있는 기회 인 것 같습니다.

스크럼 회의 및 일정과 관련하여 두 가지 아이디어가 있습니다. 첫 번째는 이것이 스크럼이 학업 환경에서 사용하기에 가장 좋은 과정이 아닐 수 있음을 나타냅니다. 일정, 인력, 가시성 및 개발 팀의 경험과 같은 요소를 포함하여 소프트웨어 프로젝트에 대한 "최상의 프로세스 모델"은 없습니다.

전반적으로 단일 방법론에 비해 모범 사례, 프로세스 조정 및 프로세스 개선을 강조하는 것이 좋습니다. 이를 통해 코스를 수강하는 모든 사람에게 가장 효과적이며 다양한 프로세스 방법론에 노출하고 주어진 조건 세트에 대한 모범 사례를 이해할 수 있습니다.

당신이 대학 교육 과정을 구축하기 위해 노력하고 있기 때문에, 나는 얼마나 높은 수준의 개요주지 소프트웨어 공학 교과 과정을 상기 대학은 내가 참석 적합 함께합니다.

기초 소프트웨어 엔지니어링은 폭포 모델로 프로젝트를 진행했으며 각 단계마다 강의가 해당 단계의 활동을 수행하는 다양한 방법에 해당했습니다. 팀은 같은 속도로 단계를 진행했습니다. 명확하게 정의 된 경계를 갖는 것은 소프트웨어를 개발하기 위해 팀에서 작업 한 경험이 최소 인 그룹의 사람들을위한 교육 모델에 잘 맞습니다. 이 과정에서 장점과 단점에 대한 다양한 민첩한 방법 (Scrum, XP), Rational Unified Process, Spiral Model과 같은 다른 방법론을 참조했습니다.

활동 측면에서 요구 사항 엔지니어링, 아키텍처 및 디자인 (객체 지향 방법을 사용한 세부 설계에 중점을 둔 하나와 시스템 아키텍처에 중점을 둔 하나)을 논의하는 특정 코스가있었습니다. 시스템 클래스 (실시간 및 임베디드 시스템, 엔터프라이즈 시스템, 동시 시스템, 분산 시스템 등) 및 소프트웨어 테스트.

소프트웨어 프로세스 전용 세 코스도 있습니다. 여러 가지 방법론과 관련하여 소프트웨어 프로젝트를 관리하기위한 모범 사례에 중점을 둔 소프트웨어 엔지니어링 프로세스 및 프로젝트 관리. 두 번째 프로세스 과정은 측정, 메트릭 및 프로세스 개선 (CMMI, Six Sigma 및 Lean 강조)을 교육합니다. 마지막으로 Scrum 방법론을 사용하여 수행 된 프로젝트를 사용하여 민첩한 소프트웨어 개발 (Scrum, Extreme Programming, Crystal, DSDM)을 가르치는 프로세스 과정이 있습니다.

주춧돌 프로젝트는 후원 회사를 위해 수행 된 2/4 프로젝트로, 후원자와 교수진의지도로 학생 프로젝트 팀이 전적으로 운영합니다. 프로젝트를 수행하는 방법의 모든 측면은 후원자가 제시 한 모든 제약 내에서 학생들에게 달려 있습니다. 대학에서 요구하는 유일한 마감일은 프로젝트에 중간 (10 주)의 중간 프리젠 테이션, 마지막 프리젠 테이션, 마지막 포스터 프리젠 테이션이었습니다. 그 밖의 모든 것은 스폰서와 팀의 의견에 달려 있습니다.

소프트웨어 엔지니어링 석사 학위를 받았을 때 XP, Scrum 및 기타 민첩한 접근 방식을 다루는 소프트웨어 프로세스라는 과정이있었습니다. 기본적으로 전체 학급은 가상의 소프트웨어 회사를 구성했으며 과정이 진행되는 동안 상당히 정교한 소프트웨어를 개발하도록 지시 받았습니다. 이 강의는 XP 관행, 스탠드 업 회의 등과 같은 것들에 관한 것이 었습니다.

대부분의 학생들은 이러한 기술에 대해 들어 보았으며 일반적으로 적용하는 데 열심입니다. 물론 팀이 실제로 반복적으로 작업 하도록 강요 할 수 있는 방법은 없습니다 . 그러나 실제로 과정의 핵심은 바로 짧은 회의를 많이 개최하고, 반복적으로 작업하고, 지속적으로 빌드하는 등 동기 부여가되는 것입니다. 그것은 한 무리의 사람들과 적은 시간으로 가치있는 것을 생산할 수있는 가장 쉽고 신뢰할 수있는 방법입니다.

기억해야 할 한 가지 : 고객을 잘 플레이하고 일부 핵심 요구 사항을 반쯤 변경해야합니다. 또는 "잊어"처음에 언급하는 것.

이 시점에서 코스는 3 주 동안 두 번의 스프린트로 스크럼으로 전환되었습니다. 우리는 이제 폭포를 완전히 제거하고 독점적으로 스크럼 기반 커리큘럼을 만드는 방법을 알아 내려고 노력하고 있습니다.

개발을 촉진하거나 스크럼을 배우는 것이 목적입니까? 학습 속도를 높이기 위해 짧은 스프린트를 고려할 것입니다.

• 일일 스크럼 회의는 학생들에게 거의 불가능합니다. 수업 중에도 교수가 강의를하기 때문에 학생들이 스크럼 회의를 개최하는 것은 불편합니다.

아마도 학생들에게 가장 적합한 매일 스탠드 업을 덜 엄격한 형태로 교체 할 수 있습니다. 또한 모든 사람이 모든 회의에 참여할 필요는 없습니다.

• 학생들이 경험이 없어서 시간이 얼마나 걸리는지 정확하게 예측할 수 없기 때문에 포인트 / 시간을 추정하기가 어렵습니다.

같은 이유로 달력 시간을 추정하는 것이 훨씬 더 어렵습니다. 기간이 도출됩니다.

스크럼은 함께 배치 된 풀 타임 개발자와 가장 잘 작동하지만 학생도 마찬가지입니다. 대부분의 학생들은 일주일에 15-20 시간을 코스에 전념하며 업무 회의를 조직하는 것은 매우 어려울 수 있습니다. 팀에는 최대 10 명의 학생이있을 수 있습니다 (그리고 항상 한두 개의 슬랙 커가 있습니다).

더 작은 팀과 함께 시도 할 수 있습니까? 10은 Scrum 팀의 상위 규모입니다. 풀 타임이 아닌 분산 팀에서도 성공할 수 있다고 생각합니다. 물론 더 어렵습니다! 그것이 그 자체로 교훈이되게하십시오.

• 교수들은 문서를 갈망합니다! 나는 Scrum 보고서에 대해들은 적이 없다. 백 로그와 번 다운 차트 만 (학계를 달래기에 충분하지는 않다).

스크럼은 어떤 종류의 문서가 필요한지 지시하지 않습니다. 실제로, 번 다운 차트조차도 필수는 아닙니다. 그렇다고 문서가 금지 된 것은 아닙니다. 팀은 교수가 필요하다고 생각하는 보고서를 포함하여 필요한 문서를 작성해야합니다.

학생들은 종종 애자일이 "바로 들어 가지 않고 코딩을 시작합니다"를 의미한다고 가정합니다. 이것은 상상할 수있는 가장 끔찍한 코드로 이어집니다. 따라서 50 페이지짜리 문서 나 UML 다이어그램을 요구하지 않고 적절한 디자인을 적용 할 수있는 방법을 찾고 있습니다.

학생뿐만 아니라 :-) 대부분의 Scrum 팀은 TDD (Test Driven Development) 및 리팩토링과 같은 XP 관행을 사용합니다.

또한 폭포 모델을 가르치는 데 여전히 가치가 있습니까?

예, 적어도 두 가지 이유가 있습니다. 첫째, 학생들이 직장 생활에서 Scrum을 사용할지 확신하지 못합니다. 둘째, 비교할 무언가가 있으면 민첩한 개발의 본질을 이해하는 것이 더 쉽다고 생각합니다.

한 번 찍은 주제와 조금 비슷합니다.

몇 가지 생각 :

• 정말로 팀 전체 회의를 원하십니까? 서브 팀이 작동합니까?
• "돌아 보지 않고"가 리팩토링을 의미하지 않는다면 리팩토링의 증거를 평가합니까?
• 성찰과 문서 평가-학생들이 자신의 활동에 대한 블로그를 유지하도록합니다. (이것은 실제로 직장에서 꽤 유용한 기술입니다. 대부분의 공식 문서보다 훨씬 더 그렇습니다)
• 추정치가 나쁘면, 희망적으로 배우고 있습니다. 추정치와 현실 사이의 변화를 추적하고 차이점을 반영하며 그들이 무언가를 배웠다는 것을 입증 할 수 있습니까?
• 적절한 디자인을 문서화하는 덜 공식적인 방법이 있습니까?
• 일부 스크럼 회의에는 Skype 또는 Gchat 또는 무언가가 충분합니까?

저의 조언은 당신이 가르치려고하는 것을 분리하고 격리하는 것입니다. 소프트웨어 디자인이나 다른 소프트웨어 공학 주제 (알고리즘 또는 기타)에 관한 과정이라면 그에 집중하십시오. SCRUM과 관련된 것이 방해가된다면 (추천 하듯이) 귀찮게하지 마십시오.

제가 대학에있을 때 어떻게했는지는 민첩한 방법론을위한 전용 과정을 갖추는 것이 었습니다. 이 과정에는 SCRUM 또는 XP에 따라 실행될 개발 프로젝트가 포함되었습니다. 과정의 초점이 프로그래밍이나 디자인이 아니라 프로세스이기 때문에 제공 될 실제 소프트웨어는 사소한 것이 었습니다. 여기서의 추론은 "하드 코어"소프트웨어 개발 주제를 방법론 주제와 혼합해서는 안되는 이유와 동일합니다. 하나는 다른 주제를 식히는 경향이 있으며 학생들은 대부분 그 단계에서 모두 처리 할 준비가되어 있지 않거나 숙련되지 않았습니다.

강의 결과물은 스프린트 계획 보고서, 주간 진행 보고서, 회고, 번 다운 보고서 및 매주 최소 두 번의 세션으로, TA가 순환하고 청취 할 그룹 스탠드 업 / 스크럼 회의를 포함했습니다.

이 과정에는 TDD (Test Driven Development)도 포함되었으며 실제로 효과가있었습니다.

또한 폭포 모델을 가르치는 데 여전히 가치가 있습니까?

가장 확실합니다. 많은 회사에서이 모델의 버전 (PPS, RUP, PROPS 등)을 프로젝트에 사용합니다. 많은 사람들은 (정확하게는 제 생각에)“순수한”스크럼이 프로젝트보다 지속적인 유지 보수에 더 적합하다고 생각합니다. SCRUM (및 일반적으로 Agile)은 범위에있어 특정 유연성과 그에 따른 요구 사항 및 전달 협상 가능성을 요구합니다. 모든 프로젝트가 그런 식으로 작동하는 것은 아니며 바이너리입니다. Y 시점에 X를 전달하면 나머지는 모두 실패입니다.

아카데믹 소프트웨어 엔지니어링 과정의 핵심은 분석, 설계, 구현, 테스트, 규칙적인 숙제 품질 코드 대신 실제 소프트웨어 품질 표준을 사용하여 소프트웨어 수명주기의 기본 단계를 가르치는 것입니다.

비 폭포 과정을 사용하여 실습을 시연하는 데는 가치가 있습니다 . 그러나 당신이 의미하는 이유 때문에 SCRUM은 적절한 과정이 아닙니다-학생들은 학기당 많은 과정을 수강하고 많은 학생들은 공부하면서 실제 직업을 가지므로 100을 가질 수 없습니다 전담 팀원 비율 또는 일일 회의 실시

대신 UP (RUP)과 같이 덜 민첩한 반복 프로세스를 사용하십시오.

워터 폴 프로세스와 비교하여 값을 표시하려면 반복간에 요구 사항을 변경하십시오. 이것은 UP과 워터 폴의 차이점을 보여 주며 민첩한 프로세스 사용의 가치를 암시합니다.

UP이 모든 폭포의 단계를 포함하므로이 후 폭포를 시연하는 것은 중복됩니다.

학기는 비교적 짧기 때문에 2 번의 작은 반복이 현실적입니다.

이 과정의 강조는 구현의 깊이가 아니어야하고 다른 과정이 있으므로 코딩 표준과 단위 테스트를 강조해야하므로 학생들이 사용할 수있는 광범위한 프레임 워크를 제공하십시오.

강의 중에는 폭포, UP, XP, SCRUM 및 Kanban (작문 요구 사항, UML, 테스트 등)과 같은 몇 가지 프로세스 이론을 강의합니다.

위 과정을 수료 한 학생들은 별도의 SCRUM 워크숍을 여름 학기 동안 2 주 동안 풀 타임으로하는 ​​선택 과목으로 고려하십시오.

스크럼은 한 학기 동안 진행되는 프로젝트가 있고 수업이 6 ~ 10 명으로 구성된 경우에 효과적입니다. 그런 다음 마지막 10 분의 수업 시간을 스크럼 회의에 전념 할 수 있습니다.