Cómo
desarrollamos en Besy
|
|
Los
equipos de desarrollo en Besysoft
se administran con Jira(R), utilizan
las técnicas Ágiles
en el proceso de desarrollo y en la gestión de
proyectos. Los métodos usados son Kanban
y Scrum.
Kanban es
un marco de gestión de proyectos que se basa en
tareas visuales para gestionar los flujos de
trabajo de forma contínua y flexible, usa
columnas que muestran en qué etapa se encuentra
la tarea, pero no hay intervalos de tiempos ni
roles fijos.
Scrum
es un marco de gestión de proyectos que ayuda a
los equipos a estructurar y gestionar su trabajo
mediante un conjunto de valores, principios y
prácticas. El desarrollo se divide en Sprints
(intervalos de tiempos fijos), que puede durar
de 1 a 4 semanas y apunta al producto o a una
parte específica. Las tareas del Sprint se
planifican y se dividen entre los miembros del
equipo. Durante el Sprint, hay pequeñas
reuniones diarias (Daily
Meetings) en los que cada miembro del
equipo habla sobre las tareas que realizó ayer y
realizará hoy. Reuniones
periódicas del equipo según las
necesidades del proyecto y del equipo. Una
sesión de demostración
para discutir las tareas realizadas y resumir
las restantes, también es
donde se expone el trabajo realizado en
el Sprint que acaba de finalizar.
Evaluación retrospectiva
de la finalización del Sprint, que tiene 3 ejes:
- Start
doing: son las cosas que no hacemos y
debemos comenzar a hacer.
- Stop
doing: Son las cosas que estamos
haciendo y deberíamos dejar de hacer.
- Continue
doing: Son las que venimos haciendo
bien y debemos continuar haciéndolas.
|
Proceso de
desarrollo
Existen
procedimientos que los desarrolladores
de Besysoft
deben conocer para ajustarse al marco
del SGC. El
objetivo de los procesos es dar una
secuencia de tareas a realizar por
los diferentes roles, a fin de
generar una producción eficaz y
eficiente del producto que cumpla
con los requisitos del Cliente.
Se consideran tres
flujos importantes; el Proceso de
Desarrollo, la Ejecución del
Sprint y el Desarrollo Atómico.
Alcance del
proceso en esta publicación
|
|
|
Desarrollo
El
proceso comienza con la propuesta
de solución aprobada, el Scrum
Master realiza el alta en el
Product Backlog, dejándolo
actualizado. El Product Owner
prioriza el Backlog, Operaciones
ejecuta el proceso de Ejecución de
Sprint. En la salida de ese
proceso se evalúa si existen aún
historias y de quedar pendientes,
si no existen cambios en las
historias el Product Owner
actualizará el Backlog con las
prioridades correspondientes.
Operaciones vuelve a
ejecutar el Sprint y si a su
salida existen cambios, pasará por
el proceso de Gestión de Cambios,
donde se volverá a priorizar el
Backlog y seguir con la ejecución
del Sprint. Si terminamos con
todas las historias y ya no
existen cambios, se pasa a la
Entrega de Producto, verificando
el cliente si cumple con los
criterios de aceptación, si no
cumple o cumple pero con cambios,
volverá al proceso de gestión de
cambios, en caso contrario
finaliza el proceso.
|
|
Ejecución
del Sprint
Comienza con el Product
Backlog actualizado y
priorizado, se debe planificar
el Sprint (sesiones de Planning)
termina en el Backlog del
Sprint, una vez que se tiene el
Sprint identificado, cada
miembro del equipo se autoasigna
y por cada una de las historias
o tareas que tenga ejecuta el
proceso de Desarrollo
Atómico y la salida
será esa porción de código,
documento o entregable que es
alcanzado por esa tarea, ahí es
donde se pregunta si se alcanzó
el fin del Sprint de ser no
vuelve a iterar hasta completar
las tareas del Sprint, cuando
termina el Sprint se verifica si
se tienen nuevas historias, pues
cuando se hace la Demo al
cliente siempre se hacen
sugerencias y eso genera nuevas
historias, si las hay se
actualiza el backlog como
entregable,si no hay más
historias se hace la
Retrospectiva y termina el
proceso con la salida del sprint
que es un "incremento" (puede
ser un conjunto de documentos o
una porción de código
funcionando) y termina.
|
|
|
|
Desarrollo
Atómico
Es la mínima unidad de todo proceso
de desarrollo.
Es el proceso que regula cada tarea que
se tiene que hacer dentro del Sprint,
comienza con el ticket asignado de la
tarea / historia que se tiene que
realizar, se debe hacer un análisis para
saber si está bien explicado lo que se
tiene que hacer funcionalmente, se
pregunta si tiene un diseño validado la
solución, si lo tiene validado se avanza
sino se diseña y valida, es muy
importante la parte de validación. En la
validación de los diseños pensando en lo
que se va a hacer enmarcado en la
arquitectura del proyecto es donde
también se valida la posibilidad de
reutilización de código. Luego de esta
validación se debe especificar un plan
de acción, puede que ya venga
especificado o no, si no está
especificado se debe anotar. Luego del
diseño pasamos a la instancia del
desglose en tareas más pequeñas con el
plan de acción, se organizan en
subtareas de ser necesario. Todo debe
estar estimado.
Una vez definida la estimación y el plan
de acción se verifica si tiene los
criterios de aceptación correspondientes
y luego se definen o revisan los casos
de pruebas en los 3 niveles, es opcional
aquí usar el tipo de ticket TEST
EXECUTION o TEST DEFINITION, si durante
las pruebas se encuentran errores se
deben generar los ticket de tipo ERROR.
Dentro del proceso de desarrollo no hay
del tipo INCIDENTE, pues es sólo para el
proceso de soporte.
Se codifica se hacen los casos de
prueba, el desarrollador ejecuta los
casos de prueba y si no se presentan
errores lo pasa a control cruzado de
control de calidad. El Test Execution es
la evidencia de la prueba.
|
|
Operaciones: En
la Wiki, en el panel de "Besyoft
SGC / Operaciones",
se listan todos los artefactos
que los desarrolladores deben
conocer:
- OPR-IN-Buenas
Prácticas de Nombrado de
Versión
- OPR-IN-Gestión
de Proyectos en JIRA
- OPR-NOR-Protocolo
de Emergencia Operativa
- OPR-PL-Burnup
- OPR-PL-Checklist
Técnica de Proyecto
- OPR-PRC-Elaboración
de Informe de proyecto
mensual para PMO
- OPR-PRC-Investigación
y Desarrollo de
Productos y Soluciones
- OPR-PRC-Procedimiento
de Gestión de roadmap de
producto
- OPR-PRC-Procedimiento
para análisis de impacto
- OPR-PRO-Desarrollo
- OPR-PRO-Desarrollo
Atómico
- OPR-PRO-Ejecución
del Sprint
- OPR-PRO-Entrega
de Producto
- OPR-PRO-Gestión
del Cambio
- OPR-PRO-Propuesta
de Solución
- OPR-PRO-Soporte
|
|
|
Fuentes:
https://wiki.besysoft.com/pages/viewpage.action?spaceKey=SGC&title=Operaciones
https://wiki.besysoft.com/pages/viewpage.action?pageId=74481981
https://www.sundevs.com/blog/kanban-scrum-which-is-the-right-methodology
https://maddevs.io/blog/jira-scrum-or-kanban/
|
|
|
Para saber si ha sido efectiva
esta información te solicitamos
realices la siguiente encuesta:
|
|
Próxima
entrega: Buenas prácticas de
desarrollo
|
|
|
|
