…Houve um tempo em que eu achava que métodos ágeis eram um excelente álibi para programador preguiçoso. E, ainda hoje, as vezes fico pensando sobre o significado do nome “ÁGIL”. Será que esse nome contempla, de fato o seu propósito, ou é um nome meramente “marketeiro”? Veja só: No dicionário, o significado de “ágil” é ser rápido e flexível, por sua vez, no dicionário, o antônimo de ágil é lento e vagaroso. Ora, ninguém quer ser taxado como lento e vagaroso! Sendo assim, se eu não quero ser taxado de lento e vagaroso, então por eliminação eu sou ágil.
Esse clichê formado sobre a palavra ÁGIL distorceu um pouco as coisas. Muitas empresas e desenvolvedores que não conseguiam implantar processos de desenvolvimentos de software maduros, e que por muitas vezes cairam no mito da Fantástica Fábrica de Software, começaram a se intitular como ágil. Nesse contexto continuo achando que métodos ágeis são um excelente álibi para programador preguiçoso.
A questão é que desenvolver software é uma tarefa que dependente de tecnologia, processos, e, sobretudo, do conhecimento das pessoas. Como já diria Fred Brooks em seu famoso artigo No Silver Bullet, não existe bala de prata, não existe ferramenta, metodologia ou qualquer outra mágica que resolva milagrosamente todos os problemas.
Segundo [Filho, 2008]: “em uma organização imatura os mesmos problemas se repetem de projeto em projeto, o trabalho é excessivo e estressante e frequentemente há a necessidade de corridas desesperadas contra os prazos, a qualidade de vida no trabalho é ruim, o ambiente é desgastante e os profissionais são desmotivados. Os erros relativos ao processos de desenvolvimento de software são comuns em organizações que utilizam processos imaturos, ocorrendo também naquelas que possuem processos rígidos, complexos e burocráticos e naquelas em que os processos apesar de existirem são seguidos parcialmente, ou em última instância, não são seguidos.”
Não obstante, o mercado tem exigido produtos de software ainda mais sofisticados e em prazos de desenvolvimento mais curtos. A referida exigência, tem instigado a pesquisa na área engenharia de software, objetivando encontrar meios para garantir que o software seja produzido atendendo às expectativas do cliente e aos atributos de qualidade definidos pela organização fornecedora de software e esperados pelo mercado.
Antes de enfatizar a importância da agilidade do processo, é preciso entender o que ela realmente significa. Em suma, é a capacidade que uma organização possui para responder rapidamente às forças , fraquezas, oportunidades e ameaças do mercado. Há inúmeras situações práticas, onde agilidade do processo é altamente desejado, incluindo: apresentando um novo produto, entrar em um novo mercado, responder à entrada de concorrentes, responder a alterações de requisitos em produtos em construção, etc.
Outro aspecto, é que o processo de desenvolvimento de software é complexo e precisa favorecer a criatividade e a inovação, e ter um nível adequado de flexibilidade para beneficiar a engenharia de processos na melhoria contínua. O grande desafio na proposta de um processo é conseguir um conjunto de regras que guiem o desenvolvimento sem comprometer a criatividade e a motivação dos desenvolvedores e sem travar a organização para a constante evolução da tecnologia e as adequações necessárias.
Uma abordagem adotada para romper a barreira da imaturidade é a definição de um processo de desenvolvimento de software padrão. O referido processo descreve as atividades que devem ser realizadas no desenvolvimento de software em todos os projetos da organização. A idéia é que isso favoreça que a organização atinja a conformidade com os padrões de qualidade esperados. Na literatura existem várias definições para processos de desenvolvimento de software:
- “Uma sequência de passos executadas para um determinado propósito; por exemplo, o processo de desenvolvimento de software.” [IEEE, 1994]
- “Um processo ´e um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos práticas e transformações usado para atingir uma meta.” [Filho, 2008]
- “O processo de software ´e um conjunto de atividades que leva à produção de um produto de software.” [Sommerville, 2007]
De forma bem resumida, o processo de desenvolvimento de software formal descreve por meio da sua documentação: o que é feito , quando é feito, por quem é feito, como é feito, além dos insumos que usa e os produtos de saída. Em outras palavras, o processo enfatiza a padronização para possuir um parâmetro de medida e de controle e para poder circunscrever o erro em busca de qualidade. Contudo, embora seja necessário definir um processo de desenvolvimento de software, só isso não é suficiente para a construção satisfatória de um software. Existem vários fatores envolvidos que influenciam diretamente a construção do software, por exemplo: a capacitação das pessoas envolvidas, as tecnologias e ferramentas utilizadas, a cultura organizacional, entre outros.
Um processo de desenvolvimento de software não é definido do zero. Na literatura existem vários modelos que descrevem orientações para a definição e implantação de processos, dentre eles a ISO 12207/15504, CMMI e MPS-BR. Nesta linha, o processo de desenvolvimento de software deve estabelecer :
- atividades a serem realizadas durante o processo, sua estrutura e organização (decomposição e precedência), incluindo a definição de um modelo de ciclo de vida quando pertinente;
- artefatos requeridos e produzidos por cada uma das atividades do processo;
- procedimentos (métodos, técnicas, roteiros e padrões) a serem adotados na realização das atividades;
- recursos necessários (humanos, hardware e software) para a realização das atividades.
Em busca de eliminar a imaturidade, as organizações investem em definir e implantar um processo baseando-se em modelos de maturidade como CMMI e MPS-BR. Entretanto, esses modelos são densos, repletos de subprocessos que devem ser implementados em cada área de processo de cada nível de maturidade (no caso de CMMI) .
Um nível de maturidade é um patamar evolutivo bem definido que que “determina” a capacidade que uma organização possui em desenvolvimento de software. Cada nível visa alcançar um processo de desenvolvimento de software cada vez mais maduro. Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de forma continua. Assim, os níveis de maturidade são cumulativos, ou seja, um nível de maturidade mais alto inclui os atributos dos níveis mais baixos. Uma vez que os modelos são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade provêem uma ordem recomendada para abordar a melhoria de processo dentro de cada área de processo.
É esperado que a cada nível alcançado pela organização, mais madura ela se torna em desenvolvimento de software. Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos. Para que isso seja alcançado, um bom processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Essa equipe trabalha constantemente na garantia e no controle de qualidade do processo e do produto, respectivamente.
Quando uma organização atinge o nível 5 no CMMI ou A do MPS-BR, ela entra em um espiral de melhoria continua. A equipe de projeto e a equipe de qualidade reportam para a equipe de definição de processo gargalos e deficiências do processo atual, e complementam com sugestões para melhoria de processo. A equipe de definição de processo por sua vez avalia todas as sugestão, e, se pertinentes, implantam a melhoria no processo. Isso se torna um ciclo de inspeção e adaptação do processo. Quanto mais madura a equipe, menos atividades de inspeção técnica e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto. Veja o post sobre Conformidade com o Produto vs. Conformidade com o Processo.
No gráfico acima tentei ilustrar o que percebo sobre a agilidade de processos. Quando se fala em agilidade em processo, já estamos condicionados a pensar em métodos ágeis de desenvolvimento de software como Scrum, eXtreme Programming , princípios Lean etc. No entanto, agilidade, na essência, se aplica em um ambiente de desenvolvimento formal também. No início, quando a organização não possui nenhum processo definido o ambiente não é estável, e, frequentemente, ela depende da competência e heroísmo das pessoas para atingir seus objetivos. Neste ambiente, a rigidez de processo é baixa, informal e caótico, mas apesar disso as organizações muitas vezes produzem produtos e serviços que funcionam. Entretanto, elas freqüentemente estão expostas a vários problemas de projeto como: exceder o orçamento e o cronograma planejado, baixa qualidade, não cumprir compromissos, abandonar processos em momentos de crises e não ser capazes de repetir sucessos do passado.
Para não ficar tão expostas aos problemas de projeto citados, as organizações partem para implantação de processos, e, a medida que esses processos são implantados e os níveis de maturidade de processo são obtidos, mais “rígido”, mais “burocrático” o processo se torna. No entanto, entendo que a tão criticada rigidez e burocracia de processos formais é uma fase transitória, de aprendizado, de padronização e, sobretudo de amadurecimento. Nos níveis mais altos de maturidade o objetivo é a simplificação, a “des-burocratização” de processo. Lendo isto alguém poderia estar perguntando: “Ora! Então porque a organização não vai direto para esse estado?” Bom, imagino que isso se torna necessário na caminhada da Imaturidade à Agilidade.
