Comment Re:Treaty Violations (Score 2, Insightful) 103
Not in space they dont, in fact just about everybody other than the US have stable launch capability, russia, china, india, and europe.
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.
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.
Its n to n, do you really want to have to read through a bunch of emails broadcast to everybody from everybody. standup makes sure everybody DOES sync up, no phones allowed, no laptops or tablets. Focused syncing of purpose.
Standups are all about keeping the team synced up and surfacing issues preventing completion of tasks. They are so the scrum master and the team lead can do thier jobs and smoke out and remove impediments. They are not about providing management status reports, I get that data by inspecting the project burn down charts, and the bug tracker ticket reports for the sprint. Nobody writes down any minutes for standups, so they are not about management or reporting, scrumm master and tech lead may make notes do they can investigate blockages.
>Also, our team speaks five different languages so Agile's demands are just ridiculous.
I think you must be a special case, i have never heard of a team that has 5 seperate lanaguages in play which they need translations for. In tech today if you dont speak english your dead in the water. I have a whoke dept of devs who speak tagalog and english, and we hold our meetings in english. Having 5 translatable languages on the go is just buying trouble no matter language you use.
I speak 5 european languages, and the only time i have ever seen anything close to that was when working at the EU offices in luxembourg on a publishing project in the mid 90's (pagination in 17 translation languages, so that the paragraphs of text all fell on the same page numbers in each version of the document) . Meetings usualy reduced to a even mixture of about 60% english, 20% french and 20% german. But we did not need to translate as all participants spoke all 3 languages. However if there was say somebody from greece in the room then we would conduct the meeting 100% in english, as everybody at a minimum spoke english and thier native language.
What about source control, you run commando on that too?
Exactley right, developers are not hired to write code, they are hired to produce products.
Scrumm meetings should never be more than 15 mins, each team member gets 2 mins to describe what they did yesterday, what they will do today, and what inpediments they have. Scrumm meetings should be just the team standing around a whiteboard. They are fast, focusec, to the point and designed to get the team synced up and problems surfaced.
If you are spending 2 hours on a scrumm meeting/standup then you have a seriously screwed process.
Waterfall just cannot work.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now. If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
If all else fails, lower your standards.
