Alguém que estudou o desenvolvimento de software, sua análise e seu projeto viu, sem dúvida, a seguinte figura clássica sendo apresentada pelo seu professor, por exemplo. Trata-se do Projeto Balanço.
Cada figura do conjunto demonstra um determinado processos ou fase do desenvolvimento de software. O conjunto conseguiu demostrar, de forma abstrata, o que realmente ocorre num projeto de software. Tornou-se famosa pela sátira ao produto de software entregue para o cliente e também pelo seu desenvolvimento. Gostando ou não, muitos profissionais consideram-na uma realidade.
É uma figura tão famosa e clássica para a comunidade de desenvolvimento, que uma equipe se organizou com o objetivo de mante-la ativa. Trata-se do Project Cartoon: http://www.projectcartoon.com/
Várias conclusões e aprendizados são percebidos ao avaliar a figura sob um ponto de vista da engenharia de software. Considerando que o balanço é uma representação abstrata do software, conclui-se que a metodologia utilizada para a "criação do balanço" é a Waterfall (cascata).
A análise do balanço é feita de forma completa no início do ciclo e diversos problemas ocorrem no decorrer do projeto para os desenvolvedores e para os clientes. Cada qual demostrado em uma figura do conjunto. Porém, a ultima figura é especial, representa o que o cliente realmente queria - é a única que não ocorre.
O Manifesto Ágil surgiu, em vista disso, como resposta aos problemas e dificuldades dos projetos de software. Seus valores e princípios revolucionaram a forma das organizações pensarem em software. A partir disso, uma pergunta deveria ser feita: Como seria o desenvolvimento ágil do projeto balanço?
Tomei a liberdade de adaptar as figuras para demostrar, no meu ponto de vista, como seria construir o famoso "balanço" utilizando uma metodologia ágil para desenvolvimento. Meu objetivo não é gerar algum resultado cômico sobre a abordagem Agile, mas sim demostrar sua aplicação em um outro ponto de vista. Todo o ciclo de vida proposto será baseado numa análise da figura clássica apresentada anteriormente, seguindo alguns dos seus princípios, como: O objetivo final do cliente (um balanço de pneu) e a visão inicial do time (um balanço convencional de madeira).
Muitas características foram desconsideradas para viabilizar o resultado final e alcançar, de forma abstrata, os valores e princípios ágeis. O desenvolvimento de software baseado em testes, burndown chart e kanban podem ser citados como características ausentes. Em contra partida, é possível notar a utilização de Iterações, Continuos Delivery, aceitação das mudanças, aproximação do cliente, entre outros.
Quinta Iteração: O time iria prosseguir o projeto entregando uma segunda corda amarrada na arvore, a intensão seria alcançar um balanço convencional feito com madeira. O projeto está sendo conduzido para a construção de um balanço convencional (feito de madeira e duas cordas). A entrega se uma segunda corda iria dificultar o objetivo do cliente - se divertir. Duas cordas numa arvora não iriam ser necessárias no ponto de vista do objetivo final desejado pelo cliente (balanço com pneu). O cliente iria utilizar essa versão e iria reprovar a funcionalidade entregue nessa iteração.
Nota Iteração: A corda com o pneu amarrado foi centralizada no ganho da arvore. O cliente iria aceitar a mudança e aprovar o projeto final. Considere que a equipe aplicou um Refactory no código e entregou qualidade, com isso, para o cliente.
Concluímos que a utilização de abordagens, valores e práticas ágeis ajudou o time a entregar um projeto de valor e de acordo com o esperado pelo cliente (lembrando que estou me baseando na figura original).
Algumas características do ciclo de vida ágil do projeto balanço podem ser notadas:
1) A utilização de uma abordagem iterativa e incremental no desenvolvimento fez com que alguns problemas com relação ao escopo não ocorram, o que não é percebido na figura original
2) O time realizou entregas contínuas para o cliente para receber avaliações (feedback) sobre o produto entregue.
3) O produto entregue a cada iteração tinha features novas que poderia ser utilizadas pelo cliente - entrega de valor.
4) As iterações podem falhar como ocorreu durante o desenvolvimento do projeto. As consequências são minimizadas por conta das entregas contínuas e o feedback do cliente faz a equipe apreender e compreender o projeto.
5) Um protótipo ou um MPV foi utilizado pela equipe para validar uma hipótese. Esse artificio é geralmente utilizado no começo do projeto com a intenção de validar a eficácia do projeto, entra outros objetivos.
6) O time aceitou as mudanças que possivelmente foram sugeridas pelo cliente. Percebemos isso na questão da utilização de um balanço de madeira para um balanço de pneu. Considere, para essa questão, a visão do cliente e do time para o projeto e a figura inicialmente apresentada.
Com isso, uma figura final como conjunto das iterações ficará assim:
Cada figura do conjunto demonstra um determinado processos ou fase do desenvolvimento de software. O conjunto conseguiu demostrar, de forma abstrata, o que realmente ocorre num projeto de software. Tornou-se famosa pela sátira ao produto de software entregue para o cliente e também pelo seu desenvolvimento. Gostando ou não, muitos profissionais consideram-na uma realidade.
É uma figura tão famosa e clássica para a comunidade de desenvolvimento, que uma equipe se organizou com o objetivo de mante-la ativa. Trata-se do Project Cartoon: http://www.projectcartoon.com/
Várias conclusões e aprendizados são percebidos ao avaliar a figura sob um ponto de vista da engenharia de software. Considerando que o balanço é uma representação abstrata do software, conclui-se que a metodologia utilizada para a "criação do balanço" é a Waterfall (cascata).
A análise do balanço é feita de forma completa no início do ciclo e diversos problemas ocorrem no decorrer do projeto para os desenvolvedores e para os clientes. Cada qual demostrado em uma figura do conjunto. Porém, a ultima figura é especial, representa o que o cliente realmente queria - é a única que não ocorre.
O Manifesto Ágil surgiu, em vista disso, como resposta aos problemas e dificuldades dos projetos de software. Seus valores e princípios revolucionaram a forma das organizações pensarem em software. A partir disso, uma pergunta deveria ser feita: Como seria o desenvolvimento ágil do projeto balanço?
Tomei a liberdade de adaptar as figuras para demostrar, no meu ponto de vista, como seria construir o famoso "balanço" utilizando uma metodologia ágil para desenvolvimento. Meu objetivo não é gerar algum resultado cômico sobre a abordagem Agile, mas sim demostrar sua aplicação em um outro ponto de vista. Todo o ciclo de vida proposto será baseado numa análise da figura clássica apresentada anteriormente, seguindo alguns dos seus princípios, como: O objetivo final do cliente (um balanço de pneu) e a visão inicial do time (um balanço convencional de madeira).
Muitas características foram desconsideradas para viabilizar o resultado final e alcançar, de forma abstrata, os valores e princípios ágeis. O desenvolvimento de software baseado em testes, burndown chart e kanban podem ser citados como características ausentes. Em contra partida, é possível notar a utilização de Iterações, Continuos Delivery, aceitação das mudanças, aproximação do cliente, entre outros.
Primeira Iteração: O time de desenvolvimento busca compreender as reais necessidades e expectativas do cliente. Percebem que o principal objetivo é se divertir utilizando um balanço um pouco diferente, que não seja o convencional, ou seja, um balanço feito de madeira. O produto final desejado pelo cliente é um balanço feito de pneu mas a equipe de desenvolvimento, obviamente, nesse momento, não sabia disso.
Segunda Iteração: Uma parte do produto será entregue ao cliente para ele validar e retornar um feedback do trabalho feito até o momento. Tendo em mente o projeto final desejado pelo cliente, concluímos que o mesmo iria aprovar esta iteração por que iria perceber que o resultado está de acordo com o esperado.
Terceira Iteração: Seria entregue uma arvore contendo uma corda amarrada em um dos galhos. Ter uma corda é necessário independente de qual tipo de balanço o cliente deseja, por isso, a iteração seria aceita também. O time possui, até o momento, uma visão abstrata do produto final. Não saberia dizer se o resultado seria um balanço de madeira ou de pneu ou, quem sabe, somente uma corda.
Quarta Iteração: O time recebeu na iteração anterior um feedback positivo do cliente sobre a corda amarrada na arvore. Com isso, o time iria trabalhar para entregar um nó na ponta da corda para o cliente aproveitar melhor a experiencia do projeto e, com isso, facilitar seu divertimento (objetivo principal dele). Ao analisar esse etapa, podemos perceber que o projeto está seguindo num rumo correto. A corda com um nó na ponta (como demostra a figura) está muito mais próximo ao desejado pelo cliente (balanço com um pneu).
Quinta Iteração: O time iria prosseguir o projeto entregando uma segunda corda amarrada na arvore, a intensão seria alcançar um balanço convencional feito com madeira. O projeto está sendo conduzido para a construção de um balanço convencional (feito de madeira e duas cordas). A entrega se uma segunda corda iria dificultar o objetivo do cliente - se divertir. Duas cordas numa arvora não iriam ser necessárias no ponto de vista do objetivo final desejado pelo cliente (balanço com pneu). O cliente iria utilizar essa versão e iria reprovar a funcionalidade entregue nessa iteração.
Quinta Iteração: Com o feedback negativo do cliente sobre a quinta iteração, a equipe iria avaliar a situação e retornar o sistema para a funcionalidade entregue na iteração anterior - a quarta iteração.
Sexta Iteração: Com a experiencia do time e do cliente sobre iteração anterior que falhou, o time irá entregar um protótipo ou um MVP para avaliação do cliente. A ideia seria apresentar o balanço convencional de forma abstrata para utilização e avaliação do cliente. Com o aprendizado da ultima iteração, a equipe está madura para compreender o sistema, o objetivo do cliente e o ciclo de vida visando entregar algo realmente de valor para o cliente. Um protótipo ou um MVP iria ajudar na validação do sistema. O cliente iria rejeitar a ideia apresentada pela equipe, visto que não é o esperado por ele.
Sétima iteração: O time iria aceitar a mudança decorrente no sistema, que consiste em entregar um balanço que não seja de madeira. O time iria entregar um funcionalidade que irá melhor a experiencia do cliente em utilizar o balanço com somente uma corda. Uma abertura redonda no final da corda seria acrescentada para melhorar a usabilidades. A equipe já percebe que a ideia de ter somente uma corda está satisfazendo o cliente e que colocar uma madeira e uma segunda corda não seriam a solução. O cliente ficaria satisfeito com o resultado mas não seria ainda o que ele esperava. A iteração seria aceita pelo cliente. A solução está bem encaminhada para o final.
Oitava iteração: O time iria melhorar a funcionalidade anterior acrescentando um pneu no lugar da abertura redonda. O cliente ficaria satisfeito com o resultado e iria propor suaves mudanças ao avaliar a situação.
Concluímos que a utilização de abordagens, valores e práticas ágeis ajudou o time a entregar um projeto de valor e de acordo com o esperado pelo cliente (lembrando que estou me baseando na figura original).
Algumas características do ciclo de vida ágil do projeto balanço podem ser notadas:
1) A utilização de uma abordagem iterativa e incremental no desenvolvimento fez com que alguns problemas com relação ao escopo não ocorram, o que não é percebido na figura original
2) O time realizou entregas contínuas para o cliente para receber avaliações (feedback) sobre o produto entregue.
3) O produto entregue a cada iteração tinha features novas que poderia ser utilizadas pelo cliente - entrega de valor.
4) As iterações podem falhar como ocorreu durante o desenvolvimento do projeto. As consequências são minimizadas por conta das entregas contínuas e o feedback do cliente faz a equipe apreender e compreender o projeto.
5) Um protótipo ou um MPV foi utilizado pela equipe para validar uma hipótese. Esse artificio é geralmente utilizado no começo do projeto com a intenção de validar a eficácia do projeto, entra outros objetivos.
6) O time aceitou as mudanças que possivelmente foram sugeridas pelo cliente. Percebemos isso na questão da utilização de um balanço de madeira para um balanço de pneu. Considere, para essa questão, a visão do cliente e do time para o projeto e a figura inicialmente apresentada.
Com isso, uma figura final como conjunto das iterações ficará assim:
mt bom
ResponderExcluir