¿Cómo se desarrolla el software donde trabajas?

Aquí hay muchas buenas respuestas, así que no las voy a repetir. Sin embargo, me gustaría citar un ejemplo que demuestra que no hay un proceso de software ideal que se ajuste a todos los equipos.

La lección clave aquí es que los procesos ágiles no son especiales, ni lo son otros procesos, sino que debe evaluar cuánto proceso necesita, en lugar de solo aplicar el mínimo que necesita para lograr sus objetivos.

Grandes empresas y pequeñas empresas : mi ejemplo compara mi empleador actual y mi empleador anterior. No podrían ser más diferentes. Mi empleador actual tiene cuatro desarrolladores en una ubicación con un promedio de 25 años de experiencia y un desarrollador experto a cargo. Mi empleador anterior tenía miles de desarrolladores repartidos en docenas de ubicaciones con un promedio de aproximadamente cuatro años de experiencia con muy pocos gerentes que habían realizado programación de computadoras en los últimos diez años.

The Big Company : el empleador más grande tenía muchos procesos. Tenían gerentes de desarrollo, entrenadores scrum, gerentes de proyecto, gerentes de lanzamiento … 13 diferentes tipos de gerentes que emplean a un par de miles de personas. Eso suena mucho y, de hecho, tuvimos muchas reuniones. Esto fue necesario para coordinar un personal global de TI de 30,000 personas. Fue efectivo

The Little Company : el empleador más pequeño no tiene nada de eso y realmente no tiene ningún problema para hablar a pesar de hacer un trabajo muy delicado. Puede haber una o dos reuniones de camisas en una semana. La palabra “proceso” no aparece en la conversación. Todos llegan a tiempo, trabajan duro, hacen las cosas a tiempo y no hay quejas de las que hablar.

Si los dos procesos son 100% diferentes, ¿cuál es el mejor? Ambos son los mejores, para las condiciones allí.

¿Cuántos puntos de falla hay? -La compañía más grande tenía potencialmente cientos de lugares donde los proyectos podían salir mal, por lo que necesitaban más medidas de control. La otra compañía tiene solo cuatro “puntos únicos de falla”, cuatro desarrolladores que tienen cada uno 25 años de experiencia con supervisión experta, por lo que tienen todas las medidas de control que necesitaban.

El software desarrollado es el resultado de una profunda pasión por innovar.

Lo primero y más importante en el desarrollo de un software es el conjunto adecuado de personas. Si una empresa pierde un conjunto correcto de programadores, entonces, lo que sea que quieran desarrollar, será un fracaso. Incluso si la idea es mala, pero con el conjunto correcto de recursos, esa idea tiene mayores posibilidades de funcionar.

Idealmente, las startups trabajan en un modelo de desarrollo de ritmo rápido. Es menos de procesos y más de desarrollo.

El software completo se divide en pequeños módulos y subcaracterísticas. Un análisis general de la solución completa está diseñado y discutido en el equipo. Después de eso, se deciden las características mínimas básicas, que se requieren para lanzar la primera versión. Entonces los desarrolladores comienzan a desarrollar esos módulos. A medida que los módulos se preparan, se entregan al equipo de Control de calidad (QA) para la prueba. Mientras tanto, el desarrollador seguirá eligiendo las características restantes. Una vez que todas las funciones estén listas. El producto completo se prueba de principio a fin tanto por QA como por el equipo de desarrollo. Los errores encontrados se solucionarán. Y luego se lanza la primera versión del proyecto. Aquí el equipo de ventas y marketing lo elegirá para vender.

Mientras tanto, los desarrolladores regresan y comienzan a elegir las características importantes restantes, según la prioridad, para la próxima versión. Una vez que el próximo conjunto de características está listo, se realiza la próxima versión. Y este proceso continúa … Mientras tanto, si llega algún comentario o solicitud de un cliente, se hará con prioridad.

En las grandes empresas, tendrán muchos procesos en su lugar. Tendrá tamaños de equipo más grandes y muchos equipos multifuncionales como gestión de lanzamiento, gestión de productos, prueba de accesibilidad, equipo de revisión, equipo de interacción con el usuario, equipo de garantía de calidad, etc. El equipo individual necesita obtener muchas aprobaciones de todo el equipo para desarrollarse y fusionarse esas características en la base del código Debido a que las grandes empresas se demoran un poco en el producto.

En términos de técnicas, la mayoría de los desarrolladores tienden a no reinventar la rueda.
Lo primero que intentarán es averiguar si alguien ya ha desarrollado una solución para ese problema y si se puede ampliar para resolver el problema en cuestión. Al elegir la herramienta adecuada, la API es muy importante. También descubrir que la licencia de herramientas climáticas permite que nuestra compañía lo use o no es también una pregunta muy importante.
Se lograrán dos beneficios utilizando una solución ya existente:

