Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:Right conclusion, wrong reasoning. (Score 1) 507

by tshawkins (#49694663) Attached to: Is Agile Development a Failing Concept?

Some of this is petulance, you see a lot of that attitude being expressed here, with devs loudly complaining that they dont want to be constrained or have to deal with the responsabilities of a methodolgy. Bullshit this and bullshit that. Most of these people are aholes, and are not the sort of people you want on any kind of project that has investors and commitments.

Any project that is beyond 2-3 people needs some kind of govenance and tracking, otherwise people just wander off in thier own directions. If devs cant get with the program, then i dont want them in my programs.

Comment: Re:Agile. (Score 2) 507

by tshawkins (#49694529) Attached to: Is Agile Development a Failing Concept?

We practice stop/start/continue retrospectives where each team member gets to put up at least 3 items. They are then ranked by frequency ( if 3 people say that doughnuts every morning is a continue item) it gets a rank of 3.

It a structured and relativly fast process, we take the top 5 stop/start items and apply them on the next sprint. It important to limit it to 3 or 5 so that its achievable.

Hence the retrospectives can be reduced to under an hour.

We also practice the 70/30 rule, only 70% of the devs time is countable towards sprint velocity, the 30% is used for meetings, estimating, reports, and other non coding stuff. It also provides a buffer for doing 911 fixes etc. I dont employ engineers to be just coders, I employ them to produce products, and that involves being able to interact with the rest of the org. This "I just want to code" attitude is stupid and shows an individual with very limited capacity. They need not apply here.

We also have a ticket gate called "dev ready" which is a state that says that all required artifacts are ready to go, all the assets have been provided, the data needed is available, the product owner etc are available for UAT. User stories are done etc. This stops tickets being planned into a sprint that cant be completed because of outstanding unknowns.

Its down to the program managers to work with the business, BA's, SA's etc to get tickets into a dev ready state before the dev teams will even consider looking at them And planning them in. Our business folks now know they have to cough up all the required information if they want thier feature added.

Im moving to small fast dynamic teams, that are never more than 4-6 devs and are reformed every 2-4 weeks. I have 45 devs in our pool. QA is also dynamicaly assigned on demand. It provides varience to the work people do, and makes sure that people dont get bored or stuck in a rut. People that cant cope with the level of change need not apply.

Finaly we are shifting to continious deployment, where we stop having releases all together, instead the teams will prepare sets of completed "feature" branches and hand them off to a "release engineering team" who will integrate test and deploy. We have this working already on our flagship products, and it works well. We have gone from one release every 2-4 weeks to a steady stream of enhancements or features being pushed to the site. The cool thing about continious deployment is that the individual changes are much smaller, not the big release, so deployment and rollback if needed is simpler.

We have seen the rate that we can get through work rise considerably, we practice continious integration and have QA doing initial go/nogo testing direct on the devs workspace. We use automated unit tests and black box testing based on selenium integrated with jenkins extensivly. Backed up with manual testing in integration by about 20 QA engineers, I have a team of 6 engineers working just on QA automation support and developer toolchain enhancements.

By moving to this continious model which is fully change driven, we have removed the difference between a 911 patch event and a feature element, so 911 patches etc are no longer as disruptive as before, the may result in a reshuffling of priorities. but its no big deal anymore. If we have a specialised long running development needed to add a large feature, I just form a team to handle that one item and allow them to itterate their own cycles until its done.

HEAD CRASH!! FILES LOST!! Details at 11.

Working...