Guideline de Desarrollo

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:

• Productividad
• Creatividad
• Sea analítico
• Criticidad
• Autodidacta

• Esperamos que el desarrollador tome decisiones inteligentes durante el desarrollo de las tareas de su sprint. Si cree que hay una forma distinta/mejor de hacer las cosas, que lo comunique. No queremos robots sino seres pensantes que puedan agregar valor a los procesos en los que estén involucrados.
• Esperamos que la calidad del trabajo sea alta en todo momento. Los errores y bugs son inevitables por la naturaleza del trabajo pero no queremos encontrar bugs obvios a primera vista, no queremos encontrar código con “chacalerias”. Esperamos que puedan dar lo mejor de sí en función a su nivel. Y estar siempre orientados a la mejora continua.
• De acuerdo a la posición que mantengan en el equipo así mismo se les va a exigir. Ej, no esperamos a un senior hacer errores de juniors. Por algo son seniors.
• Aceptar y ser responsable por los propios errores y tener la capacidad para solucionarlos, o en su defecto, tener la actitud, interes y compromiso de conseguir la solución e implementarla.
• Poseer conocimientos tecnológicos en los diferentes sistemas operativos (Linux, MacOS, Windows,etc.)
• Poseer conocimientos en los diferentes lenguajes de programación como C, Java, Python, JavaScript, Scala, Go, Angular, HTML5, node.js, MongoDB, Openstack, entre otros.
• Tiene una alta capacidad de abstracción y lógica para poder desarrollar las soluciones con la mayor calidad y mejor tiempo posible.
• Debe poseer un vocabulario amplio, y una buena capacidad lectora porque el desarrollo no solo se relaciona con códigos sino con un vocabulario necesario para nombrar, etiquetar y generar contenidos e igualmente documentar lo que se está desarrollando.
• Debe tener desarrollada la capacidad crítica y analítica para detectar aquello que para otros puede pasar desapercibido, los detalles de proceso, estructura, etiquetas, seguridad y funcionalidad.
• Debe ser autodidacta en muchos sentidos. En algunos casos para obtener información relacionada con cualquier tema de interés ya que los desarrollos abarcan cualquier área de la vida y para poder desarrollar una solución es necesario conocer el contexto de la problemática.
• Debe estar dispuesto a la constante auto superación y/o actualización de su base de conocimiento.
• Debe ser flexible y adaptable a los cambios, la mayoría de los proyectos de desarrollo experimentan cambios necesarios para ajustar lo más posible las soluciones a los requerimientos.
• Tener sentido de orientación dentro de los requerimientos de los deadlines.
• Tener el enfoque de las tareas y tickets que se deben completar.
• Tener comunicación productiva con su equipo, PM, tech lead y compañeros.

• Cumplir con los lineamientos de desarrollo de Rootstack y del cliente en caso que se requiera.
• Probar su código a conciencia y no simplemente saber que funcionó. Se debe probar bien antes de mandar un código o de solicitar un MR.
• Cumplir con los lineamientos de hacer PR’s.
• Tener sus herramientas bien configuradas.
• Si hay un factor visual en la tarea, que probar bien en distintos navegadores que se vea bien.
• Analizar las especificaciones de software y de hardware necesaria para atender la solución de la tarea.
• Analizar los requerimientos y realizar un flujo para la solución.
• Generar prototipos (demos) verificables para que el PM pueda validar los requerimientos.
• Ser capaz de definir su arquitectura de trabajo idónea dependiendo del proyecto (framework, hardware, lenguaje de programación entre otros)
• Generar la documentación necesaria de lo que va desarrollando, esto permite que el código generado pueda ser reutilizado por otros.
• Ser analítico en las pruebas de código, no sólo de funcionalidad sino en la experiencia del usuario, esto evitará costo de tiempo e incomodidades.
• Generar sin falta la Documentación para los usuarios del software desarrollado.
• Saber comunicar si existe algún bloqueo que le impida realizar sus asginaciones.

