Acho que realmente alguns Devs têm a visão alinhada com o expressado pelo autor no seu artigo, e, por isso, resolvi debater um pouco mais os tópicos por ele elencados. Entendo que algumas pessoas possam realmente encontrar nesses tópicos motivos para “detestarem” o Scrum, mas acredito que uma outra visão sobre tais razões possa transformar esse ódio em amor.
A análise feita por Willem-Jan Ageling, autor do artigo, foca em novas responsabilidades encaradas pelo Dev ao trabalhar usando Scrum. Melhor então darmos uma olhada nessas “novas” responsabilidades, dissecando o problema para entendê-lo melhor.
No Sprint Planning – Determinar uma meta do Sprint, em cooperação com o Product Owner. A equipe de desenvolvimento precisa avaliar se eles podem cumprir a meta do Sprint, pois isso impulsiona o Sprint
Será que existem equipes tradicionais, ou não-ágeis, onde o gerente não pergunta sobre prazos, ou o que será possível ser feito até determinada data de entrega? Sinceramente, nunca vi isso acontecer. Muito pelo contrário. Sempre presenciei esse questionamento ser feito de forma repetitiva, gerando inclusive discussões acaloradas, e roubando o tempo, e muitas vezes a tranquilidade, do time. Essa questão nunca pode ser abandonada, pois não há como uma organização, que estabelece metas e objetivos, trabalha com KPI e OKR, não ter alguma ideia de quando chegará aonde. Na verdade, acho que o Scrum ajuda muito o time nesse sentido, definindo um momento específico para tal discussão, de certa forma limitando-a, e evitando que roube mais tempo do time.
No Sprint Planning – Criar um Sprint Backlog. Isso envolve selecionar os itens do Backlog do produto que ajudam a cumprir a meta do Sprint e criar um plano para entregá-los.
Na realidade, entendo que o Dev Team somente ajuda o PO, ou esclarece suas dúvidas, para que ele selecione as histórias a serem contempladas. É de interesse maior do PO e de sua responsabilidade definir uma meta com o time e definir o que será feito para cumprir tal meta. Já com relação ao plano necessário, acredito que haja dois aspectos. O primeiro é que essa prática de planejar o que irá ser feito no curto prazo é extremamente produtiva. De uma forma geral, ela evita o “hacking”. Ou não conhecemos Devs que ao ouvir a primeira notícia sobre alguma necessidade do cliente já querem sentar e sair programando? Esse pequeno planejamento, ajuda sensivelmente a evitar o efeito toupeira e fomenta a colaboração e a coordenação entre os membros do time, sob pena de ao não fazê-lo gerarem retrabalho e terem muita dificuldade de coordenação. Ou seja, na minha visão, tal responsabilidade sempre existiu. Apenas, algumas pessoas, ou times, esquecem da sua necessidade e acabam pagando um alto preço posteriormente.
Durante a Sprint – Garantir que os Itens do Backlog do Produto atendam à Definição de “Done” (DoD) e aos critérios de aceitação.
O time poderia trabalhar de forma diferente? Isso me parece ser inerente ao trabalho do Dev. Senão deixou o Dev de estar trabalhando para satisfazer a necessidade de algum cliente, para ser um diletante.
Durante a Sprint – Certificar-se de que o Backlog do Sprint sempre mostra o estado atual do progresso do trabalho nos Itens do Backlog do Produto e no plano da Sprint.
Essa responsabilidade não me parece trabalho extra, mas somente uma questão de disciplina, atenção ao framework e utilização de ferramenta adequada. A reunião diária, já prevista no Scrum e que não deve ser abandonada, já tem como parte do seu escopo a apresentação do fiz, farei e problemas. Isso, por si só já permite uma atualização da situação dos trabalhos. Se, adicionalmente, o time usar uma ferramenta para acompanhamento, como o próprio Scrumhalf faz, onde as tarefas trabalhadas sejam atualizadas pelo próprio realizador e gerem automaticamente informações, como o gráfico de Burndown, a transparência e a visibilidade ficam garantidas, sem nenhum esforço extra.
Na Daily Scrum – Avaliação diária do progresso em direção ao objetivo do Sprint. Isso inclui a atualização do plano conforme refletido no Sprint Backlog.
Realmente, a Reunião Diária – Daily Scrum – é algo que toma um tempo do time. Mas, no entanto, esse tempo, que deve ser muito curto, em torno de 15 minutos ou menos, seria muito maior caso o projeto contasse com um gerente formal e os membros do time tivessem que fazer seus relatórios de andamento para ele. Adicionalmente, é fundamental lembrar que a Reunião Diária é o que viabiliza a auto-organização do time, diminuindo os tradicionais atritos com a gerência e aumentando a satisfação no trabalho.
Isso realmente não é algo comum fora do Scrum. Entretanto, além de tal discussão não dever tomar muito tempo, deve-se lembrar que, entre outros motivos, essa discussão promove a transparência e acaba evitando, ou substituindo, as constantes discussões e debates do time com a gerência, quando usando uma gestão não-ágil.
Nunca vi isso ser deixado de lado também. O Dev não pode só codificar e esquecer. A não ser que hajam outros membros para fazer a demonstração das funcionalidades implementadas, anotação de eventuais bugs, etc. A vantagem no Scrum é que isso é feito de forma organizada, mais rápida, e contando com a participação de todo o time permite que todos fiquem atualizados, reduzindo a solução de continuidade no trabalho em tarefas subsequentes.
Apesar de sempre ter promovido esse tipo de discussão nos projetos que participei, especialmente nos que gerenciei, antes da agilidade, reconheço que muitas vezes o time é deixado de lado no momento dessa discussão. No entanto, em função disso, é normal o time perder muito tempo depois, reclamando e discutindo porque algo está sendo feito. Ou seja, o exercício de pensar o que deve, ou deveria, ser feito é efetivamente realizado. A grande diferença aqui é que o dev poderá exteriorizar o seu pensamento e ouvir o dos demais companheiros. E, deve-se lembrar, a responsabilidade, como a maioria delas no Scrum, é coletiva, do time, não individual.
Essa realmente é diferente. Kaizen, ou melhoria contínua, é uma responsabilidade que o Scrum leva muito a sério. Demanda um pequeno tempo do time, mas traz benefícios enormes, inclusive permitindo que ao longo do tempo cada vez mais o Dev foque na sua atividade principal, visto que o “processo” em si está funcionando bem. Cabe ao Scrum Master tornar essa cerimônia produtiva e agradável. Seus resultados, que em um caminho não-ágil também deveriam ser apontados por uma boa gerência, sempre serão implementados da mesma forma, independente do modelo de gestão. Quero dizer com isso, que se algo precisar ser mudado, revisto, terá que sê-lo. E alguém terá que fazer o serviço.
Verdade. Agora o time deve se preocupar com isso. Mas vejamos bem. A definição de pronto, pelo menos na cabeça do Dev, já existe. Senão, como ele iria parar de trabalhar em algo? A diferença aqui é que agora o time, frisando que é o coletivo, deve criar uma definição compartilhada, que seja entendida por todos. E, na verdade, isso que inicialmente pode parecer algo pesado, após negociado evita uma série de conflitos e é de fácil manutenção, podendo, p.ex., ser um subproduto, quando necessário, da Retrospectiva.
Isso só ocorre, ou pelo menos de forma marcante, no momento da transição de um método não-ágil para o Scrum. É, nesse momento da transição, uma mudança cultural importante. Mas depois de algum tempo passa a fluir no sangue dos agilistas e não é nenhum fardo. Afinal de contas, a vida não é mais bonita assim?
Para resumir, montamos a tabela abaixo. Nesta tabela, representamos cada uma das responsabilidades, na mesma ordem do texto, e procuramos indicar a necessidade de sua adoção em um projeto qualquer, independente do modelo de gestão utilizado. Ao lado, procuramos demonstrar o impacto caso seja negligenciada. Em Scrum, procuramos mostrar a principal influência do Scrum no trato da responsabilidade e, finalmente, indicar aoned uma ferramenta pode facilitar sensivelmente o trabalho do time, caso seja aderente ao Scrum. Essa tabela é empírica, sem rigor científico, sendo somente fruto do que observamos ao longo dos projetos que participamos, direta ou indiretamente. O único propósito dessa tabela é compilar os dados, sob a nossa ótica, relativos a uma lista tão extensa, sintetizando-os, de maneira ainda que superficial, para permitir uma visão global por parte do leitor.
Bem, procuramos acima complementar a análise feita pelo colega Willem, visando dar aos Devs, ou a qualquer elemento de um time Scrum, uma outra perspectiva sobre as suas “novas” responsabilidades. O uso de elementos adicionais no time, para cuidar de determinados aspectos, ou a redistribuição de algumas atividades, podem sem dúvida ajudar, aliviando algum trabalho. Evidentemente, descontado o aspecto comunicacional deixado claro por Fred Brooks, em seu livro seminal The Mythical Man-Month, mais gente normalmente ajuda a deixar o fardo mais leve.
Concluindo, acho que o principal ponto é que o Scrum na verdade arruma uma série de coisas que na realidade já são realizadas de outras formas em atividades não-Scrum, e, quando acrescenta algo, é porque realmente é necessário e traz benefícios muito grandes para o time, e em última análise para o próprio Dev. Você consegue pensar fora da caixa e enxergar esses aspectos de forma positiva também?

