Skip to main content

Home/ Arquitectura?/ Group items tagged agile

Rss Feed Group items tagged

anonymous

Agile/Lean Documentation - 7 views

Why Do People Document? Agile developers recognize that documentation is an intrinsic part of any system, the creation and maintenance of which is a "necessary evil" to some and an enjoyable task f...

development documentation agile

started by anonymous on 03 Sep 14 no follow-up yet
Pablo Lalloni

Tuleap - 0 views

  •  
    Tuleap is a full free Open Source Suite for Application Lifecycle Management. Traditional development, Requirement Management, Agile Development, IT Service management... Tuleap makes software projects more productive, collaborative and industrialized.
Pablo Lalloni

Pacto - 0 views

  •  
    Consumers Pacto helps you test consumers by both validating and stubbing services. This helps you decouple tests to reduce test times and non-deterministic test failures without losing confidence in your test suite. You can also design compatibility tests for similar consumers. Providers You can use Consumer-Driven Contracts to ensure you're providers are well tested without losing agility. Pacto will test the provider implementation and make sure it complies with the same contract used to stub the service for consumers.
munyeco

The Twelve-Factor App - 2 views

shared by munyeco on 20 Jul 14 - No Cached
  • The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
  •  
    "Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should
  •  
    Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.
Pablo Lalloni

Reference Architecture | @datawireio - 0 views

  •  
    "Agile workflows for building microservices on Kubernetes"
Pablo Lalloni

How To Not Destroy your Agile Team with Metrics - 0 views

  • Value Delivered: You’ll need your product owner for this. Ask him to give each user story a value that represents its impact to his stakeholders. You can enumerate this with an actual dollar amount or some arbitrary number of some kind. At the end of each sprint you’ll have a number that can tell you how much value you’ve delivered to your customers through the eyes of the product owner. This metric does not measure performance, instead it measures impact. Ideally your product owner will prioritize higher value items towards the top of the backlog and thus each sprint will deliver the maximum value possible. If you’re working on a finite project with a definite end in sight, your sprints will start out very high value and gradually trend towards delivering less and less value as you get deeper into the backlog. At some point, the cost of development will eclipse the potential value of running another sprint, that’s typically a good time for the team to switch to a new product.
    • Pablo Lalloni
       
      Esta métrica parece muy inteligente. Sería bueno probarla en lugar de las métricas que se suelen usar que miden el "cómo".
Pablo Lalloni

Stackato: The Platform for the Agile Enterprise - 0 views

  •  
    "Stackato is a secure, stable, and commercially supported Platform-as-a-Service (PaaS) that is built with and on top of various open source components such as Cloud Foundry and Docker."
Pablo Lalloni

Microservices and PaaS - Part I | ActiveState - 0 views

  • Instead of building software that resembles our existing organizations, we should figure out how we want our software to look, then build the organization around that. Or reorganize it if it's already in place.
    • Pablo Lalloni
       
      Las implicancias de esta idea en nuestra organización...
  • When deploying a new feature, enhancing or fixing an existing capability, or deploying an experimental line of code, the previous code remains available and accessible. New code is deployed alongside the old code, with mechanisms in place to instantly route to one or another version.
  • Importantly, the old code is not replaced, but remains part of the system, and is kept running. If, as is often the case, the widespread introduction of the new feature results in unforeseen consequences, the feature flag can be toggled off, and the old version is instantly used instead.
  • ...13 more annotations...
  • In a microservices architecture, an application is comprised of a number of small, independent composable services that interact by way of an external published protocol, such as REST, or a messaging service.
  • Each service is focused on an individual targeted business capability, and thus its scope is minimized. For functionality out of scope, the microservice calls out to other microservices via the published protocol.
  • Small independent microservices can be built using the technology best suited for their requirements. No longer does every application component need to be built on a common company-mandated language and framework such as Java/Spring or Ruby on Rails.
  • Similarly, there's no reason to standardize on a single persistence layer across an entire application. Some microservices might best be served by Redis, others by Oracle.
  • Each microservice can be updated independently, no longer requiring the entire application to be redeployed.
  • Microservices drastically improve the time required to push out a new update, allowing a much more agile development process.
  • Many organizations consist of specialized silo teams (UI, database, API, etc) where costly handoffs and intercommunication are required to coordinate all the pieces of application construction. These handoffs cause overhead, and the need for them should be eliminated.
  • With small teams, each focused on an individual microservice, Netflix enables developers to push code to production, instead of getting mired in a complex deployment process involving several teams.
  • With microservices, the old IT mindset just doesn't work.
  • A centralized IT department cannot possibly cover the wide array of technologies spanning all microservices.
  • Instead a DevOps structure, where each team is responsible for the management of the corresponding microservice, is essential.
  • Enable developers to concoct systems of their choosing with minimal or no interaction from IT, management, VPs, hardware or other groups. "Self Service" is one of the major capabilities offered by the cloud and there's every reason to take advantage of this.
  • Now, IT can be considered as a cloud API available to the developer on-demand 24x7, instead of a complex, process-mired division hidden behind obscure process.
Pablo Lalloni

Definition of Done: A Reference - Scrum Alliance - 1 views

  •  
    "It is difficult to pin down a definition of done that suits all circumstances. The following definition is an attempt towards creating one common definition. This is not end of the road but a humble beginning.  This, again, is intended to be high-level guidance that projects can tweak to suit their environment. In this attempt, different scenarios are considered to ensure necessary checkpoints are met."
1 - 16 of 16
Showing 20 items per page