1. Lo primero que se debe tener claro es que el IDE de desarrollo que se va a utilizar para ejecutar un proyecto debe ser el mismo para todos en su tipo y versión. Por ejemplo, si se está desarrollando PHP el IDE de desarrollo utilizado en Rootstack es PHPStorm v. 2018.2.4. A continuación se muestra una lista de herramientas utilizadas en Rootstack:

   Framework:

   1. Symfony
   2. Drupal
   3. Laravel
   4. Nodejs
   5. Postman

   Frontend

   1. Angular
   2. React
   3. Sass
   4. Gulp

   Mobile

   1. React Native
   2. IOS: Swift
   3. Android: Java
   4. Ionic

   Databases

   1. Mysql
   2. Mongo
   3. Oracle
   4. Postgresql

   Gestores de base de datos

   1. Sequel pro
   2. MySql Workbench
   3. Phpmyadmin

   Integración

   1. Mulesoft

   Programación

   1. Atom
   2. Vs code
   3. PHP Storm & codesniffer phpstorm
   4. Line Text

   Virtual

   1. Virtualbox
   2. Docker

   Repositorios

   1. Bitbucket

   Generales

   1. skitch
   2. BrowserStack
2. En segundo lugar se debe tomar en cuenta que el código debe estar en inglés al igual que los comentarios del código esto permite que cualquier otro programador pueda utilizar / modificar el código. Ej. En Rootstack ha habido la experiencia de trabajar con personas que hablan mandarín, portugués etc. con un código generado en inglés así como sus comentarios, el idioma no seria una barrera
3. En tercer lugar la base de datos la debe solicitar a infraestructura principalmente
4. En cuarto lugar el manejo del repositorio debe ser estándar:
   a. Un PR debe estar bien documentado para que quien revise el PR sepa de qué se trata. Ej:
   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
   

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:

• Tomar notas de las observaciones importantes
• Pedir toda la información necesaria referente a las validaciones y relaciones de las tareas
• Tener el documento o los requerimientos / Tareas del proyecto, tener el Roadmap del proyecto
• Haber leído y analizado los requerimientos y el roadmap previamente a la reunión para saber si es realizable o no en los tiempos estipulados así como también prever cualquier tipo de necesidad, bien sea, intelectual o de recursos
• Preparación del entorno de trabajo: sabiendo en qué consiste el proyecto y las tareas que deben ser ejecutadas, se debe preparar el entorno necesario para poder desarrollarlas, esto significa adecuar las herramientas de trabajo:
  • Instalar aplicaciones de desarrollo (framework, ides de desarrollo, etc.)
  • Preparar el servidor de desarrollo
  • Adecuar los recursos de hardware
• Definir la gestión de logs para trazabilidad y agilidad de las pruebas

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:

• Si existe algún tipo de inconveniente, bloqueo o curva de aprendizaje que consuma un tiempo mayor a 1hr. Debe ser notificado para su pronta ayuda ya que esto acarreará una deuda de tiempo que se puede convertir en inmanejable
• Evitar la pérdida de tiempo con otras actividades ajenas al proyecto, o que no respeten las hr. Que fueron destinadas para el proyecto
• Si hay un entregable (PR) pasar al QA para su revisión
• Realizar los commits en Bitbucket
• Actualizar la herramienta de gestión (Jira) cambiando el estado de la tarea y/o realizando las observaciones a la tarea
• Revisar si hay algún bug reportado para su corrección según estos pasos
• Identificación y registro de la incidencia
• Análisis de la incidencia.
• Intervención sobre la incidencia.
• Seguimiento y control de la incidencia.
• Propuestas de mejora.

   1. Asunto: EOD
   2. Contenido
    * Qué trabaje:
    * Qué terminé:
    * Cuales fueron los bloqueos:
    * Qué voy a trabajar: