Eu trabalho em uma empresa que reduziu repetidamente os tamanhos de sua equipe de desenvolvimento, a ponto de as equipes de 10 homens anteriores agora terem um desenvolvedor por produto (e alguns testadores compartilhados entre 5 produtos). Costumávamos ser bastante pesados, tendo sido um spin-off de uma empresa maior e herdado seu processo em cascata de vários estágios.

Descobriu-se da equipe executiva que não estamos lançando software com rapidez suficiente e que isso provavelmente é culpa do processo (que pode ser um colaborador, embora a perda de 90% da mão de obra provavelmente não tenha ajudado). Houve um esforço para mudarmos para um processo Agile para evitar perder tempo escrevendo documentos de design etc.

Acho que estou curioso para saber se uma mudança para o Agile ajudará em equipes individuais. Entendi que muitos dos benefícios vêm de maior visibilidade e mais comunicação entre os membros da equipe, mas eu sei o que estou fazendo e meu gerente também. Eu já faço TDD, já que não temos ninguém para testar o produto.

Versão TL; DR: Acho que o que realmente estou perguntando é: você pode implementar o Agile com 'equipes' individuais e vê algum benefício com ele, ou geralmente é algo que é mais eficaz para equipes maiores?

Confira https://groups.google.com/forum/#!forum/solo-scrum

e /programming/829497/agile-methods-specifically-taylored-to-working-solo

Atualização:
o primeiro link é para o Grupo do Google Solo Scrum. O benefício mais óbvio mencionado aqui é o uso de sprints temporizados para gerenciar o escopo e determinar a velocidade do projeto - coisas muito boas.

O segundo link é para uma discussão anterior sobre Stackoverflow, o que pode indicar que esta é uma pergunta duplicada, mas achei que seria mais útil vincular a ela. Por sua vez, possui links para http://c2.com/xp/ExtremeProgrammingForOne.html, que possui muitos links e informações sobre como executar o XP solo (programação sem par).

1

o tamanho mínimo da equipe é um

Agile é uma coleção de princípios e práticas que você escolhe para adaptar o fluxo de trabalho. Se você é um show individual, escolhe o que funciona melhor para você.

XP / TDD funciona lindamente para equipes individuais. E você pula as práticas potencialmente desperdiçadoras de reuniões diárias de pé e programação em pares.

Seu principal problema não é "ficar ágil", mas sim documentação. Este artigo sobre a documentação Agile / Lean de Scott Ambler provavelmente seria uma leitura interessante para você e seus colegas de trabalho.

Agile não se trata de não documentar. Você ainda documenta, é só escolher o que e como documentará para maximizar o valor e minimizar o tempo gasto na sua criação. Você ainda captura os requisitos, executa o design, documenta suas decisões de implementação e tem total rastreabilidade ao longo do ciclo de vida, conforme necessário, mas apenas na medida em que o projeto precisa. Não capturar informações e decisões importantes sobre o projeto é uma maneira de fazer com que um projeto falhe.

Para um bônus divertido, aqui está minha opinião sobre o ágil para indivíduos:

As metodologias ágeis são projetadas para equipes. O Scrum geralmente precisa de 3 a 9 desenvolvedores, juntamente com o Product Owner e o Scrum Master (e o Product Owner e o Scrum Master não devem ser a mesma pessoa). A programação extrema geralmente requer 4-7 pessoas.

O motivo é que várias práticas comumente usadas nas metodologias ágeis convencionais não são reduzidas a um único desenvolvedor. Um excelente exemplo disso é a ênfase na programação em pares e na revisão de código no XP - você realmente não pode fazer isso com um desenvolvedor solo.

Um único desenvolvedor pode ser ágil, mas terá que ser um processo personalizado. Os métodos mais ágeis exigem alguma combinação de integração contínua, teste de unidade, desenvolvimento orientado a teste, refatoração, princípios KISS e YAGNI e assim por diante. Muitos deles se tornaram "melhores práticas", mesmo em metodologias mais orientadas a planos. Não há razão para que um desenvolvedor solo não possa tirar proveito de alguns deles, desde que não interfira na produção e fornecimento de software.

Se você quiser limitar a documentação, eu me concentraria nisso se isso estiver impedindo você. A documentação é apenas um pouco ágil e não parece que alguém da sua empresa saiba como implementá-la. Isso pode atrasar a liberação do código no curto prazo, devido a treinamento, aceitação, ajuste etc. Os poderes disponíveis apenas o descartarão e procurarão a próxima grande panacéia para atrasos na produção após uma demissão de 90%.

