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

Não é raro observar em iterações onde o Sprint Planning 2 não foi feito, problemas como: estimativas parciais, daily meetings mais longas e menos objetivas, impedimentos descobertos tarde demais e falta de alinhamento do time em relação ao que deve ser feito em cada estória.

O Spring Planning 2 é o processo no qual toda a equipe junta percorre os itens do selected backlog, entende o que se espera de cada estória e pensa em questões como: Quais classes devem ser criadas? Quantas camadas do sistema serão impactadas? Impedimentos? Quais tabelas do banco de dados serão atualizadas? Que telas devem ser criadas? Quantos testes unitários devem ser feitos? Qual é o critério de aceite? …

Após esse processo, os cartões de atividades serão criados e o time todo estará mais alinhado com o que deverá ser feito para atingir o objetivo em cada estória.

Lembra aquela estimativa que foi feita no Sprint Planning 1? Após todo esse processo, ela ainda continua válida? Muitas vezes ela precisa ser alterada e isso é necessário para garantir que o time se comprometa com entregas que ele realmente tem a capacidade de fazer.

Durante as Daily Meetings, que devem ser de curta duração e se restringir a responder as perguntas objetivas: o que foi feito ontem? o que será feito amanha? existem impedimentos afetando o desenvolvimento da estória?

Não é incomum notar estórias decompostas de forma inadequada ou até atividades criadas “on the fly” (durante a própria Daily Meeting) e com isso dificultando as respostas básicas e objetivas para ter um processo ágil e transparente. Além disso, evita explicações acerca do escopo da atividade, já que todos sabem pois também fizeram parte do processo de definição de todas as atividades.

Falando em impedimentos, será que não é tarde demais para pensar neles? Imagine uma iteração de 3 semanas. O que acontece se na última semana, quando uma estória foi decomposta em atividades, “apareceu” um impedimento que já poderia estar sendo resolvido desde o início da iteração. Agora existe a possibilidade de não entregar mais a estória porque pode não existir mais tempo hábil para resolvê-lo. Quanto antes os impedimentos forem descobertos mais livre será o caminho para fechar a estória, com menos interrupções e mais motivação.

O que mesmo precisa ser feito nessa estória? Perguntas como essa sempre surgem no meio da iteração, afinal ninguem mais lembra da reunião com o Product Owner e detalhes importantes do escopo da estória acabam sendo esquecidos. Se as atividades tivessem sido criadas enquanto todo esse conhecimento ainda é recente na mente de cada integrante do time, questionamentos poderiam surgir e ajudar a entender melhor o objetivo de cada estória que deverá ser desenvolvida ao longo da iteração.

Rodrigo Branas Comunicação, Riscos

Eu vi uma discussão interessante sobre priorização x estimativas x risco em uma lista da OnCast hoje. Gostei bastante do aprendizado e resolvi transcrever algumas coisas aqui.

Podemos ter diversas formas de priorizar nosso backlog, em geral analisamos o custo de desenvolvimento, o valor gerado para o cliente e o risco inserido numa estória. Sendo assim, considerando apenas valor gerado e risco, temos o seguinte:

- Primeiro desenvolve-se o que gera maior valor e tem maior risco para o cliente;
- Depois desenvolve-se o que gera maior valor e tem menor risco para o cliente;
- Em terceiro desenvolve-se o que gera menor valor e tem menor risco para o cliente;
- E, aquilo que tem maior risco e menor valor procuramos não executar.

Se a estimativa para uma dada estória/tema é de 13sp, parece bastante razoável e adequada em termos de estimativa para um trabalho que leva aproximadamente uma semana de esforço. Agora, se apenas 3 é a estimativa e uma semana é o tempo de esforço, indica que o risco pode ter sido subestimado. Neste último caso, me parece que um pouco mais de aprendizado sobre o que precisa ser feito, vai melhorar as estimativas e auxiliar a identificar melhor o risco.

Em geral, não alteramos nossas estimativas iniciais durante a iteração. Usamos esta informação para melhorar as estimativas da próxima iteração e, ao longo de iterações subsequentes, a velocidade vai equalizar-se e as estimativas passam a se tornar “quase certeiras”.

