Aprimoramento da agilidade dos negócios

Transcrição

1 White paper Aprimoramento da agilidade dos negócios Como os acionistas e os desenvolvedores podem falar e pensar a mesma coisa

2 Índice página Introdução: como oferecer aos acionistas informações sobre o universo dos desenvolvedores... 1 Novos desafios do trabalho em equipe... 2 Conectar lado esquerdo e direito... 3 Os três procedimentos essenciais da agilidade de negócios... 7 A análise final... 8

3 Introdução: como oferecer aos acionistas informações sobre o universo dos desenvolvedores O desenvolvimento ágil foi um sucesso fenomenal do ponto de vista da execução: as organizações de desenvolvimento podem avaliar e incorporar mudanças mais rapidamente, e agregar valor comercial com maior frequência. Mas a adoção de práticas ágeis desenvolveu ou expôs alguns sintomas interessantes, como dificuldade para mostrar como as necessidades comerciais são interpretadas e representadas pelo desenvolvimento; a falta de conhecimento do processo de desenvolvimento; ausência de evidência das razões pelas quais as principais decisões eram inicialmente tomadas; e uma desconexão entre as equipes comercial e de desenvolvimento. Um desafio fundamental é que as equipes comerciais e técnicas muitas vezes parecem falar idiomas diferentes ao colaborar em projetos ágeis, em vez de compartilhar um objetivo comum e a compreensão das metas comerciais. As pessoas falam dois idiomas: o idioma nativo e o que não faz sentido. Maribel C. Pagan Este White Paper examina como as organizações podem alinhar seus objetivos comerciais de forma mais estreita com o processo de desenvolvimento de software e garantir que todos os acionistas envolvidos no projeto colaborem de maneira eficaz para capturar as necessidades comerciais, gerenciar a mudança e acompanhar o andamento. Os três são essenciais se as organizações tiverem de reagir com velocidade a alterações nas prioridades comerciais e melhorar a agilidade comercial. 1

4 White paper Aprimoramento da agilidade dos negócios Novos desafios do trabalho em equipe As práticas de desenvolvimento ágil geralmente têm sido conduzidas por meio de uma adoção de baixo para cima. As equipes de desenvolvimento individual adotaram práticas e criaram soluções que fazem sentido para a organização e suas tecnologias, como eles o veem, por meio dos casos dos usuários. Os requisitos, por outro lado, abordam a questão por outro ângulo, sendo escritos para satisfazer necessidades comerciais específicas. Por isso, muitas vezes a execução (o que está sendo criado) será desconectada da solicitação original. Por exemplo, aplicações do desenvolvimento ágil envolvendo cartões físicos não geram um histórico das razões pelas quais as decisões foram tomadas, nem servem como documentação. Em vez disso, os cartões originais são rasgados e descartados. O sistema que emerge é o que é; alterações e razões pelas quais foram feitas não são coletadas nem controladas. E, embora alguns sistemas baseados na web rastreiem o histórico em cartão, poucos oferecem uma visualização do histórico do projeto, quando os cartões foram introduzidos, alterados e eliminados e em que ordem. Clientes comerciais tendem a pensar e programar em termos de necessidades comerciais, enquanto a equipe de entrega pensa e planeja em termos de necessidades de desenvolvimento. As duas unidades de medida raramente se alinham. Lidar com diferentes necessidades Questões como Devemos utilizar requisitos ou histórias? fazem parecer que os dois conceitos são conflitantes, que as equipes devam usar uma única forma para projetar e desenvolver software. A realidade é que métodos diferentes são necessários para atender a diferentes necessidades. Clientes comerciais tendem a pensar e programar em termos de necessidades comerciais, enquanto a equipe de entrega pensa e planeja em termos de necessidades de desenvolvimento. As duas unidades de medida raramente se alinham. As necessidades comerciais são metas de alto nível que são cada vez mais aperfeiçoadas até se tornarem requisitos totalmente formados. A equipe de desenvolvimento se apropria desses requisitos e divide-os em unidades de trabalho práticas: histórias e tarefas. Conectar os dois e obter um status comercial do andamento do desenvolvimento muitas vezes é um desafio, porque o trabalho em andamento da equipe de desenvolvimento é difícil de traduzir em um contexto comercial. 2

