Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 GustavoGrillo commented Permalink

Acho que essa mudança é um passo exagerado no sentido da imagem que o Scrum prega de que ele faz a vida do desenvolvedor melhor, é um processo mais fácil, suave e cheiroso, e com ele o desenvolvedor de software vai finalmente conseguir ter uma vida social. Esquece-se do objetivo inicial do Scrum, e de que qualquer processo de desenvolvimento que se preze: entregar mais software, com mais qualidade e com menos esforço (i.e., horas-homem empregadas). Tudo bem, é uma perspectiva simplista, mas concordo com o Moacyr no sentido de que independentemente do nome com que chamamos, tem que existir sim um comprometimento da equipe com um determinado conjunto de itens do backlog numa dada sprint. Isso significa que a equipe tem que dar sangue, suor e noites de sono para cumprir isso? Não. Mas significa que na próxima sprint esse comprometimento vai ser mais preciso, e sua precisão vai aumentando a medida que a equipe vai aprendendo. Acima de tudo, o Scrum ajuda (não garante, mas ajuda) a entregar os itens mais importantes antes e melhorar o ROI do projeto. <br /> Talvez algumas funcionalidades não estejam prontas na data desejada por essa fictícia companhia européia, mas se essas funcionalidades fossem importantes mesmo, deveriam ter sido priorizadas pelo Product Owner e entregues em sprints anteriores, certo?

2 JuanBernabo commented Permalink

Moacyr, <div>&nbsp;</div> Achei bacana tua preocupação, entendo que você não quer entrar em questões "metafisicas", porem são elas as que permitem que equipes entrem em hiperprodutividade. <div>&nbsp;</div> Seria como se a gente falasse sobre o porque dos pássaros voam antes de entender o conceito de aerodinamica, algumas explicações pareceriam no minimo esquisitas, mais esses detalhes pequenininhos fazem toda a diferença entre um avião que voa e um que não. <div>&nbsp;</div> Em Agile/Scrum/Lean a ideia não é um jogo de perde/ganha, quem fica com a feia, e parece que nas empresas essa é uma premissa que não pode ser mudada, que é justamente a parte difícil de fazer as intervenções sistêmicas nas organizações para conseguir mudar o conjunto de "premissas" e assim impactar na cultura da organização para conseguir entrar nesse estado quase de ultra condução. <div>&nbsp;</div> Não me contive é precisei escrever um post no meu blog para falar um pouquinho melhor do que eu penso ao respeito, já que eu acredito que "Mais commitment = menos produtividade". <div>&nbsp;</div> http://www.teamware.com.br/blog/mais-comprometimento-menos-produtividade/ <div>&nbsp;</div> Da uma olhada para ver o que vc acha. <div>&nbsp;</div> Abraços, <br /> Juan.

3 MoacyrMello commented Permalink

