¿Qué agregaría en esta Lista de verificación del proyecto de desarrollo de software? [cerrado]

Soy un gran admirador de las listas de verificación. Hay una lista de verificación de viaje , Lista de verificación de mudanzas e incluso una Lista de verificación de Scrum .

Contexto : ha sido contratado por una gran corporación y se le ha dado la misión de configurar todo el entorno de desarrollo de software, procesos, equipo, etc. Tiene "carta blanca". Usted será responsable de la creación de los incrementos de trabajo del software. Tamaño del proyecto: 2000 hombres / días.

Qué elementos agregaría a la siguiente lista de verificación (intencionalmente pequeña e incompleta):

• Instalar un servidor de integración continua
• Escribe un DoD
• Escriba una guía de codificación de una página
• Crear una cartera de productos
• Instalar un sistema de seguimiento de errores
• Programar tiempo de cara regular

* 1.) ¡Habla con los desarrolladores para ver lo que realmente necesitan! * *

2.) Investigue una solución para abrir múltiples entornos realmente rápido (piense en instancias de nube públicas o privadas o máquinas virtuales anticuadas si no cumple con las palabras de moda)

3.) Fuente / control de versiones

4.) Sistema de revisión de código (Crucbile / Fisheye como ejemplo)

5.) Pared Kanban (o algo similar)

6.) Protocolos de comunicación (el chat en tiempo real es una gran ventaja), los wikis también fomentan la colaboración. Esto también cubre las relaciones públicas internamente: ¿cómo va a relacionarse con los propietarios de su negocio, el personal de soporte técnico y otros grupos?

7.) Pizarras electrónicas

8.) Ambiente cómodo para desarrolladores (sofás, mesas, áreas de descanso, buena conexión WiFi, etc.)

9.) Gran café !!!

