//****************************************************************************//
//************* Agile Development / Zenhub - August 28th, 2017 **************//
//**************************************************************************//
- Agile today, Agile hooray, agileAgileAGILEagile...
-----------------------------------------------------
- So, there's a LOT of different "Software Development Life Cycles," from the simple ("Code and Fix" (which is awful, btw)) to the complex ("Spiral Model")
- The "Waterfall" model is an example, but it has a LOT of problems; so, out of frustration, some experienced developers created the AGILE model
- As an example of the difference, let's say that the Pharoah wants to build a HUGE pyramid for his grave, but if the pyramid isn't done by the time he dies, the contractor dies too!
- Fred, a UGA student, spends a year studying other pyramids for his references, then spends another year planning it out, then begins to build the massive pyramid
- 2 years into construction, the pharoah dies, but the pyramid is only halfway done!
- Sally, a Georgia Tech student, instead builds a *tiny pyramid* to start off; then, she enlarges it; then she enlarges it again
- This way, the pyramid is ALWAYS ready to be used!
- Now, some people corrupt Agile to say that you don't do ANY documentation, that you should NEVER make a prior plan; this is NOT how Agile works
- Some people have seen the "Agile Manifesto," which says stuff like "Working software over documentation"...this does NOT mean the stuff on the right is useless, but INSTEAD that the stuff on the left is where the emphasis should be
- Some of the Agile principles:
- Highest priority is on satisfying the customer
- Working software is our PRIMARY measure of success (not # of code lines, not quality documentation, etc.)
- Working software should be delivered frequently
- "Now, does this mean that Agile is our silver bullet? Will Agile projects ALWAYS finish, ALWAYS stay under-budget and on-time?"
-...NO
- Agile solves a LOT of the Waterfall model's problem, and it WILL help you to be more efficient if followed correctly, but it can't magically fix everything in a project
- A GREAT essay on this is "The Mythical Man-Month," which has a section called "The Silver Bullet" on Agile's strengths and limitations
- A BIG part of Agile is "Iterative development"
- The project is divided into a number of small pieces called "iterations" (usually 2-4 weeks)
- We try to use "timeboxing" instead of "scopeboxing"
- In TIMEBOXING, these iterations always take the same amount of TIME, and no matter HOW MUCH WE FINISH in the iteration, if the iteration is 2 weeks long, we ALWAYS finish the iteration at the end of those 2 weeks
- This GUARANTEES that we turn in something usable on schedule, even if it doesn't have as many features as we wanted
- In SCOPEBOXING, we instead decide what FEATURES we want at the beginning of the iteration, and each iteration lasts as long as it takes to finish those features, EVEN IF WE GO OVER TIME
- This means that we ALWAYS finish all functionality for the project, but we can go wayyyyyyy over time
- Timeboxing is generally preferred to scopeboxing since it's generally more useful to the customer, more predictable, and forces us to focus on essential features first
- In this class, we'll be working in 1-week iterations
- Now, as per usual, we do have to watch out for the "Dilbert" version of Agile, where people say that we should do NO planning and NO documentation...this is NOT AGILE. This is a recipe for chaos.
- There are several SPECIFIC types of Agile, like SCRUM (all about project management), eXtreme Programming (XP) (focus on process, e.g. pair programming), EVO (requirements focused), RUP (rational unified process) (complete system), etc.
-So, why are these software management procedures so important? Well, a survey of industry in 2004 found that only 25% of software projects finished on-time and within budget
- Now, civil engineers are LAUGHING at us for this; they can estimate how long it will take to build a bridge to the WEEK, and we're constantly going overbudget!
- OUR problem is the "infinite malleability of software"
- In other kinds of engineering, you can't tear down the bridge and start over just because the company wants us to add a Starbucks to the bottom; the project is more-or-less fixed once building commences
- In SOFTWARE, though, the equivalent of a manager asking "can you make this bridge 4 lanes instead of 8 lanes?" halfway through happens ALL THE TIME
- So, a quick overview of the management process we recommend, SCRUM
- Focuses mainly on software product development
- Works in timeboxed iterations called "sprints"; EACH sprint ends with a working, ready-to-ship deliverable product
- Project planned via 2 spreadsheets ("Product" and "Sprint")
- Product has a backlog of general features we want/need the product to have, with ~ estimates of how long each task will take and how long the overall product will take
- For EACH sprint, we take the highest-priority items from the Product backlog and assign them more specifically to different people (the "Sprint" spreadsheet)
- Additionally, the manager uses these things called BURNDOWN CHARTS
- There's a PRODUCT burndown chart, showing how many hours are left in the project, and a SPRINT burndown chart, showing how many hours are left in the current sprint
- This lets us quickly see if we're being too ambitious for the project (i.e. # of hours left in sprint to implement features is more than we have left in sprint)
- Has daily meetings to answer 3 basic question:
- 1) What did you do since the last meeting?
- 2) Did you hit any obstacles?
- 3) What will you have done before the next meeting?
- Meetings should usually take only 10-20 minutes
- ZENHUB!
- Built on-top of GitHub
- Issues used to measure Product features, Milestones to measure Sprints, labels to organize things, estimation to see how long things will take
- Will NOT work on the GaTech private GitHub; for this class, it IS okay to have a public repository (some other classes consider this an honor code violation, but that's not the case here)
- ISSUE_TEMPLATE.txt is optional, BUT (somehow relevant to ZenHub in a way I did not catch)
- Once you install ZenHub (HAVE to install it first), there'll be a "Boards" tab that will show the list of current issues/features (there'll be different categories for "Unfinished", In-Progress", "Closed" etc.)
- "Icebox" are the features that we wanted to do but decided are infeasible for the current project
- "Backlog" are the features that we want to implement for our project
- Can/should still assign features in the backlog to a specific sprint (can filter "issues" in backlog by current sprint)
- "In-Progress" are the features we're working on in the current sprint
- TAs are looking to see that you've entered a task, assigned it to a milestone / specific person, etc.
- We'll talk a bit more about ZenHub on Wednesday, and THEN...we'll get into Git!