🥇Organización do fluxo de traballo en equipo nun proxecto informático

Ola amigos. Moitas veces, especialmente na subcontratación, vexo a mesma imaxe. A falta dun fluxo de traballo claro en equipos en varios proxectos.

O máis importante é que os programadores non entenden como comunicarse co cliente e entre eles. Como construír un proceso continuo de desenvolvemento dun produto de calidade. Como planificar a túa xornada laboral e sprints.

E todo isto eventualmente resulta en prazos incumpridos, horas extras, enfrontamentos constantes sobre quen é o culpable e insatisfacción dos clientes: onde e como se move todo. Moitas veces, todo isto leva a un cambio de programadores, e mesmo de equipos enteiros. Perda dun cliente, deterioración da reputación, etc.

Nun tempo, acabo de entrar nun proxecto deste tipo, onde había todas estas delicias.

Ninguén quería asumir a responsabilidade do proxecto (un gran mercado de servizos), a facturación foi terrible, o cliente só rasgou e tirou. O conselleiro delegado achegouse dalgún xeito e díxome que tes a experiencia necesaria, polo que tes as cartas nas túas mans. Toma o proxecto para ti. Se estropeas, pecharemos o proxecto e expulsaremos a todos. Sairá, será xenial, despois lévao e desenvólveo como creas oportuno. Como resultado, convertínme nun xefe de equipo do proxecto e todo caeu sobre os meus ombreiros.

O primeiro que fixen foi deseñar un fluxo de traballo desde cero que coincida coa miña visión nese momento e escribín unha descrición do traballo para o equipo. Implementalo non foi doado. Pero nalgún lugar dentro dun mes todo se acomodou, os desenvolvedores e o cliente acostumáronse a iso e todo foi tranquilo e cómodo. Para demostrarlle ao equipo que non é só unha tormenta nun vaso, senón unha verdadeira saída á situación, asumín o máximo de responsabilidades, eliminando a rutina desagradable do equipo.

Xa pasou ano e medio, e o proxecto desenvólvese sen horas extras, sen “carreiras de ratas” e todo tipo de tensións. Alguén do equipo antigo non quería traballar así e deixou, pola contra, alguén realmente se meteu en que apareceron regras transparentes. Pero como resultado, todos no equipo están moi motivados e coñecen ao completo o enorme proxecto, tanto con front-end como back-end. Incluíndo tanto o código base como toda a lóxica empresarial. Chegou ata o punto de que non somos só "remeiros", senón que nós mesmos creamos moitos procesos comerciais e novas funcións que lle gustan ao negocio.

Grazas a este enfoque pola nosa parte, o cliente decidiu pedir outro mercado á nosa empresa, o que é unha boa noticia.

Xa que isto funciona no meu proxecto, quizais tamén axude a alguén. Así, o proceso en si, que nos axudou a salvar o proxecto:

O proceso de traballo en equipo no proxecto "O meu proxecto favorito"

a) Dentro dun proceso de equipo (entre desenvolvedores)