5 A conexão das necessidades comerciais e entrega leva bastante tempo até resolver a desconexão entre negócios e entrega. Mark Kulak, diretor de desenvolvimento da Borland na Micro Focus, explica o problema desta forma: Vemos isso no mundo do desenvolvimento ágil durante demonstrações, quando um patrocinador ou cliente importante está observando o software em ação. Durante a demonstração, eles verão uma pequena porção da funcionalidade que claramente não se alinha às solicitações originais, ou que está incompleto. O cliente acaba por fazer uma de duas coisas: tenta conectar os pontos em sua própria cabeça, ou faz perguntas que ninguém pode responder, como Quando o recurso de recálculo estará disponível?. Você sabe que está com problemas quando faz a pergunta e obtém uma resposta que inclui termos como front-end, unidade JS ou PL/SQL que não têm nada a ver com as necessidades comerciais originais. O cliente acaba tentando conectar os pontos em sua cabeça, ou faz perguntas que ninguém consegue responder. Conectar lado esquerdo e direito Conectar as necessidades comerciais e de entrega é bastante antiga, mas pode resolver a desconexão entre negócios e entrega. A resposta está em adicionar versão, rastreio e referências em todos os bens, desde as necessidades comerciais até as histórias e tarefas, quer já efetivadas ou em um backlog (veja o painel). Isso significa que a organização não pode apenas ver o relacionamento de negócios e de entrega, ela pode entender como diferentes necessidades evoluíram ao longo do tempo, e responder a uma importante pergunta: Como chegamos aqui?. 3

6 White paper Aprimoramento da agilidade dos negócios Fig. 1 Definir necessidades comerciais: requisitos Fig. 2 Definir a unidade de desenvolvimento: histórias de usuário 4

7 Quando os usuários comerciais e os desenvolvedores veem os mesmos sistemas, as equipes técnicas podem reconhecer as oportunidades que, de outro modo, poderiam não ver, como atalhos ou conexões possíveis. Fig. 3 Curva sinodal de requisitos Fazer a conexão entre a empresa e a entrega proporciona uma curva sinodal de requisitos de desenvolvimento ágil, como na Figura 3. O lado esquerdo do projeto de software (Figura 1) é o quê criar, enquanto o lado direito (Figura 2) representa as tarefas e tecnologias de desenvolvimento (as quais o movimento ágil tem historicamente enfatizado ou, frequentemente, enfatizado em excesso). Uma abordagem integrada inclui ambos os lados e os conecta. Quando os usuários comerciais e os desenvolvedores veem os mesmos sistemas, as equipes técnicas podem reconhecer as oportunidades que, de outro modo, poderiam não ver, como atalhos ou conexões possíveis. É fundamental, ao dividir o trabalho em termos comerciais, que as histórias e tarefas também façam sentido para os negócios, o que permite decisões conscientes sobre as prioridades e escopo. Esta abordagem adaptativa resolve todos os problemas discutidos anteriormente, evitando que a equipe faça alterações radicais a partir das referências, a menos que supervisionada por usuários comerciais. 5

8 White paper Aprimoramento da agilidade dos negócios Evitar os processos ocultos Durante o ciclo de vida do desenvolvimento, um processo pode ser concluído de modo preciso, mas não consistente. Por exemplo, uma equipe de desenvolvimento pode trabalhar fora da ferramenta ágil, como em um processador de textos, e simplesmente atualizar a ferramenta com os resultados. As organizações com verdadeira agilidade comercial evitam essa falta de visibilidade com três componentes essenciais de gerenciamento de requisitos: versão, rastreio e referências. As organizações com verdadeira agilidade comercial evitam a falta de visibilidade com três componentes essenciais de gerenciamento de requisitos: versão, rastreio e referências. Versão é prática comum manter diferentes versões do código, mas quando se trata de outros artefatos como requisitos e testes, geralmente não há histórico de mudança. Cada alteração deve ter versões, juntamente com quem fez a alteração e comentários adequados. Rastreabilidade isso pode ser aplicado a artefatos de desenvolvimento (códigos, projetos, testes unitários, interfaces de usuário, processos de implantação), que devem remontar à necessidade comercial de que tratam. No entanto, a capacidade de acompanhamento também é uma forma de conhecer quais requisitos já foram entregues (e o grau de êxito em relação aos artefatos aplicados), quanto está em desenvolvimento e o que ainda está em fase de planeamento. Em tudo isto, o que importa não é apenas a história, mas a capacidade comercial que a história ativará. Um único item pode ativar várias necessidades comerciais ou vários proprietários com necessidades complementares, embora diferentes. Referência a visão original do projeto e qualquer alteração ou iteração posterior devem ser guardadas de modo a que a versão aplicada possa ser comparada à visão original, e como a ela se chegou, etapa por etapa. Ter uma referência permite que a equipe entenda os impactos a jusante da alteração; enquanto os usuários comerciais podem retroceder até o estado atual de um plano e seus bens de entrega relacionados em qualquer ponto no tempo durante a duração do plano para entender o impacto da alteração. 6

