No estoy seguro de por qué se votó negativamente esta pregunta. Creo que es una gran pregunta. Una cosa es buscar en Google y leer algunos sitios web aleatorios que muchas veces intentan venderle algo en lugar de ser objetivos. Y otra cosa es pedirle a SO crowd, que son desarrolladores/gerentes de TI, que compartan sus experiencias y lo que funciona o no para sus equipos.
Ahora que este punto está fuera del camino. Estoy seguro de que muchos desarrolladores lo orientarán hacia "Agile" y/o Scrum, tenga en cuenta que estos términos a menudo se usan muy poco, especialmente Agile. Probablemente voy a sonar muy controvertido al decir esto, que no es mi intención, pero estas metodologías están exageradas, especialmente Scrum, que es más un producto que los consultores de Scrum comercializan que la metodología "real". Habiendo dicho eso, al final de un día, debes usar lo que funciona mejor para ti y para tu equipo, si es Agile/Scrum/XP o lo que sea, hazlo. Al mismo tiempo, debe ser flexible al respecto, no se vuelva religioso acerca de ninguna metodología, herramienta o tecnología. Si algo no funciona para ti, o puedes ser más eficiente cambiando algo, ve por ello.
Para ser más específico con respecto a sus preguntas.Aquí está el resumen básico de las técnicas que han estado trabajando para mí (muchos de ellos son de sentido común):
organizar todos los documentos y correos electrónicos pertenecientes a un proyecto específico, y que sea accesible a los demás a través de una ubicación central (utilizo MS OneNote 2007 y me encanta para toda mi documentación, progreso, funciones y seguimiento de errores, etc.)
Todas las reuniones (que debe intentar minimizar) deben ir seguidas de elementos de acción donde cada el elemento se asigna a una persona específica. Cualquier acuerdo verbal debe incluirse en un documento escrito. Todos los documentos agregados al sitio/repositorio del proyecto. (MS OneNote en mi caso)
Antes de comenzar cualquier desarrollo nuevo, tenga un documento escrito de lo que el sistema será capaz de hacer (y lo que no hará). Comprométase con eso, pero sea flexible a las necesidades del negocio. ¿Cuán detallado debe ser el documento? Lo suficientemente detallado para que todos entiendan de qué será capaz el sistema final.
Los horarios son buenos, pero se realista y honesto para usted y los usuarios de negocios. La guía básica que utilizo: versión calidad y utilizable software que carece de algunas características, en lugar de un software defectuoso con todas las características.
Tenga líneas de comunicación abiertas entre su desarrollador. equipo y entre sus desarrolladores y grupos de negocios, pero al final del día, una persona (o algunas personas clave) debería ser responsable de tomar decisiones clave.
Prueba de la unidad donde tiene sentido. Pero NO te obsesiones con eso. 100% de cobertura de código! = No hay errores, y el software funciona correctamente de acuerdo con las especificaciones.
Tiene estándares de código y revisiones de código. Comprometerse con los estándares, pero si no funciona en algunas situaciones, permita flexibilidad.
Compense su código especialmente para leer/comprender partes, pero no lo convierta en una novela.
Retroceda y limpie su código si ya está trabajando en esa clase/método; implementar nuevas características, trabajar en una solución de errores, etc. Pero no refactorizar solo por el bien de refactorizar, a menos que no tenga nada más que hacer y esté aburrido.
Y el último y más importante elemento: No se vuelva religioso acerca de ninguna metodología o tecnología específica. Pida prestados los mejores aspectos de cada uno y encuentre el equilibrio que funcione para usted y su equipo.
pls, hacen que sea la comunidad wiki –
hizo que todo fuera. Lo siento, lo he comprobado pero he puesto demasiadas etiquetas. ¿Error? –
Guau, ¿tiene una idea brillante sobre cómo algo puede hacer feliz a alguien en la computadora y quiere capitalizar, pero no tiene idea de por dónde empezar? Lugar equivocado. – hmcclungiii