The Truth About Agile: http://www.telerik.com/agile-project-management-tools/blogs/13-10-23/the-truth-about-agile-top-30-agile-myths--busted.aspx
One of the better write ups on Agile I have read in a while. "As described in the myth “Agile Projects don’t provide Budget Estimates”, agile teams fix the cost, fix the date, and vary the scope. The onus is on the Product Owner to make sure the requirements are not only prioritized correct, but ordered correctly. "
So very true! Which brings up an important aspect of Agile I don't see many publication how, "How to be a good Product Owner". If you have a customer, project manager, or product owner - whom ever is setting the priorities - if they are not effective, at that the end product is still going to suffer.
For robotics and robot builders this is important to keep in mind. Set your goals and prioritize!
Friday, October 25, 2013
Tuesday, October 15, 2013
Agile - For Robotics
Agile can be defined as - "Characterized by quickness, lightness, and ease of movement; nimble."
Agile in the business world, specifically software development is a group of development methods based on incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
When put into action successfully it makes for a quick and lean development cycle where software developers are always releasing updates or features to their software.
Think of it this way as it relates to robotics; imagine you are building a robot that has human like abilities in both form and thought. It's going to take a lot of work and a lot of time to perfect this robot. One method to build a robot like this would be to hide away in a dark lab like Dr. Frankenstein slowly going mad while perfecting your creation.
This is done with three steps:
My hardware goals were this: Build a light weight mobile robot with 2 drive servo motors, a servo controlled gripper, an interactive head, sonar sensor, wireless camera, touch/pressure sensor, voltage monitor for battery level indication and EZ-B wireless controller.
My software goals were this: Use EZ-Builder software to create a robust set of manual controls to test the robot and it's hardware. Create controls to allow for voice commands. Create controls and scripts to allow the robot to autonomously explore about an environment. Test the ability of the robot to find a target with the camera and attempt to grab the object with its gripper. Specifically test touch sensor and voltage level sensor integration. Test and export of values from the EZ-Builder to external software. Test the import of values to the EZ-Builder software from external software.
With my goals defined I could set a build/release schedule. Agile software development is usually a 2 week cycle. For the robot build or solo inventor I think the cycle is important to set and keep but not the specific amount of time in the cycle. For example if you work a 8-5 job like I do then you are going to have a limited amount of time to dedicate to your project. What works for me is a week long cycle.
Now that you have your goals and cycle you need to break down your goals to fit in the cycles. For example week 1 might be hardware fabrication. Week 2 might be setting up the software for testing of hardware under manual controls. Week 3 autonomous navigation. And so on... The idea is to have a pre-planned set of objectives to complete in every cycle that account for all of your goals.
Another part of the cycle management is the priority of the tasks. For example if in week 1 you fail to complete the hardware fabrication, your other tasks may fail. So that task may need to "carry over" into week 2 or 3 until it is complete. A goal such as "Test a pressure sensor" if it were missed in its weeks cycle it may be something that can wait and be put into a "back log" of tasks or project goals that were not started or completed.
So within the cycle management we have "carry over" and "back log". This is a way to mark your project tasks. Do they get put on the back burner in a back log pile? Or were they started and not completed or are they critical, if so they might need to carry over to the next cycle.
Last but not least is the Daily Standup. This is designed to be a review point for the project. In Agile software development this is done daily and meeting boils down to 3 questions for each team member:
What did you do yesterday?
What will you do today?
Are there any problems that are getting in your way?
For robotics, this is fantastic to do if you are working with a team. If you are a solo developer I still recommend implementing a review process where you answer those 3 questions. I currently implement this on a weekly bases. Agile software development would call this a cycle or iteration review between cycles. I find it helpful to review what I did, what I want to do and what problems I encountered.
Now, all this Agile stuff might sound like things you naturally do anyway at least some of the time. But if you apply Agile to your robotics development I think you'll find you accomplish more than the traditional method of: Build a robot, play with it for a while, get frustrated with some aspect.....leave it on desk.....move it to a closet.....see something cool on the internet that makes you want to play with your robot again, dig out the robot, dig out your parts and tools....work like a crazy person on your robot for a couple of sleepless nights. - Repeat the cycle.
Agile in the business world, specifically software development is a group of development methods based on incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
When put into action successfully it makes for a quick and lean development cycle where software developers are always releasing updates or features to their software.
Think of it this way as it relates to robotics; imagine you are building a robot that has human like abilities in both form and thought. It's going to take a lot of work and a lot of time to perfect this robot. One method to build a robot like this would be to hide away in a dark lab like Dr. Frankenstein slowly going mad while perfecting your creation.
OR...
You could apply Agile methods and practices to the design of your robot and release and add features incrementally. What I'm talking about is applying Agile for the solo developer, in the case a robotics developer who works on both hardware and software. Agile is designed for teams of software developers, so some overall modification to the methods must be made. There are many examples of solo agile developers if you seek them out in an Internet search so what I'm describing is nothing new, although it may be new to the world of robotics.Agile the J2R way
The main objective is to Deliver Value Incrementally.This is done with three steps:
- Daily Standup (a review)
- A defined set of Goals/Vision (with priority levels)
- Build/Release (carry over)
My hardware goals were this: Build a light weight mobile robot with 2 drive servo motors, a servo controlled gripper, an interactive head, sonar sensor, wireless camera, touch/pressure sensor, voltage monitor for battery level indication and EZ-B wireless controller.
My software goals were this: Use EZ-Builder software to create a robust set of manual controls to test the robot and it's hardware. Create controls to allow for voice commands. Create controls and scripts to allow the robot to autonomously explore about an environment. Test the ability of the robot to find a target with the camera and attempt to grab the object with its gripper. Specifically test touch sensor and voltage level sensor integration. Test and export of values from the EZ-Builder to external software. Test the import of values to the EZ-Builder software from external software.
With my goals defined I could set a build/release schedule. Agile software development is usually a 2 week cycle. For the robot build or solo inventor I think the cycle is important to set and keep but not the specific amount of time in the cycle. For example if you work a 8-5 job like I do then you are going to have a limited amount of time to dedicate to your project. What works for me is a week long cycle.
Now that you have your goals and cycle you need to break down your goals to fit in the cycles. For example week 1 might be hardware fabrication. Week 2 might be setting up the software for testing of hardware under manual controls. Week 3 autonomous navigation. And so on... The idea is to have a pre-planned set of objectives to complete in every cycle that account for all of your goals.
Another part of the cycle management is the priority of the tasks. For example if in week 1 you fail to complete the hardware fabrication, your other tasks may fail. So that task may need to "carry over" into week 2 or 3 until it is complete. A goal such as "Test a pressure sensor" if it were missed in its weeks cycle it may be something that can wait and be put into a "back log" of tasks or project goals that were not started or completed.
So within the cycle management we have "carry over" and "back log". This is a way to mark your project tasks. Do they get put on the back burner in a back log pile? Or were they started and not completed or are they critical, if so they might need to carry over to the next cycle.
Last but not least is the Daily Standup. This is designed to be a review point for the project. In Agile software development this is done daily and meeting boils down to 3 questions for each team member:
For robotics, this is fantastic to do if you are working with a team. If you are a solo developer I still recommend implementing a review process where you answer those 3 questions. I currently implement this on a weekly bases. Agile software development would call this a cycle or iteration review between cycles. I find it helpful to review what I did, what I want to do and what problems I encountered.
Now, all this Agile stuff might sound like things you naturally do anyway at least some of the time. But if you apply Agile to your robotics development I think you'll find you accomplish more than the traditional method of: Build a robot, play with it for a while, get frustrated with some aspect.....leave it on desk.....move it to a closet.....see something cool on the internet that makes you want to play with your robot again, dig out the robot, dig out your parts and tools....work like a crazy person on your robot for a couple of sleepless nights. - Repeat the cycle.
Subscribe to:
Posts (Atom)