Todas as tarefas créanse no sistema Jira
Cada tarefa debe describirse na medida do posible e realizar estrictamente unha acción.
Calquera característica, se é o suficientemente complexa, divídese en moitas pequenas tarefas
O equipo traballa en funcións como unha única tarefa. Primeiro, facemos unha función xuntos, dámoslle a proba e despois tomamos a seguinte.
Cada tarefa está etiquetada como backend ou frontend
Hai tipos de tarefas e erros. Debes especificalos correctamente.
Despois de completar a tarefa, transfírese ao estado de revisión de código (créase unha solicitude de extracción para o seu compañeiro)
O que completou a tarefa rastrexa inmediatamente o seu tempo para esta tarefa
Despois de comprobar o código, o PR é aprobado e, despois diso, quen realizou esta tarefa fusionao de forma independente na rama mestra, despois de que cambia o seu estado a listo para a súa implantación no servidor de desenvolvemento.
Todas as tarefas listas para ser despregadas no servidor de desenvolvemento son despregadas polo líder do equipo (a súa área de responsabilidade), ás veces un membro do equipo, se algo é urxente. Despois da implantación, todas as tarefas desde listas para a súa implantación ata o desenvolvemento transfírense ao estado: listas para probalas no desenvolvemento.
Todas as tarefas son probadas polo cliente
Cando o cliente probou a tarefa no desenvolvemento, transfire ao estado listo para a súa implantación en produción.
Para a implantación en produción, temos unha rama separada na que fusionamos o mestre xusto antes da implantación
Se durante a proba o cliente atopa erros, entón devolve a tarefa para a súa revisión, configurando o seu estado para a revisión. Así é como separamos as tarefas novas das que non foron probadas.
Como resultado, todas as tarefas van dende a creación ata a finalización: Para facer → En desenvolvemento → Revisión de código → Implementación lista para o desenvolvemento → Control de calidade no desenvolvemento → (Volver ao desenvolvemento) → Implemento listo para producir → Control de calidade no produto → Feito
Cada desenvolvedor proba o seu código de forma independente, incluso como usuario do sitio. Non se permite fusionar unha rama coa principal, a non ser que se saiba con certeza que o código funciona.
Cada tarefa ten prioridades. As prioridades son establecidas polo cliente ou polo líder do equipo.
Os desenvolvedores fan as tarefas prioritarias primeiro.
Os desenvolvedores poden asignarse tarefas entre si se atoparon diferentes erros no sistema ou se unha tarefa consiste no traballo de varios especialistas.
Todas as tarefas que crea o cliente son enviadas ao xefe do equipo, quen as avalía e ben lle pide ao cliente que as finalice ou ben as asigna a un dos membros do equipo.
Todas as tarefas que están listas para ser implementadas para o desenvolvemento ou a produción tamén chegan ao líder do equipo, quen determina de forma independente cando e como implementar. Despois de cada implantación, o líder do equipo (ou membro do equipo) debe notificarlle ao cliente. E tamén cambia os estados das tarefas a listas para probar en dev/prod.
Todos os días á mesma hora (témolo ás 12.00 horas) realizamos unha concentración entre todos os membros do equipo
Todos os asistentes ao mitin informan, incluído o líder do equipo, o que fixo onte, o que pensa facer hoxe. O que non funciona e por que. Así, todo o equipo é consciente de quen fai que e en que fase se atopa o proxecto. Isto dános a oportunidade de prever e axustar, se é necesario, as nosas estimacións e prazos.
Na reunión, o líder do equipo tamén anuncia todos os cambios no proxecto e o nivel de erros actuais que non atopou o cliente. Todos os erros son resoltos e asignados a cada membro do equipo para resolvelos.
Na concentración, o xefe do equipo asigna tarefas para cada un, tendo en conta a carga de traballo actual dos desenvolvedores, o seu nivel de formación profesional, e tamén tendo en conta a proximidade dunha tarefa determinada ao que está a facer actualmente o desenvolvedor.
Na reunión, o xefe do equipo desenvolve unha estratexia xeral para a arquitectura e a lóxica empresarial. Despois diso, todo o equipo discute isto e decide se facer axustes ou adoptar esta estratexia.
Cada desenvolvedor escribe código e constrúe algoritmos de forma independente dentro dunha única arquitectura e lóxica empresarial. Todo o mundo pode expresar a súa visión da implementación, pero ninguén está obrigando a ninguén a facelo deste xeito e non doutro xeito. Toda decisión está xustificada. Se hai unha solución mellor, pero agora non hai tempo para iso, entón créase unha tarefa en graxa, para a futura refactorización dunha determinada parte do código.
Cando un desenvolvedor asume unha tarefa, trasládaa ao estado de desenvolvemento. Toda comunicación relativa á aclaración da tarefa co cliente recae sobre os ombreiros do desenvolvedor. Pódense facer preguntas técnicas ao xefe do equipo ou aos compañeiros.
Se o desenvolvedor non entende a esencia da tarefa e o cliente non puido explicala de forma sensata, pasará á seguinte tarefa. E o xefe do equipo toma o actual e o comenta co cliente.
Todos os días, o programador debe escribir no chat do cliente sobre as tarefas nas que traballou onte e en que tarefas traballará hoxe.
O fluxo de traballo baséase en Scrum. Todo está dividido en sprints. Cada sprint dura dúas semanas.
Os sprints son creados, enchedos e pechados polo líder do equipo.
Se o proxecto ten prazos estritos, intentamos estimar aproximadamente todas as tarefas. E recollemos deles un sprint. Se o cliente tenta engadir máis tarefas ao sprint, establecemos prioridades e transferimos outras tarefas ao sprint seguinte.

