Supuestos y principios del desarrollo de la nube

Centrarse únicamente en los productos

[Hipótesis]

La experiencia del producto es la reina, el boca a boca gana, de lo contrario es basura (los clientes o el mercado son los únicos criterios de evaluación), pero los desarrolladores a menudo solo se centran en la lógica del código, mientras que los pilares técnicos a menudo solo se centran en el modelo de marco, sin una experiencia profunda y requisitos detallados desde la perspectiva del usuario, y siguen ciega o indiferentemente el diseño del producto. De hecho, el diseño de producto en sí es una exploración repetida, un proceso de prueba, error y experimentación. El diseño del producto en sí es un proceso de exploración repetida, prueba y error y experimentación, formando así varias barreras entre el desarrollo y el diseño del producto. En el proceso de demostración repetida de errores, la contradicción entre producto y desarrollo se intensifica aún más, y la crueldad de. el producto es La evolución crea la atmósfera de la materia.

[Principio]

Toda la atención debe centrarse en el producto

Desarrollo fluido impulsado por la interacción

[Supuesto]

Objetivamente hablando, los productos crecen incrementalmente y lo que obstaculiza este proceso es el modelo de desarrollo tradicional que necesita bloquear una versión específica, es decir, un desarrollo específico impulsado por la demanda, un tiempo, lugar y personal específicos. desarrollo de productos. El proceso de comunicación y retroalimentación está ahogado por las barreras de la interacción intermitente, y mucho menos del cambio bajo demanda.

[Principio]

El tiempo, el lugar y la persona para la comunicación y la retroalimentación no están restringidos

Iteración extrema

[Supuesto]< / p>

No tiene sentido simplemente evaluar la velocidad del desarrollo del software y la fase de lanzamiento del software desde la perspectiva del tiempo y el costo, aunque la prueba y error con las capacidades de comunicación y retroalimentación debe iterarse lo más rápido posible en el menor tiempo posible. y la versión más económica, también es imposible tomar una decisión sobre cómo proceder. Si bien existe un mandato cada vez más claro de iterar lo más rápido posible, desde versiones de prueba y error que permiten la comunicación y la retroalimentación hasta versiones estables de valor fundamental, la cuantificación de la velocidad de iteración es vaga y el final de cada iteración está influenciado por otras partes del proceso no mantener el ritmo crea una interrupción masiva, que no es un desencadenante eficaz para que comience la siguiente iteración.

[Principio]

Repetir rápidamente para garantizar una comunicación y retroalimentación continua

Extremadamente simple

[Hipótesis]

La simplicidad es a menudo la más fácil de entender. Sólo comprendiendo la simplicidad podemos desarrollar, utilizar, promover, mantener y desarrollar mejor un sistema de software suficientemente "simple". ", suele ser el más estable y eficiente, y sólo se pueden utilizar las cosas más simples y estables; al mismo tiempo, la simplicidad a menudo requiere la menor cantidad de trabajo y hacer menos es lo mejor, porque los requisitos no son necesariamente claros. y la ocasión No es necesariamente necesario, y su uso no es necesariamente controvertido. Las demandas inestables deben posponerse tanto como sea posible. Después de todo, la comprensión de las demandas por parte de los desarrolladores y el crecimiento del sistema también son un proceso. en un solo paso, de lo contrario fácilmente generará grandes disputas y problemas de calidad. Pero, ¿qué es la simplicidad? La escala de cada uno es diferente, ¡y la forma simple no es simple! p>La verdadera simplicidad debe ser simple hasta el punto de la brutalidad, y no hay límite para ella. Simplicidad de personal específico, número de personal y detalles técnicos

Control de calidad de la tracción a las cuatro ruedas

[Supuesto]

Si el modelo de programación tradicional no tiene especificaciones y capacitación claras, el código debe seguir la ley de Murphy: todo debe revertirse cuando llega a su extremo, y la inercia personal y profesional de los codificadores agotamiento, falta de coraje para salir adelante y abnegación, el código del programa a menudo tiene mucho olor a calidad y los requisitos adicionales de velocidad ignorarán muchos riesgos potenciales desde el punto explosivo del producto. La revisión del código tradicional requiere mucho tiempo y requiere mucho trabajo; Intensivo y es difícil tener en cuenta todos los aspectos. La revisión mutua no se puede implementar debido a problemas de responsabilidad y derechos. Al final, después de repetidas iteraciones, es imposible continuar refactorizando y perdiendo el control del producto. p>

[Principios]

Cuatro aspectos incluyen restricciones automáticas explícitas en las especificaciones de software, penetración perfecta del monitoreo de calidad estándar, acumulación transparente de pruebas de finalización de código, eliminación de dependencias en el mismo subcódigo y control de calidad del código autónomo

Seguimiento automático de la calidad

[Supuesto]

Con cualquier cambio introducido, inevitablemente existirán errores independientemente de su tamaño, y es posible que no ser causado directamente por los desarrolladores.

Puede que no sea causado directamente por los desarrolladores. Está profundamente oculto y lleno de peligros. Por lo tanto, si no hay las medidas correspondientes para confirmar cualquier cambio en el código, el desarrollador promedio perderá la confianza hasta que pierda el coraje para cambiar.

