Scrum para um único programador? [fechadas]

Sou chamado de "Windows Expert" em minha empresa muito pequena, que consiste em mim, um engenheiro mecânico trabalhando em uma função de vendas e treinamento, e o presidente da empresa trabalhando em uma função de design, desenvolvimento e suporte.

Minha função é igualmente geral, mas principalmente eu projeto e implemento qualquer programação que nosso produto precise ser executada para que nosso material seja executado nas versões atuais do Windows.

Acabei de assistir a uma visão geral de alto nível do paradigma Scrum, apresentada em um webcast. Minha pergunta é: vale a pena aprender mais sobre essa abordagem do desenvolvimento de produtos, uma vez que meus itens de trabalho de desenvolvimento geralmente são fornecidos em um nível muito alto, como "internacionalizar e localizar o produto".

Se for, como você sugere a adaptação do Scrum para o uso de apenas um programador? Quais ferramentas, baseadas na nuvem ou não, seriam úteis para esse fim?

Caso contrário, que abordagem você sugeriria para um único programador organizar seus esforços no dia a dia? (Talvez a pergunta se reduz a essa pergunta simples.)

Aprenda Scrum: sim. Se apenas para aprender sobre isso para adicionar ao seu conjunto de habilidades gerais. (mas provavelmente é o que você está procurando "Scrum-ban")

O Scrum é uma estrutura legal, mas um princípio básico é "Iterações (Sprints) terão duração fixa". Nunca vi esse trabalho em equipes muito pequenas que são mais orientadas a interrupções do que não. Se você realmente pode se inscrever e se comprometer a trabalhar em um período de tempo fixo (1 semana?), O Scrum é uma estrutura interessante. Se você não pode ... então é bom aprender sobre o Scrum, porque ele tem alguns bons conceitos que se traduzem bem em outras coisas ... como ....

Backlog - Scrum ou não, mantenha uma lista priorizada de coisas que você precisa fazer. Gosto do Excel (ou da planilha do Google Doc ...) Você pode gostar de outra coisa. Eu manteria uma ferramenta muito pequena se você for uma equipe muito pequena. (Planilha >> Processador de texto, porque você pode classificar facilmente.)

Separação de planejamento e comprometimento - Planeje em uma notação abstrata (pontos) e seja consistente (8 pontos é cerca de 2x uma história de 4 pontos e 4x uma história de 2 pontos) Quando o tempo para "fazer o trabalho", revise o problema e faça um esboço. em horas. Não mude os pontos.

Compromisso - seja visível para os outros quando você se comprometer e cumpra seus compromissos

Retrospectiva - após a entrega, reflita sobre o que poderia ter sido feito melhor.

etc etc.

O Scrum é fácil o suficiente para entender que pode ser um bom ponto de partida. Se você gosta, eu consideraria usar a variante "Scrum-ban" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Nada mais me parece "tão bem documentado" com uma comunidade razoavelmente ativa para apoiá-lo.

Eu adoraria também recomendar as metodologias de cristal de Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer e http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Pequeno / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), mas envolve muito mais leitura e escavação.

Coisas como o XP fornecem mais detalhes sobre práticas específicas, então eu também diria que leia o livro: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= livros & ie = UTF8 & qid = 1304359834 & sr = 1-1

Conselho para leitura final: Desde que você concorde com o manifesto Agile e siga os princípios: http://agilemanifesto.org/principles.html, você deve estar em boa forma.

Recomendação pessoal: adote TDD (não negociável, IMHO) Mantenha uma lista de pendências (conforme Scrum) Sempre mantenha o tamanho e a ordem de prioridade Decomponha as coisas "grandes demais para fazer entre interrupções" em pequenos pedaços. dois itens têm a mesma prioridade.) Torne seu ambiente de construção capaz de criar / testar / implantar (para ambiente de laboratório) em 5 a 10 minutos. Mostre aos seus clientes (internos e externos) os resultados de terminar uma história. seu cliente concorda. Puxe Histórias do topo da pilha e trabalhe nelas enquanto você completa a história atual. Não mantenha mais de duas coisas abertas ao mesmo tempo. Termine uma distração antes de iniciar outra.

