Development

  • La tecnología avanza a pasos agigantados y, de repente, lo que era lo más común deja de serlo. Te quedas fuera, desfasado. Por ello es importante estar atento a la hora de detectar las tendencias que nos llevarán al futuro del desarrollo software. No hablamos de modas o de los lenguajes que más marketing hacen. Hablamos de lo que realmente están haciendo y aprendiendo los programadores, así como las tecnologías que, aunque minoritarias a día de hoy, serán los estándares de facto del futuro.

    Basándonos en el estudio realizado por la plataforma educativa de O’Reilly, hemos analizado los resultados y conclusiones del informe. Una combinación de términos de búsquedas y temas que los desarrolladores están explorando y demandando activamente, lo que da un consistente indicador de los temas cuya tendencia ascendente en popularidad merece echar un vistazo.

    En el radar de O’Reilly se encuentran 3 tendencias claves, que más adelante analizaremos:

    • El fuerte crecimiento de temas relacionados con el cloud. Ya no se trata solamente de llevar una aplicación a la nube sino de su arquitectura y como sistemas cada vez más complejos y enormes han empujado a los microservicios, apoyándose, en la orquestación de servicios mediante Kubernetes.

    • El Blockchain que para algunos sigue sonando al hype de las criptomonedas, tiene una gran cantidad de usos donde desarrollar aplicaciones distribuidas sin depender de una autoridad central. No solo transacciones monetarias, sino contratos inteligente o verificaciones de autoridad.

    • Python, Java y JavaScript siguen dominando y parece que cada año revalidan su relevancia gracias a su ecosistema en constante evolución. También empiezan a sonar fuerte: Rust o Go como lenguajes modernos que ayuden a ser más productivos a los desarrolladores a la vez que permiten un alto rendimiento y escalabilidad.

     
     
    1366 2000
     Top de términos en la plataforma educativa de O'Reilly

     

    La siguiente arquitectura ya está aquí: Docker + Kubernetes

    No se trata solo de llevar a la nube las aplicaciones sino aislar cada aplicación en microservicios

    Pocas startups no están construidas a día de hoy basándose en microservicios, usando contenedores Docker para desplegar y escalar servicios orquestando esta arquitectura cada vez más grande usando Kubernetes. El foco queda claro que está en la escalabilidad y la descomposición de cada problema particular en un servicio especializado.

    1366 2000
     
     
     

    Debido a la flexibilidad que necesita una organización, llevamos años viendo com Amazon Web Services, Google Cloud o Microsoft Azure no paran de crecer. Los tres grandes actores del mercado se llevan gran parte de la tarta del cloud empresarial. El primero de todo, AWS sigue siendo el rey con cada vez más servicios concretos a un problema especifico, pero la migración de grandes compañías hacia la nube de Google Cloud abre camino a otro competidor importante.

    Docker no es ningún recién llegado. Forma parte fundamental de esta arquitectura que permite descomponer y modular cada servicio en la nube. Y por otro lado, se busca ayudar a la productividad del desarrollador aislando al máximo esos microservicios en su propio entorno, con solo sus propias dependencias y configuraciones que no entren en conflicto con el resto de servicios. Además que, un factor fundamental en esta arquitectura es la integración continua y el desarrollo continuo: lo que significa que nosotros podemos desarrollar nuevo código, crear una nueva build, empaquetarla y crear una imagen de Docker para ser desplegada a produción con la mínima fricción.

    Todo este gran número de microservicios, ejecutándose en algunos casos en centenares o miles de contenedores justifican un claro enfoque en herramientas que sean capaces de orquestar toda esa nube de recursos como Kubernetes. Desde que fuera liberado como proyecto open-source por Google, Kubernetes representa el ingrediente esencial para escalar productos a nivel global con total confianza y estabilidad. El estándar de factor queda claramente representado en Docker + Kubernetes.

     

    Blockchain madurando poco a poco para ser la base que revolucionará internet

    Probablemente la confusión entre Blockchain y criptomonedas sigue estando presente. Pero cabe recordar el origen del blockchain, un sistema distribuido, donde no necesitemos una entidad centralizada para realizar operaciones. La posibilidad de crear contratos inteligentes muestra el potencial tremendo de estas plataformas que no sólo revolucionará las finanzas sino también internet.

    Teniendo una gran base de datos distribuida donde toda la información está almacenada en bloques, los cuales son inmutables, es decir, nadie puede modificarla, abre un amplio abanico de posibilidades de desarrollo poco exploradas a día de hoy.

    smartcontract
    Smartcontracts usando Blockchain

     

    Entre las tecnologías relacionadas nos encontramos con Ethereum, no confundir con la criptomoneda Ether. Con ello podemos crear esos smart contract como piezas de código autocontenidas que definan acuerdos entre múltiples partes dentro del blockchain. Más concretamente, uno de los lenguajes a tener en cuenta es Solidity con un sintaxis similar a JavaScript y C con lo que podemos desplegar esas pequeñas entidades de código EVM (Ethereum Virtual Machine). Y tampoco podemos olvidarnos de Bitcoin o la influencia de blockchain como elemento de seguridad y sincronización en IoT.

    El principal foco es construir APIs que accedan al blockchain, crear algoritmos de consenso para verificar la información y mantener la red de blockchain sincronizadas. Un incipiente ecosistema por construir con algunas herramientas ya presentes que no hay que dejar escapar.

    Python, Java y JavaScript continúan su dominio apoyados en el Machine Learning

    Año tras año vemos a estos tres lenguajes en el top de cada ranking que se crea sobre tendencias y usos. Vamos a analizar la explicación no sólo viven de que históricamente tienen un amplio ecosistema y cuota de mercado ganada sino como las nueva tendencias se apoyan en estos tres lenguajes.

    Machine Learning es una de las tecnologías que más apoyo recibe de la comunidad de Python. Muchas de las librerías que se utilizan en Data Science tienen su base en Python. También la apuesta de Google por TensorFlow cuya API está basada en interfaces Python ha ayudado al interés por este lenguaje con bastante veteranía y solidez demostrada a la hora de analizar y extraer datos de grandes cantidades de información.

    tensorflow
     
    El stack técnico de Tensor Flow

     

    Tenemos también algunos ejemplos como PyTorch, una librería para computer vision y procesamiento de lenguaje natural que ha escalado relevancia junto con otra librería como scikit-learn.

    Java sigue siendo uno de los lenguajes claves en el de desarrollo de aplicaciones a gran escala, escoltado por Scala y Kotlin aprovechándose de la JVM. Así todos los avances de en soluciones Big Data siguen confiando en Java. Nos encontramos con tecnologías ampliamente utilizadas como Spark o Kafka.

    Y, por último, JavaScript sigue siendo el rey dentro del ecosistema web. Con un crecimiento menor que el resto pero que tiene en framework como Angular, React o Vue, a este último le dedicamos un post especial hablando de las principales razones para usarlo.

    Entre los otros lenguajes que se han colado en el ranking de O’Reilly están Go debido a su combinación de sintaxis fácil, gran soporte de concurrencia y una activa comunidad de desarrolladores, apoyada por Google. Aunque tampoco podemos olvidar de Rust, un lenguaje de sistemas muy cercano al rendimiento que provee C, seguro, con un eficiente uso de memoria, soporte de concurrencia nativa y una sintaxis moderna.

     

    Fuente: https://www.genbeta.com/desarrollo/3-tendencias-emergentes-que-marcaran-futuro-programacion

  • Así que estás diseñando un nuevo sitio web o tienda en línea, y necesitas un desarrollador web. Es posible que los necesite para desarrollar un sitio desde cero. O tal vez simplemente los necesita para trabajar con algunos ajustes, cambios, problemas o funcionalidad adicional.

    De cualquier manera, su relación con su desarrollador web puede ser difícil de administrar. Soy un desarrollador, así que sé que hay tantas, tantas maneras en que la relación puede fracasar:

    • Plazos perdidos
    • Falta de comunicación
    • Comunicación lenta
    • Sin comunicacion
    • Desarrollador promete demasiado
    • Desarrollador bajo entrega
    • Desarrollador desaparece
    • Alcance poco definido
    • Falta de protocolo para pequeños supuestos / decisiones
    • Errores o problemas no se solucionan

    Prácticamente todos los diseñadores con los que trabajo han compartido una historia de terror relacionada con una de esas cosas. Con el fin de evitar convertirme en una historia de terror, he desarrollado una lista práctica de elementos de discusión previos al inicio para ayudarnos a evitar este tipo de problemas.

    Antes de entrar en esto, seamos claros: esto no es un remedio para todas las relaciones entre diseñadores y desarrolladores. Al final del día, sigue siendo una relación humana, es complicada. Pero he descubierto que una conversación abierta sobre estos elementos puede iniciar un proyecto con el pie derecho.

    1. ¿Cómo nos comunicaremos?

    ¿Cómo te comunicarás mientras trabajas en el proyecto? ¿Flojo? ¿Llamadas telefónicas? ¿Textos? Correos electrónicos? Software de mensajería privada? Igual de importante: ¿ Con qué frecuencia se comunicará? ¿Todos los días? ¿Una vez por semana? En el kickoff, y luego no otra vez hasta QA? Si está haciendo un registro diario, ¿será un correo electrónico de dos oraciones o una llamada telefónica de 15 minutos? ¿Cuál es el plan en caso de emergencias?

    Más comunicación no siempre es mejor comunicación

    No hay respuestas incorrectas aquí, siempre y cuando establezca expectativas al comienzo. Pero recuerde: más comunicación no siempre es mejor comunicación.

    Por qué esto importa

    Desea tener una buena relación con su desarrollador, y para lograrlo, necesita un modo de comunicación establecido. Por lo general, una llamada telefónica es útil para desarrollar una conexión personal inicial y para asegurarse de que sea una buena personalidad.

    Durante el desarrollo, trabaje para lograr un equilibrio entre registrar demasiado y muy poco. Demasiado y tu eres micro-gestor. Demasiado poco y el desarrollador podría no mantenerse en el camino. Es mejor establecer las expectativas en la parte superior y atenerse a ellas.

    2. ¿Cómo manejará el proyecto?

    ¿Dónde están los archivos y las credenciales de inicio de sesión que necesitará el desarrollador? ¿Dónde realizará el seguimiento de las tareas, los hitos y los plazos? ¿Qué software utilizarás? ¿Campamento base? Trello? Asana? ¿Una hoja de cálculo o Google Doc? Básicamente, define el hub central para todo lo relacionado con el proyecto.

    Por qué esto importa

    Durante el proyecto, la gestión y la comunicación de su proyecto deben ser centralizadas y rastreables. Se puede perder mucho tiempo en la búsqueda de archivos, registros, actualizaciones, progreso, preguntas, decisiones, etc. Es por eso que es importante establecer dónde el desarrollador puede encontrar todo lo que necesita.

    3. ¿Quién toma las decisiones?

    ¿Eres tú quien toma la decisión final sobre el proyecto? ¿Hay un equipo de UI / UX involucrado? ¿Hay alguien más que tenga una opinión sobre las decisiones? ¿Hay un equipo de marketing o un gerente que quiera tomar en cuenta las decisiones? ¿Hay alguien más aparte de usted que va a orientar directamente al desarrollador? ¿Cuándo entra el cliente y cuántas decisiones toma el cliente? ¿El cliente tendrá comunicación directa con el desarrollador?

    Por qué esto importa

    No desea dar marcha atrás en el desarrollo, o hacer que su desarrollador vuelva a trabajar. Para evitar eso, es importante que cada parte interesada esté al tanto de todas las decisiones relevantes, y que cada decisión se registre en una única ubicación central.

    4. ¿Cómo debe el desarrollador manejar las suposiciones y las pequeñas decisiones?

    ¿Cuánta libertad tiene el desarrollador al interpretar diseños? ¿Deberían construir el sitio web de píxeles perfectos de acuerdo con los diseños, o deberían hacer pequeños supuestos sobre la consistencia y la reutilización de las secciones? Si ha diseñado un sitio receptivo, ¿ha diseñado para todos los puntos de interrupción? ¿Ha proporcionado notas sobre animaciones, transiciones y efectos de desplazamiento? ¿Has diseñado estados de validación para campos? (es decir, las ventanas emergentes: "Contraseña no válida" o "Nombre de usuario no existe".) Si no lo ha hecho, ¿el desarrollador es libre de tomar decisiones o sugerencias?

    Por qué esto importa

    Muy a menudo, los diseñadores se sienten insatisfechos cuando un sitio web no se corresponde con los diseños, o, a la inversa, cuando el sitio sigue muy de cerca los diseños, en detrimento de su rendimiento o la línea de tiempo del proyecto. Al principio, define el nivel de detalle deseado. Lo hace para un proceso de control de calidad mucho más suave.

    5. ¿Cuál es la línea de tiempo?

    ¿Cuál es la fecha límite difícil para el proyecto y cuál es la fecha límite blanda? ¿Se está produciendo un gran éxito de prensa para el cual se debe lanzar el sitio? Si la fecha límite es ambiciosa, ¿hay una manera de lanzarlo en fases? ¿Cuál es la expectativa de responder a los cambios rápidos? ¿Una semana de vuelta? ¿Menos de una hora?

    Por qué esto importa

    realmente no ayuda a crear plazos duros artificiales... la honestidad es la mejor política

    Si hay un plazo límite, haga que el desarrollador lo sepa y asegúrese de dejar tiempo para realizar las pruebas adecuadas. Después de que se inicie el sitio, sepa que la mayoría de los desarrolladores no pueden estar disponibles a todas horas para realizar cambios. Esperar a que un desarrollador haga una solución puede ser frustrante, pero incluso las solicitudes pequeñas requieren mantener el control de la versión, iniciar el entorno de desarrollo, conectarse al servidor, implementar en el sitio de producción, etc. Determine con anticipación durante cuánto tiempo espera que se realicen correcciones y cambios Tomar y hacer un balance del nivel de prioridad de cada tarea.

    Además, realmente no ayuda a crear plazos duros artificiales. Solo sea transparente con su desarrollador y confíe en ellos para que lo entreguen en consecuencia. Una vez más, estás construyendo una relación, aquí. La honestidad es la mejor política.

    6. ¿Cuál es la estructura del alcance, el contrato y la estructura de pago?

    ¿Cuál es el costo del proyecto? ¿Cuál es el punto de referencia para el final del proyecto? ¿Qué se incluye en el alcance del proyecto? ¿Cuándo sale el pago? ¿Está contratando al desarrollador para que haga el proyecto a una tarifa fija o por hora?

    Por qué esto importa

    Lo último que desea es que un desarrollador obtenga un sitio al 95% del camino y no inicie el proyecto debido a una discrepancia en el alcance / contrato / pago.

    Conclusión

    En general, establecer las expectativas y la comunicación son las cosas críticas aquí. Puede parecer un poco tonto discutir cómo se hablarán entre ellos durante un proyecto, especialmente si ya tiene una buena relación. Pero siempre es bueno establecer expectativas antes de tiempo, para que no termines dentro de tu propia historia de terror.

     

    Fuente: https://www.webdesignerdepot.com/2019/03/6-things-to-discuss-with-your-web-developer-before-kickoff/

  • Si está creando una aplicación móvil por primera vez, sin duda tiene muchas preguntas: ¿Vale la pena? ¿Tiene sentido? ¿Cómo sabrá la gente al respecto?

    Aquí están las consultas más comunes, y las respuestas.

     

    Tengo muchas ideas de aplicaciones. ¿Cuál debo perseguir?

    La mayoría de los empresarios exitosos han desarrollado su negocio a través de múltiples ideas , así que no se limite a una sola idea de aplicación. Crear una aplicación es como apuntar a lanzar un single de éxito en la industria de la música: por lo general, nunca se sabe cuál será la única. Dé a cada aplicación de cuatro a seis meses después del lanzamiento, y si no ve una base de usuarios en crecimiento para esa fecha, pase a la siguiente idea.

     

    Tengo una idea de aplicación, pero ¿por dónde empiezo?

    Comience poniendo su idea en el papel lo más claramente posible. Busque herramientas de creación de prototipos en Internet y cree una maqueta o estructura de alambre detallada de pantalla a pantalla de su aplicación. Una vez que tenga claros sus requisitos, busque una compañía que pueda diseñarlo y desarrollarlo por usted.

     

    ¿Cómo puedo saber si el cliente quiere mi aplicación?

    Llegue al mercado rápidamente con un prototipo. No esperes más para crear una aplicación completa con todas las características. Desarrolle las funciones principales de la aplicación y vea si el cliente está listo para comprar. Si lo hacen, recibirá una gran cantidad de comentarios importantes de sus clientes que pagan.

     

    ¿Debo crear un sitio web móvil o una aplicación nativa?

    Hay cerca de un millón de aplicaciones en cada una de las tiendas de aplicaciones iOS y Android, y estás compitiendo contra lo mejor por visibilidad y compromiso. En general, los sitios web móviles no ofrecen una experiencia de usuario única, ni agregan tanto valor al cliente, en mi opinión. Las aplicaciones son para móviles lo que los sitios web son para computadoras de escritorio. No mezcles los dos.

     

    ¿Debemos construir la aplicación en casa o subcontratar?

    Algunos de los productos más populares de hoy en día fueron subcontratados en sus primeros días, incluidos Alibaba, Fab.com, Digg y Skype. Al crear la primera iteración de su producto, mantenga los costos bajos y opte por un proveedor externo que comprenda mejor sus requisitos. Su primera prioridad debe ser colocar el producto en manos de los consumidores, y rápido. Una vez que vea una demanda real de su producto y comience a ganar fuerza, entonces podrá hacerse cargo del desarrollo y el mantenimiento en la empresa.

     

    ¿Cómo presento una aplicación en Apple App Store o Android Market?

    Cree cuentas de desarrollador con Apple y Google registrándose a través de sus sitios web y pagando las tarifas anuales de la tienda de aplicaciones de $ 99 para Apple y $ 25 para Google. Los desarrolladores deben encargarse del proceso de carga en las tiendas de aplicaciones.

     

    ¿Debo ofrecer mi solicitud como gratuita y luego descubrir cómo hacer dinero más tarde?

    Existe una posibilidad de un millón en un millón (tal vez incluso menos) de que puedas ser el próximo Facebook o Twitter. La decisión es tuya. Si desea construir un negocio, creo que es importante contar con una estrategia de monetización clara desde el principio.

     

    He construido mi aplicación. ¿Ahora que?

    Los productos no se venden solos: debe dirigirse directamente al cliente y facilitarles el acceso al artículo. Es lo mismo para una aplicación. Si bien la optimización de la tienda de aplicaciones puede ayudarlo mucho en su capacidad de ser descubierto, no es suficiente obtener una tracción significativa para que su aplicación sea un negocio sostenible. Necesita comercializar su aplicación para obtener visibilidad.

     

    ¿Cómo comercializo mi aplicación?

    La mejor forma de publicidad para su aplicación, como para cualquier negocio, es un respaldo de terceros. Las revisiones de los bloggers de tecnología, la cobertura de la prensa y el boca a boca son todas grandes vías, y es importante mantenerlas si empiezas a ver la tracción. Además, preste especial atención a las revisiones publicadas por los usuarios de su aplicación y trabaje doblemente para revertir cualquier crítica negativa.

     

    ¿Debo crear una aplicación multiplataforma?

    Las aplicaciones multiplataforma rara vez ofrecen experiencias ricas para los usuarios porque a menudo están plagadas de errores, y es difícil ofrecer una experiencia consistente en todas las plataformas. Hay una razón por la que existen diferentes lenguajes de codificación para diferentes plataformas, que tienen sus propios kits de desarrollo de software (SDK).

     

    ¿Cuánto cuesta desarrollar una aplicación?

    Esta pregunta es similar a preguntar cuánto cuesta comprar una casa o un automóvil: la respuesta depende de muchos factores. Los costos de desarrollo pueden oscilar entre $ 3,000 y $ 100,000 o más, según la complejidad de la aplicación y las características generales involucradas.

     

    ¿Qué pasa si mi aplicación no funciona?

    Al igual que muchas ideas de negocios, muchas ideas de aplicaciones no son de inicio. Las personas exitosas toman decisiones terribles todo el tiempo, pero también se recuperan y prueban otras actividades con el nuevo aprendizaje de sus fracasos. Pase a la siguiente idea de la aplicación si la actual no obtiene resultados.

     

    Originalmente publicado en: https://www.entrepreneur.com/article/228328

  • Como la mayoría de las industrias, el diseño web ha cambiado bastante con el tiempo. En sus primeros días , la gente creaba sitios web mediante un proceso de 'hágalo usted mismo'. El código a menudo se escribía a mano en un editor de texto simple.

    Pero a medida que la industria evolucionó, también lo hizo la forma en que construimos sitios. Muchas de las partes más manuales del proceso han sido reemplazadas por herramientas que brindan mayor comodidad y funcionalidad.

    Por ejemplo, muchos diseñadores prefieren usar un framework CSS como Bootstrap , en lugar de reinventar una nueva interfaz de usuario para cada proyecto. Del mismo modo, es una práctica común instalar una copia de WooCommerce en lugar de construir un carrito de compras desde cero. Al igual que la línea de ensamblaje cambió para siempre la industria automotriz, esta gran variedad de herramientas y activos disponibles han cambiado el diseño web.

    Este poder y conveniencia vienen con muchos beneficios. Sin embargo, también nos puede poner en situaciones muy difíciles. Con eso en mente, exploremos el efecto que esto ha tenido en el diseño web moderno.


    Desarrollo rápido y características potentes

    La antigua forma de crear sitios web era, incluso en el mejor de los casos, ineficiente. Construir todo desde cero (o incluso su propia biblioteca personal de código) tomó tiempo y recursos preciosos. Los proyectos tardaron más en completarse. Además, la funcionalidad compleja estaba más allá del alcance del diseñador promedio.

    El hecho de que ahora tengamos a nuestra disposición decenas de miles de piezas de software gratuitas y de bajo costo ha nivelado el campo de juego. Significa que un profesional independiente en solitario puede competir por trabajos más grandes o que un desarrollador de poca monta puede construir algo que potencialmente podría ser utilizado por millones.

    Pero no solo los profesionales se están beneficiando. En estos días, incluso los novatos pueden superar estos obstáculos antes formidables. Para algunos, podría ser tan simple como instalar un tema atractivo de WordPress y una selección de complementos relevantes. En unas pocas horas, pueden vender sus productos y servicios en línea.

    Una gran parte del proceso de diseño y desarrollo ahora es elegir y elegir qué piezas queremos utilizar. Todo, desde simples componentes de IU hasta funcionalidades de alta gama, está al alcance de todos.

     

    Lo que renunciamos

    Ya sea una nueva biblioteca de JavaScript o un CMS de código abierto, estas herramientas aumentan la eficiencia y reducen los costos. Esto es excelente para democratizar la web, pero también nos ha llevado a un nuevo conjunto de riesgos y desafíos potenciales, que incluyen:

    Menos control

    Las herramientas que utilizamos para crear sitios web hacen que el proceso sea más fácil que nunca. Pero el costo a menudo está cediendo una medida de control.

    Esto es especialmente cierto cuando se utilizan servicios de construcción de sitios cerrados y propietarios. ¿Infeliz con el servicio? Ciertamente puedes irte, pero buena suerte llevando tu sitio web contigo. Si desea mover ese mismo aspecto y funcionalidad a otra parte, puede significar comenzar desde cero.

    Confianza en otros

    Un sitio web que depende en gran medida de herramientas y servicios de terceros (que parece ser la mayoría en estos días) está, en parte, a merced de otros. Eso significa que, por ejemplo, su plugin WordPress imprescindible tiene un problema , no hay mucho que un diseñador pueda hacer aparte de esperar una solución (y aplacar a un cliente impaciente).

    En el peor de los casos, tal vez esa corrección de errores nunca llegue. En ese punto, estás atascado con algo que no funciona y forzado a encontrar una alternativa. Si bien es posible que encuentre un reemplazo adecuado, sigue siendo una experiencia frustrante.

    Riesgos de seguridad y privacidad

    Esto también abre la puerta a posibles problemas de privacidad y seguridad, también. Ya hemos visto software previamente seguro caer en manos equivocadas y utilizado con fines no tan agradables. Y la posibilidad de más abusos siempre está ahí.

    Y aunque la gran mayoría de las personas detrás de estos productos están tratando de hacer lo correcto, el miedo a un solo mal actor está bien fundado. El problema para cualquiera que construya un sitio web es que es imposible saber en quién confiar. Incluso si cree que ha tomado las decisiones correctas, la situación es fluida y puede cambiar sin previo aviso.

     

    Bueno o malo, el juego ha cambiado

    De alguna manera, se siente como una paradoja. Lo que facilita nuestro trabajo también puede agregar múltiples capas de complejidad. Pero esa es la nueva normalidad del desarrollo web moderno.

    Muy pocos de nosotros tenemos el tiempo o las habilidades necesarias para construir todo nosotros mismos. E incluso aquellos que lo hacen podrían pensar dos veces antes de intentarlo. No solo existe el factor de reinventar la rueda, sino que los clientes tampoco pueden estar locos con la idea de una solución totalmente personalizada.

    Eso nos lleva a recolectar varias piezas de varios lugares en un esfuerzo por hacer que todas trabajen juntas. Es difícil, pero parece que las técnicas para lograr una cierta armonía están mejorando constantemente.

    Es una buena noticia, porque no parece que este enfoque fragmentario desaparezca pronto.

     

     

    Fuente:https://speckyboy.com/pros-cons-building-websites-third-party-products/

  • Scrum es una metodología o marco de gestión de proyectos ágil utilizado principalmente para proyectos de desarrollo de software con el objetivo de ofrecer nuevas capacidades de software cada 2-4 semanas. Es uno de los enfoques que influyó en el Manifiesto Ágil , que articula un conjunto de valores y principios para guiar las decisiones sobre cómo desarrollar un software de mayor calidad más rápido.

    ¿Quién usa la metodología ágil Scrum?

    Scrum es ampliamente utilizado por los equipos de desarrollo de software. De hecho, es la metodología ágil más popular . Según el 12º informe anual de State of Agile , el 70% de los equipos de software usan Scrum o un híbrido Scrum. Sin embargo, Scrum se ha extendido a otras funciones comerciales, incluyendo TI y marketing, donde hay proyectos que deben avanzar en presencia de complejidad y ambigüedad. Los equipos de liderazgo también basan sus prácticas de gestión ágil en Scrum, a menudo combinándolo con prácticas lean y Kanban (subgrupos de gestión de proyectos ágiles).

    ¿Qué es Scrum en relación con la gestión ágil de proyectos?

    Scrum es un subgrupo de ágil:

    • Ágil es un conjunto de valores y principios que describen las interacciones y actividades cotidianas de un grupo. Ágil en sí mismo no es prescriptivo o específico.
    • La metodología Scrum sigue los valores y principios de ágil, pero incluye definiciones y especificaciones adicionales, especialmente con respecto a ciertas prácticas de desarrollo de software.

    Aunque desarrollado para el desarrollo de software ágil, Scrum ágil se convirtió en el marco preferido para la gestión ágil de proyectos en general y, a veces, simplemente se conoce como gestión de proyectos Scrum o desarrollo Scrum.

    ¿Cuáles son los beneficios recibidos de la metodología Scrum?

    Las organizaciones que han adoptado Scrum ágil han experimentado:

    • Mayor productividad
    • Productos de mejor calidad.
    • Reducción del tiempo de comercialización.
    • Mejor satisfacción de los interesados
    • Mejor dinámica de equipo
    • Empleados más felices

    ¿Qué tiene de especial la gestión de proyectos Scrum?

    Scrum aborda la complejidad en el trabajo al hacer que la información sea transparente, de modo que las personas puedan inspeccionar y adaptarse según las condiciones actuales, en lugar de las condiciones previstas. Esto permite a los equipos abordar las dificultades comunes de un proceso de desarrollo en cascada: el caos resultante de los requisitos en constante cambio; subestimación de tiempo, recursos y costos; compromisos sobre la calidad del software; e informes de progreso inexactos. Se requiere transparencia de los términos y estándares comunes en el desarrollo de Scrum para garantizar que lo que se entrega es lo que se esperaba. La inspección frecuente asegura el progreso y detecta las variaciones desde el principio para que los ajustes se puedan hacer rápidamente. Los eventos Scrum más comunes para inspección y adaptación son: Planificación de Sprint, Scrum diario o "Levántate", Revisión de Sprint y Retrospectiva de Sprint (ver Eventos de Scrum a continuación).

    ¿Qué es la metodología Scrum en comparación con otros enfoques ágiles?

    La mayoría de las empresas primero hacen la transición de los equipos individuales a ágiles antes de "escalar" al resto de la organización. El escalado ágil no es fácil, lo que recientemente ha provocado la aparición de nuevos marcos, como Scaled Agile Framework® y Disciplined Agile Delivery (DAD). Esta popularidad ha convertido a Scrum en una pieza importante de muchas iniciativas de gestión ágil del ciclo de vida de las aplicaciones (ALM ágil).

    ¿Cuáles son los componentes del desarrollo ágil de Scrum?

    La metodología Scrum se define por roles de equipo, eventos (ceremonias), artefactos y reglas.

    El equipo de Scrum

    Los equipos Scrum generalmente están compuestos por 7 +/- 2 miembros y no tienen un líder de equipo para delegar tareas o decidir cómo se resuelve un problema. El equipo como unidad decide cómo abordar los problemas y resolverlos. Cada miembro del equipo Scrum es una parte integral de la solución y se espera que lleve un producto desde su inicio hasta su finalización. Hay tres roles clave en un equipo Scrum:

    El dueño del producto

    El propietario del producto es la parte interesada clave del proyecto, generalmente un cliente interno o externo, o un portavoz del cliente. Solo hay un Propietario de producto que transmite la misión y visión general del producto que el equipo está construyendo. El propietario del producto es en última instancia responsable de administrar el trabajo atrasado del producto y aceptar los incrementos completos de trabajo.

    El ScrumMaster

    ScrumMaster es el líder de servicio del propietario del producto, el equipo de desarrollo y la organización. Sin autoridad jerárquica sobre el equipo, sino más bien un facilitador, el ScrumMaster garantiza que el equipo se adhiera a la teoría, las prácticas y las reglas de Scrum. ScrumMaster protege al equipo haciendo todo lo posible para ayudar al equipo a rendir al más alto nivel. Esto puede incluir eliminar impedimentos, facilitar reuniones y ayudar al Propietario del producto a preparar el trabajo atrasado.

    El equipo de desarrollo

    El Equipo de Desarrollo es un grupo autoorganizado y multifuncional armado con todas las habilidades para entregar incrementos enviables al finalizar cada sprint. Scrum amplía la definición del término "desarrollador" más allá de los programadores para incluir a cualquiera que participe en la creación del incremento entregado. No hay títulos en el Equipo de desarrollo y nadie, incluido el ScrumMaster, le dice al Equipo de desarrollo cómo convertir los elementos de la cartera de productos en incrementos potencialmente enviables

     

    Eventos Scrum (Ceremonias)

    El sprint

    Un sprint es un período de tiempo durante el cual se completa el trabajo específico y se prepara para su revisión. Los sprints suelen durar de 2 a 4 semanas, pero pueden ser tan cortos como una semana.

    Sprint Planning Sprint

    Las reuniones del equipo de planificación son eventos de tiempo determinado que determinan qué elementos de la cartera de productos se entregarán y cómo se logrará el trabajo.

    El stand-up diario

    El Stand-up diario es una breve reunión de comunicación (no más de 15 minutos) en la que cada miembro del equipo cubre de manera rápida y transparente el progreso desde la última stand-up, el trabajo planificado antes de la próxima reunión y cualquier impedimento que pueda estar bloqueando su progreso

    La revisión de Sprint

    La Revisión de Sprint es el evento de "mostrar y contar" o demostración para que el equipo presente el trabajo completado durante el sprint. El propietario del producto verifica el trabajo con criterios de aceptación predefinidos y acepta o rechaza el trabajo. Las partes interesadas o los clientes brindan comentarios para garantizar que el incremento entregado satisfaga las necesidades del negocio.

    La retrospectiva

    La Retrospectiva, o Retro, es la reunión final del equipo en el Sprint para determinar qué salió bien, qué no salió bien y cómo el equipo puede mejorar en el próximo Sprint. Con la asistencia del equipo y el ScrumMaster, la Retrospectiva es una oportunidad importante para que el equipo se concentre en su desempeño general e identifique estrategias para la mejora continua de sus procesos.

     

    Artefactos Scrum

    Backlog de Producto

    La cartera de productos es el documento más importante que describe todos los requisitos para un sistema, proyecto o producto. El trabajo atrasado del producto puede considerarse como una lista de tareas que consta de elementos de trabajo, cada uno de los cuales produce una entrega con valor comercial. Los elementos de la cartera de pedidos son ordenados en términos de valor comercial por el propietario del producto.

    Sprint Backlog

    Una acumulación de sprint es la lista específica de elementos tomados de la acumulación de productos que se deben completar en un sprint.

    Incremento

    Un incremento es la suma de todos los elementos de la cartera de productos que se han completado desde la última versión del software. Si bien corresponde al propietario del producto decidir cuándo se lanzará un incremento, es responsabilidad del equipo asegurarse de que todo lo que se incluye en un incremento esté listo para ser lanzado. Esto también se conoce como el Incremento Potencial de Envío (PSI).

     

    Reglas Scrum

    Las reglas de Scrum ágil deben depender completamente del equipo y regirse por lo que funciona mejor para sus procesos. Los mejores entrenadores ágiles les dirán a los equipos que comiencen con los eventos básicos de scrum mencionados anteriormente y luego inspeccionen y se adapten según las necesidades únicas de su equipo para que haya una mejora continua en la forma en que los equipos trabajan juntos.

    Practicando Scrum

    Empezando

    Para comenzar con Scrum , no es raro que un equipo de Scrum individual use herramientas de Scrum simples como una pizarra, notas adhesivas o una hoja de cálculo para administrar el trabajo atrasado del producto y el progreso de los elementos del trabajo atrasado en cada sprint. Sin duda, ampliar las prácticas ágiles al resto de la organización es más complicado: cuanto más equipos usan Scrum dentro de una organización o están dispersos geográficamente, más engorrosas herramientas simples como pizarras, notas adhesivas y hojas de cálculo se vuelven.

    Llevando ágil al siguiente nivel

    VersionOne aborda el desafío de escalar prácticas ágiles como Scrum al proporcionar una plataforma de gestión de proyectos ágil todo en uno que puede ser utilizada no solo por equipos individuales, sino también por empresas distribuidas que han adoptado un marco ágil escalado. La plataforma de ALM ágil VersionOne es un entorno centralizado para los interesados ​​en los niveles de equipo, programa y cartera para planificar, rastrear e informar sobre la entrega de software independientemente de la ubicación.

     

    Fuente: https://resources.collab.net/agile-101/what-is-scrum