Uma estória, idealmente, é feita pelo time todo ao mesmo tempo (cada membro pega uma tarefa da estória mais prioritária no momento), e neste contexto o tamanho de estória ideal para proporcionar um boa granularidade e uma boa visibilidade no seu burndown chart é de 3 a 5 story points. Estórias pequenas não deveriam ter mais story points do que isto e deveriam levar em média 2 dias para serem implementadas, lembrem-se - pelo time todo. Então esta dica mostra que uma estória com maior risco, digamos 13 story ponits, projeta um período de aproximadamente 1 semana para ser implementada, o que me leva a crer que as estimativas do time estavam bem assertivas, considerando os 13 story points estimados na discussão que observei.

Dado que estamos usando a escala Fibonacci, utilizamos os gaps que existem entre estimativas maiores para acomodar a incerteza do risco. Então, se não tenho muita idéia do que pode vir a ser o meu risco, utilizo estimativas maiores e os gaps da Fibonacci vão me ajudar a equalizar minhas estimativas, mesmo em estórias com risco - num futuro próximo.

Samuel Crescêncio Auto-gestão, Riscos

Outro dia, quando Caio e eu estivemos em um de nossos clientes, estávamos conversando com uma pessoa do setor de vendas e sentimos dificuldade em explicar-lhe como o desenvolvimento ágil pode ser bom no que diz respeito às mudanças. Ficamos neste embate até que me surgiu uma idéia, correndo o risco de me tornar o metafórico da OnCast, vou transcrever a estória que contei para ele:

Imagine que você nos contrate para fazer um garfo, pois fora convidado para um jantar e tinha que levar seu talher.

Depois de iniciado o processo de confecção do garfo você descobre que o cardápio do jantar vai ser sopa. Portanto o garfo não será de grande serventia, melhor seria usar uma colher.

Se estivesse dependendo do desenvolvimento tradicional, teria que esperar o garfo ficar pronto para que então fosse iniciado o processo de confecção da colher.

Se fosse através do desenvolvimento ágil, teríamos durante o processo de confecção do garfo uma mudança no sentido, e passaríamos a fazer não mais um garfo, porém uma colher.

É isso que temos com o desenvolvimento ágil, a facilidade em aceitar uma mudança no sentido do projeto. A perda com essa mudança é proporcional ao seu tamanho e também ao tamanho do projeto. Ou seja, se, no exemplo acima, ao invés de uma colher precisássemos mudar de um garfo para um Hachi (aqueles pauzinhos usados no oriente) teríamos muito mais dificuldade e possivelmente um aumento no número de iterações.

Essa resposta rápida às mudanças é um dos quatro valores do desenvolvimento ágil “Responder às mudanças sobre seguir um plano” e é também um dos princípios abordados no manifesto ágil “Até mesmo mudanças tardias de escopo no projeto são bem-vindas.”. Por ser um dos alicerces de nossa metodologia, temos que  acreditar, aceitar e, o mais complicado, fazer com que o cliente acredite nisso.

Marcelo Silva Metáforas, Riscos

Essa foi a pergunta que a Mirela, nossa Assessora de Marketing, fez ao Adriano e ao Samuel, dois dos três sócios da OnCast Technologies. Após receber várias respostas enumerando as qualidades do SCRUM/XP/Lean, me permitiram que falasse sobre uma delas. Expliquei que havia me identificado bastante com a característica do processo ágil que permite desenvolvimento de software sustentável, um dos princípios elencados no Manifesto Ágil.
Uma das maneiras de se atingir isso é com a criação de código simples, outro princípio discretizado no Manifesto Ágil. Com um código simples torna-se fácil a percepção de falhas precocemente, atacando cedo, aquele que poderia ser o câncer de todo o processo. Acabei criando o seguinte exemplo para explicar essa faculdade:

Imagine que um cliente nos peça que façamos uma casinha de Lego de determinada cor. Para isso nos entrega todas as peças necessárias sem notar que nos havia entregue uma peça de outra cor.

Caso executássemos essa tarefa utilizando o desenvolvimento tradicional, tirando toda burocracia envolvida, faríamos a casa e ao terminar, perceberíamos que na base da casa havia uma peça de cor errada. Isso implicaria em desconstruir toda a casa e, por sua vez, reconstruí-la, perdendo um tempo que o cliente provavelmente não possuía.

Caso estivéssemos usando o desenvolvimento ágil, teríamos notado a peça errada antes mesmo de terminar a casa, faríamos sua troca pela peça correta e continuaríamos nosso desenvolvimento sem essa perda tão considerável de tempo.