espero que isto ajude

Você pode usar algumas práticas usadas no Scrum, como backlog de produtos, priorização, estimativa relativa, entrega incremental, mas usar o Scrum inteiro como um processo para gerenciar o desenvolvimento de produtos por uma equipe de membros multifuncionais auto-organizados provavelmente não é o caminho a percorrer. .

A questão é se você é capaz de quebrar seus itens de trabalho em pedaços pequenos que podem ser entregues de forma incremental? Se não usar a maioria das práticas, não faz sentido. Também Scrum é sobre alta cooperação com o proprietário / cliente do produto. Não deve ser assim: "Aqui você tem uma tarefa e volta assim que terminar".

Embora eu não diga nada a favor ou contra o Srum 1-homem, direi que um sistema Kanban de tração 1-homem funciona muito bem. O Kanban, combinado com o Teste de unidade automatizado, me tornou muito mais produtivo e "documentado". Embora nem sejam realmente metodologias, mas mais ferramentas (e muito diferentes), ambas me forçam a dividir grandes projetos solo em pedaços pequenos, além de me dar uma espécie de ritual para me encorajar a fazer mais coisas a cada dia. Não há nada tão satisfatório quanto clicar em "executar todos os testes" e ver cada item ficar verde ... nada, exceto levar um cartão da coluna "Em andamento" do meu quadro Kanban para "Em teste" (ou totalmente fora do quadro) .

Eu acho que o problema real com o trabalho solo é que você pode escolher entre várias metodologias, realmente destinadas a grupos de desenvolvedores, e adaptá-lo para melhor se adequar a você. O objetivo final é realmente apenas para mantê-lo responsável, produtivo e feliz. Quem sabe como fazer isso melhor do que você (com um pouco de força daqui e um pouco de lá).

Eu tentei isso quando estava trabalhando sozinho em um ponto. As coisas que funcionaram bem foram:

1. Tendo todos os itens de trabalho em um quadro branco. Eu pude ver rapidamente o excelente trabalho que havia; onde estavam dependências e bloqueios. Além disso, muitas pessoas paravam no meu quadro e liam - e nós conversávamos sobre isso. Eu acho que isso os ajudou a entender o que "o nerd" estava fazendo o dia todo ;-)
2. O gráfico de queima também foi ótimo. Eu apenas usei o Excel para isso. Isso me permitiu melhorar as estimativas nesse ambiente. Isso me deu uma ótima visão geral de onde eu estava indo com a iteração. Minha gerente, que não era uma pessoa técnica, também adorou, pois podia ver todas as coisas diferentes envolvidas em um recurso e onde elas estavam.
3. Levantamentos diários. O melhor que pude. Todas as manhãs, atualizava todos os itens de trabalho e o gráfico de detalhamento e anotei todos os impedimentos que precisavam ser resolvidos.
4. Os testes automatizados e a integração contínua (MSTest / TFS), preferencialmente TDD, ajudarão qualquer equipe de desenvolvimento, usando qualquer metodologia - mas vale a pena mencionar aqui.
5. Iterações curtas (1 semana) realmente me ajudaram a me concentrar em fornecer algo.
6. Manter um backlog foi ótimo, pois, quando recebi um novo trabalho, pude colocá-lo no contexto de todos os outros trabalhos e convencer o proprietário do produto a priorizar novamente.

O que não funcionou foi:

1. Trabalhando sozinho, você nunca consegue esse impulso ao colaborar com pessoas que pensam da mesma forma; ou aquele senso de competição e foco que vem de uma equipe com moral e cultura realmente boas. Não há outros cérebros para escolher quando você fica preso, então bloqueios como esse não podem ser eliminados por um mestre de scrum no stand up diário.
2. Não há scrum master - então não há ninguém para interromper as interrupções. Eu tive muitos problemas com as pessoas constantemente fazendo perguntas sobre outras coisas e interrompendo meu fluxo. Sob um bom scrum master, coisas assim são interceptadas e você pode continuar. Eu nunca quis ser rude com as pessoas (talvez eu seja suave), por isso foi um problema. Além disso, sem um scrum master, você pode desviar-se do processo facilmente.

