Este artigo é uma continuação de vários artigos publicados aqui anteriormente e dedicados às etapas:
- Declaração de requisitos
- Desenho
- Implementações. Camada de serviço
Ele descreve como organizamos o processo de desenvolvimento, envolvendo desenvolvedores da comunidade Magento desde o início do projeto, em meados do verão passado, e com os quais abordamos o
lançamento de Disponibilidade Geral, feito na semana passada.
Processo de desenvolvimento
Todo o trabalho no projeto foi realizado com programadores da comunidade Magento, que ingressaram no desenvolvimento de forma voluntária,
executaram tarefas do backlog do projeto que eram interessantes para eles e, ao fazê-las, colocaram Pull Requests no GitHub.
Como resultado, houve mais de 80 pessoas que fizeram pelo menos um pool de solicitações e, no total, colocaram mais de 800 pools de solicitações.
O desenvolvimento foi conduzido pessoalmente em eventos de hackathon, que são comumente chamados de "Dia da Contribuição" no mundo Magento, e distribuído quando os caras trabalharam no projeto remotamente em um momento conveniente para abrir demos no projeto para mostrar resultados e fazer perguntas.
Eventos do formato "Dia da Contribuição", em que os programadores podem entrar e entrar no projeto com muita facilidade, além de discutir o problema com os arquitetos do sistema e seguir o procedimento, a revisão do código se tornou muito popular, pois os programadores da comunidade aprendem rapidamente e recebem recomendações e dicas. dos engenheiros centrais que trabalham com o sistema, além de adquirir habilidades sobre como resolver problemas típicos usando os mecanismos fornecidos pela estrutura; ao mesmo tempo, faça melhorias úteis no próprio sistema. Como a prática do Win-Win desse modelo mostrou, ela se aplica a todos os participantes do processo, incluindo agências que empregam programadores que participam do projeto como colaboradores, porque essas agências podem usar o conhecimento adquirido por seus funcionários como uma vantagem competitiva em seus projetos futuros.
Por exemplo, duas semanas antes do lançamento oficial, o Strix, que participou ativamente da Code Contribution para o projeto MSI, já havia lançado seu projeto baseado no Magento 2.3 + MSI Beta, que foi compartilhado em
seu blog .
E se houvesse 15 desses eventos em 2017, em 2018 havia mais de 40.
E os mais numerosos eventos reuniram mais de 100 colaboradores em um só lugar, como o recente Dia da Contribuição em Kiev antes da conferência # MageConf18 ou o Dia da Contribuição do Magento Live UE em Barcelona:
Para uma comunicação rápida com os desenvolvedores, alocamos um canal Slack separado para comunicação, que agora consiste em mais de 350 desenvolvedores.
O Slack substituiu qualquer mensageiro instantâneo e também forneceu ferramentas para receber rapidamente comentários da comunidade com soluções técnicas e de produtos que íamos implementar. Fizemos isso com a ajuda de ferramentas padrão para questionários com folga.
Por um longo tempo, a principal fonte de documentação para o projeto foi o
wiki do
projeto , que inclui todos os projetos técnicos, documentação do usuário, arquivos de comunicação no Slack, descrições das decisões tomadas nos comícios de Grooming e Stand-up.
Toda sexta-feira, os colaboradores que fizeram um conjunto de solicitações para o projeto, bem como os que têm perguntas / sugestões sobre como melhorar algo, demonstram seus resultados em um comício de demonstração aberto, ao qual qualquer um pode se conectar via Zoom:
E todos aqueles que não tiveram tempo para a manifestação podem assistir à gravação, pois cada uma dessas manifestações é gravada e apresentada no
YouTube . Por exemplo, este é um registro da última demonstração em que o colaborador Riccardo Tempesta demonstra o Algoritmo de Seleção de Origem para a seleção ideal de armazéns para entrega com base nas distâncias entre o endereço de entrega e os endereços de armazéns com mercadorias
A parte mais difícil desse modelo de desenvolvimento de software, em que não há pessoas constantemente dedicadas ao projeto, é planejar o tempo para a disponibilidade de acessórios e determinar a
velocidade e capacidade do Scrum das principais métricas para avaliar quando algum tipo de fitcha pode ser entregue. De fato, o colaborador, que investiu de 20 a 30 horas no projeto dentro de uma semana, não pode gastar nem uma hora na próxima semana, porque em seu trabalho principal haverá um bloqueio, a esposa / menina começará a ficar com ciúmes ou em vista de outras circunstâncias, porque uma pessoa pode banal deixa de ser interessante. Os desenvolvedores de terceiros não têm e não podem ter nenhuma obrigação com o projeto. Eles participam por diversão e novos conhecimentos. E isso devemos dar a eles sem exigir nada em troca!
Queime um gráfico da implementação do Milestone 2 criada com o ZenHub .Na teoria do gerenciamento de projetos, eles geralmente tentam corrigir um dos dois indicadores Escopo fixo ou Tempo fixo de entrega, na presença da condição Recursos fixos.
No caso do modelo, quando apenas desenvolvedores da comunidade participam, não temos Recursos Fixos e quaisquer tentativas de corrigir o tempo de entrega foram muito difíceis.
Portanto, no final, decidimos escolher e seguir o processo de
desenvolvimento orientado a
recursos (FDD) . Corrigir formalmente tempo suficiente para iteração (marco) por 2-3 meses. E formar o backlog desse marco, atrair novamente a comunidade para ajudar na priorização de tarefas nesse backlog é outra característica desse modelo de desenvolvimento, pois não formamos e definimos prioridades para o backlog do produto. Os colaboradores, especialmente se representam empresas, geralmente definem para si mesmos a sua própria prioridade de determinadas tarefas, que é ditada por seus projetos atuais ou futuros. Esses colaboradores estão interessados em entregar ao repositório do projeto principalmente o que é interessante para eles. Como parte do marco, trabalhamos paralelamente nas histórias e podemos liberá-las assim que estivermos prontos ou assim que chegar ao fim da iteração. Se algumas histórias não foram concluídas como parte da iteração, elas passam para o próximo marco.
E o mais importante - nos livramos da data de lançamento do produto principal - Magento 2 e agora podemos ser lançados independentemente! Por que destacamos o
meta pacote do
compositor , que se refere a todos os módulos do Inventory e o link para o próprio
pacote meta do repositório principal (mais precisamente, do pacote meta do repositório principal) se parece com o seguinte:
"magento/inventory-composer-metapackage": "^1.0.3"
isto é o
caractere ^ é usado para indicar a versão do pacote.
Da mesma forma, os links para todas as versões dos módulos do projeto dentro do pacote são indicados com a adição do símbolo ^:
{ "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } }
O operador ^ existe para compatibilidade máxima ao escrever código, para que possamos executar versões MSI internas até fazermos alterações
incompatíveis com o projeto "
> = 1.0.3 <2.0.0 ".
Por um lado, isso oferece flexibilidade suficiente para projetos como o MSI, comumente chamados de Magento Core Bundle Extensions (CBE). Tais projetos estão localizados em repositórios separados do GitHub, têm sua própria cronologia de lançamentos e são o mais isolados possível de outros projetos similares e do principal produto Magento 2. Em termos de isolamento, proceduralmente, é como seguir
a Lei de Conway . E globalmente, essa abordagem de desenvolvimento para novos serviços e projetos no Magento 2 corresponde ao conceito de
Isolamento de Serviço apresentado pelo conselho de arquitetura do Magento. Mas com maior flexibilidade vem uma maior responsabilidade (
com um grande poder vem uma grande responsabilidade ), porque nesse caso, esses projetos devem seguir rigorosamente o controle de versão semântico (
SemVer ) para evitar alterações incompatíveis com versões anteriores e garantir facilidade de atualizações para os usuários.
O backlog do projeto em si, bem como todas as iterações (incluindo as concluídas), estão disponíveis na página
Mapa do
MSI .
Por exemplo, este é o backlog Milestone 3, no qual estamos apenas começando o trabalho:
E, para concluir, gostaria de agradecer mais uma vez a
todos os colaboradores que se juntaram ao projeto e ajudaram a trazê-lo para a fase de lançamento do GA. Não teríamos conseguido sem você!
