¿Cuáles son las mejores prácticas de ingeniería de software? ¿Cuáles son los errores comunes que los desarrolladores deben evitar?

¡Las mejores prácticas más importantes para el desarrollo de software son recopilar los requisitos del producto completamente, usar el control de fuente, usar Agile / Scrum y hablar con su equipo todos los días!

Comience escribiendo un documento de requisitos.

Un documento de requisitos del producto debe actuar como punto de partida: delinear el propósito del producto, quién lo usará y cómo usarlo. Es un precursor esencial para el diseño y desarrollo.

Si bien no tiene que perder un tiempo precioso tratando de definir cada cosa posible que hará el software, debe asegurarse de capturar todo lo necesario para satisfacer las expectativas del cliente y ofrecer un producto funcional. Es un acto de equilibrio seguro.

He respondido algunas preguntas sobre este tema, pero el mejor lugar para ir es probablemente un artículo que escribí específicamente sobre cómo escribir PRD

Elija Agile y el marco Scrum.

Utilizamos metodologías Scrum y Agile porque ayuda a los equipos de desarrollo a construir proyectos de software dentro del presupuesto y dentro del plazo. Al mismo tiempo, ayuda a los clientes (o propietarios de productos como los llamamos en Scrum) a liderar equipos de desarrollo para construir el mejor producto posible, es decir, un producto que satisfaga las necesidades de la empresa y sus clientes.

Agile y Scrum son perfectos para equipos pequeños y remotos que trabajan en productos de software complejos. La idea es lanzar productos rápidamente, se obtienen comentarios y se realizan mejoras de forma iterativa. Si bien creo mucho en Agile y Scrum, no es sensato contratar un equipo de desarrollo y comenzar a desarrollar funciones sin saber en qué se está metiendo. Debido a esto, es importante no omitir la recopilación de requisitos del producto del cliente.

Agile y Scrum se adaptan a la forma iterativa actual de crear software. Fomenta una cultura multidisciplinaria donde los roles se superponen. Está diseñado para requisitos cambiantes. Por último, se basa en la transparencia, con todas las tareas y comunicaciones visibles para todos.

Elige un equipo en el que confíes.

No hay que decirlo, pero asegúrese de confiar y respetar a todos los miembros de su equipo.

Habla con tu equipo todos los días.

Esto es parte de Scrum y se llama el stand up diario. Esta es la ceremonia Scrum sin la que no puedo vivir. Todos nos reunimos en una videollamada y revisamos la lista de tareas y el progreso. Les da a todos una buena idea de lo que está sucediendo y cuál es su trabajo.

Use GIT para el control de fuente.

Nunca ejecute un proyecto sin control de fuente. Incluso si solo hay un desarrollador. El control de versiones le permite ver los cambios realizados con el tiempo y retroceder cuando sea necesario. Esta capacidad de retroceder lo hace invaluable. Una vez que tenga un gran equipo, los sistemas centralizados basados ​​en la nube, como Build software, facilitan en conjunto los equipos remotos que trabajan sincrónicamente.

Utilice una plataforma de gestión de proyectos que satisfaga sus necesidades.

Consideramos que la gestión de tareas es tan vital que creamos nuestra propia plataforma interna. Hay muchas plataformas excelentes por ahí. De Asana a Basecam a Trello, ¡solo por nombrar a los tres grandes! Escriba una lista de funciones clave y vea qué herramienta es la más adecuada para usted. Escribí un artículo que califica específicamente el mejor PMT para el desarrollo de software que puedes leer aquí.

Prueba, prueba y prueba.

Puede probar de forma manual o automática. Las pruebas automatizadas son perfectas para proyectos en etapa avanzada / modo de soporte. ¡Cuando la configuración es tan fácil como presionar un botón para verificar que todo funciona bien antes de actualizar! Este entorno controlado por prueba (TTD) también funciona en otros casos de uso, pero se vuelve menos valioso cuando un proyecto se encuentra en sus primeras etapas. En esta etapa, las cosas todavía están cambiando y no tiene sentido crear nuevas pruebas automatizadas que se extinguirán en unos días. En esta situación, tendemos a centrarnos más en el control de calidad manual. De cualquier manera, siempre probamos antes de lanzar.

Personalizado o ‘Fuera de la plataforma’.

A menudo escucho a los clientes decirme que quieren construir su propia plataforma, pero cuando analizamos los requisitos, nos damos cuenta de que ahorrarían tiempo y dinero al personalizar un producto ‘listo para usar’. Si está creando un blog, ¡no necesita crear una plataforma de administración de contenido usted mismo! Es por eso que recomiendo trabajar con un arquitecto de software para ayudarlo a decidir qué debe desarrollar usted mismo y qué puede comprar y personalizar.

Use un marco

Elegir el marco adecuado ayudará a su equipo a desarrollar una aplicación que cumpla plenamente con las reglas comerciales, que esté estructurada y que sea mantenible y actualizable. Los marcos también son más rápidos para trabajar porque permiten a los desarrolladores ahorrar tiempo reutilizando módulos genéricos. Por último, los marcos vienen completamente documentados para que todos en el equipo puedan leer y cumplir con las mismas pautas de uso.

Más allá de cumplir con los requisitos, lo que no siempre es fácil, creo que estas son prácticas importantes:

1. Escribe pruebas automatizadas. Impide el patrón de 2 pasos hacia adelante y 1 paso hacia atrás.

2. Haz que alguien revise tu código. Nadie es perfecto; todos cometemos errores.

3. Utilice siempre el control de fuente.

4. Use nombres significativos. Esto incluye variables, funciones, clases, paquetes, etc.

5. Escribe funciones cortas. Una buena regla es que no debería tener que desplazarse para ver todo.

6. No seas inteligente. Las soluciones simples resistirán la prueba del tiempo, pero las ingeniosas generalmente son demasiado frágiles.

7. Sé humilde y toma una crítica constructiva. No eres tu código.

Me gustaría resumir esto con una historia

El cliente: necesito algo para transferir algunos archivos de un servidor a otro periódicamente.

El mal ingeniero: “Oye, eso es genial. Me tomé un tiempo y resolví el problema por ti. Creé un programa c ultrarrápido que transfiere todos los archivos de a a b. Sí, y además de esto, creé también ui para que pueda definir qué tipo de archivos desea transferir. Me aseguré de que esté listo para varias plataformas. Sí, y también implementé muchas bibliotecas para que pueda usar varios protocolos y protocolos de seguridad … ”

El buen ingeniero: “Hablemos de los requisitos”.

El resultado: si el cliente solo necesita un pequeño script por lotes que será activado por un planificador, el buen ingeniero lo hará dentro de 1 hora y se ejecutará.

Algunos podrían decir … Bueno, pero ¿qué pasa con lo que viene después? Quizás el cliente necesite más en el futuro … Bueno, el problema es que “menos es más” en términos de satisfacción del cliente. El programa c ultrarrápido puede contener errores, ya que hay mucho código, la corrección de errores necesita tiempo. Si el cliente necesita nuevos requisitos que contradigan el diseño del mal ingeniero, es necesario desechar o rediseñar mucho código.

En resumen … KISS y YAGNI tienen sentido … Asegúrese de que sean la máxima prioridad en su trabajo