Foi um exercício interessante, mas parei de fazê-lo depois de um tempo. Eu acho que os benefícios do Scrum devem ser vistos em contraste com as equipes tradicionais em cascata. Mas ambos são meio discutíveis quando você está por conta própria. Não há problemas de comunicação ou colaboração - você apenas realiza o trabalho definido e pronto.

Eu acho que todo mundo deveria manter um backlog e fazer TDD.

Elementos do Agile / Scrum / Kanban que acho que fazem sentido em um único mundo de desenvolvedores:

1. Tenha um quadro no qual você organize suas histórias de usuário / itens de lista de pendências ativas, em cartões de índice, como o kanban.

2. Obtenha adesão de não desenvolvedores pelo valor desses princípios:

   • Dê-me tempo para trabalhar sem alterar minhas prioridades em mim ou microgerenciar (o ponto dos sprints). Dê-me tempo e tentarei descobrir de antemão exatamente o quanto posso fazer, e farei o meu melhor para fazer isso.

   • Se eu precisar de algo (eu sou bloqueado) e eu for até você, e você não puder resolvê-lo, o sprint pode ter que ser cancelado de forma anormal. (Isso significa apenas que precisamos de um novo plano.)

   • Ninguém muda nada no meio do sprint. Ou, se o fizermos, simplesmente cancelamos o sprint e criamos um novo. se isso acontecer muito, a produtividade cai.

   • a comunicação entre pessoas que são partes interessadas pode acontecer em reuniões diárias regulares, que comunicam quase todas as mesmas coisas que um scrum regular, incluindo as realizações do desenvolvedor para o dia. Essencialmente, você pode relatar coisas que demoraram mais do que você pensava ou foram bem e quaisquer ajustes que você está fazendo nos seus planos de implementação. (Encontrei quatro novos bugs e os registrei, acho que eles são mais importantes que esse recurso opcional, e acho que vou gastar o tempo, corrigi-los e usar esse recurso opcional.)

Trabalhei muito como desenvolvedor único e posso afirmar com certeza que a confiança entre o desenvolvedor único e seus supervisores / chefes não desenvolvedores e a boa comunicação são as chaves, não uma metodologia. Mas você sempre pode ser mais eficaz se seguir bons princípios.

Eu li um blog sobre isso e acho que pode ajudá-lo com sua pergunta.

Primeira parte: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Segunda parte: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Você pode encontrar mais algumas informações neste blog.

Eu não estou de forma alguma conectado; apenas algo que eu tinha nos meus favoritos. Espero que possa ajudá-lo.

Sim. E tenha em mente que o Scrum não precisa envolver ferramentas sofisticadas, pode ser apenas uma reunião simples de 15 minutos em que todos falam sobre o que estão trabalhando. A vantagem do Scrum é que todo mundo sabe o que está acontecendo, e isso facilita a solução de problemas antes que eles surjam e a antecipação de problemas no futuro.

Muitas dessas respostas estão faltando um ponto importante.

Uma equipe de scrum não precisa consistir apenas de programadores.

Um de seus colegas faz 'design' / 'desenvolvimento' e um faz 'vendas'.

Talvez o seu colega de 'vendas' possa ser o proprietário do produto (proxy). Quais são as expectativas do cliente?

O design e o desenvolvimento de seu outro colega realmente me parecem disciplinas da equipe scrum. O desenvolvimento do Scrum não é faseado, mas vertical (requisitos de aprovação, projeto e implementação em um sprint).

Você poderia fazer o processo de scrum com vocês três.

O que é preciso para fazer 'isso'? As reuniões de planejamento de sprint do Scrum abordam a questão do que é isso. O que o proprietário do produto espera ver para ser considerado concluído?

Durante uma reunião de planejamento do sprint, você pode dar a seus colegas o contexto sobre por que 'internacionalizar e localizar o produto' pode ser tecnicamente difícil de implementar.

Toneladas de razões para usar o scrum imho.

Sugiro tentar o Kanban e começar com o básico: visualização e limitação do trabalho em andamento (WIP).

