Quizás, después de leer este artículo, se sorprenda pensando que estoy escribiendo sobre cosas comunes que todo el mundo sabe. Pero en 10 años he cambiado sólo 3 empresas de TI, en dos de las cuales estas prácticas "banales" no se utilizaron en su totalidad, el proceso de desarrollo de software sufrió mucho por esto. Además de mi experiencia personal, me inspiraron para escribir el artículo las historias de analistas que conozco que trabajan en el campo de las tecnologías de la información y casi todo el mundo se enfrenta a problemas organizativos y de comunicación que necesitan y pueden resolverse.
Durante los últimos 3 años he trabajado como analista de sistemas en el grupo de empresas InfoWatch y en este artículo quiero compartir con ustedes las prácticas de trabajo con requisitos que utilizamos. La empresa desarrolla productos empresariales para mitigar los riesgos de seguridad de la información, proteger y analizar los datos corporativos. Para tales productos, se establecen altos requisitos en cuanto a su confiabilidad, rendimiento, tolerancia a fallas, así como requisitos para la certificación. Debido a las peculiaridades del mercado de la seguridad de la información, nuestras soluciones no están basadas en la nube, sino que se instalan in situ en el cliente. Por lo tanto, trabajamos en un modo de lanzamiento grande varias veces al año. Para alcanzar el objetivo asignado y acortar el tiempo de lanzamiento, trabajamos de acuerdo con los principios establecidos en la metodología Agile.Para comenzar el desarrollo, no preparamos requisitos del sistema absolutamente detallados, sino que comenzamos con una descripción de alto nivel de los aspectos más importantes de la nueva funcionalidad. Es decir, tomamos decisiones que sobre todo afectan el volumen y la complejidad de las mejoras y proporcionamos al equipo de desarrollo la información necesaria para comenzar a trabajar en el diseño de la arquitectura y escribir código (para funciones pequeñas). Luego, en el curso del desarrollo, detallamos gradualmente los requisitos y los llevamos a un nivel de detalle suficiente para escribir casos de prueba detallados. Este enfoque le permite no perder mucho tiempo para comenzar a trabajar y reducir el riesgo de que los requisitos tengan que ser modificados significativamente si surgen nuevas limitaciones técnicas.que sobre todo afectan el volumen y la complejidad de las mejoras y brindan al equipo de desarrollo la información necesaria para comenzar a trabajar en el diseño y codificación de la arquitectura (para funciones pequeñas). Luego, en el curso del desarrollo, detallamos gradualmente los requisitos y los llevamos a un nivel de detalle suficiente para escribir casos de prueba detallados. Este enfoque le permite no perder mucho tiempo para comenzar a trabajar y reducir el riesgo de que los requisitos tengan que ser modificados significativamente si surgen nuevas limitaciones técnicas.que sobre todo afectan el volumen y la complejidad de las mejoras y brindan al equipo de desarrollo la información necesaria para comenzar a trabajar en el diseño y codificación de la arquitectura (para funciones pequeñas). Luego, en el curso del desarrollo, detallamos gradualmente los requisitos y los llevamos a un nivel de detalle suficiente para escribir casos de prueba detallados. Este enfoque le permite no perder mucho tiempo para comenzar a trabajar y reducir los riesgos de que los requisitos tengan que ser modificados significativamente si surge alguna nueva limitación técnica.suficiente para escribir casos de prueba detallados. Este enfoque le permite no perder mucho tiempo para comenzar a trabajar y reducir los riesgos de que los requisitos tengan que ser modificados significativamente si surgen nuevas limitaciones técnicas.suficiente para escribir casos de prueba detallados. Este enfoque le permite no perder mucho tiempo para comenzar a trabajar y reducir los riesgos de que los requisitos tengan que ser modificados significativamente si surge alguna nueva limitación técnica.
Si su proceso de desarrollo es similar al nuestro, o si desea pasar a este proceso combinado, lo más probable es que las prácticas que se describen a continuación sean adecuadas para usted. Pero incluso si tiene un proceso diferente, es probable que las prácticas presentadas le sean útiles. En cualquier caso, le sugiero que se familiarice con ellos, especialmente si trabaja como analista de sistemas en una empresa de TI.
Los requisitos para el producto que se está desarrollando es el área principal de responsabilidad de un analista de sistemas. Las prácticas que se describen a continuación tienen como objetivo simplificar la gestión de requisitos y, como resultado, simplificar el proceso de desarrollo de productos:
- documentación y control de versiones;
- notificación de cambios;
- revisión;
- mítines / reuniones / estados;
- discusión / solución de preguntas abiertas;
- registro de discusiones;
- validación de nueva funcionalidad;
- presentación de nueva funcionalidad.
Requisitos de documentación y control de versiones
Es conveniente cuando la descripción del producto en forma de requisitos funcionales y no funcionales se fija en un documento, los requisitos se desglosan por áreas funcionales, se interconectan por agrupación, transiciones a través de enlaces, etc. Cuando cualquier cambio en el marco de la descripción de características o como resultado de defectos de reparación se refleje en la versión correspondiente de los requisitos.
El control de versiones de los requisitos es el mismo que para el producto en sí, lo que le permite ver el aumento de la funcionalidad con cada nueva versión. Y también obtenga acceso rápido a la información sobre cómo funcionaba esta funcionalidad en versiones anteriores y por qué se modificó.
En algunas empresas es necesario dedicar mucho tiempo a obtener dicha información, ya que es necesario revisar todas las tareas que están asociadas a una determinada funcionalidad, profundizar en su descripción y visualizar comentarios. Por cierto, una forma más rápida de obtener la información que necesita es pedirle al desarrollador que observe los cambios en el código, pero en este caso no solo le llevará su tiempo, sino también el tiempo del desarrollador, lo que le costará a su empleador. más. Describir los requisitos en un solo lugar le permite no solo encontrar la información de interés, sino también comprender de inmediato el contexto.
Usamos Confluence, que es una herramienta útil que puedes modificar un poco por ti mismo. Un colega mío habla de nuestra experiencia con Confluence en detalle en su artículo “ Cómo utilizamos Confluence para desarrollar los requisitos del producto ". Curiosamente, muchas empresas de TI tienen esta herramienta, pero no todo el mundo la usa para documentar los requisitos del producto.
Notificación de cambios en los requisitos
Es una buena práctica notificar a todas las partes interesadas sobre los cambios en los requisitos, lo que también le permite monitorear cuándo y por qué razón se cambiaron los requisitos. Si anteriormente dije que es importante reflejar en los requisitos todos los cambios como resultado de la reparación de defectos, entonces aquí estamos hablando de notificar al equipo sobre estos cambios.
Es importante comprender que los requisitos son los datos que los equipos de desarrollo, los equipos de prueba y los redactores técnicos utilizan para su trabajo, y que cualquier cambio en los requisitos debe estar respaldado en la implementación, los casos de prueba y la documentación.
Si no se notifica a los equipos involucrados, es probable que se enfrenten a los siguientes problemas:
- la implementación puede no cumplir con los requisitos;
- ;
- .
Hasta hace poco, nuestro equipo de analistas notificaba a todos los interesados sobre los cambios en los requisitos de la siguiente manera: después de realizar cambios en los requisitos, dejaban un comentario sobre el problema, enviaban una carta que contenía un enlace al problema, un enlace a los requisitos y una breve descripción de los cambios. A fines del año pasado, automatizamos este proceso: finalizamos el seguimiento de problemas (usamos JIRA) y ahora, luego de realizar cambios en los requisitos, en la tarea en la que se realizaron estos cambios, hacemos clic en el botón "Notificar sobre cambios ", seleccione los equipos interesados y haga una breve descripción de los cambios:
Captura de pantalla # 1 La
carta que se genera automáticamente después de hacer clic en el botón" Enviar alerta "tiene la siguiente presentación y contiene toda la información necesaria:
Captura de pantalla 2
Además de la carta, en el problema queda un comentario con información similar.
Revisión de nuevos requisitos
Es obligatorio revisar los nuevos requisitos por parte de los líderes de todos los equipos involucrados en el desarrollo de la función. No estamos hablando de cambios dentro de los defectos, sino de una funcionalidad completamente nueva, cuya descripción está realizando. Obtener comentarios es extremadamente útil, ya que pueden surgir las preguntas adecuadas que ayudarán a revelar en detalle las posibilidades de la nueva funcionalidad. Cuando desarrolla un pensamiento en una dirección durante mucho tiempo, identifica una necesidad, problemas, desarrolla diferentes conceptos y describe una solución dentro del marco del producto, el ojo puede volverse borroso y puede parecer que hay cosas obvias que funcionan. no tiene que fijarse en los requisitos. La revisión ayuda, incluso a través de preguntas de especialistas que se sumergen en el tema a través de la información que reciben en los requisitos, para comprender qué puntos deben aclararse o divulgarse.La revisión también ayuda a afinar la claridad de la redacción, a hacer cambios para que todos los interpreten sin ambigüedades.
Para hacer esto, también mejoramos el rastreador de problemas, agregamos un tipo separado de tarea de "Revisión", que es lanzada por el analista responsable de cada función en todos los líderes de equipo. Los gerentes de forma independiente o delegando en sus subordinados hacen la revisión de los requisitos, hacen preguntas o aclaran a través de comentarios y acuerdan los cambios realizados.
Captura de pantalla n. ° 3
Rallies / reuniones / estados
Las reuniones diarias del equipo que trabaja en la función es un gran evento para equipos pequeños, siempre que utilicen sprints frecuentes. De lo contrario, las reuniones diarias ocuparán el tiempo de todo el equipo y no serán de ninguna utilidad. Sin embargo, no debe abandonar por completo las reuniones, solo debe determinar correctamente la frecuencia de su celebración. Y luego puede mantenerse al tanto, comprender si el equipo se está moviendo en la dirección correcta en la implementación del concepto concebido, así como identificar en las primeras etapas los problemas que se pueden resolver o las limitaciones que deben acordarse.
Naturalmente, al desarrollar requisitos, debe comunicarse con el equipo, ya que puede aprender mucha información útil. Los momentos importantes que suceden en algún lugar de la “caja negra” pueden influir en gran medida en el concepto de nuevas características del producto, la comunicación con los colegas ayuda a llamar la atención sobre los momentos que son interesantes para sus roles. Por ejemplo, la comunicación con los probadores permite tener en cuenta escenarios alternativos que se planean probar en los requisitos, y es importante que inicialmente se establezcan y se tengan en cuenta en el desarrollo, y no se descubran durante la fase de prueba. .
Discusión / solución de preguntas abiertas
Me gustaría destacar la comunicación por voz como un tema aparte, ya que considero importante tener una comunicación en vivo, porque en las nuevas realidades no hay forma de discutir los temas cara a cara.
Los mensajeros se utilizan con más frecuencia, son adecuados para la correspondencia personal, en la que puede usar sonrisas, gifs, etc. para expresar sus emociones. Pero para las actividades laborales esto no es del todo aceptable y, como resultado, queda un texto seco sin rostro. eso es difícil de interpretar para el destinatario, porque la percepción de este texto depende del estado de ánimo de la persona, su actitud personal hacia ti, su implicación en el diálogo y otros factores que no dependen de ti.
Por eso, prefiero resolver las cuestiones en la discusión "por voz", es decir, llamar y discutir, para acordar algo. La llamada le ayudará a averiguar si entendió correctamente el contexto, a hacer preguntas de inmediato y obtener respuestas. La voz transmite entonación, permite colocar los acentos adecuados, prestar atención a lo realmente importante. Además, la comunicación por voz ahorra tiempo a todos los participantes y le permite concentrarse en un tema específico, ya que la comunicación por voz (y no el chat) requiere participación y comprensión para resolver el problema.
Registro de discusiones
Es absolutamente habitual y obligatorio que todos registren las discusiones de las decisiones con el cliente en forma de un TdR, que se deduce repetidamente "al grano" y se acuerda por todas las partes interesadas. Quiero llamar su atención sobre el hecho de que además de la documentación oficial en desarrollo de software, la fijación escrita de acuerdos puede ser útil no solo en el marco de la comunicación "cliente - desarrollador", sino también dentro de la empresa / equipo.
Practicamos la comunicación del equipo de registro cuando discutimos los conceptos de la solución y la funcionalidad del sistema. Dado que al trabajar en una función pueden surgir varias soluciones, de las que es necesario elegir una, naturalmente, surgen preguntas para el equipo, que, de hecho, se discuten en reuniones.
Como regla, mantenemos el protocolo en formato de pregunta-respuesta. El protocolo también justifica por qué se eligió tal solución, se registra quién tomó estas decisiones y quién las coordinó. Pero es importante entender que este es nuestro documento interno utilizado en nuestro trabajo, el cual no está regulado por nada ni por nadie. El acta registra una discusión sobre un tema específico y en una fecha concreta, es decir, es necesaria para entender por qué se tomaron o rechazaron determinadas decisiones, qué cuestiones en general surgieron y cuáles de ellas están cerradas, y cuáles requieren investigación para obtener una respuesta ... Esto es importante porque en el modo multitarea es difícil mantener toda esta información en su cabeza, además, todos los miembros del equipo interesados deben conocer y tener acceso a esta información. Además, después de mucho tiempo,puede volver a leer este protocolo y encontrar respuestas a sus preguntas, o tal vez tenga nuevos pensamientos basados en las respuestas. O una vez más se asegurará de la exactitud de la solución elegida.
La validación significa verificar que la funcionalidad implementada cumpla con los requisitos comerciales. Antes del inicio de las pruebas funcionales, el analista responsable de la función realiza la validación: comprueba si se ha implementado el escenario principal y si el comportamiento del sistema cumple con las expectativas. Esta es una práctica importante que debe usarse justo antes de la transferencia de la funcionalidad para la prueba, ya que si el script principal no se ejecuta, entonces no tiene sentido verificar otros casos. Para realizar la validación, se redacta un escenario de aceptación, que contiene los pasos que se deben realizar y la respuesta esperada del sistema para finalmente resolver el problema de negocio para el cual se desarrolló la funcionalidad. En el marco de la validación, es posible identificar, en primer lugar, la falla del escenario principal, las molestias de la interfaz de usuario, así como los defectos funcionales graves.Si se ejecuta el escenario principal, la función se considera validada y se puede enviar para su prueba. La prueba ya es más detallada, de acuerdo con los casos de prueba, verifica la funcionalidad implementada.
Presentación de nueva funcionalidad
Otra práctica interesante, en mi opinión, es la presentación de la funcionalidad antes de escribir casos de prueba o emitir una función para probar. La presentación está dirigida a los artistas intérpretes o ejecutantes que no están inmersos en el contexto como lo están sus líderes, porque no participaron en las etapas de elaboración de la solución. Como regla general, esta es una historia corta sobre qué escenarios básicos y alternativos para la resolución de problemas se implementan, qué configuraciones en el producto deben realizarse, qué características tecnológicas tiene esta solución y qué limitaciones. Como resultado, se forma una comprensión general de las nuevas funciones del producto y se eliminan una serie de preguntas que pueden surgir para una persona que no está inmersa en el contexto.
Después de probar la funcionalidad, antes del lanzamiento oficial del comunicado técnico, realizamos una presentación y demostración de la nueva funcionalidad para los empleados de los departamentos que están implementando el producto en el cliente. Esto hace posible obtener comentarios, designar características y limitaciones preliminares, anunciar el mayor desarrollo de la funcionalidad. Es importante que todos tengan un entendimiento común de la nueva funcionalidad y no tengan falsas expectativas.
Arriba, describí una pequeña lista de prácticas que mis colegas y yo usamos en nuestro trabajo. Los encuentro útiles, así que los comparto y quiero recomendarle que cree un proceso para trabajar con requisitos utilizando estas prácticas. En los próximos artículos, planeamos hablar sobre la parte sustantiva del trabajo con requisitos, con más detalle sobre qué prácticas usamos para identificar las necesidades / problemas de los clientes y formular soluciones que los cubran por completo.
Si tiene preguntas o desea compartir su experiencia, deje sus comentarios.
Autor: Venera Abbyasova AbbyasovaVenera
* Todas las imágenes del artículo están tomadas de acceso abierto en Internet.