Cuando se construye un equipo, como ahora en mi oficina. Se debe pensar que es muy importante manejar la cultura de equipo de tal manera que se pueda ser lo más productivo posible. A través del tiempo trabajando con equipos con difierentes disciplinas se podría ubicar un lista de actitudes e ideas que beneficien al equipo de desarrollo. Se la podría denominar el Credo de Desarrollo.
Este es un artículo que Eric Wase ha publicado y me permito reproducir en su extensión.
Yo <Tu nombre> soy un desarrollador.
Entiendo que la razón por la cual yo existo, es para servir y resolver las necesidades de los usuarios. Tomaré los requerimientos del usuario seriamente y seré un apasionado del servicio al cliente. No mostraré ningun desdén por el usuario que no entienda lo que yo hago y siempre trataré de cruzar el puente entre el mundo técnico y el del usuario para poder comprenderlo mejor. Al lograr entender al usuario puedo ganarme su confianza, y con esta confianza tendré un socio valioso en el proceso de desarrollo.
Entiendo que cada uno de los miembros del staff de IT es importante para lograr alcanzar mis metas. Los administradores de Bases de Datos protegen mis datos y me ayudan a asegurar el desempeño. Los Administradores de Red aseguran que mis respaldos (backups) están seguros y que tengo los accesos, permisos, software y sistemas adecuados y funcionando para realizar mi trabajo. No formaré un "gueto" de desarrolladores ni tendré una mentalidad "nosotros vs ellos". Apoyaré a los miembros de mi equipo que no sean desarrolladores como si fuera otro cliente o compañero.
Entiendo que cada uno de los desarrolladores de mi equipo es mi compañero. Como compañeros, ellos tendrán mi respeto y así lograré tener el de ellos. Con una relación basada en confianza y respeto, no voy a temer al formular preguntas, plantear inquietudes, o de otro modo ayudar a mis compañeros en la creación de código de alta calidad. Considero cualquier conflicto intelectual como una función saludable y natural de los equipos para encontrar la mejor ruta de acción para completar una tarea. Cuando el conflicto haya concluido y una dirección haya sido decidida por el equipo, apoyaré de todo corazón el enfoque adoptado, incluso si mi sugerencia no fue la "ganadora".
Entiendo que el ego en todas sus formas es destructivo y perjudicial para el equipo. Voy a recordar que el equipo es el propietario del código, no el individuo. A pesar de que debería sentirme orgulloso de mis logros personales, siempre recordaré darle crédito a la ayuda que el equipo me haya dado para cumplir estos logros, y nunca mostraré egoismo sobre mi código y técnicas hacia mis compañeros. Voy a alentar a mis compañeros a entender mi código y siempre sentar como bienvenidas cualquier crítica constructiva. Me doy cuenta de que todo el código puede ser mejorado y tomaré la crítica como una oportunidad para el debate intelectual y una experencia de aprendizaje, mas no como algo personal.
Entiendo que mi campo de acción está en constante crecimiento y evolución. Voy a crear oportunidades para explorar nuevos conceptos y estaré abierto a nuevas Ideas. No me cerraré en patrones particulares o prácticas de desarrollo en las cuales me siento a gusto pero que no son apropiadas en ciertas situaciones. Cuando uso patrones y prácticas particulares, voy a sopesar cuidadosamente los beneficios e inconvenientes de dichos patrones y tomaré las decisiones que sean siempre lo mejor para el equipo. Aunque guste de aprender cosas nuevas, me resistiré a usar herramientes y prácticas de desarrollo sólo porque son nuevas o "avanzadas", si es que no agregan valor real al código, servicio o producto que estoy haciendo.
Tengo como idea principal que a pesar de que soy el primero en escribir algún código en particular, no voy a ser el último en mantenerlo, administrarlo o hacerle cambios. Voy a tratar de mantener mi código legible, bien documentado y que tenga la menor complejidad posible. No asumiré que ya que conozco de una herramienta o patrón de desarrollo el resto de desarrolladores lo conocerá. Documento cuidadosamente los usos y justificativos para usar un patrón o herramienta para que los que vengan detrás de mí puedan entender mejor lo que yo estaba tratando de lograr con este código. Nunca construiré código "obscuro" o difícil de entender, solo por intentar lograr "un empleo seguro" o demostrar lo listo que soy.
Léelo Completo: My Team's Developer Credo en - Eric Wase Blog
Actualmente calificado con 5.0 por 1 personas
- Currently 5/5 Stars.
- 1
- 2
- 3
- 4
- 5