Mesmo que você o interrompa mais tarde, ficará mais ágil no processo. E enquanto o Kanban é bom para o desenvolvimento de software "normal", o Kanban + um processo baseado em fluxo (em oposição às iterações) supera outras ferramentas de processo quando você tem uma situação com o desenvolvimento de novos recursos e manutenção.

Segundo a recomendação do livro Kanban de David Anderson, e você também pode dar uma olhada nos meus slides em um encontro local no por que e como começar com o Kanban simples ou crisp.se/kanban para uma breve introdução.

Para o seu contexto, tenho alguns pensamentos:

• a visibilidade é fundamental. Use um quadro físico físico em vez de uma ferramenta digital, se você não puder exibi-lo permanentemente em uma tela (grande) (se estiver co-localizado)
• comece com seu processo atual
• comece apenas com sua esfera de influência, incluindo as fases de transferência upstream e downstrean (tornando-se uma fila para você, por exemplo, recursos projetados prontos para o desenvolvimento ou uma fila sua, por exemplo, recursos concluídos, prontos para vendas)
• se seus colegas estiverem interessados ​​em expandir a visualização a montante ou a jusante, tanto melhor. Talvez você acabe visualizando todo o fluxo de valor (ou rede) da sua empresa, ou seja, como o valor flui do conceito ao dinheiro
• minimizar multitarefa (!) limitando o WIP. Se o fluxo de trabalho for visível para seus colegas, eles devem entender o porquê e ver facilmente o que está no seu prato
• talvez seja útil separar o trabalho em 3 ou 4 tipos de trabalho (classes de serviço), que têm demandas diferentes: f.ex. bugs, questões críticas, trabalho com prazos rígidos, trabalho sem prazos
• observe como o seu trabalho flui, por exemplo, se você tiver gargalos em algum lugar, ou se o trabalho estiver bloqueado ou se você estiver "sedento" por trabalhar em padrões um tanto previsíveis. Isso é mais fácil a longo prazo, se você usar uma ferramenta digital, consulte alguns dos meus últimos slides.
• melhorar o fluxo do trabalho passo a passo

Se você quiser tentar algo agora, hoje, enquanto toma sua decisão, recomendo experimentar um Kanban pessoal na parede ou janela ou armário ao seu lado, como fiz na semana passada ...

Depois de ler todas as outras respostas aqui, acho que a resposta pragmática simples é:

Use processos, técnicas ou métodos que estão em uso para APRENDER algo que o ajudará a fazer melhor seu trabalho.

Agora, isso pode significar priorizar suas tarefas - todos os dias - religiosamente.

Isso pode significar resolver a lista de pendências.

Pode significar relatar o progresso - para o seu chefe (mesmo que ele não se importe ... é bom permitir que você faça um balanço mental de onde você está).

Você pode usar todos os tipos de métodos ou técnicas porque, em última análise, permitem trabalhar melhor, o que = dormir melhor à noite.

Faça coisas que funcionem (para você, nas suas circunstâncias atuais), descarte coisas que não funcionem.

A menos que você tenha o seguinte no lugar

• Meios para organizar e priorizar os requisitos recebidos.

• Estimar com precisão o esforço que será realizado para que você saiba o que pode comprometer em uma iteração

• Iterações e Melhoria Contínua - O conceito de iterações nas quais uma pessoa está continuamente inspecionando e adaptando é inestimável. Essa prática incentiva a experimentação e se baseia no aprendizado contínuo. Scrum na Igreja, página 4

• Bem, você não pode realizar uma reunião diária de scrum, mas pelo menos pode se lembrar da tarefa que irá realizar hoje. A reunião diária do scrum é usada para que as equipes possam se sincronizar umas com as outras sobre o que estão fazendo.

• Reflexão após um sprint - no scrum, chamado Retrospectiva do Sprint, no final de cada iteração, você pode refletir sobre o que aconteceu após a iteração e pensar no que deu errado e como você pode melhorá-la, quais são as melhores práticas para mantê-las fazendo

Sugiro que você adote uma abordagem minimalista e, com a melhoria contínua, pode ter um scrum que se adapte bem às suas necessidades.

Scrum não é scrum se você não pode ajustá-lo às suas necessidades e se adaptar à sua situação atual.