Work methodology

Utilizamos una estrategia dinámica y flexible para el desarrollo de los proyectos, procuramos el bienestar de nuestros desarrolladores y de todos aquellos que participen, así como se espera la mejor actitud con el equipo y la más alta calidad de trabajo para poder ofrecer a los clientes software de calidad, intuitivo y seguro.

Projects

La empresa define sus actividades en “proyectos” cada parte activa participa en un proyecto, incluso la administración de la empresa es un proyecto. Cada proyecto tiene un inicio y un final definido ya sea por fechas o por entregas las cuales quedarán definidas desde un inicio.

Existen proyectos de diferentes escalas, por lo cual cada proyecto se divide en módulos y/o submódulos buscando que estos sean lo más independientes posibles para que cada desarrollador tenga la oportunidad de trabajar en un módulo a la vez, para lograr esto se deberá tener en consideración en todo momento aquellos elementos que son GLOBALES dentro del proyecto para mantener la consistencia del desarrollo y no repetir trabajo.

Project products

Los productos del proyecto son definidos en un documento llamado "arquitectura del sistema” donde los desarrolladores podrán observar todos, estos productos que integraran la solución del proyecto.

Product modules

Los productos serán divididos a su ves en módulos los cuáles seran asignados para su desarrollo.

DEVA Agile

DEVA implementará las siguientes partes de la matodología SCRUM:

  • Organizaciones diarias
  • Sprints
  • Product demos
  • Roles
  • Sprint Retrospective

Se tendrán dos diferentes niveles de perspectiva para la aplicación de la metodología, donde una perspectiva es a grandes rasgos con el cliente y otra a detalle con el equipo de desarrollo, esto quiere decir que se establecerán sprints con el cliente y cada uno de estos sprints será un proyecto de desarrollo el cuál manejará varios sprints con metas definidas para cumplir con entregas y posteriormente se realizará la integración para pruebas.

Para cumplir con esta tarea se utilizará un sistema organizador de tareas donde habrá un tablero por cada proyecto y una lista de tareas por cada “producto o etapa” del proyecto los cuáles generalmente son:

  • Diseño y planeación: Serie de tareas para poder dar inicio al desarrollo.
  • Pruebas y Entregas: Son las iteraciones del desarrollo donde cada iteración contiene una serie de pruebas y retroalimentación.
  • Desarrollo Mn: Son los productos de proyecto ej. [Desarrollo landing, Desarrollo API, Desarrollo Admin] cada “producto” contiene los módulos del sistema que le corresponden.
  • Despliegue y Entrega Final: Especificaciones de pruebas por cada iteración
  • Seguimiento: Es opcional para sistemas que requieren mantenimiento

Test-driven development

Cada parte en la que se trabaje deberá tener pruebas para validar que lo que se requiere se está cumpliendo.

Equipos de trabajo

Los equipos de trabajo se formarán de acuerdo al projecto, cada equipo contará con un administrador el cuál se encargará de estar en constante contacto con el equipo y coordinar las reuniones y entregas del proyecto, sin embargo se busca en general que cada quien peuda trabajar individualmente en tareas pequeñas teniendo en cuenta que la mayoría de las propiedades estarán ya definidas en las documentación facilitando la integración.

Calidad y tiempos

La calidad se logrará con el uso de los diferentes estándares internos los cuales serán definidos más adelante, siempre se deberá buscar la mejor práctica tomando en cuenta los recursos del sistema, la experiencia de usuario y la seguridad como ejes de decisión.

Forma de trabajo

Los equipos deberán reunirse al iniciar el proyecto y al menos una vez a la semana de forma donde todos puedan verse y platicar sobre su experiencia.

Podrán trabajar desde forma remota cada desarrollador que se encargue de un módulo, en caso de que son más de un desarrollador los asignados a un módulo deberán tener una reunion extra en la semana para acordar avances y mantener una comunicación constante para el desarrollo del módulo.

Diario se deberá hacer un pequeño reporte en una reunion individual con el administrador del proyecto para checar avances y resolver problemas.

Roles

Para el desarrollo de los proyectos se contará con los siguientes roles:

  • Vendedor: El cuál tiene la definición del proyecto y estableció los lineamientos de la solución
  • Arquitecto: Junto con el vendedor define a detalle todos los elementos técnicos del proyecto
  • Administrador del proyecto: Es quien organiza al equipo y se encarga de verificar que las pruebas sean correctas así como la integración final.
  • Desarrrollador: Es quien se encargará de realizar el código y actividades necesarias para lograr la funcionalidad de cada módulo y submódulo del sistema

Horarios

Entregas

Pagos

Al finalizar cada módulo de trabajo se realizará el pago de este módulo en caso de ser módulos menores a una semana de trabajo se acumularán con los siguiente módulos para lograr mínimo una semana de trabajo.

Start working Pipeline

  • Cuentas de usuario
  • Capacitacion desarrollo web
  • Capacitación angular y/o tecnologías web
  • Capacitación metodología de trabajo
  • Ambiente de desarrollo
  • Ambientes de frameworks
  • Tips y trucos

AGILE & Methodology

La metodología a seguir durante los proyectos será parecida a SCRUM y seguiremos los valores y principios de AGILE.

SCRUM REFERENCE CARD
What is Agile Methodology? -> YOUTUBE
AGILE MANIFESTO

Values and principles (AGILE)

The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.

  1. Individuals and Interactions Over Processes and Tools The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

  2. Working Software Over Comprehensive Documentation Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function. The Agile Manifesto values documentation, but it values working software more.

  3. Customer Collaboration Over Contract Negotiation Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.

  4. Responding to Change Over Following a Plan Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.

  5. Adapt continuously

  6. Document continuously. Documentation is made throughout the life-cycle, in parallel to the creation of the rest of the solution.
  7. Document late. Documentation is made as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
  8. Executable specifications. Requirements are specified in the form of executable "customer tests", instead of non-executable "static" documentation.
  9. Single-source information. Information (models, documentation, software), is stored in one place and one place only, to prevent questions about what the "correct" version / information is.

The Twelve Principles are the guiding principles for the methodologies that are included under the title “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs.

With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.

The twelve principles of agile development include:

Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes. Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams. Enable face-to-face interactions – Communication is more successful when development teams are co-located. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change. Simplicity – Develop just enough to get the job done for right now. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products. Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.

Reference