Como muchas comodidades en el desarrollo de software, una base de datos compartida es un pozo de alquitrán esperando fosilizar un proyecto. Los desarrolladores sobrescriben los cambios de los demás. Los cambios que hago en el servidor rompen el código de su máquina de desarrollo. El desarrollo remoto es lento y difícil. Evite a toda costa el uso de una base de datos compartida, ya que, en última instancia, hacen perder tiempo y contribuyen a producir errores.

Hablamos sin cesar de mejorar la calidad del software y reducir los riesgos, pero el software implementable es el activo más tangible para los “externos”.
como clientes o usuarios. No se puede subestimar la importancia de este punto.

Puede administrar los ámbitos de tiempo, costo y calidad de manera mucho más efectiva al basar sus decisiones en software funcional con comentarios y métricas reales, no solo elementos de tareas en un cronograma de proyecto.

Un conjunto de requisitos está completo si y sólo si describe todos los requisitos importantes que preocupan al usuario, incluidos los requisitos asociados con la funcionalidad, el rendimiento, las restricciones de diseño, los atributos o las interfaces externas.

Así como no existe un lenguaje de programación adecuado para cada aplicación, tampoco existe una forma correcta de desarrollar especificaciones más detalladas. Diferentes entornos requieren diferentes técnicas, y los administradores y redactores de requisitos probablemente necesitarán desarrollar una combinación de habilidades adecuadas a diversas circunstancias.

El proceso de desarrollo del equipo define quién hace qué, cuándo y cómo.
En el modelo en cascada, las actividades del software avanzan a través de una secuencia de pasos, y cada paso se basa en las actividades del paso anterior.
El modelo en espiral comienza con una serie de prototipos basados ​​en riesgos, seguidos de un proceso estructurado en forma de cascada.
El enfoque iterativo, un híbrido de los modelos en cascada y en espiral, desacopla las fases del ciclo de vida de las actividades de software que tienen lugar en cada fase.
Independientemente del modelo que utilice, debe desarrollar al menos un prototipo inicial para obtener comentarios de los clientes.

Algunas personas pueden pensar que la mejor manera de estimar un proyecto es tener requisitos detallados e información de diseño para cada característica. Pueden argumentar que esta es la forma más profesional y precisa de abordar el problema. Sin embargo, no estoy de acuerdo con esta opinión. Creo que es más importante poder tomar decisiones rápidas sobre el alcance del proyecto sin gastar demasiado tiempo y recursos en estimaciones detalladas. ¿Por qué? Porque las estimaciones detalladas a menudo resultan erróneas o irrelevantes más adelante, y crean un “inventario desperdiciado” que podría haberse utilizado para actividades más valiosas. Le sugiero que sólo haga estimaciones detalladas cuando el cronograma lo permita y cuando tenga una comprensión clara del valor y la prioridad de cada característica.

Uno de los problemas más frustrantes, generalizados y aparentemente francamente siniestros en todo el desarrollo de aplicaciones es el síndrome del “Sí, pero”, que consiste en la observación de la reacción de los usuarios ante cada pieza de software que he desarrollado.

Por alguna razón, siempre observo dos reacciones inmediatas, distintas y separadas cuando los usuarios ven la implementación del sistema por primera vez:

• “Vaya, esto es genial; realmente podemos usarlo, qué trabajo tan genial”. Atta boy", y así sucesivamente. • “Sí, pero, hmmmmm, ahora que lo veo, ¿qué pasa con esto…? ¿No sería bueno si…? ¿Qué pasó con…?"

El desarrollo de software es un proceso complejo y colaborativo que requiere comunicación y trabajo en equipo efectivos. Sin embargo, muchos equipos de software luchan con problemas de productividad y no logran entregar productos de alta calidad a tiempo y dentro del presupuesto. En esta publicación, analizaré por qué la productividad del equipo es más importante que la productividad individual y cómo puede mejorar el desempeño de su equipo de software aplicando algunas estrategias y mejores prácticas comprobadas.