b) O proceso de traballo co cliente

Cada desenvolvedor pode e debe comunicarse co cliente
Non podes permitir que o cliente impoña as súas propias regras de xogo. É necesario de xeito educado e amable deixar claro ao cliente que somos especialistas no noso campo, e só nós debemos construír procesos de traballo e implicar o cliente neles.
É necesario, idealmente, antes de proceder á implementación de calquera funcionalidade, crear un diagrama de fluxo de todo o proceso lóxico para unha característica (fluxo de traballo). E envíao ao cliente para a súa confirmación. Isto só aplícase a funcionalidades complexas e non obvias, por exemplo, un sistema de pago, un sistema de notificación, etc. Isto permitirache comprender con máis precisión o que precisa exactamente o cliente, gardar a documentación para a función e tamén asegurarse contra o feito de que o cliente poida dicir no futuro que non fixemos o que pediu.
Todos os diagramas/diagramas de fluxo/lóxica, etc. aforramos en Confluence/Fat, onde lle pedimos ao cliente nos comentarios que confirme a corrección da futura implementación.
Intentamos non cargar o cliente con detalles técnicos. Se necesitamos entender como quere o cliente, debuxamos algoritmos primitivos en forma de diagrama de fluxo que o cliente pode entender e arranxar/modificar todo por si mesmo.
Se o cliente atopa un erro no proxecto, pedímoslle que o describa con gran detalle en Fat. En que circunstancias ocorreu, cando, que secuencia de accións levou a cabo o cliente durante a proba. Adxunta capturas de pantalla.
Tentamos cada día, como máximo cada dous días, implementar no servidor de desenvolvemento. O cliente comeza entón a probar a funcionalidade e o proxecto non está inactivo. Ao mesmo tempo, este é un marcador para o cliente de que o proxecto está en pleno desenvolvemento e ninguén lle conta contos de fadas.
A miúdo ocorre que o cliente non entende completamente o que necesita. Xa que crea un novo negocio para si mesmo, con procesos que aínda non foron depurados. Polo tanto, unha situación moi común é cando tiramos anacos enteiros de código ao lixo e remodelamos a lóxica da aplicación. Diso dedúcese que non é necesario cubrir absolutamente todo con probas. Ten sentido cubrir só a funcionalidade crítica con probas e despois con reservas.
Hai situacións nas que o equipo dáse conta de que non nos adaptamos aos prazos. A continuación, realizamos unha auditoría rápida das tarefas e informamos inmediatamente ao cliente sobre iso. Para saír da situación, suxerímoslle lanzar funcionalidades importantes e críticas a tempo e deixar o resto para o lanzamento posterior.
Se o cliente comeza a facer diferentes tarefas desde a súa cabeza, comeza a fantasear e explicar cos seus dedos, entón pedímoslle que nos proporcione un deseño de páxina e fluír cunha lóxica que debería describir completamente o comportamento de todo o deseño e a súa elementos.
Antes de asumir calquera tarefa, debemos asegurarnos de que esta función estaba incluída nos termos do noso acordo/contrato. Se esta é unha función nova que vai máis alá dos nosos acordos iniciais, entón debemos estimar definitivamente esta función ((prazo de entrega aproximado + 30%) x 2) e indicarlle ao cliente que tardaremos moito tempo en completala, ademais de o prazo desprázase polo tempo estimado multiplicado por dous. Fagamos a tarefa máis rápida - xenial, todos só se beneficiarán diso. Se non, entón estamos asegurados.

c) O que non aceptamos no equipo:

