Qual é o impacto do ITIL ou CMMI no desenvolvimento?[fechado]

Question

Li muitos livros sobre quais práticas funcionam bem ou não no desenvolvimento de software.E NUNCA ouvi falar de metodologias como ITIL ou CMMI em nenhum webcast, livro ou blog na área de desenvolvimento.

Já ouvi falar dessas metodologias na minha escola e me parecem práticas burocráticas.

No entanto, todos os livros sobre desenvolvimento que li falam sobre colaboração ou pessoas sobre documentação.(Sim, muitos livros ágeis)

Então minha pergunta é:Metodologias como ITIL ou CMMI têm algum impacto ou relação com o desenvolvimento ou com o dia a dia do desenvolvedor?E você tem ótimos livros ou blogs que falam sobre algumas boas ideias nessas metodologias que posso usar em uma equipe de desenvolvimento?

Answer 1

O ITIL está mais focado na infraestrutura e no lado do suporte e não no desenvolvimento; portanto, a discussão do ITIL é provavelmente mais apropriada na versão do StackOverflow focada em "TI" que supostamente está em desenvolvimento.Além disso, discordo ao chamar esse outro site de "TI" focado, já que TI abrange infraestrutura, suporte e desenvolvimento na maioria das empresas...provavelmente uma boa porcentagem de usuários do StackOverflow são desenvolvedores em departamentos de TI.

Trabalhei com CMMI e Team Software Process (TSP), ambos produtos da Watts Humphrey e do Carnegie Mellon Software Engineering Institute.Se você está comprometido com a melhoria contínua e acredita que a medição está no centro de qualquer melhoria contínua, então você encontrará valor no CMMI.

É muito fácil fazer o CMMI (e o TSP) de maneira errada ou de uma forma que afaste os desenvolvedores e acabe como uma fachada ou algo que fica bem em uma pilha de certificações.Veja os fornecedores de desenvolvimento na Índia... eles são milagrosamente todos CMMI nível 5.O que eles não dizem é que quase sempre houve um pequeno projeto ou equipe em sua organização que trabalhou duro para obter a certificação, mas as práticas repetíveis simplesmente não existem para 95% de sua organização.

O foco no controle de tempo (pontuação do relógio), rastreamento de defeitos (cotas de bugs), linhas de código (muitas maneiras de "jogar" se você quiser) e em tornar seu processo repetível (fazendo um desenvolvedor se sentir como uma engrenagem sem liberdade para inovar) desanimam muitos desenvolvedores.<- observe os contra-argumentos desgastados entre parênteses.

O fato é que 90% dos desenvolvedores por aí (poucos dos quais leem StackOverflow ou quaisquer blogs/sites técnicos) disparam com entusiasmo e carecem de autoconsciência de onde residem suas oportunidades de melhoria.Para eles, o rigor do processo e a oportunidade de fazer melhorias incrementais na qualidade através da autoconsciência que a repetição e a medição facilitam são componentes valiosos do CMMI.

Feito da maneira certa, você obtém os mesmos benefícios de métodos ágeis como Scrum, onde novamente o foco está em iterações repetíveis, aprendendo com cada iteração e melhorando/restringindo seu objetivo.É preciso muita maturidade e experiência para liderar uma equipe na adoção de métodos Agile ou CMMI e obter valor total deles.

Agile é sexy e CMMI está longe de ser sexy, e é por isso que você não ouve falar tanto sobre isso.

Answer 2

A adoção ágil tende a ser de baixo para cima: os técnicos tropeçam e o recomendam à gerência.

O ITIL/CMMI tende a ser de cima para baixo: a gerência tropeça nele e o empurra para os técnicos.

Isso não torna um bom e o outro ruim; Principalmente isso afeta a linguagem usada para descrever cada abordagem. E há muitas exceções - pessoas com experiência nas trincheiras que são boas em aplicar o CMMI e gerentes que se divertiram.

Google para "ágil cmmi" e você receberá muitos hits. Prefiro não recomendar um em particular, porque é um debate em andamento (ou seja, algumas dessas pessoas estão simplesmente erradas).

Na minha opinião, a noção de processo é certamente uma idéia útil ao analisar o trabalho diário de desenvolvimento de software. A idéia de que existem algumas atividades recorrentes e que essas atividades são frequentemente organizadas em seqüências semelhantes, é um bom ponto de entrada para fazer perguntas que levam à melhoria. Você também pode obter alguma milhagem perguntando o que é Repetivel e em que condições as atividades podem ser chamadas gerenciou.

O erro e os excessos começam quando o pensamento mágico se instala: "Se apenas descrevermos (no papel) o processo perfeito e o documentamos com precisão, as pessoas o seguirão e obteremos software perfeito". Não funciona dessa maneira.