Building Minds - o Blog da OnCast

A OnCast finalmente rende-se a uma forma intuitiva de gestão. Fases em cascata é realmente a melhor solução para atendar às demandas do mercado, tanto emergenciais, quanto grandes projetos que, por terem uma extensa fase de planejamento, conseguem segui-lo à risca.

Nossos projetos agora terão um Gerente de Projeto, que irá centralizar a informação e as decisões. O GP irá delegar ao seu critério para seus subordinados. Caso haja algum problema ou descontentamento, os recursos serão ser trocados imediatamente, a fim de preservar o plano do projeto. O Gerente de Projeto irá comandar as alocações e desalocações de pessoal, com seu WBS e gantt chart, além da geração de artefatos, para todo o fluxo descrito a seguir:

• No início do projeto, com tudo formalizado em contrato, para segurança de todas as partes e definição clara de interfaces cliente/fornecedor, analistas de requisitos irão documentar claramente as necessidades do cliente.
• Em seguida, o analistas de sistemas, assessorados por arquitetos de sistemas, transformarão a visão de requisitos em uma visão de sistema. Tudo muito intuitivo!
• Um arquiteto da informação poderá colaborar com a documentação dos requisitos e entregar macro esquemas de tela junto com os artefatos do analista de sistemas.
• Os designers criarão todas as telas, para que tudo fique claro antes da mera programação.
• Os programadores poderão dividir responsabilidades, preferencialmente por módulos dos sistema. Assim ele será conhecedor do todo seu módulo, de fácil controle. Ferramentas case e proprietárias são priorizadas neste momentos, por sua agilidade e suporte.
• Agora só falta testar! Inicia-se a fase de verificação, quando planos de testes confrontam o resultado da programação e se por acaso algum erro for encontrado, é fácil localizá-lo dada a vasta documentação do projeto e às ferramentas de debug. Neste momento, todos os módulos programados são integrados. A equipe de testes deve ser muito pragmática e apaixonada por trabalho repetitivo e braçal em teclado.
• Em paralelo aos testes, com documentação farta do projeto, o produto começa a ser documentado.
• Por fim, e ainda intuitivamente, o software segue para homologação e produção.
• Após em produção, o sistema começa a sofrer manutenções que começam a torná-lo, muito aos poucos, usável.

O que antes era um tripé incerto na gestão de projetos, Tempo, Escopo e Custo, agora mantém-se fixo e a variável que soluciona a equação é a Qualidade:

• Prazo é impossível alterar, já que o projeto inicia com seu fim anunciado à diretoria, à imprensa e ao mercado.
• Redução do Escopo impossibilita um grande evento de lançamento, pois obviamente é feio o sistema estar incompleto, mesmo que a maioria das funcionalidades não sejam utilizadas nos primeiros meses.
• Quanto ao Custo, nem se fala: quanto menor o investimento, maior o ROI. Não há o que argumentar, pois é pura matemática!
• Já a Qualidade, dá-se um jeito! Boas práticas atrapalham o mundo real. Nem sempre é preciso 3 camadas, desacoplamento e automatização de build e testes. Depois da entrega isto pode ser visto… Em um projeto futuro…

A OnCast, que até agora estava melhorando continuamente, finalmente atinge um ponto de maturidade, finalizando o ciclo de aprendizado. Com a adoção do OnCascade, espero em breve poder dar más notícias…

Adriano Campestrini Metodologia, Riscos

Defino Débito Técnico como a distância entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia. Sua unidade é o spag (Sg), ou spaghetti :).

O termo foi cunhado em 1992 por Ward Cunningham, mas até hoje não há consenso de seu significado. Steve McConnell divide Débito Técnico em duas categorias: Intencional e Não Intencional (leia seu artigo). Uncle Bob em seu artigo “A Mess is not a Technical Debt” fala que um débito técnico não intencional (negligente) não deve ser considerado débito técnico. Martin Fowler subdivide débito técnico de duas maneiras: Prudente/Imprudente e Intencional/Inconsciente, gerando os quadrantes de débito técnico.

