A industria informática está chea de linguaxe ambigua, xerga dura e ideas complexas que son difíciles de entender e que poden provocar a túa mente nun frenesí de búfer computacional.
Fervenza? Scrum? Áxil?
Se estas frases son completamente estrañas para ti, non te preocupes; o teu útil equipo de técnicos de HashDork está aquí para axudarche a comprender as distincións entre estas etapas cruciais do proceso de desenvolvemento para que poidas ter coñecemento.
As técnicas áxiles, scrum e fervenza cubriranse nesta publicación do blog, xunto con como cada unha pode axudar ao teu equipo no seu conxunto.
Empecemos polo áxil, e nós levaremos o resto.
Que é Áxil?
O desenvolvemento de software áxil segue un enfoque iterativo e incremental. En lugar dunha preparación extensa ao comezo dun proxecto, as técnicas áxiles son flexibles para as necesidades cambiantes ao longo do tempo e promoven a retroalimentación continua dos usuarios finais.
Os equipos multifuncionais traballan en iteracións de produtos ao longo do tempo, e este traballo clasifícase nun atraso e priorízase en función do valor do negocio ou do cliente. O propósito de cada iteración é crear un produto utilizable.
O liderado promove a cooperación, a responsabilidade e a comunicación cara a cara en metodoloxías áxiles.
As partes interesadas e os desenvolvedores empresariais deben colaborar para garantir que o produto satisfaga as demandas do consumidor e os obxectivos da empresa.
A frase "desenvolvemento áxil" refírese a unha variedade de métodos e marcos que se basean nos ideais e principios descritos no Manifesto áxil.
Os expertos aconsellan adherirse a principios e valores áxiles e utilizalos como guía para decidir as accións correctas a levar a cabo nun ambiente particular mentres se aborda o desenvolvemento de software.
O equipo colaborativo e autoorganizado son as principais áreas de enfoque para a comunidade de desenvolvemento de software áxil.
Os equipos poden decidir de forma autónoma como abordarán un proxecto en particular, pero iso non significa que os supervisores sexan inexistentes. Os equipos áxiles son polo tanto multifuncionais.
Nun paradigma áxil, os xestores seguen sendo necesarios. Asegúranse de que cada membro do equipo teña ou adquira as habilidades necesarias para o proxecto.
Os xestores nun marco áxil operan fomentando unha atmosfera que saca o mellor do equipo. Pero en lugar de tomar o liderado, adoitan pasar a un segundo plano e deixan que o equipo decida como entregará as cousas.
Os xestores só se involucran cando os equipos intentan resolver problemas repetidamente sen éxito.
Ciclo de desenvolvemento áxil
As etapas do ciclo de desenvolvemento áxil están listadas a continuación. É fundamental lembrar que estas fases non deben realizarse en orde porque son flexibles e cambian constantemente. Moitas destas etapas teñen lugar simultaneamente.
- Planificación: Despois de que un equipo do proxecto decida que unha idea é práctica e viable, comezan a buscar características. Esta fase ten como obxectivo priorizar cada característica e asignala a unha iteración despois de dividir a idea en pezas máis pequenas (as características).
- Análise de requisitos: Para determinar os requisitos comerciais, este paso implica varias discusións con xestores, partes interesadas e usuarios. Quen usará o produto e como o utilizará están entre os detalles que o equipo ten que recoller. Estas normas deben ser específicas, aplicables e cuantitativas.
- Proxecto: Os requisitos atopados na fase anterior utilízanse para preparar o deseño do sistema e do software. Consideracións para o aspecto do produto ou solución debe ser feita polo equipo. O equipo da proba tamén desenvolve unha estratexia ou plan para a proba.
- Implementación, codificación ou desenvolvemento: O foco desta etapa está na construción e avaliación de funcións e na planificación do despregue de iteracións (seguindo o enfoque de desenvolvemento iterativo e incremental [IID]). Dado que non se proporcionan funcións, comeza a iteración 0 do período de desenvolvemento. Ao completar actividades como a contratación, a configuración e o financiamento, esta iteración proporciona as bases para o crecemento futuro.
- Probas: Despois de que o código foi creado, compróbase cos requisitos para garantir que o produto realmente satisfaga as demandas dos usuarios e cumpre os obxectivos comerciais. Nesta fase realízanse as probas de unidades, integración, sistema e aceptabilidade.
- desenvolvemento: Despois das probas, o produto envíase aos clientes para que poidan utilizalo. Non obstante, o proxecto non está rematado despois da implantación. Os clientes poden atopar problemas adicionais despois de comezar a usar o produto, o que necesitará que o equipo do proxecto atope unha solución.
vantaxes
- Entrega máis rápida e de maior calidade: Ao dividir o proxecto en iteracións (unidades xestionables), o equipo pode concentrarse nunha colaboración, desenvolvemento e probas de maior calidade. Cando se realiza a proba con cada iteración, os problemas atópanse e solucionan máis rapidamente. Ademais, con revisións constantes e posteriores, este software de alta calidade pódese subministrar máis rápido.
- O cambio é benvido: Aínda que os ciclos de planificación son máis curtos, é sinxelo aceptar e acomodar cambios en calquera momento do proxecto. O atraso sempre se pode mellorar e redefinir, o que permite aos equipos facer cambios no proxecto nun par de semanas.
- É posible que non se coñeza o obxectivo final: Agile é excelente para proxectos cando o obxectivo final non está claramente definido. A medida que o proxecto avance, os obxectivos iranse clarificando e o desenvolvemento poderá acomodar facilmente estas necesidades cambiantes.
- Mellora continua: Os programas áxiles promoven a entrada de usuarios e equipos en todas as fases do proxecto, permitindo a aplicación do aprendido para mellorar a seguinte iteración.
- Valóranse as opinións dos clientes: Hai varias oportunidades para que os clientes vexan o traballo que se completa, ofrezan comentarios e afecten realmente o resultado final. Ao interactuar tan íntimamente co equipo do proxecto, poden desenvolver un sentimento de propiedade.
- Forte traballo en equipo: Agile enfatiza a importancia da comunicación regular e dos encontros en persoa. As persoas poden asumir a responsabilidade e posuír determinados compoñentes do proxecto cando traballan en equipo.
Desvantaxes
- Os membros do equipo deben ter coñecementose: Os equipos áxiles adoitan ser pequenos. Así, os membros do equipo deben ter unha ampla gama de habilidades. Ademais, deben comprender e sentirse a gusto usando a técnica Agile seleccionada.
- A planificación podería ser menos precisa: En ocasións pode resultar difícil determinar unha data de entrega exacta. Agile está construído sobre a entrega de prazos e os xestores de proxectos adoitan reorganizar as prioridades das tarefas. Así, é probable que algunhas das entregas que estaban programadas inicialmente para a súa entrega non se rematen a tempo. Ademais, pódense engadir máis sprints en calquera momento do proxecto, alongando todo o calendario.
- Pódese ignorar a documentación: Algúns membros do equipo poden crer que concentrarse na documentación é menos crucial xa que o Agile Manifesto favorece o traballo do software antes que a documentación exhaustiva. Os equipos áxiles deben acadar o equilibrio ideal entre documentación e diálogo, aínda que unha documentación exhaustiva non poida garantir por si só o éxito do proxecto.
- A saída final pode diferir moito: Quizais non houbese unha estratexia clara para o proxecto Agile inicial e, polo tanto, o resultado final pode variar moito do previsto inicialmente. Ao engadir novas iteracións baseadas no cambio da entrada do cliente pode producirse un resultado final substancialmente diferente, xa que Agile é tan adaptable.
- Compromiso de tempo dos desenvolvedores: O equipo de desenvolvemento debe estar totalmente comprometido co proxecto para que agil sexa eficaz. O método Agile, que leva máis tempo que un enfoque convencional, require unha participación activa e unha cooperación constantes. Ademais, implica que os desenvolvedores deben comprometerse coa duración total do proxecto.
Que é Fervenza?
A iteración máis popular do ciclo de vida de desenvolvemento do sistema (SDLC) para proxectos de enxeñería de software e TI coñécese como "enfoque en cascada", que segue un procedemento lineal e secuencial.
O diagrama de Gantt, unha forma de gráfico de barras que mostra as datas de inicio e finalización de cada traballo, úsase ocasionalmente para planificalo.
O equipo de desenvolvemento avanza ao seguinte nivel despois de finalizar unha das oito fases. O equipo non pode volver a unha fase anterior sen ter que reiniciar todo o procedemento.
Ademais, o cliente pode ter que avaliar e aceptar os requisitos antes de que o equipo poida pasar ao seguinte nivel.
O modelo de fervenza desenvolveuse nos entornos altamente organizados dos sectores de fabricación e construción, onde os axustes poden ser prohibitivamente caros ou mesmo imposibles.
A técnica da fervenza chámase así porque está pensada para fluír só nunha dirección, cara abaixo, como unha fervenza. As súas fases inclúen análise, inicio, probas, deseño, construción, implantación, mantemento e probas.
A técnica da fervenza ten varias vantaxes, como calquera outra estratexia. Unha delas é que as fases de planificación e deseño do proxecto están máis consolidadas.
Os clientes e o equipo de desenvolvemento están máis aliñados cando se trata de entregas do proxecto mentres usan o desenvolvemento de software en cascada. Como é consciente do alcance do proxecto desde o principio, o desenvolvemento da fervenza tamén facilita o seguimento do progreso.
O proceso en cascada utiliza especialistas, desenvolvedores, analistas e probadores para concentrarse nos seus traballos no proxecto en lugar de que todo o equipo faga fincapé nun paso.
Etapas da Fervenza
Os seis pasos da Fervenza deben ocorrer todos un despois do outro:
- Requisitos de recollida e almacenamento: Deberías acumular coñecementos exhaustivos sobre o que esixe este proxecto neste momento. Existen varias técnicas para recoller estes datos, incluíndo entrevistas, enquisas e brainstorming colaborativo. As necesidades do proxecto deberían ser evidentes cando remate esta fase e o teu equipo debería ter recibido unha copia do documento de requisitos.
- Deseño dun sistema: O sistema está deseñado polo teu equipo utilizando especificacións predeterminadas. Durante esta etapa, non se realiza ningunha codificación, pero o equipo establece requisitos para o hardware ou a linguaxe de programación.
- Implantación: Esta etapa implica a codificación. Os programadores usan os datos da etapa anterior para crear un produto utilizable. O código adoita implementarse en pequenos anacos que se combinan ao final dunha fase ou ao comezo doutra.
- Probas: O produto pode comezar a ser probado despois de completar o código. Calquera problema atópanse meticulosamente e informan os probadores. É posible que o teu proxecto teña que volver á fase un para a súa reavaliación se aparecen problemas significativos.
- Entrega/despliegue: o produto está rematado neste momento e o teu equipo envía os entregables para a súa implantación ou liberación.
- Mantemento: O cliente recibiu o produto e está a empregalo. É posible que o teu equipo teña que desenvolver correccións e actualizacións cando aparezan problemas para solucionalos. Unha vez máis, problemas significativos poden requirir un retorno ao primeiro paso.
vantaxes
- Fácil de manexar e xestionar: O enfoque Waterfall é sinxelo de usar e comprender xa que cada proxecto se manexa da mesma forma secuencial. Antes de comezar un proxecto Waterfall, o equipo non está obrigado a ter ningún tipo de experiencia ou formación previa. O enfoque da fervenza é moi estrito; cada etapa ten un conxunto de entregas e unha revisión, o que facilita a súa administración e mantemento.
- Requírese unha metodoloxía ben documentada: A documentación que require a metodoloxía da fervenza axuda a aclarar o razoamento detrás das probas e do código. Ademais, crea un rastro en papel no caso de que os interesados queiran información adicional sobre unha determinada fase ou para calquera iniciativa futura.
- Aplicación da disciplina: Cada paso dun proxecto de fervenza ten un comezo e un final, polo que é sinxelo comunicar o progreso ás partes interesadas e aos clientes. O equipo pode reducir a posibilidade de perder un prazo poñendo primeiro os requisitos e o deseño antes de producir código.
Desvantaxes
- Pode ser difícil reunir requisitos precisos: Falar cos consumidores e partes interesadas para determinar as súas necesidades é unha das etapas iniciais dun proxecto Waterfall. Nesta fase inicial do proxecto, pode ser un reto determinar os seus requisitos particulares. Os clientes a miúdo aprenden sobre os seus requisitos a medida que se desenvolve o proxecto en lugar de expresalos por adiantado.
- Os cambios son difíciles de acomodar: A tripulación non pode retomar o traballo despois de rematar unha fase. É moi difícil e caro volver e reparalo se aprenden durante a fase de proba que faltaba a funcionalidade durante o proceso de requisitos.
- O software ofrécese despois da súa data de vencemento: Deben rematar dúas ou catro fases do proxecto antes de que poida comezar a codificación real. Como resultado, as partes interesadas non verán software funcional ata finais do ciclo de vida.
Que é Scrum?
Un dos marcos de procesos máis populares para poñer en práctica Agile é Scrum, que é un subconxunto de Agile.
É un paradigma iterativo para xestionar a creación de software e produtos complexos. Os sprints, que son iteracións de duración fixa que duran unha ou dúas semanas, permiten ao equipo lanzar software nunha programación regular.
As partes interesadas e os membros do equipo reúnense para discutir os seguintes pasos despois de cada sprint. Os roles, responsabilidades e reunións en Scrum permanecen constantes.
Por exemplo, Scrum especifica a planificación do sprint, o stand-up diario, a demostración do sprint e a retrospectiva do sprint como os catro rituais que proporcionan a estrutura de cada sprint.
O equipo utilizará artefactos visuais como taboleiros de tarefas ou gráficos de queimadura durante cada sprint para demostrar o progreso e obter comentarios incrementais.
En scrum, o equipo e o propietario do produto traballan en estreita colaboración para identificar e priorizar a funcionalidade do sistema. Conségueno creando un backlog de produtos, que contén todas as tarefas necesarias para producir software que funcione segundo o previsto.
Os parches de erros, os requisitos non funcionais e as funcións deberían incluírse na cola. Os equipos interfuncionais deben estimar e rexistrarse para entregar incrementos de software durante Sprints continuos, que normalmente duran 30 días, unha vez que se establecen os obxectivos.
Só o equipo pode engadir funcionalidades ao Sprint despois de comprometer o atraso para ese Sprint.
A próxima entrega de Sprint, avalíase a acumulación de produtos e, se é necesario, repriorízase e escóllese o seguinte conxunto de entregas para formar parte do seguinte sprint.
Proceso Scrum
- Atraso do produto: Para pedir os elementos do produto pendiente, reúnense o Product Owner e o equipo Scrum (o traballo no produto pendiente provén das historias e requisitos dos usuarios). O produto atrasado é unha lista de todas as funcións desexadas para o produto en lugar dunha lista de tarefas que deben rematar. Despois diso, o equipo de desenvolvemento selecciona tarefas do produto atrasado para executar en cada sprint.
- Planificación de sprint: Antes de cada sprint, o Product Owner entrega ao equipo os principais elementos do atraso nunha reunión de planificación do sprint. Despois, o grupo selecciona elementos da lista de produtos que poden rematar durante o sprint e móvenos ao sprint (que é unha lista de tarefas para completar no sprint).
- Refinación/preparación do atraso: Para asegurarse de que o atraso estea preparado para o seguinte sprint, o equipo e o propietario do produto reúnense ao final dun sprint. O equipo pode descartar historias de usuarios que xa non son pertinentes, engadir outras novas, revisar a orde na que se deben abordar ou dividir as historias de usuarios en tarefas máis pequenas. Durante esta reunión de “grooming” procurarase que o atraso só contemple os elementos pertinentes, profundos e acordes cos obxectivos do proxecto.
- Reunións Scrum todos os días: Nunha reunión stand-up de 15 minutos chamada Daily Scrum, cada membro do equipo discute os seus obxectivos e os problemas que xurdiron. Todos os días ao longo do sprint, o equipo participa no Daily Scrum, que mantén a todos en tarefas.
- Reunión para avaliar o sprint: O equipo presenta o seu traballo nunha reunión de revisión do sprint ao final de cada sprint. En lugar dun informe ou unha presentación en PowerPoint, esta reunión debería incluír unha demostración real.
- Reunión de sprint retrospectiva: O equipo analiza as modificacións que deban facerse no seguinte sprint, así como o ben que Scrum está a traballar para eles ao final de cada sprint. O equipo pode discutir os aspectos positivos, negativos e as áreas de mellora do sprint.
vantaxes
- Máis responsabilidade do equipo: Non hai ningún xestor de proxecto que instrúa ao equipo scrum sobre que facer e cando. O traballo que se pode rematar en cada sprint é decidido polo equipo no seu conxunto. Todos cooperan e dan unha man uns aos outros, potenciando o traballo en equipo e fomentando a individualidade de cada membro do equipo.
- Mellora a visibilidade e transparencia do proxecto: Hai menos malentendidos e incerteza xa que todos os integrantes do equipo son conscientes das súas responsabilidades grazas ás frecuentes reunións de stand-up. O equipo pode xestionar os problemas antes de que se descontrolen xa que os problemas son detectados con antelación.
- Reducións de custos melloradas: A comunicación constante mantén ao equipo informado de calquera problema ou cambio tan pronto como se produce, o que axuda a aforrar custos e mellorar a calidade. Os fragmentos de funcións máis pequenos proporcionan comentarios continuos e permiten a corrección precoz dos erros antes de que os erros maiores sexan demasiado caros para remedialos.
- Fácil de adaptar aos cambios: é máis sinxelo xestionar e adaptarse aos cambios cando hai bucles de feedback frecuentes e sprints curtos. A modo de ilustración, se o equipo atopa unha historia de usuario nova durante un sprint, pode engadir rapidamente esa función ao sprint seguinte na reunión de perfeccionamento do atraso.
Desvantaxes
- Perigo de arrastre de alcance: Debido á falta dunha data de finalización establecida, certos proxectos de Scrum poden sufrir un aumento do alcance. As partes interesadas poderían verse atraídas a seguir esixindo máis funcións se non hai un prazo para a súa finalización.
- Un mal Scrum Master pode descarrilar todo: Non é o mesmo un xefe de proxecto que un scrum master. O Scrum Master debe confiar no equipo que está supervisando e nunca darlles instrucións. O Scrum Master non ten poder sobre o equipo. O proxecto fallará se o scrum master intenta xestionar o equipo.
- Os problemas de precisión poden derivarse de tarefas mal formuladas: Se as tarefas non están claramente especificadas, os gastos e os horarios do proxecto non serán precisos. A planificación faise un reto e os sprints poden levar máis tempo do previsto se non se definen os obxectivos iniciais.
- Para un equipo son necesarias experiencia e dedicación: Para que o equipo teña éxito, os roles e os deberes deben estar claramente definidos. O equipo Scrum require membros do equipo con habilidades técnicas porque non hai roles claramente definidos (todo o mundo fai). O equipo tamén debe comprometerse a participar nas sesións diarias de Scrum e unirse durante toda a vida do proxecto.
Agile Vs Scrum
Aínda que Agile e Scrum usan a mesma metodoloxía, hai algunhas variacións entre ambos. O Agile Manifesto describe un conxunto de principios para crear software mediante o desenvolvemento iterativo.
Scrum, por outra banda, é un conxunto de pautas que deben cumprirse mentres se realiza o desenvolvemento de software Agile. Agile é un concepto, mentres que Scrum é unha técnica para poñelo en práctica.
Scrum é un método para implementar Agile, polo que ambos teñen moitas cousas en común. Ambos enfoques son iterativos, priorizan a entrega temprana e frecuente de software e aceptan cambios. Tamén apoian a apertura e o desenvolvemento continuo.
Agile Vs Fervenza
Ríxido vs flexible describe mellor as distincións entre o proceso Waterfall e Agile. Aínda que Agile é fluído e cambia constantemente, Waterfall é unha metodoloxía moito máis axustada e ríxida.
Estas outras distincións entre eles son as seguintes:
- Agile non require un enfoque lineal, mentres que Waterfall é secuencial.
- Aínda que as necesidades adoitan estar predefinidas nos proxectos Waterfall, prevese que se alteren e se adapten nas iniciativas Agile.
- A diferenza de Agile, os proxectos Waterfall non permiten realizar modificacións nos traballos que se completaron nunha fase previa.
- A fervenza é un procedemento organizado no que debes rematar cada paso antes de pasar ao seguinte. Non obstante, Agile é unha metodoloxía flexible que che permite continuar co proxecto ao teu ritmo.
Agile Vs Waterfall Vs Scrum
- A fervenza aumenta a confianza no que se proporcionará moi pronto despois de que sexa planificado. Agile depende das mellores prácticas dun entorno de desenvolvemento. Aquí, unha serie de riscos do proxecto pódense xestionar ben xa que os resultados son avaliados continuamente.
- Waterfall non prevé que o equipo e o proxecto se baseen no mesmo lugar. Mentres scrum e agile necesitan a coubicación dos empregados.
- Agile céntrase en reducir a reelaboración do proxecto e fomenta que os cambios se incorporen moito antes. En contraste coa fervenza, que responde de forma diferente, scrum tamén permite o descubrimento precoz dos cambios.
- Agile e scrum proporcionan un modelo máis compacto para o produto final. Isto xera un problema coas promesas feitas ao comprador. Pola contra, o gráfico de fervenza dá aos clientes e desenvolvedores unha mellor impresión do resultado final.
- Cada unha destas técnicas conta cun conxunto de ferramentas para organizar e simular as tarefas que interveñen na súa creación.
Conclusión
Se seguiches ata agora e confías no teu coñecemento das distincións entre os procesos Waterfall, Agile e Scrum, xa deberías saber que estratexia funcionará mellor para ti e para o teu equipo.
A técnica Waterfall, que é para proxectos cun alcance, prazo e orzamento definidos, pode ser a túa mellor opción se che gustan as regras e procedementos duros e consideras que aportan claridade.
Por outra banda, se a liberdade e adaptabilidade que ofrece Agile te inspiran, podería ser onde deberías poñer a túa atención.
Scrum é o camiño a seguir, se queres un pouco de disciplina dentro dun marco flexible.
Non obstante, debes considerar estes enfoques á luz do proxecto no que estás a traballar e do teu resultado final.
Deixe unha resposta