Im there too man, Pasig city.... thank god for A/C......

But this cant be true......

There has been no sudden rise in the number of drooling morons......

There is no evidence that the moronic drooling is a man made phenomenon.

Godddddammmm libertards........

You get the best ones money can buy........

I would ask for a refund if i where you...........

You need to feed him MOAR BRAINZZ

+1

+1

I also use cLion (based on Intelij) for c/c++,

And has a free immeadiate segfault on linux...... lasted about 30 seconds on my fedora box before it blew up....

Not in space they dont, in fact just about everybody other than the US have stable launch capability, russia, china, india, and europe.

Also by assigning property rights to off planet resources, its making a pretty big attempt to extend its soverign juristiction. Who gave the US ownership of the universe.....

Svn blame or git blame is your friend

We are going to be using it with software qa metrics to work out who is generating the most problematic code.

http://svnbook.red-bean.com/en...

http://git-scm.com/docs/git-bl...

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.

My experience is that standups are 10-15 minutes, in the 3 orgs i have done agile in, its always been the same. We hold the meetings standing up at the team whiteboard which is situated at the end of thier seating area.

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.

Waterfall

All of them, at its core agile is about adaptive teams, and oss has to adapt continiously to the needs of its teams.