Eu aprendi que Kanban é um método para implantação/gerenciamento de mudanças. Acabei marcando errado por isso. Penso que nada impede que esse método seja aplicado em desenvolvimento de software (e, de fato, o é), principalmente quando estamos falando de mudanças no âmbito das metodologias ágeis. Mas, daí dizer que kanban é um método DE desenvolvimento de software, acho um pouco demais. Pois abre para a interpretação de que Kanban foi concebido para desenvolvimento de software: o que, pelo pouco, ou quase nada, que sei, não seria uma verdade.
Dificilmente, a CESPE alteraria o gabarito dessa assertiva. O meu histórico de recursos (naturalmente, uns mais bem fundamentados que outros) me ensinou que examinadores geralmente são um tanto quanto bitolados nesse sentido e preferem não enxergar para além de sua zona de conforto técnico. Além do mais, "pega mal" para eles o fato de uma de suas questões escolhidas (muito bem pagas, diga-se de passagem) ser anulada ou ter seu gabarito alterado. Em todo caso, fica o protesto e abertura para discussão/aprendizado.
Abs,
Engraçado como a gente vai abstraindo de alguns detalhes que percebemos que não são importantes para acertar questões de concursos públicos, li meu comentário feito em dezembro de 2015 e aproveitei para atualizá-lo com um novo entendimento postado recentemente em outra questão.
Um framework pode ter um conceito muito próximo ou até convergente ao de uma metodologia. Basta darmos uma "pesquisada" rápida que constataremos a "salada".
De acordo com os conceitos que normalmente me aproprio* para facilitar o meu entendimento, concordo que o Scrum tem um aspecto mais próximo ao de um framework do que de uma metodologia. Mas, na boa, não há o mínimo consenso, seja no âmbito dos concursos públicos, seja no âmbito dos profissionais do mercado privado, seja no meio acadêmico sobre o que seria um framework.
Para complicar ainda mais essa discussão, o livro Implantando a Governança de TI, dos autores Aragon Fernandes e Ferraz de Abreu, diz explicitamente, na página 384, que Scrum é uma metodologia ((...) "a metodologia Scrum foi concebida" (...)). E esse livro é muito usado pelas bancas de concursos públicos.
Quanto ao Kanban, defendê-lo como uma metodologia é "doído" demais. Mas, da mesma forma como acontece com o Scrum, encontramos com facilidade referências a essa ferramenta (também prefiro chamar assim) como framework, como sistema, como técnica e até (pasmem!) como metodologia (e isso em artigos sérios).
Conclusão, não me apegaria a isso, tanto no caso do Scrum como no caso do Kanban, como algo determinante para avaliar uma questão de concurso.
Outro ponto que gostaria de comentar é em relação ao gabarito: Incremental diz respeito a algo que adiciona uma parte que antes não existia. É como se fosse a adição de um novo módulo que sequer existia na versão anterior de um software. É como se adicionássemos uma nova peça a um produto.
Iterativo é algo que melhora uma parte que antes já existia em determinado estágio de evolução. É como se fosse a melhoria de um módulo anteriormente elaborado (ou pré-elaborado). É como se fosse um ajuste em uma peça de um produto.
Assim, temos que o Kanban é linear (orientado a fluxo). Nele, uma tarefa (ou atividade, ou entrega) entra de um lado e sai do outro. Pronto! Podemos dizer, assim, que houve um incremento, quando aplicável. Podemos até utilizar o Kanban dentro de uma iteração de modo a forcecer subsídios (entregáveis) para a mesma (e quando ele é utilizado em conjunto com o Scrum, é exatamente isso que acontece dentro de uma Sprint), mas não é essa (a iteração) a preocupação do Kanban, ele é focado, como dito anteriormente, em fluxo. Concordo com o gabarito.
Referente a ao parágrafo anterior, sugiro uma leitura em http://www.netobjectives.com/blogs/real-differences-between-kanban-and-scrum , item Flow vs. Iterations.
Sorte para os que cuidam dela.
* estrutura conceitual básica; esqueleto