Skip to main content

Home/ Agilesparks/ Group items tagged automation

Rss Feed Group items tagged

Yuval Yeret

Engineering Higher Quality Through Agile Testing Practices The Agile Coach - 1 views

  • Maintaining quality involves a blend of exploratory and automated testing. As new features are developed, exploratory testing ensures that new code meets the quality standard in a broader sense than automated tests alone. This includes ease of use, pleasing visual design, and overall usefulness of the feature in addition to the robust protections against regressions that automated testing provides. 
  • Exploratory testing is a risk-based, critical thinking approach to testing that enables the person testing to use their knowledge of risks, implementation details, and the customers' needs.
  • On our development teams, QA team members pair with developers in exploratory testing, a valuable practice during development for fending off more serious bugs. Much like code review, we’ve seen testing knowledge transfer across the development team because of this. When developers become better testers, better code is delivered the first time.
Yuval Yeret

DevOps Manifesto - 0 views

  • About creating visibility between dev and ops
  • Cross-functional teams over organizational silos
  • Products not projects
  • ...5 more annotations...
  • Automation over documentation (and more automation... and more...)
  • creating self-service infrastructure for teams
  • Cross-functional teams over organizational silos
  • Creating products that are owned by the delivery team
  • Delivery teams run software products - not projects - that run from inception to retirement
Yuval Yeret

InfoQ: Automated Acceptance Tests - Theoretical or Practical - 0 views

  •  
    especially for you elad ;-)
Yuval Yeret

EE Times - Using agile methods in medical device development - 0 views

  • FDA and other regulatory agencies fundamentally want to see that your product has safety in mind. To do so, they require complete traceability through the hardware and software. There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests.
  • Medical devices companies are going primarily agile to respond to change and effectively manage technical complexity by collaboratively building solutions with their partners and customers to ultimately deliver what the customer wants before the competition does.
  • demo the new functionality created after each iteration to your customers, using web-based meets. Using these tools enables you to get immediate feedback from your customers throughout the project. Continuous customer feedback reduces the risk of building the wrong solution. The fact is in most cases you can’t make the release cycle more frequent since it includes giving tests to regulatory agencies. This is a tedious process that makes sure the device is safe. Doing the whole release cycle more frequently can be way too time consuming.
  • ...3 more annotations...
  • ou could also give a version to select customers as long as it will not be directly used for care or diagnosis on current patients. The idea there is the customer gets the current iteration in house for say a blood analyzer. They could load it with real patient data and test out the new functionality as long as it is not used to diagnose an existing patient, since it has not gone through regulatory
  • agile development has gotten so popular in medical device companies that the AAMI (Association of Medical Instrumentation) is currently working on new guidance for mapping agile to a medical standard called IEC 62304.
  • In conclusion, agile development works and is being used in medical device development. The issue is you need to have a good toolchain that allows for complete traceability across the entire lifecycle in order to comply with standards. It is also very important to integrate and test frequently. This, in turn, leads to the need for build automation. With all of this in place, agile development for medical devices becomes much easier to make work.
Yuval Yeret

The Product Owner in the Agile Enterprise - 0 views

  • Responsibilities Vary by Software Business TypeSince the business mission, organization, operating methods, roles, titles and responsibilities differ dramatically across industry segments, it follows that the patterns of agile adoption vary across these segments as well
  • Information Systems/Information Technology (IS/IT) -teams of teams who develop software to operate the business; accounting, CRM, internal networks, sales force automation and the like. Customers are primarily internal to the enterprise.
  • Embedded Systems (embedded) - teams of teams who develop software that runs on computers embedded in other devices - cell phones, electronic braking systems, industrial controls and the like. Customers may be either internal or external to the enterprise.
  • ...17 more annotations...
  • Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.
  • So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.
  • ultimate user (mobile device user) is fairly far removed from the major technologies
  • Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:
  • Embedded Systems Example - Symbian Software Limited
  • Clearly, the development of a mobile phone operating system is a highly technical endeavor
  • mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV
  • the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.
  • All our POs come from engineering teams and are senior engineers with product or customer experience.
  • one PO to two team mapping typically, rarely 3 teams, sometimes 1
  • IS/IT Examples
  • role/title of the Business Systems Analyst
  • is often a reasonably good fit for the Product Owner role.
  • In the larger IT shop, I have also seen the role filled by Project Managers
  • In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.
  • In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business
  • Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests
1 - 11 of 11
Showing 20 items per page