O surgimento de inúmeras ferramentas tecnológicas, sem dúvidas, tem deixado os gestores imobiliários um pouco confusos. Afinal, escolher qual delas é capaz de melhorar o relacionamento com os clientes e fidelizá-los, pode não ser uma tarefa fácil.
Por outro lado, no entanto, isso configura um cenário extremamente promissor para o setor imobiliário. Isso porque a modernidade viabiliza um novo tipo de relacionamento com os clientes, sim. Ao contar com a tecnologia, por exemplo, será possível manter mais presença e proximidade.
Isso facilita o dia a dia do corretor e de toda a equipe, que terão mais agilidade para lidar com possíveis adversidades. Sendo assim, será muito mais fácil entregar um serviço rápido e de qualidade.
Ao longo deste artigo, vamos explicar mais sobre essas novas ferramentas e quais você precisa prestar mais atenção para elevar a sua imobiliária a um novo padrão de qualidade.
Antes de tudo, é preciso colocar a casa em ordem. Por isso, para modernizar sua imobiliária, tenha em mente questões como:
As redes sociais funcionam como um cartão de visitas. Além disso, quando você não está nelas, menos pessoas são alcançadas.
Portanto, invista em um trabalho sério de estratégia digital, caso queira conquistar mais visibilidade e expandir sua área de atuação.
Quando você aposta em um site visualmente atrativo e com ótima navegabilidade, seus clientes permanecerão mais tempo nele. E lembre-se sempre, ele é uma porta de entrada para alavancar suas vendas.