9 A escolha do software adequado para gerenciar a mudança ajuda consideravelmente: a ferramenta ideal vinculará as necessidades comerciais originais ao requisito certo e à criação correta. Os três procedimentos essenciais da agilidade de negócios Captura das necessidades comerciais Começando da parte inferior esquerda da curva sinodal da Figura 3 (página 5), temos a ideia: o ponto a partir do qual tudo literalmente evolui. A menos que as ideias ao redor das necessidades comerciais sejam coletadas com precisão, compartilhadas e transformadas em requisitos, o resultado final de um projeto não suprirá as necessidades dos acionistas e o retrabalho será inevitável. A consequência é que os requisitos devem ser capturados e organizados da forma mais flexível possível para que todos aos acionistas vejam que é fácil colaborar e compartilhar informações comerciais essenciais. Os resultados não devem ficar restritos a qualquer formato de arquivo, uma vez que as ideias podem vir de qualquer lugar, deve existir a capacidade de organizar e compartilhar fotos, documentos, relatórios ou até mesmo tarefas rabiscadas de forma rápida da forma mais conveniente. Gerenciar com eficácia as alterações das necessidades e prioridades comerciais Os requisitos inevitavelmente evoluem à medida que as necessidades e demandas dos acionistas mudam a fim de oferecer suporte às demandas e expectativas de negócios. Enquanto as equipes de desenvolvimento ágil respondem rapidamente ao apoiar essas alterações, o desafio de coletar e comunicar como elas afetam os backlogs de desenvolvimento ágil e a entrega ao longo do tempo ainda é uma tarefa que consome muito tempo e é constantemente negligenciada. Não precisa ser. Agilidade significa a capacidade de alterar planos entre iterações e ainda fazer todos compreenderem o impacto dessas mudanças, e como o produto está evoluindo ao longo do ciclo de vida. A escolha do software adequado para gerenciar a mudança ajuda consideravelmente: a ferramenta ideal vinculará as necessidades comerciais originais ao requisito certo e à criação correta. Isso efetivamente combina gerenciamento de requisitos com o gerenciamento de mudança. Sem estes dois elementos, sua evolução de trabalho ficará descontrolada e menos bem gerenciada, com a equipe de desenvolvimento criando uma parte por vez, o que talvez consiga, ou não, remontar às metas originais do projeto. 7

10 White paper Aprimoramento da agilidade dos negócios Monitoramento do andamento Acabamos de chegar ao momento culminante da curva sinodal: o ponto em que usuários comerciais definiram suas metas e agora precisam ver se o que foi solicitado está sendo criado. A transparência de vincular histórias com os requisitos torna isso possível quando se utiliza a ferramenta certa. Na verdade, o usuário comercial (ou qualquer acionista não-técnico) é capaz de ver o universo do desenvolvedor por meio das informações capturadas diretamente a partir das ferramentas ágeis preferidas pela equipe de desenvolvimento. Isso proporciona acompanhamento imediato e contínuo da evolução e das alterações feitas às ideias enquanto estão em desenvolvimento: uma verdadeira forma de transparência comercial que acelera o andamento. A análise final Com os acionistas cada vez mais distribuídos pela organização e fora dela, e com as prioridades e expectativas comerciais em contínua alteração, a capacidade de unir as equipes comercial e de entrega é a chave para reagir mais rapidamente melhorar a agilidade comercial. Manter os projetos ágeis vinculados às metas comerciais é um desafio. No entanto, a solução é exatamente esta: vincular as equipes comerciais e de desenvolvimento em uma parceria estreita. Isso libera a equipe de desenvolvimento para criar as soluções certas, enquanto a equipe comercial garante que sejam criadas com uma metodologia de governança responsável. Os requisitos, com versão, acompanhamento e referências, oferecem as informações sobre os motivos e quando tomar decisões comerciais. Com os acionistas cada vez mais distribuídos pela organização e fora dela, e com as prioridades e expectativas comerciais em contínua alteração, a capacidade de unir as equipes comercial e de entrega desse modo é a chave para reagir mais rapidamente e melhorar a agilidade comercial. Saiba mais sobre como vincular as equipes comercial e de desenvolvimento em com/businessagility 8

11 Micro Focus Argentina Brasil Colombia México Venezuela Micro Focus Sede da empresa Reino Unido +44 (0) PB B 10/ Micro Focus. Todos os direitos reservados. Micro Focus, o logotipo da Micro Focus entre outros são marcas registradas ou marcas comerciais registradas da Micro Focus ou de suas subsidiárias ou empresas afiliadas no Reino Unido, nos Estados Unidos e em outros países. Todas as outras marcas pertencem aos seus respectivos proprietários.