LabVIEW

Agile software development methodologies are built to account for change.  As such, it is not necessary that the customer creates a detailed list of requirements before the start of the project or that the developers perfectly predict how long each requirement will take to implement.  Agile solves the problem by helping us make decisions based on the information we currently have. We create user stories for features that we can currently define and epic stories for feature sets that we need later but are not yet able to define in detail.

Effective scrum requires its participants to play certain roles and Bloomy’s scrum process is closely based on industry-standard scrum practices. A Bloomy scrum team consists of two to four Bloomy developers and one member of the customer’s team.  The customer’s team member acts as the product owner, while the Bloomy team includes at least one scrum master and one developer.  Both Bloomy and customer stakeholders provide support throughout the process but do not play a direct role in the scrum.

At Bloomy we use the agile scrum process to deliver the highest business value to our customers in the shortest amount of time.  Scrum allows us to deliver working software to our customers at the conclusion of each two week sprint so that they can interact with the software and provide feedback for the next iteration.  Ceremonies that encourage open and honest communication are central to the scrum framework and help to expose assumptions early by frequently incorporating customer feedback.

So you've been to Core 1 and Core 2. Good start.

You've also experimented with LabVIEW and started making some VIs of your own. Even better.

But now after a few weeks/months/years of not using LabVIEW you wake up and you've forgotten how it all works and all the things you've learned. Whoops. Even worse, your boss reminds you about your deadline that requires some LabVIEW development and, by the way, is right around the corner. Not so good.

Ugh. So what do I do?

The Actor Framework has become the defacto standard tool for developing large, maintainable, and scalable applications in LabVIEW.  For many LabVIEW developers, however, the learning curve associated with the Actor Framework seems like it is much too steep for them to take advantage of its many benefits.  The purpose of this article is to help developers who are familiar with the common design patterns of “procedural” LabVIEW development transition to the Actor Framework.  Hopefully, by the end of this article you will see that the Actor Framework is not quite so different from the patterns