En 2018, se reimprimió el libro "Desarrollo de requisitos de software". Los colegas me enviaron un enlace a la publicación. Los autores agregaron técnicas para trabajar en proyectos ágiles, determinando el papel del analista y recomendaciones para la automatización. Hay
críticas extremadamente
conflictivas en la Web. Pedí un libro y resolví la pregunta.
Pros
Todo esta pintado
Los principiantes obtendrán una comprensión completa del trabajo del analista. Los profesionales recordarán lo que ellos mismos enfrentaron. Se analizan todas las etapas de creación de especificaciones. El Apéndice B contiene un manual compilado sobre la base del principio de solución de problemas. La tabla de contenido en sí misma actúa como una pista. Las listas de verificación detalladas se encuentran en casi todos los capítulos. Por ejemplo, una plantilla de especificación incluye 8 cláusulas, 24 subcláusulas y dos apéndices. Guia integral.
Información fácil de encontrar
La información está claramente estructurada y esto facilita la búsqueda del libro. La tabla de contenido está escrita en 9 páginas. Rápidamente encuentra el escenario y la explicación correctos. En cada capítulo hay referencias a otros capítulos, si alguna pregunta se describe allí con más detalle. Al final del manual hay un glosario de términos, por lo que no puede tener miedo de frases como "UML", "ciclo de vida del proyecto en cascada" o "matriz CRUD". En un par de minutos hay una versión en PDF de ediciones anteriores, puede usar la búsqueda de documentos si necesita datos específicos.
Para todos en TI
Los analistas entran en contacto con todos los involucrados en el proyecto: clientes, diseñadores, desarrolladores, evaluadores, vendedores, soporte y usuarios del producto. Y cada grupo debe saber cómo correlacionar adecuadamente los términos de referencia con lo que están haciendo. Un empleado inexperto puede preguntar algo como: "¿Y dónde está escrito para nosotros que cuando hace clic en este elemento no debe pasar nada?" Si lee el libro, responderá a esta pregunta y dejará comentarios razonables sobre el documento.
Explicación de términos
Es difícil leer el manual por costumbre, pero después de la página 700 se hace más fácil :) En el curso de la presentación, cada concepto se da entre paréntesis su original en inglés. Esto es conveniente porque el traductor no siempre es preciso y puede abrir Wikipedia en inglés. Al final del libro hay un glosario de términos con explicaciones. Es cierto que no todos los conceptos se encuentran en el manual. Para complementar la lista, tuve que agregar 50 nuevas frases y números de página a mano.
Contras
Verbosidad
Los autores abusan de largas oraciones e información innecesaria. Debido a esto, el significado es más difícil de atrapar.
"Las herramientas de administración de requisitos lo ayudan a rastrear los requisitos, lo que hace posible identificar relaciones entre diferentes tipos de requisitos, entre requisitos en diferentes subsistemas y entre requisitos individuales y componentes del sistema relacionados (como diseño, módulos de código, pruebas y documentación del usuario)".
Leo Tolstoi, ¿y tú?
"... los métodos de comunicación pueden proporcionar una sincronización efectiva en tiempo y espacio dentro del equipo".
Y en el flyleaf está escrito que este es un manual, no un tratado filosófico.
"Diagrama de estado para el estado de los pedidos de alimentos".
Los autores no repiten dos veces, no repiten.
"Stephen Withall (2007) describe muchos esquemas para documentar con precisión los datos (también llamada información)".
Datos = Información. ¡Y hay algo en eso!
Y ese ruido semántico en todo el libro. Existe la sospecha de que a los autores se les pagó por las líneas.
Errores gramaticales
En el curso de la lectura, los conté más de 160. Todos los errores dentro del currículo escolar. Por ejemplo: se omiten las palabras, se usa "-tsya" en lugar de "-tat", las oraciones se repiten en un párrafo, se encuentran errores tipográficos comunes, se omiten las comas, se confunden los conceptos que se escriben de manera similar.
El primer error ocurre tan pronto como abres el libro. Chris no tiene megalomanía, simplemente la confundieron con Karl, quien le dedicó un libro. Ellos son esposos
¿Cómo te gusta esa frase?
"Rediseñe el sistema para un mejor procesamiento de las reglas comerciales volátiles que eran un soporte complejo para el proyecto".
Colocación de producto
En el curso de la presentación, los autores mencionan repetidamente los productos de Microsoft. Son tan famosos que no tiene sentido escribir sobre ellos. Y cuando es necesario nombrar los sistemas de gestión de requisitos (SUT), los autores guardan silencio sobre ellos. Solo leo este capítulo por su bien. El libro acaba de ser lanzado por Microsoft Press, mientras que los "blandos" no tienen un SUT completo. La lealtad de la empresa superó la deuda profesional.
Subestimación
Por ejemplo, en el Apéndice B, los autores proporcionan un ejemplo de documentación de requisitos. Escriben que los clientes deberían poder cambiar las suscripciones. Pero no se dice sobre la creación de suscripciones. ¿Cómo puedo cambiar algo que aún no se ha creado? Se saltó la fase inicial.
O se indica que el sistema debería permitir al cliente especificar un método de pago. Pero no está escrito sobre la confirmación del pago. ¿Cuál es el punto de indicar cómo desea pagar si no se puede confirmar el pago? Perdí la etapa final.
Los pasos restantes se detallan en la aplicación con cierto detalle. En este contexto, los eslabones perdidos en la cadena de opciones dejan una sensación de subestimación. Está claro que las aplicaciones se dan como ejemplo, pero aún así.
¿Qué es relevante para Rusia?
Antes de leer, pensé algo como esto: “¿Qué puede aconsejarnos un estadounidense? Tienen todo en números, y no hay problema ". Resultó que los problemas son casi los mismos.
Sin cultura de respeto por los requisitos.
Como dijo un desarrollador familiar: "No leo TK, pero inmediatamente escribo código". Este no es un enfoque equilibrado. La implementación no está coordinada con las partes interesadas, no se están estudiando opciones adicionales y se pasan por alto las comunicaciones con otros elementos. El riesgo de error y su precio aumentan. Si el usuario encuentra un error después del lanzamiento, su precio aumenta 21 veces. En la etapa de TK, eliminarlo es mucho más barato. Pero si bien las compañías no toman en serio la especificación, se "querrá lo mejor, pero resultó como siempre".
Sin requisitos comerciales
Los requisitos comerciales describen por qué una organización necesita un sistema, es decir, objetivos que una empresa pretende lograr con él. Pero si nos fijamos en las empresas rusas medianas, se obtiene una impresión extraña. Algunos no entienden por qué producen, mientras que otros no entienden por qué compran. Pero las ambiciones se inflan y apuestan por los sellos en Instagram. Sucede que te comunicas con otro genio de Skolkovo, y él impone apasionadamente necesidades imaginarias a sus clientes. Como resultado, la compañía se ve como un vegetal, y el presupuesto se ve como un cubo de basura.
"Adjuntar" al diseño
Esto es imposible, porque después del rediseño, debe editar el TK. Esta es una pérdida de tiempo innecesaria. La especificación no necesita ser dependiente del diseño. Deje que los diseñadores tengan la opción de implementar este o aquel requisito. Por ejemplo, el elemento de control "Eliminar" se puede representar como un botón, icono, enlace, deslizar o elemento del menú contextual. Es mejor describir esto a través de funciones y circuitos, en lugar de interfaces. No "el sistema muestra una lista desplegable", sino "el sistema ofrece una opción".
No hay comprensión de los detalles del analista.
Por ejemplo, en una empresa, los analistas han ampliado las responsabilidades. Se les indicó que informaran a las autoridades sobre cuándo se implementa este o aquel requisito y quién lo aplica. Si hubo un retraso, descubrieron por qué. La tarea se transfirió por etapas y se nombraron personas responsables de otros departamentos. Como resultado, la parte de contenido sufrió. Todo lo descrito es responsabilidad del gerente del proyecto. El gerente es responsable del intercambio de información sobre el proyecto, el analista es responsable del intercambio de información sobre el producto. Estas son dos líneas de negocio diferentes.
No se utilizan herramientas.
Un jefe quería que aquellos que trabajan con TK los conocieran cerca del texto. Esto no es realista. La compañía tiene varias decenas de conocimientos tradicionales, y su número está aumentando. Si usted mismo terminó de redactar TK hace un mes, todavía lo olvida, porque luego se sumerge en 2-3 nuevos. El problema se resuelve no debido a la memoria, sino a la implementación de sistemas de gestión de requisitos (SUT). Apoyan la identificación, gestión, seguimiento y retiro de requisitos. Pero hay que pagar por ellos, y los empleadores prefieren trabajar a la antigua usanza, como en un dicho:
Dos soldados del batallón de la construcción reemplazan la excavadora.
Y una de las fuerzas aerotransportadas los reemplaza doblemente.
Post scriptumEscribí a los editores de una versión del libro en ruso sobre los errores y les sugerí que los arreglaran. La solicitud fue leída, pero el personal no respondió. Por eso consideran que el analfabetismo es la norma. Esto es triste porque el original es bueno.
Conclusión
El libro deja una impresión controvertida debido a su desorden. El contenido es alto, pero la forma no lo es. Esto es desalentador. Pero si un especialista quiere desempeñarse como analista, tendrá que entender lo que los autores querían decir. No es fácil, pero el tiempo invertido lo vale, y te respetarás un poco más.