Este artigo evidencia aspectos importantes do processo de codificação, traçando um paralelo entre eficácia e eficiência no trabalho do desenvolvedor. Também destaca como a adoção das práticas ágeis proporciona uma melhoria na qualidade do código fonte em projetos de software.  Influência do Mercado no processo de desenvolvimento. Motivos da baixa qualidade no processo de codificaçãoO mercado é regido por constantes mudanças que impactam no dia a dia das empresas. Sabe-se que tais mudanças se revertem em alterações, às vezes diárias, nos softwares e consequentemente afetam o ritmo de trabalho do time de desenvolvimento. Diante disso, é necessário, que os desenvolvedores possam corresponder proporcionalmente a essa demanda, fazendo com que as organizações se mantenham, ou se tornem, mais competitivas perante o mercado. É comum que uma pressão recaia sobre o time, uma vez que todo o processo está associado à utilização de sistemas. Neste cenário, a eficácia passa a ser um caminho natural para responder à demanda do mercado. A eficácia é o menor caminho para alcançar um objetivo. Neste contexto, o objetivo pode ser a correção de um erro que impede o andamento de um determinado processo ou a entrega de uma nova funcionalidade que irá gerar algum diferencial para a empresa. Porém, nem sempre eficácia e qualidade andam juntas. A grande incidência de código mal escrito é resultado da eficácia buscada pelo time. Geralmente, isso ocorre quando uma demanda classificada como urgente é solicitada pelos gestores. O código de baixa qualidade geralmente tem características como inflexibilidade, fragilidade, alto nível de dependência e baixo grau de entendimento. Há outros fatores que podem contribuir para a produção de código de baixa qualidade. Considere uma provável necessidade de autoafirmação de um desenvolvedor que deseja mostrar que pode atender com rapidez o que lhe é solicitado. Em situações como essa, é evidente a influência de fatores psicológicos, como, por exemplo, o ambiente de competitividade no time de desenvolvimento. Consequências da má qualidade de códigoPriorizar somente a eficácia no processo de codificação é prejudicial e insuficiente, se tornando uma prática válida apenas para gestores que buscam soluções imediatistas. Conforme mencionado anteriormente, a eficácia resulta em um aumento na incidência de código mal escrito, o que é bastante prejudicial a todos os envolvidos. Para exemplificar este prejuízo, podemos destacar: - Improdutividade resultante da manutenção de códigos de complexos;
- Compromete psicologicamente a equipe, devido à sensação de não corresponder às expectativas dos envolvidos;
- Proliferação de código de má qualidade;
- Expõe a reputação profissional do desenvolvedor, pois deixará uma má evidência do seu trabalho;
- Aumento do custo do projeto.
Devido a pouca evolução do projeto, é comum que os gestores exerçam uma cobrança mais efetiva visando alcançar os resultados, o que resulta em maior pressão ao time de desenvolvimento. Além disso, os gestores passam a adotar as seguintes práticas: - Contratação de novos desenvolvedores objetivando maior produtividade da equipe;
- Maior fiscalização sobre as atividades de cada desenvolvedor;
- Propostas de hora extra, buscando reduzir o prazo de entrega;
- Desligamento de membros do time.
Tais ações geralmente não implicam na melhoria da produtividade. Pelo contrário, resultam na insegurança, desmotivação, inchaço da equipe e ainda menor evolução no andamento do projeto. Utilização das práticas ágeis neste contextoAdotando o SCRUM como framework, o desenvolvimento de um grupo de funcionalidades (Sprint Backlog) sempre estará associado a um tempo predefinido. Isto garante que a equipe possa realizar o seu trabalho com boa qualidade, em um período que pode variar de duas a quatro semanas. Neste modelo, há um espaço de tempo definido para a entrega de uma funcionalidade, sendo que a complexidade do trabalho é diretamente proporcional a esse tempo. O conceito de Time Box faz com que o tempo, que antes era um fator crítico, passe a ser aliado do desenvolvedor ao realizar o seu trabalho. O fator tempo passou a ser controlável uma vez que o time pode mensurar a relação entre trabalho desenvolvido e o tempo gasto ou tempo restante. A adoção das Time Boxes favorece a produção de código de qualidade, obedecendo a boas práticas e convenções específicas do projeto ou da empresa. Quando adotamos o SCRUM, favorecemos ao desenvolvimento de um ritmo de trabalho uniforme, ao aumento da produtividade além de contribuirmos para uma melhora considerável no ambiente de trabalho. Além do uso de Time Boxes, outro pilar do SCRUM que favorece a qualidade de código é a inspeção. O fato de haver inspeção constante faz com que ocorra diminuição de inadequações no código já que o mesmo será previamente detectado e corrigido. Nesse contexto, devemos salientar que a interdisciplinaridade e autogerenciamento do time de desenvolvimento permitirá que todos possam inspecionar o código, contribuindo para o aprendizado constante e para a prevenção de erros do release. A programação pareada proposta pelo XP Extreme Programming, permite a refatoração de código quase que de maneira automática. A análise do código de um segundo desenvolvedor é importante e permite que a utilização de determinados métodos ou variáveis seja questionada, repensada e otimizada. Como atender as constantes demandas do mercadoEntregar releases de forma contínua significa manter o projeto em conformidade com as características do mercado que está em constante mudança. Definir as features que irão compor o próximo Sprint Backlog e saber alinhá-las aos interesses da gerência ou de outros stakeholders é um artifício que permite atendê-los de maneira convincente. O dimensionamento do tempo para desenvolvimento e entrega de releases deve estar associado aos anseios do mercado. Isso está intimamente relacionado à criação de um elo confortável entre a forma de trabalho do time e as expectativas da gerência. Ter um código legível e fácil de manter é um dos requisitos necessários para que o time possa entregar software de forma contínua e em curtos espaços de tempo, estabelecendo um ciclo harmônico entre a empresa e o mercado. *** Artigo de Fábio Carigé
|
Este artigo inspira-se em conversas que tive ao longo de conferências com alguns potenciais clientes que, expressando sua preocupação com os perigos do desenvolvimento baseado em modelos, me fizeram pensar a respeito. Na minha opinião, já foram publicados vários artigos sobre os perigos do desenvolvimento baseado em modelos. Muitos deles sustentam argumentos válidos; outros, no entanto, têm um caráter mais histórico e uma natureza repetitiva, e não consideram os recentes avanços nesse tema. É difícil encontrar artigos que façam referência a “Oito razões pelas quais escrever código manualmente é extremamente perigoso”. Certamente, existem mais de oito razões a serem enumeradas, e até me senti tentado a escrever algumas delas. O desenvolvimento em modelos gera muitos perigos, muitos dos quais originados da não compreensão de seu real valor. Assim, admito que muitos dos riscos mencionados em diversos artigos são reais. Contudo, queria enumerar também algumas das vantagens trazidas pelo desenvolvimento baseado em modelo, conhecido pelo nome “Model-driven Development” (MDD). 1. O MDD é portador de muita flexibilidade
Não há dúvidas de que o MDD implica grande flexibilidade para empresas e negócios. A flexibilidade é entendida aqui como a capacidade de dar respostas às mudanças e à adaptabilidade, tanto no que diz respeito à parte técnica como na comercial. Quando, a partir de uma linguagem selecionada, se escreve uma solução à mão, tem-se um tipo de flexibilidade (que se relaciona com o poder dentro da linguagem escolhida…?) em curto prazo, mas, a longo prazo, se está introduzindo uma grande dose de rigidez. Por isso, é fundamental levar em conta, antes de definir que passos seguir, o tempo pretendido de duração do investimento que é o objeto do desenvolvimento. Quando a escolha é Silverlight, Flash, Visual Basic, Fox, tanto no passado como no presente, é preciso criar aplicativos HTML5 ou iOS. Nesse caso, temos que grau de flexibilidade? E quantos conceitos podem ser reutilizados a partir do código existente, sempre que isso for possível? Quando o código é criado à mão, tudo o que se obtém é um código que poderá ser reutilizado ou – talvez e mais provavelmente – não. No desenvolvimento baseado em modelos, existe um modelo e a possibilidade de reutilizar conceitos. Quem cria um aplicativo Android a partir do modelo FoxPro Win é quem a longo prazo dispõe de maior flexibilidade.
Desse modo, a resposta para a pergunta ”O desenvolvimento baseado em modelos é flexível?” é: depende. Para empresários e companhias que planejam suas atividades a longo prazo, a resposta é: sim, o desenvolvimento baseado em modelos permite uma excelente flexibilidade. 2. Modelos modernos com grandes possibilidades de expansão
Atualmente, existem modelos com grande capacidade para estender em distintos níveis e cujos designs são pensados para sua interação com o código escrito à mão em todos os níveis. É comum que grande parte desse código, a médio prazo (se for realmente muito comum), se incorpore ao modelo em algum momento. Não existem modelos perfeitos, embora muitos deles sejam úteis e tenham grande capacidade para se estenderem. O interessante é encontrar uma maneira que conte com a vantagem de produtividade dos MDD, além da possibilidade de extensão, quando o modelo não for suficiente. 3. Os programadores podem concentrar-se mais no “que” do que no “como”
É formidável permitir que quem não tem nenhuma ideia sobre Objective C possa criar aplicativos de negócios para iPhone e iPad que cumpram os alinhamentos da Apple e se baseiem em um modelo que também pode ser usado para gerar aplicativos em Android, BlackBerry ou Windows 8, quando for preciso. E tudo isso com um mínimo esforço. Realmente fantástico. 4. Existem plataformas MDD que suportam controle de versões e integração contínua
Contrariamente ao que as típicas queixas estabelecem sobre o desenvolvimento baseado em modelos, na realidade, ele pode suportar o controle de versões, a colaboração e outros aspectos. Um exemplo disso é o fato de que estamos trabalhando há muitos anos para obter a atual situação, e é realmente interessante contar com a versão completa de um sistema de controle integrado com ferramentas de integração contínua. 5. Existem ferramentas muito ligadas ao MDD
Quase todas as indústrias recorrem ao software para aumentar sua produtividade e melhorar a eficácia de todos os seus níveis operativos. Trata-se de um enfoque óbvio.
Entretanto, a indústria do software é a única que se recusa a criar um programa por meio da aplicação de um sistema para cumprir os mesmos objetivos (aumentar a produtividade e melhorar sua eficácia e eficiência). Por sorte, existem muitas empresas que estão bem próximas de uma mudança de paradigma.
A única maneira de alcançar essa transformação é por meio da criação de mais ferramentas fascinantes que criem software mediante a utilização de software. 6. A equipe que trata das necessidades deve concentrar-se apenas em aspectos comerciais
A equipe responsável por considerar as necessidades pode concentrar seu trabalho no aspecto comercial, sem ter que se envolver com a parte técnica. É comum que a satisfação de certas necessidades seja impossível por causa das limitações do modelo. Porém, isso também acontece com as soluções de código escrito à mão.
É muito difícil conseguir que em um formulário exista a possibilidade de um scroll dentro de outro scroll em uma solução Android, mas a causa de tal impossibilidade não deriva do desenvolvimento baseado em modelos.
Meu argumento baseia-se no fato de que, como disse antes, uma das maiores vantagens dos modelos atuais é sua interoperabilidade com o código escrito à mão. E, no pior dos casos, será preciso escrever algo à mão. Mas isso não invalida a maior parte das vezes, em que as equipes devem concentrar-se sobre o aspecto comercial da equação em vez de preocupar-se em como programar uma solução em particular. 7. Deve-se vender a solução no paradigma MDD
O desenvolvimento baseado em modelos constitui uma maneira diferente de criar soluções, e não é necessário dar explicações ao usuário final, já que ele se encarregará de obter os benefícios.
Pode-se apresentar a solução como algo extremamente flexível a longo prazo, em que se salva uma grande quantidade de informação do negócio (representada através dos modelos) que será utilizada no futuro. 8. Já não é preciso se preocupar com a evolução tecnológica
Quando se trabalha na gestão de uma empresa, querer aplicar a melhor tecnologia disponível a cada momento é lógico. Mas quando isso implica ter que considerar os detalhes de cada nova tecnologia, estará tirando o foco do aspecto central do negócio.
Recorrer ao desenvolvimento baseado em modelos permite concentrar-se apenas no modelo do negócio sem ter que se preocupar com as contínuas mudanças de tendências da tecnologia subjacente. Esta foi minha aproximação inicial ao tema, mas a lista de razões pode ser aprimorada.*Johan den Haan descreve aqui outras razões para justificar o uso de “Model-Driven Development”.
|
Vivemos a passagem da topologia da dependência do líder-alfa para a da inteligência coletiva dos formigueiros.
Quanto mais converso com meus alunos, mais vejo o tamanho do desafio que temos pela frente.
Temos que compreender uma mudança topológica do mundo, conseguir digeri-la e adotar práticas para poder lidar com ela.
Ufa, não é pouca coisa.
Nunca na história (desta humanidade como dizia o Lula) tivemos a
chance de perceber a mudança dessa natureza (topológica cognitiva) e ter
de lidar tão rápido com ela, pois cada vez as mudanças nas topologias
estão ficando mais rápidas (se podemos dizer que séculos são rápidos, no
caso da última).
Digamos que vivemos hoje a passagem na placa-mãe da sociedade de uma topologia para outra.
Uma topologia cognitiva define basicamente como nos organizamos como
espécie em todos os sentidos: decidimos, produzimos, conhecemos,
aprendemos.
Vivemos a passagem da topologia da dependência do líder-alfa para a da inteligência coletiva dos formigueiros.
Em termos de topologia já tivemos três, conforme sugeriu Pierre Lévy: oral, escrita e digital.
Podemos dizer, assim, que estamos nos primórdios da topologia
cognitiva 3.0, mais dinâmica e compatível a um mundo de 7 bilhões de
pessoas, que vive em megalópoles.
Muitos dirão que há tempo para se preparar, mas há dois problemas aí:
- projetos que estão sendo feitos de redes sociais corporativas estão
fora de foco e vão ser dinheiro jogado fora ( e os projetos estão aí em
desenvolvimento);
- e a coisa agora está sendo muito mais rápida do que as anteriores,
por causa da densidade e capacidade de inovação dos polos principais,
todo cuidado é pouco, vide indústria da música.
Vejamos:
Detalhemos.
- Note que há por baixo da sociedade uma topologia que define a forma de trocarmos informações.
- Podemos apontar, conforme nos sugeriu Pierre Lévy, essas três etapas, que passam pela oralidade, escrita e agora a digital.
- Cada uma necessária pelo crescimento da população, que força uma sofisticação topológica, que forma a placa-mãe da sociedade.
- Podemos notar que as topologias têm fases, primeiro são beta-testadas em grupos menores e depois se massificam.
- Se relacionam com o ambiente presencial: quanto menores os
conglomerados, mais podemos horizontalizar; quando aumentam, é
necessário verticalizar. Na nossa topologia, estamos tentando
horizontalizar a explosão demográfica, por isso estamos adotando o
modelo das formigas.
- O modelo topológico da espécie humana adotado té aqui é mais próximo das matilhas, com uma maior dependência do líder-alfa.
- A sofisticação da topologia, com novas tecnologias cognitiva,
significa necessariamente o aumento de troca entre os indivíduos para
manter a espécie funcional.
As topologias cognitivas atingem toda a sociedade e é
sobre ela que a gestão vai ser modelada. Assim, não é a gestão que
define a topologia cognitiva, mas o contrário.
Veja o modelo abaixo, que segue um pouco as topologias passadas.
- Note que na rede centralizada, todos dependem muito mais do centro, do líder-alfa, com pouca interação entre as pontas.
- No segundo modelo, divide-se um pouco o papel das pontas, mas ainda
há uma forte centralização, que vai entrando cada vez mais em crise,
conforme o tamanho da espécie vai aumentando, pois perde-se tempo ao se
depender de um ponto específico.
- E, por fim, na distribuída, que é o modelo mais próximo da topologia 3.0, apenas administrada, através de rastros digitais.
A passagem de um modelo de 2 para 3 é hoje
impossível, pois precisamos do líder alfa para definir critérios de
decisão e organizar o fluxo.
O que a topologia cognitiva 3.0 permite, através da rede digital, é a
criação de trocas, a partir de rastros digitais, similar ao das
formigas, que vai retirando a necessidade da supervisão do líder-alfa,
cada vez mais trocamos com os pares palavras e rastros, o que vai nos
permitindo consolidar um novo modelo de gestão mais eficiente do que o
anterior.
Vide os modelos de gestão do Taxibeat, Mercado Livre, Estante
Virtual, todos baseados no Karma Digital, rastros, nos quais quem compra
ajuda a mostrar onde e quando comprou e alguns classificam a qualidade
do atendimento, ajudando aos que vem depois a tomar decisões melhores e
mais seguras.
Essa é a grande mudança, pois conseguimos administrar muito mais
gente, com um modelo de gestão muito mais barato, pois formiga humana
ajuda formiga humana.
Assim, a topologia define a gestão e não o contrário.
Nosso problema é que a atual topologia está nas camadas mais
profundas do nosso cérebro e precisamos criar métodos para conseguir
vê-las e poder modificá-las. Isso é a parte mais difícil.
Toda a estrutura social, incluindo a escola, prepara e
está moldada para o modelo ineficaz da matilha, sendo hoje o
formigueiro a aberração, causando forte estranhamento.
É possível migrar com menos sofrimento?
Sim, difícil, porém cada vez mais necessário.
É isso que dizes?
|
A convergência de quatro grandes ondas tecnológicas, que são
Cloud Computing, Big Data, Mobilidade e Social Business provocam
disrupções e, portanto, tanto oportunidades como riscos aos negócios e
às áreas de TI atuais.
Adotar e gerenciar de forma eficiente e eficaz essas quatro ondas vai
causar impacto significativo nos gestores e profissionais de TI. Dois
aspectos se destacam: governança e gerenciamento desse novo ambiente, e a
essencial necessidade de repensar a arquitetura de sistemas que irão
compor os novos sistemas que englobarão essas ondas tecnológicas. Neste
artigo, vamos debater a questão da arquitetura desses novos sistemas.
Os sistemas atuais, desenvolvidos pelo paradigma cliente-servidor,
não foram feitos para integrarem de forma consistente recursos como
social business, mobilidade e Big Data, e nem foram concebidos para
operarem em ambiente de nuvem. Compreensível. Tudo é muito novo. Afinal,
a onda da mobilidade começou a se formar com o sucesso do iPhone
(lançado em 2007) e dos tablets (marcado pelo anúncio do iPad em 2009).
Social business foi encarado como igual a Facebook e visto apenas como
mais um meio de o marketing se relacionar com seus clientes, sem maiores
preocupações com os sistemas legados da corporação. Big Data foi
inicialmente visto como um novo nome para Data Warehouse e, portanto,
“já fazemos isso”, e cloud surgiu com grande desconfiança. Aliás, a
mesma de vinte anos atrás começava-se a falar em client-server!
O cenário tecnológico atual é muito diferente do de anos atrás. O
ambiente central era o ERP, e tudo girava em torno dele. Hoje, o ERP
continua como base de processamento de dados transacionais, mas atende a
apenas de 30% a 40% das necessidades de informações de uma empresa. Os
novos sistemas devem atuar de forma integrada com as ondas tecnológicas.
Ou seja, uma interação via mídias sociais, oriunda de um tablet, gera
uma transação de venda e baixa do estoque, passando por uma análise,
provavelmente em tempo real, do perfil do cliente, para propor uma ação
promocional de cross-selling.
Esse contexto nos leva a uma arquitetura baseada em serviços (e tem
gente que disse que SOA morreu… O termo SOA pode ter até desaparecido,
mas aplicações orientadas a serviço são uma demanda real e bem
presente), pois os princípios básicos desse modelo (encapsulamento,
separação de funções, baixo nível de acoplamento etc.) permitem
desenvolver as aplicações com esse nível de integração com tantas e
diversas tecnologias.
Bem, começam agora as dificuldades. Primeiro, capacitação. Depois de
um período de esplendor, no qual SOA era a sigla da moda, o termo caiu
em desuso e infelizmente hoje nem todos os desenvolvedores estão
capacitados a desenvolver aplicações que sejam realmente SOA. Além
disso, nos últimos anos, a concentração da capacitação foi no modelo
cliente-servidor, acoplado ao paradigma teclado-mouse, Portanto, não é
fácil conseguir desenvolvedores com skill para desenvolver novos
aplicativos, touch-screen, integrados com plataformas de social business
e atuando com tecnologias de Big Data em tempo real, em um ambiente de
nuvem. A própria academia não está preparando adequadamente esses
profissionais. Recentemente, estive em uma universidade de peso, e os
temas Big Data, Cloud Computing, Mobilidade e Social Business eram
palestras de uma hora cada, em um currículo de quatro anos. Ou seja,
estavam formando profissionais para um mundo que já é passado…
Vamos debater um pouco mais essa arquitetura. O conceito básico dos
novos sistemas provavelmente será “everything is a service”, e a
aplicação central será um framework com APIs que permitirão aos usuários
e outras empresas desenvolverem novas funcionalidades. Um exemplo
simples: por que a tela do Internet banking tem que ser a mesma para
todos os usuários? Se os acessos aos recursos básicos forem efetuados
vias APIs seguras, o banco ficará responsável apenas pelos sistemas core
( e eventualmente uma home page padrão, como default), deixando as
interfaces serem desenvolvidas por outras empresas e pelos próprios
usuários. As características dessa arquitetura são essencialmente SOA:
alta modularidade, serviços distribuídos (os serviços podem estar em
nuvens de diversos provedores), baixo nível de acoplamento e fácil
substituição de serviços (modelo adotado pelas empresas típicas da Web,
sempre em beta mode, ou seja, evoluindo constantemente os serviços, sem
impactar o que opera ao seu redor).
Uma sugestão é usar como benchmarks para os novos sistemas, não os
modelos de aplicações que as demais empresas do setor usam, mas olhar as
empresas da Internet e avaliar como elas resolvem o desafio de estarem
atendendo a imensos volumes de dados, implementando constantemente novas
funcionalidades e usando APIs para fomentarem um ecossistema de novas
aplicações criadas por outras empresas e pelos seus usuários. Um bom
exemplo é a Amazon.com. É uma aplicação tipicamente SOA, com APIs
abertas para novas funcionalidades. Para ter uma ideia da arquitetura da
Amazon.com recomendo acessar este texto,
principalmente a sessão Lessons Learned. Claro que o modelo de
aplicações da Amazon não é válido para todas as empresas, mas serve de
referência de “best practice” para uma aplicação SOA de alta
escalabilidade, principalmente para empresas com volume significativo de
clientes, como bancos, grandes varejistas, telcos e cartões de crédito.
Enfim, estamos diante de grandes mudanças que vão afetar as áreas e
os profissionais de TI. A arquitetura de sistemas e os arquitetos de
software passam a ter um papel da maior importância, mas devem estar
preparados para essas mudanças! Talvez a melhor frase final seja “SOA is
Dead, Long Live to services”.
*** Artigo de Cezar Taurion
|
Olá, pessoal!
Mais um artigo da série Agile! Veremos como escrever boas user
stories. Este é um ponto importante, pois uma boa user story deve ser
entendida tanto pelo team técnico quanto pelo cliente/PO.
Lets…
Sabemos que escrever as user stories é “trabalho” do PO, mas na
teoria, porque na prática quem vai escrever ou é o Scrum Master ou o
time. Nem sempre a realidade do mercado consegue seguir o que temos na
literatura. Mas o objetivo deste artigo não é esse e sim tentar
responder: “as user stories do seu projeto são boas?”. Ou seja, para seu
cliente, ela é valiosa? Ele olha para ela e sabe de fato o que
significa que será feito?
Estou lendo o livro The Samurai Agile,
de Jonathan Rasmusson (em breve vou publicar um review sobre ele); em
um dos seus capítulos ele aborda sobre o assunto e vi que já cometi
alguns erros quando precisei escrever user stories há um tempo, em um
projeto pessoal. Um dos problemas foi não ter percebido o quanto alguns
pontos na user story estavam técnicos. O autor faz uma pergunta
interessante: “Se seu cliente estivesse com fome e ele tivesse que
escolher apenas entre as duas opções abaixo, o que seria mais claro para
ele?”
1. História: Ernie’s Tech Diner
C++ 3 days
Connection pooling 2 days
Model-View_presenter pattern 5 days
2. História: Sam’s Business Pancake House
Create user account 3 days
Notify subscribers of new listings 2 days
Cancel subscription 1 day
Com certeza a história dois faz mais sentido para o negócio do
cliente. Os termos são simples e fáceis de serem entendidos. E o mais
comum: quando somos muito técnicos e escrevemos como na primeira
história, o SM deve ficar atento com isso caso todo o time esteja
participando da escrita das US. E em outro exemplo o autor trouxe que
podemos ser técnicos e o cliente entender. A história abaixo não perde
seu valor:
Add database connection pooling: é dificil para o cliente entender
Mas…
Reduce page load time from 10 secs to 2 secs.
Parece que faz mais sentido para o cliente e você já sabe o que
acontece nos bastidores para atingir o objetivo da user story (US).
Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.
- Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
- Negociável: é que ela pode ser alterada e adaptada e não fechada.
- Testável: que seja possível criar testes que valide aquela história. Algo como:
Login with expired:
Testable:
– redireciona logins expirados
– mostra mensagens de erros apropriadas
- Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.
Vou ficando por aqui, espero que tenham gostado.
See ya!
*** Artigo de Camilo Lopes
|
Neste artigo vou trazer o que ganhamos ao escrever User Stories
ao invés de ter que gastar mais tempo escrevendo documentações de
requisitos. Não estou dizendo que não devemos documentar, pelo
contrário. Porém, a ideia é saber o que e como documentar.
O User Stories promove os seguintes pontos:
- Aprendizado;
- Precisão;
- Encoraja a comunicação face-to-face com o cliente;
- Possibilita feedback em tempo real;
- Evita a falsa sensação de que temos tudo documentado de forma correta e só falta implementar;
- Permite uma colaboração e inovação com o time.
Já os documentos de requisitos:
- São grandes e cansativos;
- Encoraja o trabalho por imaginação com falsos ‘achismos’;
- É difícil de planejar;
- Feedback em tempo real é inexistente;
- Desencoraja abertura de colaboração e invocação com o time.
Isso quer dizer que não vou documentar? Não. Em um projeto Agile há
documentação sim, porém ela não é o meio primário de obter as coisas e
nossa última fonte de obter o entendimento, conversar com o cliente, é
mais importante. A diferença é que aqui evitamos o desperdício do tempo
documentando, pois ao terminar toda documentação, o que foi escrito no
início talvez não tenha mais valor para o cliente.
Vou ficando por aqui. Espero que tenham curtido o artigo e possam colocá-lo em prática na realidade de vocês. ***
Artigo de Camilo Lopes
|
Confira algumas dicas para um escopo dinâmico de projetos de sistema por meio de uma abordagem ágil.
1. Definindo um escopo de projeto de software
Um conjunto de definições que especificam as funcionalidades de um
software a ser desenvolvido constitui um escopo de projeto de software.
Esse escopo deve considerar o contexto no qual o software será
utilizado, seus objetivos, funções e seu desempenho. Para isso, ele deve
ser bem definido e claro, além de procurar especificar com detalhes as
funcionalidades e as restrições do projeto.
Se buscarmos analisar de uma maneira mais objetiva, um escopo de
projeto de software prevê e delimita situações relacionadas ao cotidiano
do cliente e por isso propõe uma solução para melhoria da produtividade
do mesmo.
Delimitar funcionalidades e prever melhorias no processo de trabalho
do cliente faz com que ele seja informado sobre custos, prazo e o que
será realmente entregue. Isso fará com que a proposta se torne mais
atraente, uma vez que essas informações possibilitarão uma adequação do
seu trabalho em função do que será gasto e do software que lhe será
entregue. Paralelamente, se adotarmos a ótica de quem desenvolve o
software, esse contexto também se torna interessante já que haverá uma
previsão de receita, prazo e demanda. Por isso, o desenvolvedor possui
um roteiro do que deve ser feito, quanto irá ganhar e quando estará
livre para assumir um novo projeto. Ou seja, o cliente sabe o que
precisa desde o início do projeto, e o desenvolvedor calcula com
exatidão o dia em que será entregue o software com todas as
funcionalidades solicitadas.
2. A previsão e a realidade
O contexto descrito anteriormente é na maioria das vezes irreal
devido às mudanças resultantes do mundo dinâmico. Além disso, na grande
maioria das vezes, o cliente não sabe com exatidão o que ele realmente
precisa para melhorar o seu processo de trabalho. Em geral, ele sabe
apenas indicar o problema e as suas consequências para a empresa. Ele
sabe também que a solução pode vir através de um software.
Analisando desse ponto de vista, a possibilidade de definição de um
escopo de projeto de software é inviabilizada em função das indefinições
do cliente e da inconstância do ambiente em que o negócio do cliente
está contextualizado.
Diante da indefinição de um escopo de projeto de software devido a
esses aspectos, como é possível mensurar custos, prazo e as
funcionalidades que serão entregues?
Partindo da premissa de que o cliente tenha um total conhecimento das
suas necessidades e por isso não solicite mudanças ao longo do projeto,
então a equipe poderá fazer um bom trabalho de estimativa para que o
escopo seja previsível. Correto? Não. Tendo em vista esse contexto,
haverá ainda a dependência de que o cliente comunique todos os detalhes
do seu processo para a equipe e que ela entenda com exatidão o que lhe
foi transmitido pelo cliente. Sabemos que o cliente não expõe
detalhadamente suas necessidades, já que elas possuem um alto número de
detalhes que fazem diferença no processo de desenvolvimento. Mesmo
considerando que todos os detalhes serão passados pelo cliente de
maneira escrita, o desenvolvedor poderá interpretar o que leu de várias
formas, e isso irá resultar em inadequações no processo de
desenvolvimento.
3. Consequências da definição de escopo
Na grande maioria dos projetos de software, definir previamente um
escopo de projeto de software, buscando obter seu prazo e seu custo, não
possui qualquer validade, já que o cliente será enganado com prazos e
custos irreais, e a equipe de desenvolvimento não terá noção exata sobre
prazo, escopo e esforço necessário para desenvolvimento do software. É
importante que o cliente saiba que fixar um escopo, na maioria das
vezes, é inviável e poderá prejudicá-lo. Se mesmo assim o cliente optar
por um escopo fixo, o mesmo estará assumindo que nenhum conhecimento lhe
será acrescentado no decorrer do projeto e, além do mais, estará
garantindo que não haverá mudanças no seu processo de negócio. Por isso,
essa opção significa correr alto risco em relação ao software não
atender as suas reais necessidades quando lhe for entregue.
Algumas estatísticas informam que mais de 60% das funcionalidades de
um software, resultante de um projeto com escopo definido, não são
utilizadas em ambiente de produção. As prioridades em determinados
processos do cliente podem ter mudado desde o momento da definição do
escopo ou simplesmente o desenvolvimento da funcionalidade pode não ter
representado um valor real para o cliente. Consequentemente, mais de 60%
do valor do projeto foram desperdiçados.
4. Dinamizar o escopo é uma boa alternativa
A proposta é a definição de um escopo inicial que possui as
funcionalidades mais importantes para a realidade do cliente. Dessa
maneira, essas funcionalidades serão projetadas, desenvolvidas, testadas
e entregues de maneira que o cliente irá percebendo e fornecendo
feedbacks sobre novas necessidades do seu negócio. Baseando-se nessa
nova proposta, o cliente passa a aprender com o próprio projeto e, por
isso, terá condição de redefinir suas necessidades e reorganizar suas
reais prioridades sem se preocupar em redefinir o escopo do projeto. Por
outro lado, a equipe de desenvolvimento passa a obter progressivamente
conhecimento sobre o negócio do cliente e sobre aspectos técnicos
relacionados ao projeto, podendo desenvolver uma solução de melhor
qualidade.
E quanto ao custo e prazo do projeto? Esse aprendizado pode
significar a redução do prazo do projeto e consequentemente a redução de
custos, já que o cliente passa a ter noção de suas reais necessidades.
Isso irá evitar esforço desnecessário para o desenvolvimento de uma
funcionalidade que não será essencialmente importante para o processo do
cliente ou até mesmo não compensará ser desenvolvida devido a sua
relação custo x benefício. Dessa forma, não haverá sentido em definir
antecipadamente o escopo de projeto de software expondo seu prazo e
custo.
Rever as prioridades do cliente é a melhor forma de conduzir o
projeto de software. Isso só é possível ao longo do projeto e na medida
em que o cliente passa a entender melhor o seu negócio, e a equipe de
desenvolvimento passa a entender melhor o projeto.
5. Adoção de contratos de escopo dinâmico
Trata-se de um contrato baseado na imprevisibilidade de um projeto de
software. O escopo absorve as incertezas do projeto. É possível fixar
custo, prazo e qualidade como variáveis. Ou seja, pode-se fixar o que o
cliente irá gastar e quanto tempo irá durar, porém ele não sabe o que
irá receber (escopo), da mesma forma que ele não saberia se fosse
definido o escopo do projeto. No escopo definido, há apenas a ilusão de
saber o que será entregue. Portanto, não há perda em relação à definição
ou indefinição do escopo nesse caso.
A qualidade pode ser fixada graças a técnicas de desenvolvimento
orientado a testes, refatoração, integração contínua e outras técnicas.
O entendimento do projeto pelo cliente será garantido através de cada
iteração. Cada iteração irá gerar um release do sistema que irá conter
novas funcionalidades. A partir da utilização dessas funcionalidades, o
cliente irá perceber se elas lhe atendem suficientemente ou se precisam
de ajustes. Dessa maneira, o cliente tende a ter a sensação de que o
projeto está evoluindo e que suas necessidades estão sendo atendidas. A
partir disso, ele passará a analisar se o que será desenvolvido possui
relevância ou custo-benefício favorável. Observemos que o projeto poderá
ser encerrado com um prazo relativamente baixo, já que a tendência é
que o cliente sinta-se satisfeito com as funcionalidades já entregues e,
por isso, o cliente passa a desembolsar um valor menor pelo software.
Uma das principais vantagens é evitar o desperdício de esforço, prazo e
custos no projeto.
6. Conclusões – mudança cultural
É inegável que há uma grande mudança cultural ao adotar uma visão
dinâmica e flexível do projeto. É preciso especificar ao cliente os
detalhes de todos os aspectos abordados anteriormente, desde a ausência
de previsibilidade ao aprendizado do cliente no decorrer do processo.
Esses pontos corroboram a necessidade de alterações nas formas de
contratação de projetos de software. Caso haja percepção dessa
necessidade por parte do cliente, é mais viável a utilização do contrato
de escopo variável para atender o problema. Pode-se também comparar
vantagens do contrato de escopo negociável em relação ao contrato de
escopo fixo para convencimento do cliente. Certamente se perceberá o
quanto esse modelo tende a enriquecer e aumentar o sucesso em projetos
de desenvolvimento de software.
***
Artigo de Fábio Carigé
|
A programação em par
é uma prática um tanto quanto controversa, e altamente ágil
contra-intuitiva. Em poucas palavras, são duas pessoas que trabalham na
mesma coisa, usando apenas um computador, ao mesmo tempo. Parece loucura
que isso funcionaria de fato, muito menos ser melhor do que dois
programadores trabalhando separadamente. Mas de alguma forma ela
funciona.
Estamos usando essa técnica há algum tempo, e tenho notado alguns benefícios interessantes que gostaria de compartilhar.
Eliminando dialetos
Se você pedir a 10 pessoas para escrever um pequeno parágrafo sobre
uma ideia específica, provavelmente receberá 10 resultados muito
diferentes. De fato, isso provavelmente seria verdade mesmo se você
tivesse especificado exatamente o que queria que a pessoa escrevesse
(tudo – desde quantas frases deveriam ser utilizadas até as estruturas
gramaticais permitidas).
O mesmo vale para os programadores. Os devs possuem seus próprios
estilos de escrita de código, não importa a linguagem. Eles diferem em
nomes de variáveis e nomes, preferências para construções específicas de
fluxo de controle, comentários de estilos etc. Resumindo, os devs
possuem seus próprios dialetos.
Esses dialetos são especialmente perceptíveis quando um único dev
trabalha exclusivamente em uma parte específica de uma grande base de
código. Ler módulos diferentes em um código fonte é como ir a uma
excursão no campo e ouvir tudo com sotaques diferentes.
Claro, existem coisas que você pode fazer para tentar minimizar essas
diferenças (coisas como padrões de codificação e convenções de
nomenclatura). No entanto, acho que a maioria dos devs tem dificuldade
em seguir as convenções de nomenclatura quando são deixados à sua
própria sorte. É muito fácil recorrer ao seu dialeto quando ninguém está
olhando.
Comece a trabalhar em par (pairing). O pairing é quase
surpreendentemente eficaz em eliminar dialetos de dev e em obter um
código inteiro para ler a base como se fosse escrito por um único
programador. Aparentemente, é muito mais difícil injetar seu próprio
estilo no código quando alguém assume o teclado a cada poucos minutos.
Reduzindo a complexidade
Muitos devs amam a complexidade. Mais perturbador, muitos se sentem
obrigados a, desnecessariamente, introduzi-la no código que escrevem. O
mais preocupante de tudo é que poucos têm a autoconsciência para
perceber o que estão fazendo antes que seja tarde demais. Então, os
códigos fontes em todos os lugares estão repletos de versões diferentes
de uma máquina de Goldberg.
O fato é que, quando o código está apenas na sua cabeça, ele
normalmente parece muito simples. As condições de limites e os casos
extremos são examinados rapidamente, saltos esquisitos de lógica não
parecem tão estranhos, as construções complexas parecem simples, e assim
por diante.
A programação em par te obriga a explicar suas
ideias de design aparentemente racionais para outro ser humano. Na
maioria das vezes, o próprio ato de explicar para alguém o ajuda a
perceber que algo está errado. E, se isso não o faz, um olhar intrigado
ou um cético “OK…” do seu par provavelmente o fará.
Pensamento final
As duas razões mais comumente aceitas para programação em par são
promover propriedade compartilhada e forçar revisões de código
contínuas. São benefícios importantes com certeza, mas a programação em
par também ajuda de outras maneiras. Você já notou algum que você
gostaria de compartilhar?
***
Texto original disponível em http://tatiyants.com/benefits-of-pair-programming/
|
Eu não sei exatamente quando foi que comecei a me ressentir com
pessoas para quem eu estava escrevendo código, mas foi um sinal claro de
que eu estava me sentindo esgotado. Durante dez anos, trabalhei como um
desenvolvedor em agências de design e marketing, em seguida, no Yahoo!,
e, finalmente, dentro da minha própria empresa de serviços ao cliente.
Em algum ponto ao longo do caminho, eu tinha perdido contato com as
pessoas que utilizam o software que eu estava criando. E isso foi um
saco!
Uma das grandes alegrias de criar software é resolver problemas. Não
apenas resolver problemas academicamente, mas realmente consertar as
coisas para as pessoas. Tornar a vida de outras pessoas melhores,
permitindo-lhes realizar mais com menos. A satisfação obtida por ter
outro ser humano satisfeito usando o que você criou é o que faz tudo
valer a pena. Se esse ciclo de feedback é quebrado, você acaba liberando
código para o vazio como uma máquina produzindo funcionalidade para a
especificação.
Uma coisa que você encontra rapidamente quando você reduz seu papel para simplesmente uma das codificações para a especificação
é que a sua posição padrão para qualquer pedido é “não”. Para manter o
projeto no prazo, no orçamento, e para evitar que a equipe boie, você
tem que se manter firme contra o que poderia ser visto como mudanças
desnecessárias e pedidos estúpidos de usuários que realmente não sabem o
que estão falando. É cansativo dizer “não”, e acaba acumulando
rapidamente ressentimento para com aqueles que fazem as perguntas.
Antes que você perceba, o trabalho não é divertido como ele costumava ser.
A solução é fácil. Pare de codar para especificação, e comece a programar novamente para os usuários.
Funcionalidade não é o bastante
Acho que todos nós, provavelmente, estivemos em uma situação na qual
os usuários pedem algo que já existe. Com o nosso pequeno CMS, Perch, os usuários muitas vezes pediram a capacidade de reordenar itens de conteúdo.
É claro, já era perfeitamente possível reordenar os itens – havia
opções para definir o conteúdo para ordenar em qualquer campo, e em
qualquer direção. Se o usuário precisava de uma ordem arbitrária, eles
poderiam adicionar um novo campo, adicionar um número aos seus itens, e
ordenar com isso. No papel, era um sistema bastante poderoso e flexível.
No entanto, os usuários ainda estavam pedindo uma maneira de ordenar o
conteúdo. A funcionalidade estava lá, mas os usuários não estavam
encontrando, entendendo, ou ambos. A especificação foi atingida, mas a funcionalidade estava fracassando com os usuários.
Lembre-se, a especificação é um requisito mínimo. Para realmente fazer um bom trabalho, às vezes é necessário ir além do que a especificação diz e fazer algo que realmente funciona para as pessoas que têm de usá-la.
Aceite quando os usuários estão tendo problemas
Uma grande parte disso é aprender a aceitar quando o código em que
está trabalhando está quebrado. Às vezes os problemas internos são os
mais difíceis de resolver e, como com todos eles, o primeiro passo para
resolvê-los é admitir que você tem um problema. Como um desenvolvedor, é
uma lição muito difícil aprender que, uma característica que funciona
perfeitamente, livre de erros, está quebrada se os usuários não a
entendem.
O que você desenvolveu pode atender aos requisitos da especificação o suficiente para obter o aval, mas não estamos trabalhando para a especificação mais. Como é que vamos começar utilizar e aval?
Às vezes, o problema pode ser resolvido com uma melhor mensagem de
usuário, ou por repensar a interface, mas outras vezes você só tem que
aceitar que os usuários estão tendo problemas, e que você precisa voltar
à prancheta – e que isso é ok. Se o que está aí não funciona para os
usuários, então não funciona.
Minha primeira recomendação nessa situação é simplesmente ouvir seus
usuários. Pergunte a eles o que estão tentando conseguir. Muito parecido
com a debatida citação “cavalos mais rápidos” de Henry Ford, seus
usuários podem aparecer com as soluções erradas, mas o seu requisito
fundamental pode muitas vezes ser destilado a partir dessas soluções.
Então, pergunte a eles, e depois ouça atentamente a resposta.
Os verdadeiros grandes desenvolvedores resolvem problemas
Voltei para a prancheta com a minha ordenação de conteúdo e
implementei uma interface JavaScript de reordenação usando drag e drop. O
core que meus usuários estavam pedindo era uma forma rápida de definir
uma ordem arbitrária de conteúdo. Eu não sou de lançar enormes
quantidade de JavaScript em todos os problemas, mas, nesse caso, parecia
que drag and drop era uma boa maneira de atingir esse objetivo.
Agora os usuários podem pegar um pouco de conteúdo e largá-lo
facilmente onde quiserem. O resultado final é diferente da
funcionalidade que fornecemos antes? Não, mas o processo de chegar lá é
mais alinhado com a maneira como os usuários querem utilizar o software.
Isso não só significa que eles não estão me incomodando com pedidos
de recursos que existem, mas também que são capazes de conseguir mais
com o software.
FAQs são erros que você não corrigiu ainda
Temos uma política de não ter FAQs. Se os usuários estão perguntando
sobre algo com regularidade, então isso significa que não estamos
explicando as coisas claramente, ou que o produto pode ser melhorado.
Com o Perch, os usuários precisam adicionar o domínio do seu site e a
chave de licença correspondente antes de poderem logar em uma nova
instalação. Se eles perderam todas as instruções e não conseguiram fazer
isso, então foram presenteados com a seguinte mensagem:
“Desculpe, sua chave de licença não é válida para este domínio.”
Apesar de precisa, essa mensagem muito raramente resultou em o
usuário tomar o rumo correto de ação para resolver o problema. O que
elas realmente fazem é pedir ajuda dizendo que eles não conseguiram
logar.
Uma maneira de resolver isso seria adicionar FAQ ao nosso site que
explica o que fazer quando se deparar com a mensagem. Isso seria um
curativo na ferida – seria estancar a hemorragia, mas não aliviar a dor.
A solução real era muito mais simples. Nós modificamos a mensagem de
erro:
“Desculpe, sua chave de licença não é válida para este domínio. Log
em sua conta Perch e adicione o seguinte como o seu domínio de produção
ou de teste: example.com”
Com example.com sendo o domínio onde a instalação está sendo
executada. Após essa alteração simples, ninguém nos faz essa pergunta
mais. Tenho certeza de que muita gente ainda sente falta das instruções
de instalação e vê o erro, mas não é mais um problema para eles – eles
só precisam fazer a alteração e continuam sem incidente.
A pior coisa que você pode fazer com FAQs é uma lista delas em seu
site. FAQs são bugs, e a única resposta satisfatória para eles é
corrigir o problema; assim, as perguntas não serão feitas novamente.
Ser um desenvolvedor não é fornecer ferramentas, é resolver
problemas. Se queremos curtir o que fazemos, fazer coisas
impressionantes, e não nos sentirmos esgotados, então precisamos
encontrar maneiras de resolver problemas que funcionam muito bem para os
usuários. Se você fizer um grande software, os usuários apreciarão seu
trabalho e você vai se sentir orgulhoso com o que você conseguiu. Pra
mim, isso soa como uma boa receita para ser feliz no seu trabalho.
***
Texto original disponível em http://phpadvent.org/2011/code-for-the-users-not-for-the-spec-by-drew-mclellan
|
Assim, não é a Internet que vai se adaptar à atual gestão, porém a atual gestão que vai se adaptar à Internet.
Fazer a gestão é procurar controlar variáveis e se adaptar às incontroláveis para se chegar a um dado objetivo. Certo?
- Há variáveis que temos ingerência – que podemos administrar;
- E outras a que temos que nos adaptar.
A base de um ambiente de gestão (controle/descontrole) começa pela troca de informações, da circulação de ideias.
Ninguém vende ou compra nada para ou de ninguém, não faz nenhuma
troca, sem antes criar um canal informacional/comunicacional para que
ela seja feita.
Assim, a base dos negócios começa com:
- uma plataforma de informação e comunicação;
- sobre a qual se desenvolve uma plataforma de trocas.
Quando uma muda, a outra se adapta e vice-versa.
Dessa maneira, podemos dizer que a gestão é diretamente
condicionada pela plataforma de comunicação e informação da sociedade,
que estabelece regras específicas de controle e de troca.
Se temos uma mudança nessa plataforma básica, os negócios mudam.
Se temos uma mudança radical na forma de controle dessa plataforma
básica, a gestão também muda de forma radical, pois o controle passa a
ser feito de uma nova maneira, com repercussão na gestão.
O grande problema que estamos vivendo com a chegada da
Internet é que consideramos que a gestão continua a mesma com pinceladas
de uma nova tecnologia, uma nova forma de comunicação.
Porém, estamos mudando a forma de controle da plataforma de informação e comunicação.
Ou seja, os que estão acessando essa nova plataforma estão
experimentando uma troca mais desintermediada do que a passada –
reintermediando processos, tanto de comunicação (primeira etapa) como de
trocas (segunda fase).
E estão gostando disso e mudando-se enquanto usam.
Ou seja, usar o novo ambiente cognitivo significa uma mudança do ser
humano, que passa a ser mais maduro cognitivamente e emocionalmente em
relação àqueles que se acostumaram ao papel impresso, ao rádio, à
televisão.
Dessa forma, estamos entrando, inapelavelmente, em um mundo novo, com
uma nova plataforma de troca informacional, que nos leva a um novo
ambiente de controle, com novos consumidores/cidadãos – que implica uma
nova forma de se fazer a gestão.
Assim, não é a Internet que vai se adaptar à atual gestão, porém a atual gestão que vai se adaptar à Internet.
Ou seja, temos dois modelos de controle que estão vivendo em paralelo hoje:
- O modelo 1 (de controle tradicional/analógico) –
com um centro muito forte, que coordena as ações, que estabelece uma
separação entre os vários pontos, criando uma intermediação específica,
nisso se encaixam professores, médicos, jornalistas, organizações de
todos os tipos;
- O modelo 2 (de novo controle digital) – com um
novo centro mais inteligente e sofisticado, que permite a troca muito
mais livre entre as pontas, reintermediando de forma mais inteligente os
processos.
O modelo 1 tem processos e custo mais elevado do que o
modelo 2, por isso ficará cada vez mais obsoleto, pois não consegue
impedir que empreendedores + capital de risco entrem em cada vez mais
áreas com a nova forma de gestão tanto da comunicação, quanto dos
processos. Na área pública, nota-se a necessidade de aumento cada vez
maior de quadros com resultados cada vez menores.
Uma revolução cognitiva estabelece, assim, uma nova forma mais
sofisticada de controle (gestão), baseada em novos princípios,
conceitos, métodos e tecnologias.
A nova forma é incompatível com a anterior.
Tentar criar organizações híbridas (com dois tipos de controle) é uma insanidade típica de um tempo sem clareza.
O modelo 1 é incompatível com o modelo 2!!!
Simples assim, são dois modelos de controles com DNAs diferentes.
Precisamos criar um canal de passagem, no qual é preciso ter as duas áreas agindo em paralelo, com a 1 isolada da 2.
É a forma mais barata e eficaz de fazer a passagem.
As tentativas que estão sendo feitas de misturar modelos é altamente
dispendiosa, com resultados pífios, como estamos vendo por aí.
Que dizes? ***
Artigo de Carlos Nepomuceno
|
Nos últimos anos, tenho apresentado inúmeras palestras sobre
Cloud Computing, Big Data, Mobilidade e Social Media. Embora muitas
vezes estes temas sejam apresentados de forma independente, eles formam
uma convergência de forças transformadoras que, na minha opinião, irão
mudar de forma radical o atual “way of life” de TI. Os dispositivos
móveis, impulsionados pelo tsunami da consumerização, serão a plataforma
de acesso, onde volumes imensos de dados e processamento serão operados
em nuvem, criando inúmeras e inovadoras formas de conexões entre
pessoas e empresas, gerando o que chamamos de social business.
No ambiente doméstico já vivenciamos isso no nosso cotidiano. Por
exemplo, posso armazenar uma informação, seja esta um texto ou uma foto,
e acessá-la pelo meu smartphone, meu tablet, meu iPod, ou meu laptop.
Onde estão estas informações? Estão em uma nuvem. Este movimento também
vai entrar no ambiente corporativo. As razões são muitas. Uma delas é
que os usuarios domésticos, e principalmente a geração digital que está
entrando no mercado de trabalho, já lidam com a tecnologia com muita
intimidade. Além disso, a imensa complexidade da infraestrutura por trás
de um contexto destes está mascarada para eles. Eles interagem com seus
dispositivos móveis sem terem ideia da complexidade tecnológica que
está na retaguarda. Por outro lado, nas corporações, muito da
complexidade tecnológica está exposta aos seus usuários. Eles devem
interagir com TI para obter novos serviços e serem autorizados a usar
determinada tecnologia. Os interfaces dos sistemas aplicativos são
complexos e pouco intuitivos. Requisitar mais capacidade computacional é
demorado, passa por um lento processo de aprovação e instalação de
novos servidores e softwares.
Claramente que existe uma diferença significativa e palpável entre a
imensa facilidade com que a pessoa interage com a tecnologia em casa e
como ele interage com ela no seu ambiente de trabalho, dentro das
empresas. Este descompasso cria uma pressão muito grande para a
reformulação do atual cenário de TI.
Em casa posso pesquisar rapidamente um livro eletrônico na Amazon e
baixá-lo para meu Kindle. Posso ver filmes atuais via Netflix e pegar
qualquer musica no iTunes, de forma fácil e quase instântanea. Faço isso
sozinho, sem necessidade de recorrer a nenhum suporte técnico. Esperar
horas para ter acesso a quaisquer destes recursos é inimaginavel. Estas
mudanças estão fazendo com que alguns setores caminhem para
obsolescência, mesmo sem perceber. Um exemplo? Eu confio muito mais nas
opiniões dos meus amigos que na opinião dos críticos de cinema quando
escolho um filme. Existirão críticos de cinema no futuro? Decisões
sobre tecnologias são muito mais influenciadas pelas conexões com outros
profissionais via plataformas sociais, como Facebook, Linkedin e
Twitter, do que pela leitura dos sites oficiais das empresas. Qual será o
valor de um site típico de hoje daqui a cinco anos?
Mas nas empresas, o acesso às informações e recursos computacionais
leva muito tempo. Os processos são demorados e muitas vezes
burocráticos. A tecnologia nem sempre é usada para transformar
processos, mas simplesmente automatizá-los. Não criam inovações no dia a
dia dos funcionários e nas relações da empresa com seus clientes.
Portanto, neste verdadeiro turbilhão de transformações as áreas de TI
deve reinventar-se. A convergência aparece em todos os momentos. Por
exemplo, para criarmos um modelo de social business, o acesso via
dispositivos móveis é essencial. A computação móvel vai ter tanto
impacto na sociedade e em seus hábitos quanto o automóvel. A sociedade
atual é baseada em um modelo centrado no automóvel. Com a computação
móvel, o trabalho deixa de ser um local físico, estabelecido, para ser o
local onde você está. As pessoas querem fazer suas conexões a qualquer
momento, exatamente quando precisarem. A rede social também depende de
escala e para suportar esta escala é necessário um ambiente
computacional dinâmico como cloud. E as conexões geram muitas
informações, que, se analisadas e correlacionadas, nos permitem ampliar a
rede e gerar mais conexões: big data.
A computação em nuvem é o elo de ligação entre as outras forças. É a
base em que construiremos um novo modelo de aquisição e entrega de
produtos e serviços de TI. Na verdade, TI tende a ser serviço por
excelência. “TI-as-a-Service” será o modelo dominante, quem sabe, já no
final desta década.
Este cenário apresenta um grande desafio para as áreas de TI. O
processo atual de identificar uma determinada tecnologia, instalá-la e
ensiná-la aos usuários cai por terra diante da consumerização. Esta
permite que os usuários escolham suas próprias tecnologias e aprendam a
usá-las sozinhos ou com ajuda da sua rede social, sem interferência dos
fornecedores. A convergência das forças e, principalmente, a
consumerização estão deslocando o eixo de controle da TI para o usuário.
Em tempo, consumerização é muito mais que BYOD (Bring Your Own Device),
pois sua influência cria uma expectativa de experiências com a
tecnologia que provoca disrupções na maneira como TI deverá ser usada
nas empresas. O BYOD é consequência da consumerização e não um sinônimo.
Portanto, os setores de TI que continuarem sendo rígidos e inflexíveis
diante destas mudanças, correm o risco de se tornarem anacrônicos.
Não há outra alternativa para TI a não ser se transformar. É verdade
que as transformações no setor de TI de uma empresa são tarefas
complexas. Existem inúmeros sistemas legados a serem mantidos e diversas
gerações de tecnologias que interoperam entre si, mas é importante que o
legado fique restrito apenas aos sistemas e não ao mind-set. O que TI
deve fazer? Redesenhar sua arquitetura para contemplar a convergência
das quatro forças que interagem entre si, impulsionando-se
reciprocamente. Os dispositivos móveis são a plataforma de acesso e um
impulsionador para as midias sociais. A informação passa a ser o
contexto para a criação das conexões e o ambiente de cloud computing é a
base computacional para suportar todo este cenário.
TI pode, com esta arquitetura, deixar de ser um centro de custo, para
ser parte integrante do negócio, como a plataforma que a empresa vai
usar para criar novos produtos e negócios. TI passa ser função do
negócio e o CIO deve se transformar em um executivo de negócios que usa
tecnologia como alavancador de inovações, e não se manter como um
tecnocrata. Deve pensar e falar a linguagem do negócio e não em 0s e 1s.
Focar na tecnologia por si é apequenar o potencial da TI. ***
Artigo de Cezar Taurion
|
Já faz muito tempo que as empresas investem em
inovação para poder responder às constantes mudanças do mercado. Essas
empresas precisam adaptar processos, de forma mais rápida, e diminuir o
time-to-market de produtos, respondendo às necessidades de clientes e,
assim, mantendo-se competitivas no segmento de atuação. No momento em
que os softwares utilizados por elas se tornam a peça chave em processos
produtivos e de inovação, é quando diretores e gestores descobrem que o
sucesso do negócio depende diretamente da agilidade do departamento de
TI.
Nesse contexto, em que organizações precisam replanejar
constantemente decisões estratégicas, reduzir custos operacionais, além
de adaptar processos e serviços para poder atender clientes cada vez
mais exigentes, investir em uma forma de gerenciamento de projetos mais
ágil, com o Scrum, pode se tornar um diferencial competitivo
fundamental. O Scrum é uma metodologia de gerenciamento de projetos,
baseada no desenvolvimento iterativo e incremental de software, que
beneficia empresas e clientes, basicamente, em três pontos principais:
1. Aumento do Retorno Sobre o Investimento (ROI)
O Scrum prioriza a
entrega de requisitos de maior valor de negócio, ou que apresentam
maior risco estratégico para a empresa. Isso significa que o dono do
produto (product owner) sempre manterá uma lista priorizada (Backlog)
com todas as funcionalidades que deverão ser implementadas antes pelo
time de desenvolvimento. Dessa forma, garantimos que tudo aquilo que for
mais importante para o negócio do cliente será desenvolvido, testado e
entregue primeiro. Isso permite agregar mais valor ao negócio, em menos
tempo, diminuindo custos de operação e aumentando o retorno sobre o
investimento (ROI) desses projetos.
2. Mais Flexibilidade às Mudanças do Mercado
A pesquisa do PMI
(Project Management Institute), realizada em 2010, com 300 grandes
organizações no Brasil, colocou mudanças de escopo constantes como o
segundo problema mais comum na gerência de projetos, sendo citada em
mais de 70% das organizações entrevistadas. Não é incomum projetos serem
concebidos e encerrados no meio da execução, por inúmeros fatores,
como: mudança de mercado, reposição de concorrentes, ou mudanças de
expectativas dos clientes finais. O mercado vai mudar sempre. O que faz
uma empresa ser competitiva é responder rápido a essas mudanças. O
Scrum, como a maioria das metodologias ágeis de desenvolvimento,
incentiva o desenvolvimento incremental e entregas parciais do produto
que está sendo desenvolvido. Essas entregas (chamadas de sprints)
geralmente têm duração de duas a quatro semanas, e contemplam o ciclo
completo de desenvolvimento do produto, com as fases de planejamento,
design, implementação e testes de aceitação de cada requisito que está
sendo desenvolvido. Se o cliente mudar, se o mercado mudar, se o que
ontem era tão importante hoje não fizer mais sentido, sem problemas.
Podemos mudar nosso planejamento e repriorizar nosso backlog já no
próximo sprint.
3. Redução do Time-to-market
Nessa mesma pesquisa, o não
cumprimento de prazos é campeão entre os problemas em projetos, citado
por mais de 72% das 300 organizações pesquisadas. A maioria dos projetos
é desenvolvido para criação ou melhoria de um produto ou serviço, que
atende a alguma necessidade identificada no mercado. Isso significa que
essa necessidade de mercado tem data de validade, que geralmente é
curta, pois pode se modificar ou deixar de existir rapidamente, em
questão de semanas ou dias, dependendo do segmento de negócio do
cliente. Como o Scrum promove a entrega de funcionalidades completas a
cada sprint, o produto vai sendo construído e entregue à medida que o
projeto avança, e novas funcionalidades vão sendo disponibilizadas no
mercado. Essa característica do Scrum permite que produtos sejam
lançados e validados no mercado muito rapidamente, reduzindo
drasticamente o time-to-market de produtos, e atendendo aos prazos de
forma mais eficaz. Esses fatores fazem com que o Scrum já seja aplicado
por empresas de diversos segmentos no Brasil, além de ser visto com bons
olhos por grande parte dos de gestores, líderes e gerentes de projeto
da área de TI.
Prontos para uma metodologia ágil? ***
Artigo de Eduardo Kruger
|
Antes de falarmos de testes propriamente ditos, vamos fortalecer os
alicerces do nosso conhecimento com algumas palavras muito usadas quando
abordamos esse assunto:
- Defeito, falha e erro;
- Verificação e validação (V & V).
Vamos às definições, segundo o documento ISO/IEC/IEEE 24765:2010:
- Defeito: uma imperfeição ou deficiência em um componente do
projeto, quando ele não cumpre os seus requisitos ou as especificações e
precisa ser reparado ou substituído.
- Erro: uma ação humana que produz um resultado incorreto, como o software que contém uma falha.
- Falha: um passo, um processo ou definição de dados incorreta em um programa de computador.
Ok, primeiras definições dadas, termos bonitos, mas para o cliente
existe pouca ou nenhuma diferença entre essas três palavras, pois
qualquer uma delas se encaixa perfeitamente na seguinte frase que pode
ser dita por ele com uma certa dose de fúria ou com aquele sorrisinho no
canto dos lábios: “Encontrei um(a) ... no software”. Para o cliente não
importa a definição, o fato é que o software não está funcionando e ele
quer uma resposta. Rápida, de preferência. Vamos prosseguir.
Verificação e validação são conceitos que devem estar no sangue de
quem se propõe a participar do processo de desenvolvimento de um
software. E, para facilitar o entendimento, vamos lançar mão das
expressões criadas por Boehm em 1979:
- Validação: estamos construindo o produto correto?
- Verificação: estamos construindo o produto corretamente?
Verificação envolve determinar se o software está de acordo com suas
especificações, ou seja, se atende aos requisitos especificados.
Validação tem por finalidade assegurar que o software atenda às
expectativas do cliente.
E por falar em expectativas dos clientes, uma pausa para reflexão:
por qual motivo muitos deles ainda têm expectativas em um nível tão
baixo, ao ponto de um erro no software não causar nenhuma surpresa ou
indignação? Por que alguns clientes ainda aceitam as falhas de um
software alegando que os benefícios são maiores que as desvantagens?
Podemos discutir isso mais profundamente em um próximo artigo. Topa?
O cenário apresentado no parágrafo anterior apesar de, infelizmente,
ainda ser comum em algumas instituições, é cada vez menos aceitável
quando o desenvolvimento é encarado de maneira séria, com
comprometimento e envolvimento de todos, e a meta é a entrega de
software confiável e de valor ao cliente. O famigerado termo bug é
comumente associado ao fracasso do profissional ou da empresa que
desenvolveu o software. Sendo assim, é válido e eu ouso dizer,
obrigatório, investir esforço na verificação e na validação do produto
que está sendo desenvolvido.
Dentro desse processo de verificação e validação, temos os testes,
que são um dos pilares do processo de desenvolvimento de software. Os
testes de um software envolvem executar uma implementação do mesmo com
dados de simulação.
O teste é uma técnica dinâmica de verificação e validação. Testando,
podemos mostrar ao desenvolvedor e ao cliente que o software atende aos
requisitos e descobrir falhas, comportamentos incorretos ou não
conformidades com o que o produto se propõe a oferecer. Mas fique
atento: teste planejado e executado de maneira incorreta pode ser tão
ineficiente quanto não realizar testes.
Como existem vários tipos, elabore o seu plano com aqueles que melhor
se adequem à sua realidade, ao seu ambiente, à sua equipe e ao produto
que está sendo desenvolvido. Inclua ou remova tipos de teste sem medo.
Automatize. Monte a infraestrutura necessária. Busque sempre a melhoria
do seu plano de testes. Não acredite que achou ou tenha a pretensão de
um dia ter, a bala de prata dos testes.
A cultura de teste deve estar viva, entranhada dentro da equipe de
desenvolvimento e ser algo natural, tal como a pausa para o café.
Testar sempre será uma preocupação da equipe de desenvolvimento? Em
que momento podemos parar de nos preocupar com os testes? Acredito que
só quando decidirmos largar esse negócio de desenvolver software de
qualidade e irmos para a praia pescar com os amigos. Ótima ideia. Mas,
calma aí, será que não vamos precisar testar a isca e o anzol?
Bons testes. ***
Artigo de Max dos Santos
|
Tem havido muita discussão sobre como as práticas de desenvolvimento
Agile estão prejudicando mais do que ajudando. As pessoas se queixam de
coisas como testes unitários, TDD, CI, programação em par, e falam que
revisões de código limitam a criatividade do desenvolvedor e criam um
trabalho desnecessário.
Isso é naturalmente irônico, já que os processos Agile surgiram
precisamente porque as pessoas sentiram que os processos não-Agile que
os precederam estavam prejudicando mais do que ajudando. Então, o que
está acontecendo aqui?
Por que os processos existem?
Os processos existem para garantir os resultados. Se você não se
preocupava com a rapidez com que podia fazer algo, ou com quão bem ele
funcionará, você não precisa de processos. Mas você se importa. Então
descobre maneiras para garantir que possa entregar a tempo, com
qualidade, e com qualquer outra característica com que se importe.
Processos também existem para obter resultados previsivelmente bons
de grupos de trabalhadores qualificados de formas diferentes. Se eu
tiver um exército de pessoas que fazem widgets, quero alguma garantia de
que vão continuar a fazer widgets bons, não importa quem esteja
envolvido (desde que tenham algum nível base de habilidades).
Mas e o desenvolvimento de software?
Isso não deveria surpreender ninguém, mas o desenvolvimento de
software também precisa de processos. Por que não precisaria? Afinal,
você se preocupa com fornecimento de bons softwares e deseja resultados
bons das pessoas que o constroem.
E o que faz um bom software? Além do óbvio (que funciona bem e faz o
que você quer que ele faça), um bom software é fácil de conviver. É
fácil de corrigi-lo se for necessário, é fácil mudá-lo se quiser.
Por que os processos tendem a ser ruins?
É quase inevitável que os processos limitarão os impulsos individuais
(ou seja, criatividade). Levados ao extremo, eles sufocarão a paixão,
transformarão todos em ociosos estúpidos, e geralmente tirarão a
diversão do trabalho. Ninguém quer isso. Mas ainda precisamos fazer as
coisas.
O truque é não levar as coisas longe demais. Parte disso está no
reconhecimento de que quanto mais capazes são os desenvolvedores, de
menos processos você precisa para orientá-los. E vice-versa.
Imagine por um segundo que a sua equipe de desenvolvimento seja
composta por ninjas que podem fazer rapidamente um código como se não
estivesse estlizado. Eles podem construir o que você quiser, com rapidez
e eficiência, sem bugs, e levar aos clientes finais com o mínimo de
perturbação quantas vezes você quiser. Será que você ainda precisaria de
processos elaborados para ajudar a guiá-los? Provavelmente não.
Mas aqui está a realidade: a maioria das empresas não tem equipes de
ninjas escrevendo código. Isso vai soar duro, mas a maioria dos
desenvolvedores não é ótima. Na verdade, a maioria nem sequer é
especialmente boa. E pensam que são melhores do que realmente são
(incluindo eu mesmo).
E isso fica ainda pior. A maioria das equipes também tem que lidar
com bases de código hostis, o que torna muito mais difícil fazer um bom
trabalho. Mesmo desenvolvedores bons podem se complicar com isso.
No entanto, apesar dessa realidade, você ainda precisa fazer as
coisas. Então, você encontra maneiras de obter desenvolvedores
(excelentes e não tão excelentes) para fazer um bom trabalho. É disso
que trata a maioria das práticas de Agile.
Você faz uma unidade de teste ou TDD ou par, porque ajuda a reduzir
erros e a escrever um código mais sustentável. Você configura a CI, pois
ela ajuda você a encontrar bugs rapidamente e lhe ensina como fazer o
deploy do seu aplicativo de forma eficiente. E assim sucessivamente.
Pensamento final
Se você acha que as práticas de engenharia Agile são dolorosas ou
desnecessárias, você pode muito bem estar certo. Mas, seja como for,
essas práticas são as melhores ferramentas que temos hoje para conseguir
que os desenvolvedores façam um bom trabalho. Então, se você realmente
quer uma mudança, há dois caminhos a percorrer: ou obter desenvolvedores
muito melhores ou inventar melhores práticas.
⁂
Texto original de Alex Tatiyants, disponível em http://tatiyants.com/are-agile-dev-practices-needed/
|
Como em outros artigos, vou falar de
música e lembranças de tempos passados. Em minha adolescência e início
da juventude, eu tocava alguns instrumentos e fazia a regulagem do som
(volume e tonalidade) nas reuniões da igreja.
Para podermos ir direto ao assunto, apenas resumo que, em quase
todas as ocasiões em que estava fazendo a parte técnica, a que me
competia regular o som, era necessário principalmente para os microfones
fazer algum ajuste nos graves, médios e agudos para que o som ficasse
bom, audível ao máximo e, principalmente, sem excessos/ imperfeições na
voz em determinadas faixas de frequência que fizessem com que os alto
falantes da igreja saturassem, atingissem o seu limite e assim gerassem
uma distorção do som.
Mas havia uma pessoa em especial, que era diferente das outras: a
voz dela simplesmente não precisava de retoques. Era só entregar o
microfone na mão dela e aumentar o volume do canal ao qual o microfone
estava conectado que já estava tudo pronto. Por mais que você tentasse
realizar ajustes na tonalidade percebia que, na verdade, ao mexer nos
controles acabaria por danificar a qualidade do som da voz dela. Ou
seja: a voz dela era excelente já ao natural, ela era boa cantora de
nascimento.
Claro, no grupo também existiam pessoas que não tinham um talento
natural e não executavam seu ‘trabalho’ de forma tão natural; mas ainda
sim eram importantes na composição do conjunto do grupo.
Às vezes saiam algumas farpas entre um componnente e outro, mas a
pessoa que citei primeiramente nunca estava envolvida. Falsidade do
grupo? Não… Primeiro porque ela era uma boa pessoa e humilde por
natureza; segundo porque todos tínhamos ciência da importância daquele
membro para o grupo exercer o seu melhor e, por isso, nunca dávamos
chance para que ficasse um disse-me-disse, um desentendimento com ela.
Deixávamos sempre tudo às claras e jamais exigíamos que a mesma fizesse
algo de um jeito da qual era realmente contra. Ninguém queria
perdê-la.
Mas qual é a lição dessa história?
Três coisas:
- Que há pessoas que já são boas no que fazem por natureza;
- Gerentes, superiores ou técnicos ligados à esta pessoa precisam aprender a lidar com isto;
- Mesmo que a pessoa não seja simplesmente ‘O CARA’ da área em que
atua, a empresa e seus vários gestores devem entender que NÃO É
NECESSÁRIO impor sempre e em tudo um estilo de fazer as coisas.
Se um subordinado do gerente X fez um determinado procedimento,
executou determinada ação ou simplesmente escreveu umas linhas de código
de forma diferente do que este gerente faria, não é por causa disto
que o trabalho necessita ser refeito. Claro, desde que o resultado
final fosse o mesmo.
Aliás, convenhamos, se um gerente quer que as coisas sejam feitas
exatamente do jeito que ele faria, sem nada diferente, trago para ele
uma má notícia: será necessário que você mesmo execute o trabalho.
Precisamos entender que funcionários trazem velocidades de execução,
experiências, estudos, treinamentos, práticas e, principalmente (na
minha opinião), personalidades diferentes. E dificilmente algumas destas
características baterá com as suas.
Há limites para esta compreensão, sem dúvida: o funcionário precisa
seguir determinadas regras da empresa. É necessário que ele entenda que
ela exige uma burocracia boa para que as coisas fluam como deveriam.
Mesmo porque uma empresa em que todos fizessem o que bem
entendessem, e da forma como quisessem, não seria uma empresa: seria na
verdade uma associação anárquica de pessoas que buscam (em vão?)
cumprir uma tarefa para alguém (fosse este alguém uma pessoa de seu
próprio grupo ou o cliente).
Apenas devemos ter a consciência de que se impormos coisas demais
aos nossos funcionários, eles podem se sentir podados, pressionados a
fazer da forma que não gostariam, não valorizados em sua criatividade e
individualidade e, com o tempo, eles podem se cansar das imposições e
deixar de fazer parte do seu time. E neste caso quem sairia perdendo
mais? É óbvio em que há situações em que meu pensamento não vale, mas,
francamente, acho que seria a empresa. Baseando-se em custos de
realocação e contratação de funcionários, considerando, inclusive,
curvas de aprendizagem de alguma tecnologia ou conceitos de negócio. ***
Artigo de Leonardo Franco
|
25
0
