Hey guys. I’m the lead software person on my team, and I’m doing a bit of organization for the year. For my fellow software peeps, what is a good way to roughly schedule the software team for the build season?
2 Likes
Schedule the development so you have the software ready for each mechanism as they get completed mechanically. That way you can debug and improve them at the earliest. The amount of time you spend testing/debugging/polishing features should correlate appropriately with your priority list.
Also, don’t wait until you have a complete robot to start developing auto’s. You can start on this as early as day one. Then test and tune them at each development milestone. (Working chassis. Working manipulator, working scoring mechanism, etc…)
Setting a feature freeze date a certain amount of time before a competition is not a bad idea. (Especially for those “Experimental Auto’s” many teams often end up with.)
3 Likes
Out of curiosity which software are you planning your gantt chart in?
Probably using a spreadsheet software like Sheets or Excel.
Try to take advantage of the design/build time to build your codebase top/down rather than bottom/up. As soon as you have the robot designed at the sketch level, you can start figuring out what your subsystems and commands will be (even if you don’t know how they’ll work). Stub all of these out, and begin filling in code as the subsystems are better defined. Note also that by thinking about these things early, you can help drive what sensors you will need BEFORE the thing is built, and it’s a lot easier to design a sensor in than to tack it on after construction, especially if you want it to be robust (and you do, right?)…
[To put dates on this, you’ll have to coordinate with the rest of build.]
2 Likes
FYI I highly recommend Github’s Project board feature, allows you to integrate with your repos and issues, a lot better alternative to just using Sheets.
I would recommend a more Kanban ticket/style method (Github projects has this) over a Gantt for software purposes, you’d see more Gantt in manufacturing things where a part needs to be turned over from one team to another, whereas Kanban is more common in software development which is more task/ticket oriented.
https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
3 Likes
Agreed. Github has really helped us stay organized.
1 Like
Investigate Libre project ( I might have the words reversed). It is a pretty complete project management system.
I’d only heard of Kanban in passing and verbally before this. I read the article you linked. The three Kanban rules make great sense in my work environment, which is essentially production. One of them (2) requires a good bit of WIP in order to keep both people and computers busy, but keeping it to a practical minimum is so straightforward it’s trivial. I have implemented 1-1/2 of the other two already; trying to figure out how to put the “columns” bit into my daily production status/outlook report; this is currently text in a comments field of a one page table that looks out two weekly production cycles, but I’m always on the lookout for something even simpler. Bottom line - I get this for production!
However, I’m having difficulty seeing how to implement this in an FRC environment or a non-FRC software development environment. Here are my biggest issues; can you help me see how this fits?
FRC: Build season is now about seven weeks to the earliest events, and fourteen events to the later CMP. Given this short timeline, and the need for driver practice and mechanical iteration, how can the software crew meet the FRC team’s needs without delivering usable / real-world-testable updates frequently? Every other week seems slow already; there are many times I recall testing code two or more times per build session!!
non-FRC SW development environment: Here, I have the opposite problem. Perhaps I’m missing something, but it seems that Kanban abandons all the project management tenets I’ve ever learned. In an environment where tasks are of a developmental (vs production) nature and therefore unequal and somewhat unpredictable, how do you do project management? That is, how do you recognize when you are behind schedule and need to either assign more people to a specific task, or prioritize and eliminate/delay tasks?
Well from what I understand and was told by manufacturing engineers at my internships, Kanban is a form of lean manufacturing which you most likely know.
Where I interned, they made power distribution for aircraft. They had a kanban system set up for their transformer department where other lines would submit cards for transformers they needed and then the whole card thing goes from there. However, what they had every morning is a line meeting where the supervisor would go over any safety, production, or quality issues that occurred recently or may come up in future (I.e. part shortages). Then with this information and the Kanban cards at transformers, floor managers plan out what cards should be processed first at transformers and inform the supervisor as so.
A similar system is also in place for the SMT line except instead of cards it’s just a Big whiteboard with a bunch of boxes but same process basically.
Let me know if this helps or if you have any questions. It might still be unclear this is my first time describing it.
I’m not sure if I can answer all your questions, but I can say how I’ve seen Kanban being used both at my internships and FRC.
Usually with software development you’ll have a todo list, an in progress list, a list for tasks ready for unit testing, a list for tasks that fail unit testing or new tasks for new bugs that arise, and a list for finished tasks ready for implementation, usually meaning stuff ready to be merged back into the master branch.
I think the biggest answer to your question is to be specific about tickets, doing things on a feature-based level. At my internship, you would have a ticket for, say, laying out a new page on a website, or a new call to an API, or even just adding some buttons to a page, or bug-related tickets: so and so isn’t working on this page, find and fix. For FRC, this might become writing a new command, or adding a pid to a subsystem, or perhaps adding another layer of processing to vision.
I disagree with the article in that we usually have some kind of deadline for each task, at least when we want each task to move from one list to another, and we assign people to each ticket (Github as well as the kanban system I used at my internship makes assigning people both really easy, and adding deadlines could be as simple as putting it in the title).
To be fair, I really hope you are testing your code more than twice in a build season! FRC code can become very complex and testing things frequently can better ensure things go right during competition. I know that between driver practice and mechanical iteration we find things that go wrong in the code all the time. Some of WPILib’s new simulation stuff in 2020 will make testing code without a robot a lot easier as well.
I’m not sure if I answered your question, so please let me know if you have any more!
@risho900, you are describing a production environment; I get kanban for this. At my office, we also have daily production/operations briefs at the beginning of the day which are short enough that most of the people there are standing, and in that we put out the following key items:
- What’s going on downstream with our customers around the world (what does our future demand look like); never less than four slides, rarely more than six. Calling out key items usually takes two to three minutes total.
- What’s going on upstream (do we have all the data products we would like, and if not, what’s the timeline look like, and what’s the workaround if that’s too slow); often “all good”, rarely more than 30 seconds long.
- Who’s doing what today and (as currently planned) tomorrow; usually the longest bit; takes about five minutes.
- General announcements about both official [e.g. infrastructure maintenance] and unofficial [holiday open house is on Dec xx at yy00 to zz00]; often nothing, occasionally a minute or two.
OK, this all makes sense; please let me say back what I understand in my words and correct me if I didn’t get it:
You make the tickets/cards smaller rather than larger than typical agile sprints, and “deliver” each feature after it passes a basic level of testing, rather than bundling several potentially unrelated features into a sprint. This would appear to get features to the customer faster, at a bit more risk (mitigated by Git or other version control technology). It also separates unrelated tasks, which would definitely support using a multi-thread tracking* and overall project management (build season for FRC, major deliverable for a COTS or many-thousands-of-lines custom application) better than sprints.
I think you misread what I wrote (emphasis added):
That’s two or more times in the same day.
* Gannt is one way to do multi-thread project tracking. Probably not the best, but the simplest one I know.
I think you misread what I wrote (emphasis added):
Oh crap lmao… my goodness I read that VERY wrong, my bad! That makes a lot more sense, that sounds typical. Usually we aim for one commit a night in terms of progress and we’ll move around one or more tickets per commit.
You make the tickets/cards smaller rather than larger than typical agile sprints, and “deliver” each feature after it passes a basic level of testing, rather than bundling several potentially unrelated features into a sprint. This would appear to get features to the customer faster, at a bit more risk (mitigated by Git or other version control technology). It also separates unrelated tasks, which would definitely support using a multi-thread tracking* and overall project management (build season for FRC, major deliverable for a COTS or many-thousands-of-lines custom application) better than sprints.
That’s pretty much exactly it. Sometimes we’ll group tickets towards a particular release, or even on rare occasion have a separate kanban for a particularly major release or for different major tasks (and github again makes this easy). In a workplace setting you still wouldn’t make a new release per ticket but you might say on each ticket which version number it’s working towards and bundle a few tickets per delivery. For FRC you don’t have to worry about any of this as much; usually you have one robot so one Kanban is sufficient, and deploying “releases” is trivial, if you separate master and develop branches you can merge back in every few develop branch commits without much effort or consequence.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.