[Principio]

Cualquier cambio de código debe contar con controles de calidad automatizados completos e informes de seguimiento de calidad

Reutilizar sincronización y moderación

[Hipótesis ]

Aunque la reutilización es la forma fundamental de mejorar la calidad, la reutilización de baja calidad puede conducir fácilmente a la introducción de problemas graves. El resultado final es inútil. Una vez que la reutilización se combina con la innovación, es más fácil volverse demasiado innovador. Una pequeña cantidad de uso suele ser demasiado grande para perderla, lo que hace que la gente no pueda rechazarla.

[Explicación]

Basado en la interfaz de reutilización, la reutilización se impulsa sincrónicamente según la etapa del software en sí, lo que ahorra inversión en generalización antes del lanzamiento oficial del producto.

Apertura controlable

[Hipótesis]

Mientras algo no esté abierto (irrelevante y libre), habrá un único punto de falla escondido en el middle, incluso puede ser basura que no se puede eliminar a menos que exista un buen soporte de servicio, por lo tanto, se debe evitar el middleware cerrado (relevante para la confianza) durante el tiempo de ejecución y las limitaciones del sistema operativo (capaz de instalar, implementar y actualizar de manera flexible y rápida); ). Si hay un temporal, entonces debe estar al menos desacoplado y reemplazable para garantizar un control total.

[Principio]

Permanezca abierto: completamente acoplado libremente, pero establezca estándares de calidad del acoplamiento

****Mismo diseño y ruta unificada

[Supuesto]

Los modelos técnicos y las rutas de implementación no se reconocen. Incluso si son "muy buenos", a menudo no están fundamentados. Si hay fallas, hay que abandonarlas o persuadirlas, de lo contrario, la prisa por implementarlas y promoverlas conducirá a un sinfín de problemas que no se comprenden se magnificarán aún más, entrando así en un círculo vicioso, especialmente cuando se conectan con otros sistemas. si desea apresurarse hacia el éxito, muchas rutas técnicas no están completamente unificadas, como conjuntos de caracteres, bases de datos, integración de aplicaciones, integración de datos ..., lo que de hecho formará defectos de software "fatales"; La orientación tecnológica del equipo de desarrollo y el sesgo del marco no están preestablecidos. Debemos tratar de mantener los hábitos de la mayoría de los desarrolladores, comprender la orientación psicológica de la alta dirección de la empresa y esforzarnos por lograr una comprensión completa del equipo de desarrollo.

[Principio]

****El marco, la ruta y el diseño de los componentes deben ser coherentes, respetar la realidad, dar prioridad a la reutilización, integrar diferencias, resolver contradicciones, unificar la ruta. y lograr entendimiento mutuo* ***, expectativas consistentes

El servicio es la continuación del producto

[Hipótesis]

Los métodos de entrega tradicionales se entregan principalmente en etapas, lo que da como resultado el crecimiento y la fragmentación del producto.

[Principio]

El verdadero comienzo de un producto es el apoyo a su uso

Cambiar la mentalidad es la única salida

[Hipótesis]

En el proceso de desarrollo tradicional, definitivamente encontraremos que: la repetición sin sentido conducirá al aburrimiento, y los ajustes manuales en muchos lugares de acuerdo con las especificaciones conducirán inevitablemente a conflictos de coherencia. Cuantos más problemas se produzcan en la libertad de elección, la libertad desenfrenada puede generar obstáculos. Los obstáculos, la libertad sin supervisión traerán destrucción mutua, la falta de límites para lo mismo conducirá a una revisión poco clara de las responsabilidades y dificultades en la división del trabajo, las normas verbales sin revisión se saldrán gradualmente de control, quedarse despierto hasta tarde y otras horas extras excesivas conducirán al ritmo. El desequilibrio y la participación fuera de control que el conjunto no puede reconocer, la tendencia de las personas responsables a culparse unos a otros y las lagunas jurídicas que el conjunto no puede captar conducirán a resistencias cada vez más fuertes y dislocaciones y cambios jerárquicos artificiales. Cada vez más grave a medida que pasa el tiempo, cuanto más caro es, el código sin inspección de terceros está lleno de peligros ocultos y los lemas de poner a las personas en primer lugar y respetar plenamente no tienen sentido. ..

[Principio]

El pensamiento determina el destino. Sólo cambiando fundamentalmente el comportamiento de desarrollo de los desarrolladores y estableciendo un sistema de desarrollo que subvierta el desarrollo tradicional será posible remodelar el estatus de los desarrolladores (. escapar del destino de los codificadores): igualdad total y respeto mutuo, es posible enfrentar de manera verdaderamente activa, proactiva y efectiva los desafíos de la era de la nube.

Gestión de procesos de software en la nube

[Supuesto]

Las personas están inertes, el código se está volviendo entrópico y la gestión tradicional a menudo está fuera de contacto con la realidad.

[Principio]

El proceso de desarrollo debe gestionarse continuamente: gestionar el proceso de desarrollo automatizado