Desarrollo ... es como una droga: escriben un sistema, lo escriben, porque es apresurado. Y luego, de repente resulta: "pensión alimenticia" debe pagarse. Y cualquier cambio en el sistema conduce a una montaña de errores. Pero incluso a principios del siglo pasado, el gran
Kurt Godel previó esto y
demostró estrictamente que incluso en aritmética carecemos de la inteligencia para expresar todas sus leyes sin contradicciones. Y en programación y aún más, comenzaremos a pisarnos y confundirnos. Lo que, en general, es lo que sucede: la computadora portátil se enciende y se reinicia por la noche, luego las aplicaciones móviles cometen errores y comienzan a caerse del bolsillo y se dispersan, regañan y chirrían en el piso.
¿Y cómo te gustan las versiones beta de moda de todo y todo ahora? Parece que pronto los aviones comenzarán a aparecer en versiones alfa-beta.
¡Pero puede programar sin errores para que el alma se regocije y no solo sea agradable beber cerveza con el cliente, sino también seguro!
En esta serie de publicaciones sobre varios aspectos del desarrollo de software, intentaré crear un conjunto minimalista de valores y reglas que, en primer lugar, se coloquen en la cabeza de la persona promedio y, en segundo lugar, generalmente permitan ... ganar con el menor gasto y tiempo. Hoy, hablemos francamente sobre la recopilación de requisitos para un sistema de software.
Teatro, teatro en todas partes. Pero la industria del desarrollo de software se beneficiará indudablemente si todos los participantes en el proceso se dicen la verdad, en primer lugar, a sí mismos y, en segundo lugar, nadie apoyará las emociones no sistemáticas y el ministerio a Cthulhu.
No necesita ir muy lejos por ejemplos: los modelos de desarrollo abiertos y su éxito (no necesariamente sin fines de lucro) muestran de manera convincente:
- claridad, apertura, coraje
- discusión con la comunidad y el cliente
- identificación y resolución rápida de problemas
así como las comunicaciones más justas basadas en la confianza y el respeto mutuo: lleve al éxito una solución de software, por ejemplo, un sitio web.
El mundo está cambiando activamente. Las comunicaciones horizontales ocurren a la velocidad de la luz, y si no aprendemos cómo usar esta nueva arma, definitivamente perderemos. Pero primero, eche un vistazo.
¿De dónde vinieron las "guerras santas" en la programación?
Todo es simple Es suficiente recordar el curso escolar de geometría. La comprensión científica del mundo en el que vivimos se basa en ... la creencia en "verdades inmutables" = axiomas, por ejemplo, que "las líneas paralelas no se cruzan" o en el número de números primos
en un rango (aunque esto es un teorema, pero el perro funciona, pero nadie entiende por qué).
Es imposible probar el axioma, solo queda creer que siempre funciona. Pero no podemos volar al horizonte de eventos de Black Hole y verificar. Y explique por qué la interacción entre fotones también se transmite mucho más rápido que la velocidad de la luz.
Numerosas teorías científicas usan axiomas para la conclusión lógica de los teoremas, y así nacen libros tan espesos con un cierto período de garantía. Como resultado, y esto ya no es divertido, el Gran Teorema de Fermat se
demostró en los años noventa de tal manera que solo un puñado de aquellos con un excelente nivel de educación especial puede entender la prueba, capaz de palear docenas de páginas de un texto fino con fórmulas bajo un microscopio :-) Por eso continúan busca evidencia "real", simple y hermosa.
Incluso en lo que aparentemente podría ser más simple, aritmética, se hicieron repetidos intentos para poner en orden los axiomas, pero las cosas siguen ahí ...
Del mismo modo, los lenguajes de programación y las tecnologías en las que creamos sitios web, aplicaciones móviles y sistemas de información, de hecho, también representan un conjunto de axiomas o puntos de referencia, que también debe primero "creer" y sobre los cuales se construye la base de la tecnología, pero es imposible demostrar que son ciertas (aunque a veces todavía es posible: intente escribir un sitio web en C ++ y vea cuánto tiempo y dinero pierde).
Por ejemplo, en el mundo de Java / C # y otros lenguajes modernos, estrictamente escritos con autoridad y reputación, con mecanografía estática, solo necesita tomar y "creer" que el mundo consiste en psicópatas, propensos a la violencia y la pérdida de autoidentificación, y por lo tanto un "conjunto de axiomas" hace todo para proteger al desarrollador no solo de sus colegas, sino también de sí mismo (por supuesto, estoy bromeando).
El resultado son sistemas de software que se crean durante mucho tiempo, a partir de hierro y hormigón, que luego se cubren con cientos de pruebas automáticas, y como resultado puede resultar que para cuando se complete la construcción, los requisitos comerciales estén obsoletos por mucho tiempo, las armas nucleares estén prohibidas y se desactive un búnker con paredes de 100 metros. Inmediatamente al museo. Pero a menudo esa percepción del mundo funciona bien, por ejemplo, en el desarrollo de sistemas estrechamente especializados o donde el costo del error es muy alto (bancos, etc.).
En el mundo de los lenguajes dinámicos con mecanografía estricta / no estricta (PHP, JavaScript, Python, Ruby), el conjunto de axiomas es perfecto, de la palabra "completamente", otro:
- estamos rodeados de personas inteligentes que escriben bien y ordenadas de inmediato
- persecución manía (cambiar el tipo de una variable debajo de la lista, acceso a miembros de la clase ocultos por otro desarrollador con una intención "maliciosa", se requiere una refactorización profunda del código, etc.), una enfermedad que debe intentar recuperar rápidamente
- el hardware se está volviendo más barato, por lo que debe compilar el programa solo en partes y luego, si es necesario
- cuanto más código, más errores, por lo que el código debe leerse bien de inmediato, ser claro, conciso y sexy
En el mundo de los lenguajes funcionales, como Haskell / OCaml, debe creer que:
- cualquier tarea puede expresarse por función
- variables, ciclos y mutabilidad - conduce a errores (esto es realmente así)
- programación - para el pensamiento selectivo e inclinado al análisis
Como resultado, en lugar de simples secuencias de comandos de muleta "hechas, comprobadas, decididas y olvidadas", el trabajo científico real comienza en el lugar de trabajo y las búsquedas de las "funciones de Dios" son muy interesantes para expresar el sitio web ... con un conjunto de funciones sin variables, ¡guau!
Por supuesto, exagero, pero no hay humo sin fuego. Aunque en algunas tareas este enfoque funciona
bien, y a
nadie se le ocurrió un enfoque mejor.
"Cruzadas" en la gestión de proyectos de software
En el campo de la gestión de proyectos, la situación está aún más cubierta de tristeza pseudocientífica. Y la razón es bien conocida: una solución obvia, simple y concisa para la frente:
- entender lo que quiere el cliente
- atraer especialistas y evaluar la cantidad de trabajo
- escribir código
en realidad, por alguna razón, no funciona :-)
Los participantes experimentados en los equipos del proyecto son conscientes de que el cliente a menudo, cursi, no sabe lo que quiere, porque está abrumado por las emociones y copió problemas matemáticos en la escuela, lo que finalmente condujo a una "atrofia parcial de la parte del cerebro" responsable de la expresión lógicamente consistente de su pensamientos Tener opos poéticos, dibujos de lápiz labial y notas de acordes de guitarra, en lugar de los requisitos técnicos para el sitio web, especialistas, llorar para no reírse de la impotencia, aumentar las estimaciones de la cantidad de trabajo en un orden de magnitud, introducir un impuesto por insuficiencia, etc.
En estas condiciones de falta de lógica y deseo estrictos, perdóname, usando mi cabeza para su propósito previsto, como si fuera a pasos agigantados, hay terribles abusos no científicos en el estilo de astrología / numerología / pranyozhenie y adivinación en posos de café.
Por lo general, los abusos son explotados activamente por personas muy seguras que pueden convencer bien, que nunca tuvieron el "código" (sí, estoy hablando del Ágil incorrecto).
Dicen que en algunos equipos antes del sprint, incluso los fanáticos más ardientes nos obligan a los ingenieros a, perdón, la terapia de orina :-) Sin embargo, estas "prácticas" en sí mismas a menudo son
creadas por desarrolladores muy experimentados que, como ningún otro, pueden usarlas correctamente.
Aquí me gusta mucho la analogía con los nunchucks: parece un arma simple, pero solo unos pocos pueden usarla correctamente, y la mayoría se lastima, lo siento, ya sabes lo que tú mismo.
Otro mito es la intercambiabilidad.
A veces intentan convencernos de la
intercambiabilidad de los ingenieros . Es bien sabido que para obtener una buena y profunda comprensión de la tecnología de software, debe leer muchos libros,
escuchar una docena de cursos , resolver varios cientos de problemas y participar en cinco proyectos de software, de los cuales al menos uno ha llegado a la meta. A continuación, comienza el experimento, que después de 5 años, al menos, hace del codificador - Especialista.
Por lo general, trabajando constantemente en proyectos, el desarrollador es fluido en uno o dos lenguajes de programación y tecnologías relacionadas. El éxito y el crecimiento profesional de un ingeniero radica precisamente en su estrecha especialización, porque Además de los propios idiomas, es necesario profundizar en las bibliotecas del sistema, que a menudo son muy numerosas y la documentación para ellas es muy extensa.
El problema es que ahora, por alguna razón, está de moda no leer libros, sino googlearlos y descartarlos, sin incluir el cerebro, mientras se masturba mentalmente en redes sociales y notificaciones de teléfonos inteligentes.
Encontrar un verdadero especialista que aprenda sistemáticamente de abajo hacia arriba, lenta pero seguramente, cerrando las brechas en su propio conocimiento, se está volviendo cada vez más difícil. El mercado, desafortunadamente, está lleno de "autodidacta" con ... "manos malcriadas".
Que hacer Valores de supervivencia recomendados
En primer lugar, no hay necesidad de desesperarse y es muy importante no caer en las emociones. Es necesario comprender claramente que el desarrollo es, en primer lugar, las matemáticas rigurosas (generalmente a nivel escolar) y la lógica con las métricas, en las que, usando terver e intuición, debe lidiar con riesgos prioritarios y jefes "húmedos" en la infancia.
Solíamos jugar juegos en línea antes y funcionó bien, así que adelante, solo que en lugar de jefes tendrás proyectos de software y en lugar de errores, ¡zerg!
Siempre es posible y necesario gestionar los riesgos con sobriedad y, por experiencia, si se realiza "sistemática y científicamente", un proyecto de software despegará a tiempo, o rápidamente quedará claro por qué el misil no se inicia y cuál / quién, específicamente, el problema.
En vista de lo anterior, se recomienda que comience a adherirse a los siguientes valores del enfoque empírico-científico cercano, que se entrecruzan estrechamente con el conocido himno al sentido común: "
python zen " y "
manifiesto ágil ":
- Busque la solución más simple y clara
- Cuanto más claro, más correcto
- Se volvió difícil: significa en algún lugar una jamba y debes continuar buscando más
- Arrogancia: de la inseguridad o una infancia difícil
- Las capacidades del cerebro humano son limitadas, especialmente bajo la influencia de las hormonas, y en algunos períodos incluso
- Del alcohol y el tabaquismo: nos estamos apagando intensamente
- Tendemos a olvidar rápidamente incluso lo que sabíamos bien e incluso más recientemente
- Esforzarse por la máxima transparencia y apertura
- Respetarse unos a otros
- Fomentar el ascenso más rápido posible y la discusión de los problemas en el círculo más amplio posible, ideal inmediatamente en todos
- Saca conclusiones y no pises el rastrillo 3.14 veces seguidas :-)
Colección de requisitos
Habiendo aprendido algunos secretos y características de las tendencias en el desarrollo de software, seguiremos adelante con confianza: aprenderemos cómo reunir correctamente los requisitos para el sistema.
¿Puede el cliente pensar en principio?
Nada gracioso, sigue siendo una situación normal. Y el cliente en este contexto es un concepto colectivo. En primer lugar, intente evaluar el nivel de pensamiento lógico y la capacidad de concentrar representantes de los clientes. ¿Con quién vas a trabajar y quién te ayudará? Posibles opciones:
- Partido político Es necesario hacer, por ejemplo, un proyecto web antes de la fecha porque alguien quiere / prometió algo ... Los requisitos son vagos, nadie conoce los detalles, y quién sabía, dejará de funcionar hace mucho tiempo. El proyecto fue aserrado por un equipo que se fue y fue casi imposible entender lo que vieron. En las paredes, cerebros secos de, posiblemente, el suicidio de un destacado programador. El código es malo y frágil, huele de modo que lastima tus ojos. A menudo, en tal situación, intentan encontrar, disculpe, el "sacrificio sagrado", que se puede culpar por los próximos seis meses y ... comenzar a buscar uno nuevo. Sensación de miedo, depresión y supresión de la apertura del proceso con una mezcla de sangre en los labios. La probabilidad de hacer una solución de software a tiempo, aunque pequeña, todavía está ahí, si lo vuelve a hacer en un marco listo con documentación preparada. Por lo general, la única forma y no de otra manera.
- Usted se comunica con los representantes del cliente y comprende que es sinceramente difícil para las personas expresar de manera consistente / formal sus propios pensamientos, que se confunden después de la tercera oración, se repiten y circulan en círculos. Después de 15 minutos de diálogo, comienzan las quejas de dolor de cabeza. Se escucha la risa, el ambiente de la fiesta, la selfie, la vida fue exitosa ... Pero los deseos, en general, son comprensibles y sinceros, solo necesitas ayudarlos un poco para que se besen estrictamente. La probabilidad de despegar aquí es generalmente mayor que en el párrafo 1, pero nuevamente, el uso de la solución en caja más preparada con documentación preparada y escenarios típicos generalmente ayuda.
- El cliente entiende bien lo que quiere y trata de expresar lógica y constantemente sus propios pensamientos y deseos. En esto, es ayudado por un analista que no está confundido, exponiendo los pensamientos de la gerencia y haciéndolos pasar como propios. El equipo del cliente también tiene al menos un experto en su área temática (divertido, pero esta es una situación bastante rara). En este caso, la probabilidad de ayudar y resolver el problema mediante programación es muy alta. Aquí puede participar en el diseño, discusión conjunta del glosario, modelos de objetos, modelos de datos, flujos de datos, escenarios de prueba de carga. Lo más probable es que pueda recopilar los requisitos en un tiempo razonable.
Otro punto importante aquí es construir relaciones tan confiables con el cliente como sea posible, mostrar su apertura y deseo de ayudar al cliente a expresar sus pensamientos con claridad. A menudo, algún tipo de capacitación ayuda, en la que se explica a los representantes de los clientes cómo trabajar con las siguientes herramientas de recopilación de requisitos:
- Glosario General
- Un modelo de datos lógico en el que se introducen relaciones estrictas de multiplicidad entre los elementos del glosario (uno a uno, uno a muchos, muchos a muchos)
- Roles y cadenas de uso que muestran quién usa el sistema y cómo
Alarmas que indicarán problemas inminentes en la recopilación de requisitos:
- los representantes de los clientes traducen las "flechas" entre sí y no pueden conectar las dos palabras, hay muchas emociones: se recomienda escalar el problema lo más rápido posible e ir a un nivel superior; de lo contrario, usted, como un "sacrificio sagrado", se presentará como un regalo para el culto al desastre y licencia de jubilación / maternidad. Trabajar en tales condiciones en Agile es extremadamente peligroso, es mejor escribir requisitos técnicos estrictos y avanzar en pequeños pasos
- los representantes de los clientes responden al estilo de: oh, te duele la cabeza, pero eres inteligente, un "programador", así que hazlo bien. Aquí debe exigir la búsqueda de un experto en el área temática, responsable de las respuestas en nombre del cliente y lo antes posible. O vea el párrafo anterior.
- prefieren no hablar de problemas (código ilegible, falta de documentación para los principales procesos comerciales), porque se gastó dinero, se recibieron posiciones, se expresaron bonificaciones y se expresaron los riesgos que pueden llevar a una limpieza intensiva del personal (sin embargo, todos "entienden", y aquí los ingenieros hacen girar el barril): es difícil dar consejos aquí, actuar sobre el clima real
En los casos clínicos anteriores, nuevamente, el desarrollo de una solución box / cloud lista para usar con documentación preparada ayuda mucho. Tal enfoque reducirá los riesgos de cambios repentinos en el curso en 180 grados por orden de magnitud. Pero las garantías ya son menos.
En el caso de un enfoque adecuado por parte del cliente, un deseo de aprender y comprenderlo, un deseo sincero de lanzar un proyecto a tiempo y desarrollarse más, el uso simultáneo de varias plataformas tecnológicas ayuda mucho. El diseño ya no da miedo: siente que el cliente comparte la responsabilidad de reunir los requisitos con usted al 100% y puede intentar hacerlo bien. Usted - se aseguran mutuamente y juntos luchan con la complejidad:
- Sitio web PHP con marco, solución en caja
- análisis predictivo en Python
- una aplicación móvil, ya sea en una única plataforma que funciona en todas partes, o escribimos para cada dispositivo
¡No pierdas el tiempo!
Si durante 2-3 semanas, en casos extremos, un mes y medio, no pasa la sensación de que estás participando en la obra "chatea con una mirada inteligente y toma tiempo y pon todo en alguien", tira de la grúa, prende fuego al tren y grita fuerte a grito: "¡Vayan a casa, niños! el rendimiento ha terminado ".
En serio, organice una reunión con la gerencia del cliente e insista en incluir empleados adecuados en el equipo del proyecto, que comprendan en detalle cómo funciona el negocio y puedan responder preguntas estrictamente formuladas por los ingenieros. O renuncie, a veces este es el paso correcto: guarde su cara y crezca como especialista.
Lista de verificación
Como resultado, podemos considerar que el proceso de recopilación de requisitos fue exitoso y tiene sentido continuar si, junto con el cliente, pudo preparar los siguientes artefactos en un par de semanas:
- Glosario que enumera 50-150 términos de dominio
- Modelo de datos lógico con relaciones de término del glosario.
- Casos de uso con términos del glosario
- Para algoritmos complejos: diagramas de flujo o diagramas de actividad de UML
- Interfaces del sistema de software que no contradicen lógicamente los elementos anteriores
- Se decidió por un conjunto de axiomas que describen su actitud hacia el mundo = eligió la tecnología de software. Aquí, muchos, debido al amor a la creatividad, se sienten atraídos por el sado-masoquismo y el deseo de reinventar la rueda: luchar contra este deseo. Decida: o todo el mundo está lleno de trucos sucios y psicópatas y crea un búnker que puede resistir un ataque de ovnis, o los desarrolladores sinceramente quieren ayudarlo. La mejor tecnología y un conjunto de axiomas: un marco desarrollado o una solución de caja lista para usar: los riesgos de no despegar disminuirán en órdenes de magnitud (en la experiencia, el 95% y los proyectos superiores despegan)
- Te perdiste el sistema de software a través del cliente, a ti mismo, a través de tu cerebro, y en ninguna parte hay manchas de barro o granizo emocional. Si hay lugares potencialmente malcriados (y esto, por regla general, siempre sucede), inclúyalos en el plan de gestión de riesgos y expréselos en cada reunión del proyecto. Y espera que te enmarquen y asegúrate de preguntar cómo te lo perdiste
Si no se pudieron recopilar los artefactos anteriores para el período especificado, y solo hay documentos que cubren el quinto punto, como el "lápiz labial" TK vago, los analistas no van a cooperar entre sí, no se esperan expertos en el área temática del lado del cliente, los problemas se silencian y reina la atmósfera del escaparate y "Solo buenas noticias": empaca tus cosas: lo más probable es que no te dejen volar, la exploración de la luna se pospone por un período de tiempo indefinido y estás en una representación teatral no se dispersará ".
Para lograr un verdadero éxito, es muy, muy importante amar verdaderamente los sistemas de software, rendirse al máximo para reunir los requisitos y el diseño, desear un comienzo temprano, beber cerveza con un cliente, confiar en los demás y repetirse constantemente las palabras de
Edsger Dijkstra : “la simplicidad es la clave fiabilidad "!
Con la llegada de todos y sinceramente les deseo buena suerte en la implementación de proyectos de software.