Atualmente, estou trabalhando com um professor da minha universidade para desenvolver novos currículos para os cursos de Engenharia de Software e Design Capstone oferecidos em minha faculdade.
Até recentemente, os dois cursos usavam exclusivamente o modelo em cascata e, portanto, os alunos passavam a maior parte do tempo escrevendo relatórios longos. Depois de muita pressão minha, meu professor decidiu incluir o Scrum no currículo de Engenharia de Software no semestre passado.
A primeira metade do semestre ainda era em cascata, com os alunos escrevendo relatórios de design de 40 páginas e documentos de especificação de software. No meio do semestre, todas as equipes foram solicitadas a lançar uma demonstração de seus aplicativos. Nesse ponto, o curso mudou para o Scrum, com dois sprints de 3 semanas. Agora estamos tentando descobrir como eliminar a cascata completamente e criar um currículo exclusivamente baseado em Scrum.
Infelizmente, encontramos algumas incompatibilidades entre o Scrum e os alunos:
- As reuniões diárias do Scrum são quase impossíveis para os alunos. Mesmo durante a aula em si, é inconveniente que os alunos realizem reuniões do Scrum, pois o professor geralmente está dando palestras.
- A estimativa de pontos / horas é difícil, pois os alunos são inexperientes e, portanto, não podem prever com precisão quanto tempo levará algo.
- O Scrum funciona melhor com desenvolvedores localizados em período integral, mas os alunos também não. No máximo, os alunos dedicam 15 a 20 horas por semana ao curso, e a organização de reuniões de trabalho pode ser extremamente difícil. As equipes podem ter até 10 alunos (e sempre há um ou dois preguiçosos).
- Professores anseiam por documentação! Não ouvi nenhum relatório do Scrum - apenas as listas de pendências e gráficos de burndown (que não tenho certeza serão suficientes para apaziguar os acadêmicos).
- Os alunos geralmente assumem que ágil significa "Entre diretamente e comece a codificar sem olhar para trás". Isso leva a alguns dos códigos mais horríveis que se possa imaginar. Portanto, estou procurando uma maneira de aplicar o design adequado sem exigir um documento de 50 páginas ou uma pilha de diagramas UML.
Dado esses problemas, como você acha que meu professor e eu podemos adaptar o Scrum para funcionar em um ambiente acadêmico (e deveríamos nos preocupar com o Scrum em primeiro lugar)? Além disso, ainda há valor em ensinar o modelo em cascata?
Agradecemos antecipadamente por qualquer feedback!
fonte
Respostas:
Eu hesitaria em descartar o Waterfall de maneira tão rápida.
Embora seja um modelo defeituoso para a construção de sistemas de software, não é um mau modelo de ensino instruir sobre boas práticas para cada estágio do ciclo de vida. Independentemente do modelo de processo aplicado ao projeto, você ainda executa a engenharia de requisitos, a arquitetura e o design do sistema, a implementação, o teste, a liberação e a manutenção (incluindo refatoração e aprimoramento). A diferença é como essas fases são organizadas e conduzidas, mas todas as atividades ainda acontecem.
Eu diria que sua transição de Waterfall para Scrum no meio do projeto não é a melhor idéia. Uma chave para o sucesso do Scrum é um projeto de longa duração. Os primeiros três a cinco sprints são a equipe que decide a velocidade, aprende o processo e passa pelo desenvolvimento da equipe. Embora você esteja fazendo os movimentos, não é realmente o Scrum nesse ponto. Além disso, tentar criar um currículo exclusivamente baseado em Scrum é provavelmente uma má idéia, pois o Scrum não é uma bala de prata - é melhor ensinar as melhores práticas do que uma única metodologia. Na força de trabalho, nem todos os projetos vão usar o Scrum. De fato, em alguns ambientes, o Scrum seria prejudicial ao sucesso do projeto.
Você já encontrou problemas com o Scrum em um ambiente acadêmico, e alguns deles são difíceis de resolver adequadamente.
O não problema em sua lista de incompatibilidades é que a estimativa é difícil. Sim, ele é. Mas a única maneira de melhorar a estimativa é estimar e comparar dados reais com estimativas. Os alunos devem estimar tamanho, tempo e esforço usando vários meios (histórias, linhas de código-fonte, horas, páginas, horas-pessoa) com antecedência, para que estejam mais preparados para fazer isso depois de se formarem e ingressarem na força de trabalho.
A necessidade de documentação é algo que pode ser abordado tanto da perspectiva do professor quanto da perspectiva dos alunos. As abordagens Lean nos dizem que a documentação que não agrega valor à equipe ou ao cliente é um desperdício (em termos de tempo e custo). No entanto, é necessária alguma documentação para atingir alguns objetivos, tanto do aluno quanto do professor (cliente / cliente), para diversos fins. No geral, parece uma oportunidade para ensinar alfaiataria de processos e gerenciamento quantitativo de projetos (que também desempenham um papel nos métodos ágeis).
Com relação às reuniões e agendamento do Scrum, há duas idéias que me vêm à mente. A primeira é que isso indica que o Scrum pode não ser o melhor processo para uso em um ambiente acadêmico. Não existe um "melhor modelo de processo" singular para projetos de software, com fatores como cronograma, equipe, visibilidade e experiência da equipe de desenvolvimento (entre outros).
No geral, eu sugiro enfatizar boas práticas, adaptação de processos e melhoria de processos por meio de metodologias únicas. Isso permitirá que você seja o mais eficaz para todos os participantes dos cursos e os exponha a uma variedade de metodologias de processo e entenderá quais são as melhores práticas para um determinado conjunto de condições.
Como você está trabalhando para criar um currículo universitário, darei uma visão geral de alto nível de como o currículo de engenharia de software da universidade em que participei se encaixou.
Foi uma engenharia de software introdutória que passou pelo projeto em um modelo em cascata, com as palestras durante cada fase correspondendo a diferentes maneiras de conduzir as atividades daquela fase. As equipes progrediram nas fases na mesma proporção. Ter esses limites claramente definidos se encaixou bem no modelo de ensino para um grupo de pessoas sem experiência mínima trabalhando em equipes para criar software. Ao longo do curso, foram feitas referências a outras metodologias - vários métodos ágeis (Scrum, XP), Rational Unified Process, Spiral Model - com relação a suas vantagens e desvantagens.
Em termos de atividades, houve cursos específicos para discutir engenharia de requisitos, arquitetura e design (dois cursos - um focado no design detalhado usando métodos orientados a objetos e outro focado na arquitetura do sistema), vários cursos focados no design e implementação de vários classes de sistemas (sistemas embarcados e em tempo real, sistemas corporativos, sistemas concorrentes, sistemas distribuídos etc.) e testes de software.
Existem também três cursos dedicados ao processo de software. Gerenciamento de processos e projetos de engenharia de software, focado nas melhores práticas para gerenciar um projeto de software com relação a várias metodologias. Um segundo curso de processo ensina medições, métricas e melhoria de processos (enfatizando CMMI, Six Sigma e Lean). Finalmente, existe um curso de processo que ensina o desenvolvimento ágil de software (Scrum, Extreme Programming, Crystal, DSDM discutido) usando um projeto realizado usando a metodologia Scrum.
O projeto capstone era um projeto de dois quartos que foi realizado para uma empresa patrocinadora e executado inteiramente pela equipe do projeto do aluno, com orientação dos patrocinadores e de um orientador do corpo docente. Todos os aspectos de como conduzir o projeto são com os alunos, dentro de quaisquer restrições estabelecidas pelos patrocinadores. Os únicos prazos estabelecidos pela universidade eram uma apresentação intermediária a meio caminho (10 semanas) do projeto, uma apresentação final no final e uma apresentação em pôster em quadriciclo pouco antes do final. Todo o resto dependia do patrocinador e da equipe.
fonte
Quando fiz meu mestrado em engenharia de software, houve um curso chamado Processo de Software que lidava com XP, Scrum e outras abordagens ágeis. Essencialmente, toda a turma formou uma empresa de software hipotética e foi instruída a desenvolver um software bastante elaborado durante o período do curso. As palestras eram sobre coisas como práticas de XP, reuniões de pé, etc.
A maioria dos estudantes já ouviu falar sobre essas técnicas e geralmente gosta de aplicá-las. É claro que não há como forçar a equipe a trabalhar de forma iterativa, etc. Mas esse foi o objetivo do curso: tornar-se uma motivação para realizar muitas reuniões curtas, trabalhar iterativamente, fazer construções contínuas etc. porque você descobre rapidamente é simplesmente a maneira mais fácil e confiável de produzir algo de valor com um grupo de pessoas e com uma pequena quantidade de tempo.
Uma coisa a lembrar: certifique-se de jogar bem o cliente e alterar alguns requisitos importantes no meio. Ou "esqueça" de mencioná-los inicialmente.
fonte
O objetivo é facilitar o desenvolvimento, ou aprender Scrum, ou - meu palpite - ambos? Eu consideraria sprints mais curtos para acelerar o processo de aprendizado.
Talvez você possa substituir as stand-ups diárias por uma forma menos rigorosa, quando funcionar melhor para os alunos. Além disso, nem todos precisam participar de todas as reuniões.
Estimar o tempo do calendário é ainda mais difícil, pelos mesmos motivos :-) Com os pontos da história, você não estima quanto tempo levará algo: estima o tamanho relativo. Duração é derivada.
Talvez tente com equipes menores? 10 está na escala superior para uma equipe Scrum. Acho que você também pode ter sucesso com equipes distribuídas em período integral, mas é claro que é mais difícil! Que isso seja uma lição em si.
O Scrum não determina que tipo de documentação é necessária. Por uma questão de fato, nem mesmo os gráficos de burndown são obrigatórios. Isso não significa que a documentação seja proibida: a equipe deve produzir a documentação necessária, incluindo os relatórios que os professores julgarem necessários.
Não apenas os alunos :-) A maioria das equipes do Scrum usa práticas de XP como TDD (Test Driven Development) e refatoração: proponho que você incorpore isso nos currículos.
Sim, pelo menos por duas razões: primeiro, não é certo que seus alunos usem o Scrum em sua vida profissional e, segundo, imagino que seja mais fácil entender a essência do desenvolvimento ágil se você tiver algo para comparar.
fonte
Parece um pouco semelhante a um assunto que tirei uma vez.
Alguns pensamentos:
fonte
Meu conselho é separar e isolar o que você está tentando ensinar. Se for um curso de design de software ou algum outro assunto de engenharia de software (algoritmos ou outros enfeites), concentre-se nisso. Se envolver SCRUM se tornar um obstáculo (como você sugere), não se preocupe.
Como fizemos isso quando eu estava na faculdade foi fazer um curso dedicado para metodologias ágeis. O curso incluiu um projeto de desenvolvimento que deveria ser executado de acordo com o SCRUM ou XP. O software real a ser entregue era trivial, pois o foco do curso não era programação ou design, mas processo. O raciocínio aqui é o mesmo do motivo pelo qual você não deve misturar assuntos de desenvolvimento de software "hard core" com assuntos de metodologia, pois um tende a eclipsar o outro e os alunos geralmente não estão prontos ou qualificados o suficiente para lidar com ambos nesse estágio.
Os resultados do curso eram coisas como relatórios de planejamento de sprint, relatórios de progresso semanais, retrospectivas, relatórios de burndown e, a cada semana, tínhamos pelo menos duas sessões que incluíam uma reunião de stand-up / scrum em grupo onde os ATs circulavam e ouviam.
Este curso também incluiu TDD (Test Driven Development) e funcionou muito bem.
Certamente é. Muitas empresas usam versões desse modelo para seus projetos (PPS, RUP, PROPS etc.). Muitos acham (corretamente, na minha opinião) que SCRUM "puro" é mais adequado para manutenção contínua do que projetos. O SCRUM (e o Agile em geral) exigem uma certa flexibilidade no escopo e a possibilidade de negociar requisitos e entrega ao longo do caminho. Nem todos os projetos funcionam assim, são binários: entregar X no ponto Y no tempo, tudo o mais é uma falha.
fonte
O objetivo de um curso acadêmico de Engenharia de Software é ensinar aos estágios fundamentais do ciclo de vida do software - análise, design, implementação, teste, juntamente com o uso de padrões reais de qualidade de software, em vez do código regular de qualidade da lição de casa.
Há valor em demonstrar a prática usando um processo que não seja em cascata ; no entanto, devido às razões pelas quais você indicou que o SCRUM não é um processo adequado - os alunos fazem muitos cursos por semestre, muitos também têm empregos reais enquanto estudam, portanto, você não pode ter 100 % de membros dedicados da equipe ou realizam reuniões diárias.
Considere usar um processo iterativo menos ágil, como UP (RUP).
Para mostrar o valor comparado ao processo em cascata, altere os requisitos entre as iterações. Isso mostrará a diferença entre UP e a cascata e sugerirá o valor do uso de processos ágeis.
Demonstrar a cachoeira depois disso será redundante, pois a UP cobre todos os estágios da cachoeira.
Como os semestres são relativamente curtos, duas pequenas iterações seriam realistas.
Forneça uma estrutura ampla para os alunos usarem, pois a ênfase deste curso não deve ser a profundidade da implementação; existem outros cursos para isso; em vez disso, deve enfatizar padrões de codificação e testes de unidade.
Durante o curso, as palestras ensinam a teoria de alguns processos, por exemplo, cascata, UP, XP, SCRUM e Kanban (junto com outros tópicos, como requisitos de escrita, UML, testes e etc.).
Para os alunos que concluíram o curso acima, considere um workshop SCRUM separado como um curso eletivo, que leva um período de duas semanas em período integral durante o semestre de verão.
fonte
O Scrum funciona se você tiver um projeto de semestre / semestre e a turma for dividida em grupos de 6 a 10 pessoas. Depois, você pode dedicar os últimos 10 minutos do horário da aula à reunião do scrum.
fonte