O que quis dizer com este exemplo é que um problema, dentro do desenvolvimento ágil, é atacado assim que é encontrado, desta forma é suplantado, minimizando o tempo gasto com isso.

Fazendo um gancho do exemplo do Lego com o desenvolvimento de softwares, podemos lembrar do Test-Driven Development (TDD) que é a abordagem que nos ajuda a encontrar a “peça” errada, antes desta “peça” influenciar nas outras “peças” que compõe o software.

Em suma, pode-se dizer que o desenvolvimento ágil tenta mitigar o efeito “bola de neve”, tornando mais simples e contínuo o processo criativo.

Marcelo Silva Ferramentas, 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

Preocupado com o burndown da sua primeira iteração?

Se você é um integrante do time e está preocupado com o burndown da primeira iteração do seu projeto, fique sabendo que é muito provável que você falhe.

É isso mesmo! Na primeira iteração o negócio, a tecnologia e o ambiente podem ser novidades, o time ainda não acertou a mão nas estimativas e não está entrosado. Sem falar que nem todos podem estar maduros com o processo, inclusive o Product Onwer, e na ansiedade que isto gera. Para mitigar seus riscos, aí vão algumas dicas do que o ScrumMaster pode fazer antes, durante e depois da primeira iteração:

Antes da primeira iteração:

Invista na sua comunicação com o Product Owner. Você pode organizar uma reunião de kick-off do projeto, para que sejam definidas as regras do jogo. No planejamento da primeira iteração, o Product Owner deve ficar ciente de que as estimativas devem ser “mais erradas” que o normal, para que ele não se surpreenda com uma entrega incompleta (a única certeza que temos das estimativas é que elas estão erradas, mas isto é outra discussão).

Também não é sadio o Product Owner tratar a primeira iteração decisiva quanto a continuidade do trabalho - chame sua atenção para o fato de que o time deve se estabilizar apenas na terceira iteração.

Defina as datas e locais das próximas reuniões de planejamento e explique sua necessidade. Isto irá desencorajar qualquer desculpa para reagendamento.

Não peque por escassez de planejamento e estimativas. Puxe o time para não ter pressa nem preguiça ao receber tanta informação nova. As regras de negócio costumam ser novidade: intercalar reuniões com e sem os conhecedores do negócio ajudam a refinar o entendimento do escopo. Reserve tempo antes de estimar, para analisar a macro-arquitetura e qualidade do código legado, APIs e estudar novas tecnologias.

Durante:

Mantenha o Product Owner sempre informado, mesmo que seja por email, mesmo que ele não responda. Surpreenda-o o mais cedo possível, mesmo em caso de atraso (que é um caso de visibilidade que você preferiria não estar vendo, mas é forçado pelo burndown). Não deixe-o esquecer que tropeços eram esperados na primeira iteração.

Registre cada suposição mal feita durante o planejamento, cada aumento inesperado de escopo e cada impedimento: será útil para o aprendizado do time na retrospectiva.

Time-boxed: é importante aceitar o fim da iteração na data combinada mesmo com burndown no alto. Finalizar as iterações na data combinada é especialmente importante nas primeira iterações: mostra organização, marca o ritmo do processo e disciplina o time a se planejar melhor para entregar tudo com que se compromete. Em caso extremo, com um burndown chart completamente horizontal, ou burn up, considere dar a iteração por encerrada antes do tempo e realize um novo planejamento.

E depois da iteração 1:

Não alcançou o objetivo da iteração? Tudo bem! O importante é não se acomodar e aprender.

É durante a Reunião de Retrospectiva que ocorre o aprendizado, é quando você vai evitar cometer os mesmos erros na iteração 2.

Recomendo evoluir durante a reunião um Value Stream Map ou uma Análise SWOT. Mapear a cadeia de valor irá tornar a forma de trabalho do time mais focada em gerar valor para o cliente. Na análise SWOT, sugiro avaliar o que pode ser feito para melhorar cada ponto elencado como fraqueza ou ameaça. Atenção especial aos erros de estimativas e aos incrementos de escopo descobertos durante a iteração.

No caso de uma insatisfação do Product Owner quanto à entrega, sugiro ao ScrumMaster expôr a ele os pontos relevantes da análise SWOT e, inclusive, dar seu feedback sobre o Product Owner, a fim de que ele melhore continuamente seu desempenho neste papel.
E agora?

Deixe seu comentário contando como foi sua primeira iteração. E bom trabalho na segunda!

Adriano Campestrini Metodologia, Riscos