Vindo de uma equipe de um homem (embora esperemos que não por muito tempo).

Esforço-me por conseguir o Agile para mim, no sentido de que pretendo que eles sejam mais desenvolvedores do que apenas eu para projetos futuros. Escrevo uma EAP de alto nível, crio histórias de usuários, tarefas sob histórias de usuários, casos de teste e mantenho um bom controle de projetos de uma maneira que meu gerente possa ver e entender. Pode ser um pouco complicado porque eu "apenas sei" na minha cabeça onde estou, mas dedico algum tempo para fazê-lo de qualquer maneira puramente para permanecer diligente com a equipe mítica do futuro que me foi prometida, mas que ainda não ocorreu. Gostaria de pensar que estou desbravando bons processos para as pessoas que virão atrás de mim.

Documentação que eu faço em pequenas quantidades, principalmente diagramas de fluxo e diagramas de casos de uso, mas geralmente nada de baixo nível, a menos que exista algo realmente complicado ou importante sobre isso que eu não queira esquecer. Também faço diagramas de implantação para o benefício de futuras pessoas, quando elas precisam criar um novo ambiente para "treinamento" ou algo semelhante.

Estou aprendendo TDD lentamente, mas ainda não o aperfeiçoei, é extremamente difícil de fazer no sentido puro para aplicativos herdados sem refatorar grandes e arriscadas faixas de funcionalidade. Novas funcionalidades complicadas com as quais ainda luto, mas ainda busco uma cobertura de 100%, que é o jogo final do TDD, afinal. Talvez eu não siga o melhor caminho para chegar lá.

Definitivamente, isso pode ser feito, mas principalmente por necessidade.

Por que o Agile como uma equipe individual quando você pode formar uma única equipe de cinco desenvolvedores com um único backlog de produto para seus cinco produtos? Tente iterações de uma ou duas semanas, concentrando-se em um produto de cada vez e veja como sua produtividade melhora com cinco engenheiros trabalhando juntos como uma equipe coesa e auto-organizada. Dependendo da frequência com que você planeja liberar, pode ser necessário ajustar o comprimento do sprint. Suponho que a empresa talvez não queira esperar 10 semanas entre as atualizações de um produto. Nesse caso, as durações de uma semana podem funcionar melhor. Você poderia trabalhar em dois produtos em um único sprint, mas eu tentaria o meu melhor para evitar isso, para que você possa se concentrar em uma única meta de produto e fazer isso de forma produtiva e com qualidade.

A IMO ter uma única pessoa dedicada a um único produto provavelmente é uma abordagem imprudente quando há cinco desenvolvedores e cinco projetos no total, independentemente da metodologia escolhida.

Muitas práticas ágeis valem a pena para equipes> 0. Controle de origem e desenvolvimento sem atrito, por exemplo, e sempre valem a pena, por menor que seja a equipe.

Isso realmente depende de haver uma adesão do lado dos negócios ou apenas uma coisa nova para a gerência culpar no desenvolvimento (que soa como a situação, com base na redução de 90% no tamanho das equipes). A higher visibility and more communication between team membersnão significa apenas entre os desenvolvedores. É importante para os negócios ver para onde vai o seu tempo e definir as prioridades corretas.

Vimos um enorme aumento de confiança entre os lados de negócios e de TI da nossa empresa, porque agora cada equipe tem um Dono do produto que participa das stand-ups diárias, e eles veem para onde vai o nosso tempo e são os aqueles que tomam decisões sobre o que trabalharemos a seguir. Em vez de os gerentes serem constantemente bombardeados com solicitações e, em seguida, o desenvolvimento ser responsabilizado quando as coisas passam despercebidas ou se não há tempo suficiente no dia para fazer tudo, agora são os Proprietários do produto que são responsáveis ​​por definir as prioridades e fazer com que decisões sobre o que é incluído em um sprint.

Portanto, se houver um comprometimento dos Proprietários do Produto que se envolverão no processo, sim, o processo Agile pode ser muito eficaz, mesmo para uma equipe. Mas se essa é apenas outra maneira de transformar os desenvolvedores em bodes expiatórios, o Agile falhará para todos.