Minha classificação é algo como a de Steve. É muito útil determinar a existência de um Débito Técnico apenas avaliando o software em si, sem considerar as condições em que foi inserido. A separação entre intencional e não intencional não pode ser determinada apenas analisando o artefato. Um código mediano não é inapropriado se houve estratégia e todos estão conscientes das consequências da sua inserção.

Logo, a todo código ruim ou mediano dou o nome de Débito Técnico, a todo código que compromete o produto ou o futuro do projeto. É uma métrica direta da qualidade do software. Utilizo a subdivisão Intencional/Inconsciente para identificar se houve/não houve justificativas estratégicas para tal débito. As classificações Prudente/Imprudente dadas por Martin, credito mais à equipe, e não ao débito técnico em si.

Vamos descorrer um pouco mais sobre a distinção entre Débito Técnico Intencional e Débito Técnico Inconsciente.

Débito Técnico Intencional

Fazer o refactoring para abrigar a nova funcionalidade nos custará 5 dias, utilizar a arquitetura atual, mesmo que entortando alguns conceitos, nos custará 1 dia. Nossa entrega é no meio desta semana e a multa por atraso é indecente.

Qualquer gestor responsável diria:

1 dia! Faremos simplista agora! Agendamos um refactoring na próxima release, mesmo que nos custe 10 dias depois.

Existem momentos na vida de um projeto que atingir os deadlines é mais importante que a qualidade. O mundo está cheio de desafios: concorrência acirrada, time-to-market, pressões externas e internas… Não observar estes desafios é a pior das negligências de um projeto. De nada adianta um projeto que não atinge seus objetivos. Conhecer os prós e contras de suas estratégias é primordial para fazer a escolha correta.

Em uma boa equipe Scrum, o Product Owner tomaria esta decisão, principalmente porque conhece as necessidades do mercado. À equipe técnica (team) cabe o papel de levantar alternativas e alertar o Product Owner sobre os prós e contras de cada uma. O balanço entre qualidade e metas é o resultado esperado, bem como um agendamento de refactorings para amortizar o eventual débito técnico resultante.

Débito Técnico Inconsciente

Este débito técnico pode ser incorrido por algumas razões:

• Uma equipe técnica iniciante falha ao enxergar uma solução que não comprometa o futuro do projeto.
• O Product Owner é negligente ao considerar os riscos de suas ações, não considera os argumentos da equipe técnica e falha ao avaliar as necessidades de médio e longo prazo de seu projeto.
• O imponderável, algo que não pode ser antecipado nem por uma equipe sênior. Isto é comum a trabalhos de pesquisa e desenvolvimento de cunho científico.

De maneira geral, acredito que nem todo Débito Técnico não intencional seja negligente. Como visto acima, existem casos em que a complexidade do trabalho irá impor que débito técnico seja naturalmente inserido e permaneça desconhecido por algum tempo. Isto não configura negligência. Entretanto, ignorar o fato de que débitos técnicos serão inseridos é negligência. Cabe à equipe toda monitorá-los e corrigi-los a medida que sejam identificados.

Rodrigo Machado Metáforas, Riscos

Um dos problemas mais críticos de um projeto é quando o cronograma foge do controle do time e as estimativas revelam-se erradas e sem maturidade. Isto demonstra que os processos utilizados para chegar a elas podem ter falhas. Frente a problemas como este, é importante ir fundo nas suas causas e planejar que tipo de melhorias podem ser feitas para tornar as próximas iterações bem sucedidas.

Nas primeiras iterações, é inevitável. De certa forma, é esperado que as estimativas não sejam realista por motivos como: desconhecimento do escopo, novas tecnologias e falta de entrosamento da equipe. Esses fatores reunidos, ocasionam a falta de estimativas confiáveis e o desconhecimento da velocidade real do time.