1. Ahorro de tiempo.
2. Solución disponible más madura.

Luego, los desarrolladores personalizarán la solución o escribirán una nueva completa (en caso de que no haya una solución similar disponible) para resolver el problema. Otra cosa importante que los desarrolladores tienen en cuenta es el caso de uso diferente de la función. Y manejar todos los casos de uso como parte de su código es realmente importante.

Lo último pero no menos importante es la innovación continua. Si se detiene la innovación, se detiene la generación de ingresos del producto. La innovación de nuevas características y estabilidad son claves para una buena solución de software.

El proceso de desarrollo consta de dos pasos:
1. Comprende el problema
2. Resuélvelo
Es importante que se hagan en ese orden. No comience a escribir código antes de comprender el problema. La programación no es investigación.

Todo lo demás, ágil, cascada, se trata de cómo el proceso de desarrollo es administrado por extraños, no cómo ocurre.

Los siguientes son los pasos involucrados en el desarrollo de software:

Planificación: significa cuál es su objetivo y visión para desarrollar el software.

Documentación: significa cómo es la interacción entre el cliente y el sistema.

Implementación: la codificación del backend en cualquiera de los lenguajes de codificación conocidos

Revisión: significa cuáles son los defectos en su flujo y cómo los recuperará

Prueba: significa que el software funciona correctamente o no

Despliegue: significa la instalación práctica de software en el entorno de trabajo.

En mi lugar de trabajo, el software se desarrolla siguiendo los pasos mencionados. El desarrollo de software no es una tarea fácil. Si necesita algún tipo de ayuda a este respecto, puede consultar a Soft Examiner .com, que brindan ayuda profesional a este respecto y tienen una variedad de software para cumplir mejor con sus requisitos. Puede facilitarle la vida utilizando este software.

Aquí está el enlace Software de gestión de compensación de incentivos

Si hablamos de un alto nivel profesional de desarrollo de software, prefiero tener en cuenta los siguientes pasos:
1. Análisis de mercados y requisitos.
2. Diseño de un producto.
3. Desarrollo de software.
4. Pruebas.
5. Lanzamiento del producto.
Para la implementación de todas estas etapas, sus desarrolladores deben ofrecerle gestión de proyectos, análisis de componentes de vulnerabilidad, garantía de calidad profesional, desarrollo de conceptos de prueba, rediseño y mantenimiento, ajuste y actualización de software. Trabajé con http://en.intechcore.com/ empresa que proporciona los servicios completos en el desarrollo de software.

Aquí hay algo que dibujé una vez para describir cómo se desarrolla el software en la academia.

Mi filosofía no convencional es:

El resultado final no importa …
Los usuarios no importan …
El éxito del producto no importa …
El código solo y nada más que el código importa …
Solo a tu propio código serás verdadero.

Si el código hace solo y exactamente lo que pretendía, eso es Zen.
Si el código también es tan rápido como quieres que sea, eso es Zen.
Si el código también es tan limpio como quieres que sea, eso es Zen.
Si el código también es tan legible como quieres que sea, eso es Zen.

Pero debe tener una fuerte intención, debe medir críticamente, sangrar perfectamente y comentar de buena gana, de lo contrario no es Zen.

En este momento estoy trabajando para una compañía de servicios y no para una compañía de software, pero fingiré que todavía estoy trabajando para la última compañía que dejé.

Allí, utilizamos una forma ligera de desarrollo ágil de Scrum, con cinco equipos de desarrollo separados, cada uno de los cuales se centró en un área funcional específica dentro de nuestra plataforma general de clientes. Tuvimos reuniones diarias de pie, sprints de dos semanas, y recientemente implementamos un ciclo de lanzamiento de dos semanas (donde el trabajo completado en un sprint generalmente se publicaría dos semanas después de su finalización). Estábamos trabajando en la implementación de la cobertura de pruebas automatizadas en todo el conjunto de ofertas y tecnologías de integración.

En mi tiempo allí, hicimos grandes avances al ser un grupo reactivo, que elegía algo de la lista de las 1000 características, para convertirnos en un equipo enfocado, estratégicamente y entre los diez principales atrasados.

Mi filosofía es y siempre ha estado entregando lo que es de valor para el cliente de la manera más rápida y completa posible.

Me enfoco exclusivamente en áreas de incertidumbre. Me niego a hacer suposiciones de que algo funcionará. Quiero verlo funcionando.

Eso también se aplica al proceso comercial.
Así que haré un montón de experimentos, cada uno de los cuales tiene como objetivo reducir mi incertidumbre sobre un tema en particular.

Una vez que finaliza esa fase, el montaje y la introducción de la solución más grande deberían ser menos propensos a eventos inesperados. Debiera ser.