• Configuración de la cadena de herramientas: IDEs, servidor CI, servidor de calidad de código, control de fuente, servidor web, bases de datos, rastreador de problemas, etc.
• Copias de seguridad : ¿qué rol tiene cada persona en el equipo? ¿Qué procesos / módulos posee y quién es su respaldo?
• (Aceptación del usuario) Entorno de prueba Configuración del : no solo integración continua w. pruebas unitarias, pero pruebas de integración para cubrir las cosas realmente malas, múltiples plataformas, servidores de aplicaciones, máquinas virtuales, etc.
• Configuración de las pruebas de rendimiento : cuanto antes mejor, ya que necesitará datos históricos para responder "¿Con qué característica / hito el rendimiento bajó tanto?"
• Esquema de documentación (usuario final) : ¿qué va a estar en la documentación? ¿Qué tipo (s) de documentación se necesita?
• Canales de comercialización : ¿cómo se anuncian los hitos internos y los lanzamientos externos? ¿Tiene un nombre genial para el software, un logotipo, colores, texto, etc.?
• Comunicación interna : ¿cómo se informará a los compañeros de otros equipos sobre los cambios? ¿Cómo se está haciendo la colaboración? Wiki? ¿Derechos de acceso?
• Aseguramiento de la calidad de personas y procesos: ¿quién va a probar qué, con qué frecuencia y con qué criterios?
• Proceso de publicación : cuándo, con qué frecuencia, cómo, quién lo hace, quién recibe la publicación, etc.
• Gestión de riesgos : el peor de los casos (desde un punto de vista de gestión de proyectos y un punto de vista de tiempo de ejecución, por ejemplo, 'el cliente está perdiendo dinero porque el software falló en el módulo X, ¿cuál es el plan de respaldo?)
• Asegurar el entorno de desarrollo central, por ejemplo, virtualizarlo para Escrow
• Lugares para reuniones formales e informales.
• Entrenamiento o introducciones para todas las personas, para que sepan qué es toda la configuración, para qué sirve cada parte y cómo la usan.
• Identificar al cuidador y darle todas las cosas (por ejemplo, permisos) que necesita para cuidar cuando las cosas van mal

Revisiones post mortem : dado que está trabajando en cosas en bloques, programaría una revisión de una o dos horas (dependiendo del tamaño del equipo) para tener una reunión cara a cara (si es posible) donde todos vayan y digan qué se hizo bien, qué podría hacerse mejor, y lo que no era necesario. Ser capaz de aprender de sus errores en el proceso de desarrollo temprano significa que puede evitar cometerlos más adelante cuando no tenga tanto tiempo para trabajar.

Comencemos por contratar un buen equipo de los profesionales adecuados para su proyecto. En una aplicación comercial típica, necesitaría contratar a un desarrollador de bases de datos y un dba, una persona de control de calidad, un administrador de sistemas, analistas de negocios, desarrolladores de aplicaciones, un especialista en interfaz de usuario y líderes de equipo como mínimo. DBA, administrador del sistema, analistas de negocios y control de calidad deben estar en una cadena de informes separada del equipo de desarrollo. El especialista en bases de datos de desarrollo debe informar al mismo líder técnico que los desarrolladores de aplicaciones y el especialista en IU.

Configurar el espacio de la oficina. Las oficinas privadas son geniales si puede obtenerlas (le deseo mucha suerte con esto), pero en un mínimo necesita escritorios, teléfonos, computadoras, pizarras y un par de salas de conferencias dedicadas. Asegúrese de que haya un lugar para el almuerzo, un refrigerador, refrescos, refrigerios y café disponibles. Refrescos y café gratis aún mejor.

Configure servidores dev / qa / staging y prod para la aplicación y las bases de datos. Las bases de datos nunca deberían estar en el mismo servidor que las aplicaciones. Dependiendo del tamaño y el alcance del proyecto, es posible que necesite varios servidores o SAN, etc. para cada entorno.

Tan pronto como se configuren los servidores, programe copias de seguridad del sistema de archivos, la base de datos y los registros de transacciones de la base de datos. Haga esto el primer día que se arreglen las cosas. Contrata una empresa como Iron Mountain para realizar copias de seguridad fuera del sitio semanalmente.

Configure un sistema de control de origen y cree un documento que describa cómo se utilizará. No olvide insistir en que TODOS los cambios estructurales de la base de datos y las inserciones de datos para las tablas de tipo de búsqueda estén en scripts en el control de origen. Esto facilitará la implementación.

Compre software comercial o descargue software de código abierto para el conjunto de herramientas que decidió utilizar con licencias para todos los usuarios pertinentes.

Compre máquinas para desarrolladores que griten rápido y que tengan dos monitores. Compre al menos una máquina de usuario de prueba que gime lentamente y sea típica de lo que los usuarios tendrán en sus escritorios.

Entrene a sus nuevos desarrolladores en cómo desea que se hagan las cosas. Si tiene un equipo lo suficientemente grande como para tener algunos desarrolladores junior, entonces programe capacitación adicional para ellos e incluya el tiempo en la planificación de su proyecto. Monitoree a los jóvenes muy de cerca por al menos tres meses. Monitoree de cerca a todos los nuevos empleados durante el primer mes. Deshágase de Deadwood y desarrolladores rebeldes lo antes posible.

Determine qué debe hacerse en qué orden (la ruta crítica). No asigne tareas al final de la ruta crítica hasta que se completen las tareas de las que dependen.

Crear planes de prueba y requisitos.

Establezca reuniones de progreso programadas regularmente con los clientes. Merecen saber qué estás haciendo y cuáles son los obstáculos. No dejes de decirles cuándo llegarán las cosas tarde. Si faltan tres semanas para la fecha límite y ya sabe que la perderá, ese déficit no desaparecerá mágicamente antes de que tenga que avisarle al cliente. Asegúrese de que el cliente sepa que los requisitos adicionales significan costos y tiempo adicionales y que cada requisito adicional tendrá que eliminar otras tareas o la fecha límite cambiará por la cantidad de horas en las nuevas tareas. Dejar esto en claro desde el principio le ahorrará mucho dolor y horas extra y costos excesivos absorbidos por su grupo y no por el cliente.

Configure un entorno para la prueba de rendimiento, no solo la velocidad de un usuario, sino uno en el que pueda probar la cantidad esperada de usuarios simultáneos. No espere para hacer esta prueba hasta el día anterior a su lanzamiento.

En la planificación del proyecto, suponga que el control de calidad encontrará errores y que llevará tiempo solucionarlos. No programe el control de calidad solo por un día al final.

Cree datos de prueba que sean aproximadamente del tamaño que cree que tendrá la base de datos. Haga que todos los desarrolladores prueben su código con la base de datos de este tamaño. No permita que los desarrolladores solo desarrollen en una pequeña base de datos en sus máquinas personales. Esta es una causa frecuente de código que funciona bien hasta que llega a producción.

Planifique recompensas en el presupuesto. Desmotiva a las personas cuando trabajan duro durante meses y solo los gerentes obtienen bonificaciones. También diga gracias con frecuencia y por escrito.

Es posible que necesite un sistema de gestión de proyectos o al menos configurar hojas de cálculo para rastrear lo que necesita rastrear. Al hacer la planificación del proyecto, no asuma más de seis horas al día como persona en su plan. Esto ayuda a tener en cuenta el tiempo que no se dedicará al proyecto, como vacaciones, enfermedad, vacaciones, reuniones de recursos humanos, revisiones de rendimiento, etc. Si sabe que el proyecto se encuentra en un período de alta indisponibilidad (por ejemplo, un proyecto que se ejecuta del 1 de noviembre al 1 de enero en los EE. UU.), es posible que deba hacer asignaciones adicionales para más vacaciones y vacaciones. No es justo esperar que los desarrolladores renuncien a sus vacaciones y vacaciones y nadie puede predecir cuándo sucederán cosas como tiempo de enfermedad, servicio de jurado, tiempo de duelo, etc. Suponga que sucederán con su equipo en este proyecto.

Algunas cosas que no veo en la pregunta y las respuestas posteriores:

• Plan de recuperación en un desastre. ¿Cómo está haciendo una copia de seguridad de los cuadros de desarrollo, puesta en escena, pruebas, etc.? ¿Todos los desarrolladores tienen lo que necesitan para trabajar desde casa en un día de nieve ocasional? Etc.

• Plan de entrenamiento. ¿Cuántas semanas de año de entrenamiento necesitan sus desarrolladores para mantenerse al día? ¿Alguien lo está rastreando? (Una hoja de cálculo puede ser suficiente para la mayoría de los equipos). Tenga un mecanismo para que denuncien (enviar a alguien un correo electrónico diciendo que vieron 2 horas de transmisiones web sobre "lo que sea" probablemente sea suficiente) y para que la administración planifique, por ejemplo, a quién debemos enviar a qué Conferencia este año.

• una posición de herramienta. ¿Es este un "le damos a todos una suscripción a MSDN; no instale nada más en sus máquinas de trabajo" o "queremos su código pero no nos importa lo que use para editarlo, compilarlo y probarlo " tipo de lugar. Tomar y registrar la decisión.

• tanta ALM integrada como pueda soportar o pagar. Por lo general, la razón de la "falta de coincidencia de impedancia", la doble entrada, la superposición de herramientas y la integración de la aplicación de silla giratoria es que el sistema creció poco a poco. A partir de cero, desea demostrar que su gente puede permanecer en una sola herramienta durante todo el ciclo. No escribir código en X, compilar con Y, probar con Z, cambiar el estado del elemento de trabajo / tarea con A, informar el tiempo que pasaron con B, decirle a la persona que estaba esperando que ahora pueden continuar con C, tratando de calcular averiguar qué hacer a continuación con D, medir el progreso general con E, etc.

Negociar más días-hombre.

Es un evento raro cuando las personas asignan suficiente inicialmente.

[Más tarde ... renegociar aún más ...]

Como he tenido el mayor problema con las bibliotecas de terceros y su uso:

1. Determine las bibliotecas y versiones que va a utilizar.
2. Cree el proceso de integrar actualizaciones de la biblioteca a su proyecto.
3. Asegúrese de que los desarrolladores estén todos a bordo de las opciones de biblioteca.
4. Cree un canal beneficioso para la discusión abierta sobre las tecnologías que se utilizan.

¿Por qué? No puedo decirle la cantidad de veces que las bibliotecas de terceros (propietarias) han tenido errores graves que nos enviaron semanas de tiempo de desarrollo porque no teníamos ningún proceso para subir o bajar. O tratando con desarrolladores que dicen "¿qué versión usaste? ¿Por qué usaste funciones marcadas como obsoletas?"

Un gran costo para las organizaciones no es asignar presupuesto a la seguridad durante todo el ciclo de vida del desarrollo, esto significa que la seguridad generalmente termina después del hecho de que un conjunto de actividades o controles ineficaces y costosos se implementan demasiado tarde para hacer mucho bien.

Obtenga seguridad incorporada desde el plan inicial del proyecto, con hitos clave, lo mismo que lo haría con todos los demás aspectos del desarrollo, y use un proceso iterativo para mantener actualizada la guía de seguridad. El cierre definitivo de la seguridad debería ser una comprobación sin sorpresas de que todos los controles de seguridad se implementaron según el diseño.

De lo contrario, terminará ejecutando la seguridad después de la implementación, donde podría costar entre 8 y 10 veces más (cifras de Gartner, IBM y otros), molestará a las personas, ya que es probable que la funcionalidad se vea afectada y que sea demasiado tarde para evitar la explotación y daños.

1. Llévalo al equipo

¡Pregunta a los programadores! Realmente, eso es lo más importante. Encontrará mucha resistencia si los desarrolladores no están directamente involucrados en este cambio. Después de todo, se trata de la forma en que funcionan, no usted. No hace falta decirlo, pero tratar de forzar métodos y herramientas en las personas generalmente es contraproducente.

2. Inspeccionar y adaptar

Haga que el equipo descubra la mejor manera de trabajar, utilizando su experiencia para ayudarlos gentilmente a seguir el camino elegido. Luego, regularmente y en colaboración, mire hacia atrás sobre cómo están (ellos) y adapte el proceso para mejorarlo.