Con este Guideline se busca explicar las competencias que debe tener un desarrollador de rootstack
Establecer las competencias, responsabilidades e importancia de este rol para Rootstack. Acá se definen las herramientas y estrategias de desarrollo que se deben aplicar.
En Rootstack hay desarrolladores, no programadores simplemente porque son capaces de analizar y visualizar el flujo del proceso que llevarán a cabo mediante el código de programación, eso los distingue de un programador común pudiendo caracterizarse por la programación orientada al objeto y la separación de las diferentes etapas lógicas en nivel de presentación, de aplicación y de acceso a los datos siempre enfocado en la calidad del producto.
A parte de todos los atributos de cualquier integrante de Rootstack se espera de nuestros desarrolladores:
Framework:
Frontend
Mobile
Databases
Gestores de base de datos
Integración
Programación
Virtual
Repositorios
Generales
This PR does the following:
- Creates a Photo Gallery component.
### To Review:
- [ ] Checkout this branch
- [ ] Run gulp run -t rebuild
- [ ] Run `lando drush yaml-content-import sites/default/demo_content/
- [ ] Navigate to the demo Photo Gallery and verify that it displays as a slick slider.
- [ ] Verify slideshow has been added to kitchen sink
- [ ] Verify demo content is created.
>NOTE Need to add image style. Held off until you were done renaming those etc.
b. Utilizar GitFlow para este proceso, un buen tutorial lo pueden revisar en https://datasift.github.io/gitflow/IntroducingGitFlow.html
c. Una vez aprobado el PR el TL hace el Merge, el desarrollador debe estar pendiente que si el PR fue aprobado se haga el merge
Han habido muchas frustraciones de varios PM's en Rootstack en los últimos meses porque el ingeniero de software en los proyectos no está probando bien los sistemas que están siendo ejecutados
En reuniones con una nueva compañía de Canada se menciona que la razón por la cual ellos están buscando a otro contratista es que el actual con el cual trabaja tiene ingenieros que no parecen ingenieros ya que no garantizan que lo que se está desarrollando funcione correctamente y los sistemas fallan en cuestiones básicas
Al final la queja real es por la falta criterio y actitud para realizar pruebas de primer nivel, y con esto me refiero a: 1. Que se vea correctamente 2. Que funcione correctamente con base al uso de un usuario normal y las expectativas del task
Las pruebas del segundo nivel que son aceptables en cierto sentido y que hayan bugs menores son: 1. Permisología orientada a los tasks 2. Performance orientado a los tasks (esto no es igual a que haya que re implementar todo el task por que simplemente se tomaron decisiones de arquitectura tontas)
Se les solicita que por favor que revisen su trabajo y hagan pruebas de primer nivel y los que son detallistas con su trabajo ir hasta las de segundo nivel
Al final las consecuencias de no hacerlo a parte de desepeñar mal su trabajo es 1. Esto lleva tiempo 2. costos extra de QA / PM ya que es un flujo ilimitado innecesario porque simplemente no se tiene esta cultura
Durante el desarrollo se mantiene una rutina de trabajo armónica articulada con el equipo de trabajo conformado por el PM , TL, Desarrolladores y QA, en dónde en una fase inicial se consume los requerimientos, son analizados y desglosados en tareas
En el primer encuentro del proyecto, habrá un Kickoff en dónde el PM expondrá el alcance del proyecto y en dónde se desglosa detalladamente cada tarea en colaboración con el TL, es en este momento en donde, con capacidad analítica, se realizan todas las preguntas necesarias para que las tareas queden totalmente claras para poder hacer la proyección de su posible solución, se recomienda:
Según la naturaleza del proyecto, definir cuál es la metodología de desarrollo, esto debe ser definido por el desarrollador y debe ser transmitida al PM para que entienda cuál será la línea procedimental para el cumplimiento de las tareas
Según la envergadura de cada tarea y la curva bien sea de aprendizaje o de ejecución, una vez entendidas y analizadas, el desarrollador debe evaluar si el calendario propuesto por el PM es real o debe ser modificado, es de suma importancia ya que de esto depende el budget y la fecha de entrega del proyecto.
En el marco de la metodología ágil Scrum, se toma de ella que el proyecto se desarrolla adoptando una estrategia de periodos definidos para entregas: Sprint, el PM define el período de cada sprint y el intervalo de las reuniones de equipo (Scrum) para lograr el cometido de cada sprint se debe practicar la siguiente línea ejecución:
1) El desarrollador debe revisar las tareas del sprint
2) Del Sprint, definir las tareas que se ejecutarán durante el día
3) Desarrollarla:
End of day Es una práctica indispensable para un integrante de la organización, esto permite dejar explícita todas las tareas realizadas en el día de tal manera que el PM y las personas responsables están anuentes del estado de cada una de ellas. La práctica sería la siguiente: - 5 minutos antes de cerrar el día enviar un correo con lenguaje claro y sencillo a tu PM con la siguiente información:
1. Asunto: EOD 2. Contenido * Qué trabaje: * Qué terminé: * Cuales fueron los bloqueos: * Qué voy a trabajar: