05 May 2014
Recentemente o Governo Federal abriu uma consulta pública para propostas de revisão da Instrução Normativa SLTI/MP Nº 4, de 12 de novembro de 2010, e suas atualizações. Isso é importante por que as regras atuais não estão proporcionado os resultados desejados. Nesse caso, isso significa que os sites e serviços de TI do governo não evoluem rápido o suficiente e não são adequados as necessidades dos usuários.
Eu acredito que, a medida que mais e mais cidadãos tem acesso a Internet, se torna cada vez mais importante oferecer serviços online de qualidade, e por isso colaborei com uma série de recomendações e estarei presente na audiência pública sobre o assunto. Compartilho aqui as 11 recomendações que eu fiz com base na IN04:
1
Contribuição: Estabelecer um tamanho máximo de equipe contratada ou um valor máximo do contrato.
Justificativa: Grandes projetos de TI oferecem maior risco para o contratante e reduzem o conjunto de possíveis contratados. Limitando a escala dos projetos – em combinação com uma simplificação das exigências para contratação – os órgãos conseguiriam ter acesso a serviços mais especializados e resultados mais rápidos.
2
Contribuição: Reduzir as exigências para contratações até um determinado valor (simplificação do estudo técnico preliminar e da análise de risco).
Justificativa: Uma das lamentações mais frequentes dos contratantes de software é o investimento necessário para fazer um edital (algumas estimativas falam de R$20.000,00 e meses de trabalho). Isso desestimula a realização de editais menores, e tem por consequência comprometer a agilidade do governo. Uma redução das exigências para contratos menores facilitaria este processo sem aumentar o risco para a União.
3
Contribuição: Utilizar resultados objetivos atingidos como critérios técnicos para seleção de fornecedores (por exemplo: aumento no número de cadastrados, taxa de retorno no site, diminuição nos número de pedidos de suporte).
Justificativa: Software público é feito para os cidadãos. A utilização de critérios que não são relacionados ao resultado gerado, cria uma série de incentivos perversos como a “compra” de certificações ou foco no processo em detrimento dos resultados.
4
Contribuição: Vedar a utilização de critérios técnicos que não são traduzidos em benefícios diretos ao usuário final nem dizem respeito a orientações estratégicas do governo (certificações, número de defeitos reportados em desenvolvimento).
Justificativa: Critérios técnicos indiretos estimulam o desperdício por não estarem vinculados a resultados e historicamente não tem gerado os resultados esperados de aumento da qualidade de entrega de software. Existem critérios que medem o resultado objetivo para o cidadão ou o comprometimento com políticas nacionais (como software livre). Estes devem ser estimulados.
5
Contribuição: Preferência por contratação de pequenas e médias empresas como critério de seleção.
Justificativa: Pequenas empresas de software tem mais condições de proverem inovação e de estarem comprometidas com o projeto para que foram contratadas (uma vez que representará uma grande parte no seu portfólio). Quaisquer risco adicional que a União sinta estar exposta deveria ser ponderado em relação ao benefício para o desenvolvimento do setor que este investimento virá a acarretar.
6
Contribuição: Exigência de utilização de software de código aberto e de padrões abertos em qualquer contratação que envolva o desenvolvimento ou adaptação de uma solução.
Justificativa: O CEGE prevê a adoção de uma política de Software Livre na administração pública. Assim, vemos como importante que a Instrução Normativa contemple esta orientação. Software livre torna a administração pública menos dependente de grandes empresas – normalmente estrangeiras – e permite uma adaptação mais rápida de novos fornecedores. Os padrões abertos também devem ser exigidos por permitirem uma maior democratização do acesso a tecnologia e reduzirem a dependência de soluções proprietárias.
7
Contribuição: Utilizar volume e tempo de contribuição de funcionários para projetos de código livre como um critério técnico.
Justificativa: Uma vez que a adoção de Software Livre é considerada estratégica para o Estado, é importante que a administração pública estimule um maior número de contribuições a essa comunidade. Além disso, ao valorizar desenvolvedores que já contribuem em projetos, estará medindo de maneira mais eficiente a experiência comprovada dos fornecedores (uma vez que ter o seu código aceito em uma base é uma medida mais objetiva do que ter passado em uma prova de certificação).
8
Contribuição: Exigir dedicação exclusiva do Fiscal Técnico do Contrato e do Fiscal Administrativo do Contrato para projetos maiores do que um determinado limite.
Justificativa: Uma das principais causas de fracasso de projetos de software é a falta de envolvimento do contratante e problemas de comunicação relacionados. Por outro lado, entendemos que os funcionários do serviço público são naturalmente sobrecarregados e talvez não tenham o tempo necessário para o projeto sem dedicação exclusiva. Portanto sugerimos que esta alocação seja obrigatória em projetos mais arriscados para aumentar a probabilidade de sucesso.
9
Contribuição: Oferecer para projetos até um determinado valor a possibilidade da análise da solução técnica ser incluída como um percentual do custo e tempo do trabalho a ser feito pelo contratado (permitindo que o contrato seja terminado sem dano às partes caso após esta fase qualquer uma das partes determine que o projeto não pode ser realizado nos parâmetros estabelecidos anteriormente).
Justificativa: Dado que a elaboração de um edital e o projeto técnico relacionado já demandam um investimento da União em horas de seus funcionários e utilização de materiais, sugerimos que para projetos até determinado valor esse esforço possa ser alocado como parte do trabalho contratado sem maiores riscos de perda do investimento. Se a regras para término deste contrato forem claras, no pior caso só se perderá o custo da elaboração do projeto, algo que acontece hoje em editais tanto em casos de reescrita quanto em casos de disputa judicial.
10
Contribuição: Substituir parte das exigências de documentação por exigência de testes automatizados desenvolvidos em colaboração com os fiscais administrativo e técnico.
Justificativa: Hoje em dia existem técnicas modernas de desenvolvimento de software que garantem a qualidade do software mesmo após alterações no código. Estas técnicas podem incluir artefatos que são legíveis por indivíduos sem formação técnica. Estes artefatos são mais valiosos que documentação estática – e normalmente são chamados de “documentação viva” - pois devem ser atualizados sempre que alguma funcionalidade do software for alterada.
11
Contribuição: Remover referencias a definição de processo/metodologia de trabalho e arquitetura da solução (isso deve ser parte do trabalho da contratada).
Justificativa: A arquitetura e a metodologia de trabalho não são tão importantes quanto o objetivo da área ao contratar um projeto de desenvolvimento de software e normalmente os contratados tem maior exposição ao estado-da-arte e podem sugerir soluções melhores. Já existem técnicas bem desenvolvidas para derivar trabalho de desenvolvimento de software a partir de objetivos de negócio e por tanto a União deveria concentrar seu esforço em definir e medir o resultado esperado.
Então? O que acham? Essas recomendações são implementáveis? Vão gerar o resultado desejado? Vão ter consequências inesperadas? Comente abaixo!
24 Apr 2014
O papel dos épicos na análise ágil
Quando o Alexandre Klaser e eu apresentamos Priorização por Objetivos (que descreve um quadro aonde as colunas são hipóteses a ser testadas e as linhas são níveis de refinamento), muita gente pergunta qual o papel de épicos no quadro de objetivos. A verdade é que eles não tem papel algum.
Talvez não seja para tanto, acredito que existam cenários aonde o conceito de épico faz sentido (como por exemplo quando se descobre que uma estória é grande demais - nesse caso, podemos a transformá-la em um épico até que ela seja dividida em estórias menores), mas não gosto da ideia de escrever épicos para depois dividi-los em estórias. Quando se faz isso, creio que se está partindo de um conjunto "preexistente" de funcionalidades, e o descrevendo em estórias. Para fazer isso, necessariamente devemos pressupor que esses requisitos já são conhecidos e só estamos colocando eles no papel. Gosto de chamar esse modelo de "Indutivo". Esse modelo parte de um problema, para uma solução imaginada para o problema, que é dividida em um conjunto de funcionalidades descrita por épicos, e esses épicos se tornam estórias.
Problema → Solução → Funcionalidades → Épicos → Estórias → Software funcionando
Essa sequência pressupõe que a solução para o problema é a que foi imaginada inicialmente e pressupõe que o software que representa essa solução (e portanto resolve o problema) será obtido quando todas as funcionalidades forem implementadas conforme descritas nos épicos (e por consequência, nas estórias). Até ai tudo bem, mas como vamos saber se todas as funcionalidades descritas são necessárias para prover a solução. E mais: Como temos tanta certeza que a solução imaginada de fato resolve o problema? E por fim, como o problema em questão se relaciona com os objetivos de negócio?
O modelo indutivo é adequando em situações aonde o custo de mudar de ideia é alto, portanto se investe muito tempo especificando o que deve ser feito para ter certeza que a se fará a coisa certa. Por sorte, hoje em dia software não está limitado por isso (se é que algum dia esteve). Por outro lado, o modelo indutivo pode acarretar um aumento desordenado do escopo, pois como não se tem oportunidade de validar o quanto é o suficiente, acabamos acrescentando todas as funcionalidades que vão garantir que o problema será resolvido. Mesmo em equipes maduras, a consequência dessa análise anterior é um backlog cheio.
Gerativo vs. Indutivo
O que me parece é que o modelo Indutivo descreve o que deve ser feito em oposição ao resultado que se deseja obter, e com isso resulta em uma solução "fechada" que não deixa margem para descoberta e inovação. O que propomos quando falamos de Priorização por Objetivos é um modelo de análise "Gerativo". O modelo Gerativo busca fazer com que o objetivo de negócio "gere" as estórias para atendê-lo. Para isso, não assumimos que existe um problema a ser resolvido, mas levantamos hipóteses que acreditamos nos deixar mais próximos do objetivo do negócio, assim:
Objetivo → Hipótese → Estórias → Software funcionando
A primeira coisa que se pode perceber é que este é um caminho mais curto para software funcionando. Isso não quer dizer que se entregaria o mesmo volume de estórias em menos tempo, mas apenas que o trabalho fica pronto em pedaços menores e a validação ante o objetivo em questão se dá mais rápido. Outro benefício é que se pressupõe muito pouco, uma vez que não imaginamos que exista uma solução correta.
Alguém pode perguntar se utilizando este modelo algum dia entregaremos alguma funcionalidade desejada, uma vez que elas não são descritas formalmente. É impossível responder isso sem outra pergunta: Quem "desejava" aquela funcionalidade? O analista? O gerente? A única pessoa que pode legitimamente desejar algo do software, é o usuário final daquele software. A equipe de projeto só deveria desejar satisfazer este usuário, portanto qualquer funcionalidade "desejada" pela equipe de projeto é apenas a opinião de tal equipe a respeito do que atenderá a necessidade do usuário. Na minha experiência, não existe esforço de análise o suficiente para identificar isso. Software funcionando é a melhor medida de sucesso.
23 Apr 2014
Muitos times que tentam implementar processos ágeis reportam não colher os benefícios prometidos. Isso pode ter inúmeras causas, mas uma que passa frequentemente desapercebida é que e as estórias vão inflando a medida que pressões do dia a dia começam a aparecer. Não estou falando da estimativa em pontos, mas sim do escopo esperado de uma estória. Tentar fazer demais em uma estória compromete o fluxo, aumenta o ciclo (tempo de provisionamento) e gera frustração no time. Uma equipe ágil que busca entrega contínua e iterativa deve tentar reverter essa tendência.
Normalmente consideramos a sigla I.N.V.E.S.T., cunhada por Bill Wake, como o instrumento de medida padrão para boas estórias. Vamos ver o que ela significa:
Independente (Independent) – Realiza valor incremental imediatamente
Negociável (Negotiable) – Não é um contrato, pode ser alterada por uma conversa
Valor (Valuable) – Torna a experiência melhor para alguém
Estimável (Estimable) – Pode ser comparada relativamente com outras estórias
Sucinta (Small) – O menor incremento possível
Testável (Testable) – Você sabe quando está pronto
Apesar de útil, esse acrônimo pode fazer um desserviço para times iniciando em ágil, pois ele sacrifica a ordem de importância para compor uma palavra em inglês. Por exemplo, é importante que uma estória seja independente, mas isso não é mais importante do que ela ter valor (e provavelmente é menos). Assim, quem começa a avaliar suas estórias de cima para baixo, vai primeiro verificar se ela é independente, e sacrificar a qualidade da estória antes mesmo de verificar se ela tem valor. eu considero mais importante me perguntar se uma estória tem valor e se ela é testável. O time pode até insistir em fazer o esforço, mas deve se perguntar por que isso é tão importante ou como vai saber quando pode considerá-la pronta. A próxima etapa é tentar balancear sua independência com o seu tamanho (sucinta) – para ser sincero, eu raramente olho para as outras duas características (negociável e estimável).
Por que estórias grandes são ruins
Maior risco de erro
Além dos prejuízos óbvios para o fluxo (estórias maiores levam mais tempo para terminar), estórias grandes demais também causam outros problemas. É mais provável que detalhes importantes acabem se perdendo se a estória for grande demais. Na verdade, é comum reduzir o número de critérios de aceite totais quando se divide uma estória grande em múltiplas, porque a complexidade é acrescentada iterativamente (para entender por que isso acontece, imagine, por exemplo, tentar descrever todas as raças de cachorro em prosa ao invés de em uma hierarquia). Isso impacta até mesmo os desenvolvedores que estão codificando a estória. Se uma estória tem dezenas de critérios de aceite. É muito mais provável de um ser esquecido do que se ela tem meia-dúzia.
Dependências fora de controle
O controle de escopo e a priorização são muito mais fáceis com estórias pequenas. Se eu tenho uma estória que exibe “nome”, “foto” e “descrição”, eu só posso retirá-la do escopo se eu não preciso mais de algum dos três elementos. Caso eles estejam em três estórias separadas, eu posso preferir fazer dois deles agora e adiar outro ou removê-lo do escopo completamente. Claro que ao escrever a estória, somos tentados a agrupar coisas simples para “facilitar”, mas isso traz a premissa implícita de que todos são igualmente simples e o custo de fazer os três ao mesmo tempo é o mesmo. Se isso não for verdade, pode se perder muito tempo até perceber que isso está nos segurando. É muito melhor entregar três estórias breves em sequência do que ficar bloqueado com uma estória grande. Se essa estória grande (ou mais provavelmente uma pequena parte dela) bloquear muitas outras, isso pode ter consequências ainda piores!
Previsões ruins
Além disso, por causa da regressão a média, estimativas de diversas estórias pequenas são muito mais precisas, para o mesmo prazo total. Da mesma forma que quando jogamos um dado cem vezes podemos esperar que a distribuição de resultados seja mais homogênea do que quando lançamos 10 vezes, quando se estima cem estórias, é natural haver um erro aleatório, em algumas para mais, em outras para menos, mas quanto maior o número de estórias, mais provável é que a média seja mais próxima da realidade. Além disso, é naturalmente mais fácil de estimar estórias pequenas, aonde os detalhes podem ser todos considerados ao mesmo tempo, do que estórias grandes que certamente apresentarão casos mais complexos.
Em suma, estórias menores tendem a ser mais precisas, permitem um melhor acompanhamento do progresso, permitem que o time mude de ideia rapidamente e aumenta a confiança do time na entrega.
Fazendo estórias ainda menores
Para escrevermos estórias menores, podemos utilizar alguns truques que diminuem a ansiedade de ter coisas “pequenas demais para ter importância”:
- Lembre que em desenvolvimento ágil com entrega contínua, ir para produção é uma decisão de negócio – não uma decisão técnica – portanto o negócio pode decidir lançar algo em produção apenas quando todas as estórias pertinentes estejam prontas (ou pode mudar de ideia e não esperar todas estarem prontas!)
- Divida as estórias em pedaços pequenos e verticais atravessando todas as camadas (como se fosse um bolo). Mesmo que possa parecer mais trabalhoso, na prática a independência que estórias divididas dessa forma traz permite que futuras estórias semelhantes melhorem iterativamente a implementação, diminuindo a pressão por “fazer tudo certo da primeira vez”
- Não descreva a implementação, mas sim o valor esperado. Normalmente, um problema bem entendido acaba sendo mais fácil de resolver do que a solução imaginada a priori. Lembre de buscar identificar o mínimo valor incremental que pode ser testado, por mais insignificante que ele pareça
- Não se preocupe se no começo do projeto as estórias forem grandes. É nessa hora que – para diminuir o risco – se implementam funcionalidades cruciais. O importante é garantir que à medida que o projeto avança, as estórias ficam cada vez menores
Agora é só olhar para o seu backlog e se perguntar quais estórias poderiam ser menores. Não tem por que não tentar imediatamente!
Link original: http://www.thoughtworks.com/pt/insights/blog/encolha-suas-estorias
