Permite tomar un proyecto de sitio web con un número de miembros del equipo y tiene varias funciones. Durante el desarrollo, ¿es mejor para el mismo tipo hacer una función completa (DB, lógica de aplicación, frontend (Javascript, HTML, CSS, etc.)) o es mejor para el tipo diferente hacer la aplicación lógica y frontend. En la mayoría de los casos, DB lo hace otro tipo, creo. Cual es la manera recomendada para hacer esto.Desarrollo web
Como con la mayoría de las preguntas subjetivas, depende.
Tiendo a caer en el campo de conjuntos de habilidades especializadas. En ese caso, haga que funcionen según sus puntos fuertes. Es mejor enfocarse en una cosa que se hace realmente bien. Si quieres que esos desarrolladores tengan una amplia experiencia, tal vez rotar roles en el próximo proyecto, pero no trates de hacer las cosas del tipo "todo o nada". Terminas con una gran cantidad de conjuntos de habilidades diluidas y nadie puede profundizar demasiado y resolver los problemas especialmente peludos sin hackers.
Downvoter: los comentarios serán apreciados. Sin ellos, tiendo a suponer que eres otra persona que responde tratando de promocionar la tuya. : -/ –
La respuesta a esta pregunta depende de las personas involucradas y del tamaño del proyecto.
En general, es más fácil mantener cada capa de la aplicación coherente si hay una sola persona que escribe la capa (separación horizontal), pero con un equipo compacto de buenos desarrolladores, puede cortar un proyecto verticalmente y organizar el trabajo por "características" reales
de trabajo horizontal como usted sugiere razas menos conocimiento general de la aplicación, ya que cada dev conoce su capa, y no las otras capas.
Todos los puntos perfectamente buenos. Supongo que eso depende de la cantidad de conocimiento de dominio que necesiten y cuán técnicamente desafiante es el proyecto. También es más fácil rebanar verticalmente si tus desarrolladores saben cómo trabajar en todas las capas, y una autoridad (como un arquitecto) está dictando algunos estándares y una arquitectura general. Nuevamente, depende completamente de la situación. –
Independientemente de la forma que se mire, usted quiere asegurarse de que hay una cierta redundancia en el conocimiento y la comprensión de cada uno de los desarrolladores de enfocar. Entonces, donde podría centrarme en una característica o capa, hay al menos otro desarrollador con una buena comprensión de mi trabajo. De esta forma, un desarrollador clave que abandona la empresa no puede descarrilar el proyecto completo.
Steve, es tan difícil decir qué es mejor a menos que especifique un objetivo en particular.
Creo que si todas las partes de la tarea se asignan a una sola persona, la tarea se completará más rápido. Esto es porque en este caso podemos ahorrar en la comunicación: explicar la idea de implementación, dividir la tarea en partes, asignar partes a otras personas, negociar responsabilidades, etc.
Por otro lado, si hay muchos especialistas involucrados, puede resultar en de mayor calidad de la implementación (siempre que tenga personas educadas y con experiencia). Pero es más como tomar más tiempo y dinero.
Por último, corresponde a tu para decidir, lo que es mejor : más rápido, más barato o mayor calidad. Para las tareas críticas del proyecto, buscaría la calidad, para las no críticas, buscaría la velocidad.
Estoy seguro de que cuando llegue a organizaciones tales como myspace, facebook y google no puede tener sólo una persona que trabaja en el código.
Creo que la mejor manera de abordar una situación es por registrando y explicando qué trabajo/cambios han realizado.
Por ejemplo, si mi socio trabaja en alguna característica de mi sitio, deberá documentar y explicar en su totalidad los cambios que ha realizado o implementado, y también explicar qué está haciendo su código y cómo se integra en el resto del sistema.
De esta forma, cuando llego puedo ver que ha realizado un cambio en el sistema de la clase Input y que ha explicado cómo ha conseguido uno de los últimos ataques XSS o lo que sea.
Así que cuando leí su código que ya saben:
La parte principal de ser un equipo es la comunicación, por lo que contar con un sistema que proporcione la comunicación sería vital.
Las personas tienden a trabajar muy bien allí porque no hay necesidad de la comunicación. pero a medida que crece y se expande tiene que poder estructurar su aplicación y su equipo, necesita asegurarse de que pueda tener 20 personas haciendo cosas diferentes, pero todos saben lo que está sucediendo dentro de la aplicación, ya que ven un "Registro de cambios". como tal.
Mi opinión es que un equipo es mejor que una persona singular.
Creo que para los equipos pequeños, es normal que los programadores solo hagan la codificación (incluido el desarrollo de la base de datos) y los demás que hagan CSS y otra parte del diseño. Si los programadores son suficientes, pueden separar su trabajo y todos para crear su propio módulo (parte del proyecto) comenzando desde la base de datos y terminando con la incrustación de la lógica y el diseño.
Como dice la gente, depende del proyecto pero la forma en que trabajamos se espera que todos tengan las habilidades básicas en la pila de arquitectura desde la interfaz web, pasando por Java y SQL, y toman áreas funcionales para trabajar en hacer todo cosa.
Eso nos funciona porque la mayoría de nuestras funciones de interfaz y SQL son relativamente simples, por lo que las habilidades de profundidad rara vez se necesitan aquí, y porque nuestro trabajo se fragmenta cuidadosamente en fragmentos funcionales de buen tamaño. Si ese no es el caso contigo, entonces no funcionará.
Como regla general, si esto es posible creo que esto funciona mejor ya que dentro de cada bit de funcionalidad se obtiene a alguien que se centra en el producto final completo y como resultado se obtiene una mejor experiencia de usuario. También reduce las dependencias entre las personas del equipo, lo que significa que es menos probable que la gente pierda el tiempo esperando a que alguien más termine algo.
Las excepciones a esta Me tienden a no perder el tiempo con:
Diseñadores - desarrolladores generalmente producen trabajo web feo y diseñadores general escribir código más pobre. Por lo general, considero que el diseñador es un rol especializado para cualquier cosa donde la interfaz sea clave.
DBA: si tiene una base de datos compleja, quiere un DBA (o al menos un desarrollador con sólida experiencia) para unir todo y mantenerlo sólido. En casos extremos, se pagarán por sí mismos en la optimización que hacen y en el ahorro de hardware.
Pero, por regla general, me gustan los generalistas. Hay excepciones, pero en general no creo que el tipo de sistemas que está desarrollando la mayoría de las empresas tenga un nivel de complejidad que exija, por ejemplo, a un especialista de JBoss que no haga nada más.
Usted debe preguntar a sus empleados lo que les gusta hacer ... y luego, después de hablar con su jefe y los clientes le dirá cada uno a hacer lo que mejor sabe :)
Como cada jefe de proyecto sabe hay un plan y hay una realidad: dos cosas diferentes :)
¿Cuál es su plan: completar un solo proyecto tan rápido, tan rápido y tan bueno como sea posible? O tal vez desee construir un equipo feliz de calidad que MIEGT le brinde mejores resultados y más flexibilidad en el futuro.
Buscar por un momento una respuesta y que mejor que sea sólido antes de continuar y se enfrentan a la realidad ...
Tienen una buena respuesta ... Ahora son atacados con contradiciendo las demandas por su gerente, su cliente, su propio equipo y tal vez por sus colegas. Sus empleados quieren aprender nuevo personal o no aprender en absoluto, a su jefe no le importa quién trabaje, siempre y cuando lo haga en el mismo tiempo y la calidad a la que está acostumbrado de su padrino y su cliente se asegura de acumular la presión a medida que el proyecto se retrasa.
Conclusión:
If you can't remember when the last time you finished a task on time - no buscar aventuras. Este desafío, por prometedor que sea, puede interpretarse y se interpretará como la incapacidad del gerente para hacer su trabajo: "por supuesto, el proyecto falla ... ¡las tareas las realizan las personas equivocadas!"
If you are on top of your duties ... puede preguntarle a sus empleados si quieren romper la rutina y trabajar en diferentes herramientas. Mi conjetura es que después van a dejar de ser sospechoso, que se harán más interesado en el trabajo, más feliz y motivado y descubrir que trabaja para usted abre nuevas oportunidades para ellos ...
humana, por desgracia, no son máquinas, hacen crujidos incluso cuando todo está bien, si el mejor hombre hace un sonido, dale un adelanto de lo que quiere, así que seguirá haciendo el 90% de su proyecto principal.
Yo prefiero la función por desarrollo de características. Principalmente porque si terminas el 80% de las características, tienes una aplicación en funcionamiento, pero si terminas el 80% de las capas, no tienes nada.
Todo se trata de lo que está optimizando. Desarrollar característica por característica le permite obtener una nueva versión más rápido. También lo ayuda a encontrar brechas en su arquitectura donde no es compatible con sus características. Pero requiere que las personas tengan habilidades generales: todos deben poder hacer un pequeño diseño de base de datos, una pequeña codificación de middleware y un pequeño diseño de front-end. No tienen que ser brillantes, pero deben saber cuándo están al límite de sus habilidades y pedir ayuda.
Desarrollar capa por capa le permite obtener el máximo provecho de sus exportaciones, pero se encuentra con algunos peligros. Si su persona de la base de datos no comprende los requisitos del front-end, es posible que su base de datos esté organizada de forma tal que requiera que la interfaz haga muchas consultas. Si su middleware se desarrolla de manera OO, puede tener la "Falta de coincidencia de impedancia" con su base de datos o interfaz. También puede terminar creando cosas en la capa incorrecta, porque "no podemos esperar a que se actualice el middleware, así que lo haremos al principio".
En mi experiencia, siempre hay más cosas que queremos hacer de las que tenemos tiempo. Prefiero el desarrollo característica por característica, porque puedo retrasar las características a la versión 2 y lanzar un sitio útil. No puedo retrasar una capa, dejándome con hojas de programación.
¿Está familiarizado con XP? http://www.extremeprogramming.org/ – roundcrisis
@Miau - No, pero leeré al respecto. Gracias :) – felix