Aí Juan e Gustavo, como vão? <br /> É uma boa surpresa encontrar os amigos por aqui. Voces sabem que eu gosto muito do Scrum, é como o filho mais novo que está se saindo bem na faculdade, enquanto o mais velho, o RUP, já dobrou o cabo da boa esperança (grrrr que comparação! Só pode ser a hora....). <div>&nbsp;</div> Mas falando sério, eu acho mesmo que a nova interpretação é desnecessária. O mesmo se dá com aquele ponto de trocar priorização por ordenação. Agora o backlog deve ser ordenado e não priorizado, conforme a última atualização do Scrum Guide. Aí também eu senti o gélido bafejar do pântano metafísico de discussões insondáveis. Mais valeria se os luminares do Scrum acrescentassem um kanbanzinho no processo, melhor ainda se propusessem um Kanban automatizado, prá guardar histórico, como em nossa ferramenta RTC (Rational Team Concert http://www.ibm.com/developerworks/rational/products/rtc/)... Aí sim sentiria firmeza na evolução. Abraços. <br /> Ooops, vou olhar seu artigo sim, só que amanhã, hoje meta além da física... só no travesseiro. <br />

4 MoacyrMello commented Permalink

O ponto que o Juan levantou é muito interessante, e eu posso dizer que concordo 120% com ele. Vamos ver qual é esse o ponto a que estou me referindo. <div>&nbsp;</div> Para os que não leram o post (excelente por sinal), ele afirma que há uma potencialidade inexplorada, latente, na equipe de desenvolvimento, que pode elevar a produtividade a níveis muuuito mais altos. No entanto essa produtividade não aparece na medida em que usamos métodos tradicionais na gestão da equipe. Como já disse, acredito 120% nisso, simplesmente porque acredito que seres humanos não tem um limite de produtividade se acrescentarmos a imaginação à equação. Além disso, se analisarmos o que se entende por gestão tradicional em projetos, compromisso pode mesmo ser usado no sentido restrito de responsabilizar e punir. Nessa situação é mesmo um milagre que produtos de software continuem saindo de equipes assim gerenciadas. <div>&nbsp;</div> Eu sei que resumi brutalmente a coisa, mas para o que me interessa é o bastante. Na verdade eu acho que a metáfora de porcos e galinhas é muito limitada. Aliás como toda metáfora ela precisa de um contexto para nos dizer algo. E o contexto para a discussão de compromisso não é produtividade mas a criação de um propósito. E propósito é o que dá significação para as coisas. Os fans de Jornada nas Estrelas (ainda passa?) vão se lembrar de uma estória em que um satélite, lançado da Terra, cai num planeta habitado apenas por máquinas. Só há máquinas nesse planeta, e não sabemos mais que isso, além de que o planeta fica muuuito distante e o satélite chegou lá após passar por um buraco negro (é... na estória é fácil). <div>&nbsp;</div> O ponto é que esse tal satélite, V’Ger, que vamos descobrir era o Voyager, tinha a missão de enviar dados para a Terra, mas nenhuma das máquinas do planeta tinha qualquer outra missão, eram apenas máquinas vivendo, ou maquinando... Aí acontece uma coisa muito interessante, todas as máquinas se unem para ajudar V’Ger a realizar a missão dele, seu propósito. Agora elas também tinham um propósito! A Terra não responde aos sinais, então as máquinas constroem uma enorme espaçonave e atravessam a galáxia determinadas a entregar pessoalmente os dados e informações coletadas por V’Ger! Objetivos e propósitos tem essa força, são capazes de dar significação ao que fazemos, e isso é muito importante, para homens ou máquinas. <div>&nbsp;</div> Então, pulando alguns anos-luz para nosso contexto, quando o Scrum nos recomenda discutir a meta da sprint, independentemente de qualquer estimativa e/ou pressão, e afirmarmos um compromisso com a meta, a minha interpretação é que buscamos uma ligação, intelectual e emocional, ao curso de ação estabelecido na discussão do time. E esse compromisso será tão mais verdadeiro quanto melhor, mais honesta e sincera forem as discussões preparatórias. Quando combinamos uma meta e afirmamos nosso compromisso, estamos afirmando um objetivo comum e declarando nossa vontade de cumprí-lo. Isto, necessariamente, não tem nada a ver com esforço desmedido, noites sem dormir, culpa e punição. Tudo depende do ambiente cultural da organização e da gestão de projetos. Como sabemos, Scrum não é para qualquer tipo de organização. <div>&nbsp;</div> Por outro lado seria injusto afirmar que só a equipe de desenvolvimento tem o dilema de firmar compromissos. Quer dizer que a equipe de marketing também não precisa se comprometer com a campanha combinada com a mídia pra o lançamento da release? E a Produção? Não se compromete a colocar no ar a parte servidora, a tempo de funcionar o roll-out? Ou então os executivos, não se comprometem com datas de lançamento de produto? A questão é tão complexa quanto queiramos. Na interpretação tradicional do contexto da piada, porcos são os que realizam trabalho, facilmente identificados como os papéis de Scrum Master, Product Owner e Developer. Os demais são galinhas porque de alguma forma sua participação é crucialmente diferente. Mas qual forma? Poderíamos criar facilmente um contexto onde os usuários fossem crucialmente dependentes do trabalho a ser entregue. Usuários não realizam trabalho na especificação de um sistema? A questão não deveria portanto se fixar a papéis, num único contexto interpretativo, apesar de que eu sei que muita gente interpreta como se fosse assim, afinal é mais simples. <div>&nbsp;</div> A deselegante metáfora de porcos e galinhas ganha sentido quando analisamos o contexto de um propósito comum em que as partes deveriam ser mais ou menos iguais nos seus objetivos, ganhos e perdas. Se, ao invés de expandirmos o contexto, restringimos a aplicação somente aos papéis de desenvolvedores, Scrum Master e Product Owner, cometemos a injustiça de não reconhecer que há muitas outras situações em que o dilema comprometer-se/envolver-se pode aparecer. Por fim, vamos lembrar que contextos são variáveis também no tempo, a exemplo da famosa máxima de gestão futebolística: “Eu ganhei, nós empatamos, eles perderam”, não é de hoje que o ser humano varia o grau de seu comprometimento com as coisas. <br /> Abraços, Moa