Com o passar do tempo, a fluência da equipe aumenta e é possível confiar mais no que está sendo estimado e  se comprometer com uma quantidade de trabalho, tendo a confiança de poder entregá-la com qualidade e dentro do prazo combinado.

Entretanto, é comum ver projetos já avançados com problemas no cronograma. Atrasados ou adiantados, ambos os casos são ruins. Demonstram que o processo de desenvolvimento tem problemas e que o time pode nao estar conseguindo mensurar corretamente o risco existente em cada estória.

Por isso, é importante recolher métricas, constantemente, para uma melhoria continua dos processos ligados a às estimativas. Depois de cada Daily Meeting, podemos avaliar de uma maneira simples e direta, seja marcando no próprio cartão ou em uma planilha, os resultado das estimativas. Caso elas tenham se cumprido, devem ser consideradas adequadas, caso contrário, baixas ou altas. Também é interessante ter algumas observações referentes aos motivos dos problemas, se for o caso.

Idealmente, a produtividade que foi acordada no inicio deve variar pouco, mostrando que o time é capaz de manter processos sustentáveis de desenvolvimento. Apesar de ser bom manter uma reserva gerencial, ou gordura, para se resguardar de quaisquer problemas que possam acontecer em durante a iteração, se este for um hábito constante, pode acabar ocasionando gráficos parciais e dados irreais, além de um processo opaco tanto para o time quanto para o cliente.

Analisando o gráfico, após uma iteração problemática, é possível notar os pontos que fizeram com que a iteração não fosse bem sucedida. As métricas das atividades fechadas nos dias em que a produtividade oscilou de forma acentuada devem ser analisadas com cuidado. É provavel que essas estimativas estejam marcadas como baixas ou altas, e com o objetivo de melhorar no futuro, podemos nos aprodundar nos motivos que causaram estes desvios.

Se as estimativas foram altas, medidas como planejar escopo extra ou antecipar estórias de alto risco podem ser interessantes para agregar mais valor à iteração e garantir uma entrega completa e com qualidade. É interessante justificar para o cliente que as superestimativas decorrerem de novas abordagens tecnológias ou de negócio do projeto, ou seja, frente a um risco que teve que ser considerado, com isso o time vai ganhar mais maturidade e com a lição aprendida vai saber lidar com situações parecidas em futuras iterações. Entretanto, caso não existirem motivos suficientemente justificados para elas, uma conscientização do time, acerca do problema e de como poderá afeta a imagem do time perante o cliente, deve ser feita.

Por outro lado se ocorrerem estimativas baixas, isso pode refletir um desconhecimento das técnologias envolvidas ou do negócio, comum no inicio do projeto, e isso vai trazer também maturidade para o time da mesma forma que aconteceu com as superestimativas. Caso as estórias sejam livres de débitos relacionados à novas técnologias ou escopo ainda não trabalhado, uma análise dos impedimentos que podem ter ocorrido durante o desenvolvimento é fundamental para identificar que ações corretivas que foram tomadas no momento em que os problemas aconteceram, e se ajudaram a evitar a queda de produtividade do time. No primeiro sinal de queda da produtividade por problemas de impedimentos é importante parar a atividade até que os impedimentos sejam resolvidos para evitar a desmotivação do e desperdicio do esforço do time, que poderia estar sendo convergido em estórias sem impedimentos.

Caso a desmotivação já tenha dominado o time, tomar medidas corretivas como pair programming ou move people around, podem ajudar a subir a moral do time e estabilizar o processo produtivo.

Com a obtenção e avaliação desse tipo de métrica, podemos entender melhor cada movimento que o gráfico realizou e como isso afetou a iteração e assim o time poderá se desenvolver de uma forma mais transparente,  madura e produtiva, com um alto grau de confiabilidade tanto nas estimativas, quanto na garantia da entrega do que foi assumido com o cliente, aumentando a confiança de ambos os lados e gerando novas oportunidades de negócio para a empresa.

Rodrigo Branas Comunicação, Riscos