Incoherencia, incoherencia, esquecemento
"Alimentación do almorzo". Se non podes completar a tarefa, non sabes como, entón tes que notificar inmediatamente ao líder do equipo sobre isto e non esperar ata o último.
Brovada e presumido dunha persoa que aínda non demostrou a súa capacidade e profesionalidade mediante actos. Se se demostra, entón é posible, dentro dos límites da decencia 🙂
A fraude en todas as súas manifestacións. Se a tarefa non se completa, non debes cambiar o seu estado a completada e escribir no chat do cliente que está lista. O ordenador fallou, o sistema fallou, o can mastigou o portátil: todo isto é inaceptable. Se ocorre unha verdadeira forza maior, o xefe do equipo debe ser notificado inmediatamente.
Cando un especialista está fóra de liña todo o tempo e é difícil contactar con el durante as horas de traballo.
Non se permite a toxicidade no equipo! Se alguén non está de acordo con algo, entón todos reúnense para un mitin e discuten e deciden.

E unha serie de preguntas/teses que ás veces fago ao meu cliente para eliminar todos os malentendidos:

Cales son os teus criterios de calidade?
Como determinar se un proxecto ten problemas ou non?
Incumprindo todas as nosas recomendacións e consellos para cambiar/mellorar o sistema, só ti corres todos os riscos
Calquera cambio importante no proxecto (por exemplo, todo tipo de fluxo extra) levará á posible aparición de erros (que, por suposto, solucionaremos)
É imposible entender nun par de minutos que tipo de problema ocorreu no proxecto, e máis aínda solucionalo alí mesmo
Traballamos nun fluxo de produto específico (Tarefas en Zhira - Desenvolvemento - Probas - Implementación). Isto significa que non podemos responder a todo o fluxo de solicitudes e queixas no chat.
Os programadores son só programadores, non probadores profesionais, e non poden garantir a calidade adecuada das probas do proxecto
A responsabilidade das probas finais e da aceptación das tarefas na venda correspóndelle enteiramente a ti
Se xa asumimos unha tarefa, non podemos cambiar inmediatamente a outras ata que completemos a actual (se non, isto leva a aínda máis erros e un aumento do tempo de desenvolvemento)
Hai menos xente no equipo (por vacacións ou enfermidades), e hai máis traballo e fisicamente non teremos tempo para responder a todo o que queiras
Solicitarche que implementes a produción sen tarefas probadas no desenvolvemento é só o teu risco, non o do programador
Cando estableces tarefas difusas, sen fluxo correcto, sen deseños de deseño, isto require moito máis esforzo e tempo de implementación por parte de nós, xa que temos que facer unha cantidade adicional de traballo en lugar de ti.
Calquera tarefa sobre erros, sen unha descrición detallada da súa aparición e capturas de pantalla, non nos dá a oportunidade de entender o que pasou mal e como podemos emitir este erro.
O proxecto require un perfeccionamento e melloras constantes para mellorar o rendemento e a seguridade. Polo tanto, o equipo dedica parte do seu tempo a estas melloras.
Debido a que temos horas extras (correccións urxentes), debemos compensalas noutros días

Como regra xeral, o cliente entende inmediatamente que todo non é tan sinxelo no desenvolvemento de software e que o desexo por si só non é suficiente.

En xeral, isto é todo. Entre bastidores, deixo moitas negociacións e a depuración inicial de todos os procesos, pero como resultado, todo funcionou. Podo dicir que este proceso converteuse nunha especie de "Bala de prata" para nós. As persoas novas que chegaron ao proxecto xa podían aproveitarse de inmediato para traballar desde o primeiro día, xa que se describen todos os procesos, e a documentación e a arquitectura en forma de diagramas deron inmediatamente unha idea do que estamos a facer todos. aquí.

PD Quero aclarar que non hai ningún responsable de proxectos da nosa parte. Está do lado do cliente. Non é un técnico en absoluto. proxecto europeo. Toda a comunicación é só en inglés.

Moita sorte a todos nos vosos proxectos. Non te quemes e intenta mellorar os teus procesos.

fonte no meu publicación do blogue.

Fonte: www.habr.com