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.....
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.
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.
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.
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
Its turning into a nice thingiverse alternative, and they have a rule that all items must be printable and accompanied by a pic of the print. 80% of the shit on thingiverse has never been printed, and is just a dumping ground for designers. The stl files on thingiverse are often broken and are non manifold or missing vertices, such that they wont slice properly.
Filament is just ordinary plastics, you are sugesting that plastic will become a controlled substance?. Even if it did, making your own filament from recycled plastic is relativly easy, the equiptment to do it costs less than $200. Which will allow you to cutup and convert food packaging, bottles etc and produce filament.
And dont start down the drm route, a 3d printer is a relativly simple device. There are litteraly 1000's of open source designs, 100's of electronics designs for controlling it and 10's of firmwares. There is absolutly no way that anybody can put the genie back into the bottle and enforce drm on to this.
If you have goten into a router, then discovering what the internal network is, is trivial. No matter how much obstication you do, the network interfaces are inspectable. So they may as well be the same as changing them is no protection at all.
There is no evidence the OP is any more than an average programmer. Regardless you cant be a programmer without problem solving skills, and while i agree that skills are variable, that just means that they are more or less able to meet the requirements of the job.
Software engineering requires skilled people. And the job requirment is given to require abilities and skills beyond what for example a store checkout operator would require to meet the requirments of thier job description. Thats also why a developer generaly is paid more than a store clerk.
Having those abilities does not however give somebody the right to be considered a special class of worker, in that they can ignore thier work for hire contracts. The ability to be creative is an expectation , given that software development except in a few very limited cases is still a craft and not a science. A developer has more in common with an artisan, than a scientist.
What you seem to be suggesting is a form of elitism that suggests that these people are "special" and the normal rules of the workplace dont apply to them.
For the tasks that he has been directed to do --- yes.
After all that is what he is employed to do, use his brain to provide solutions, if there are no neurons firing there then the company would be better cutting him loose and employing somebody else with more active cranial contents.
For gods sake, he is hired to be a programmer/developer, he is supposed to be creative. If human creativity was not required to solve these problems then there would be an application sitting in his seat instead of him.
"He is presumably putting the special efforts of his own brain and creativity into it; which is not merely hours of manual labor"
When you hire a programmer, designer, or engineer, they are expected to have a brain, make special effort and be creative (inovative) in thier solutions. Its kinda part of the job description, and if you are paying them for thier work all of the above is pretty much a given.
Slashdot Mirror
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.
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
https://pragtob.wordpress.com/...
Checkout myminifactory
Its turning into a nice thingiverse alternative, and they have a rule that all items must be printable and accompanied by a pic of the print. 80% of the shit on thingiverse has never been printed, and is just a dumping ground for designers. The stl files on thingiverse are often broken and are non manifold or missing vertices, such that they wont slice properly.
Filament is just ordinary plastics, you are sugesting that plastic will become a controlled substance?. Even if it did, making your own filament from recycled plastic is relativly easy, the equiptment to do it costs less than $200. Which will allow you to cutup and convert food packaging, bottles etc and produce filament.
And dont start down the drm route, a 3d printer is a relativly simple device. There are litteraly 1000's of open source designs, 100's of electronics designs for controlling it and 10's of firmwares. There is absolutly no way that anybody can put the genie back into the bottle and enforce drm on to this.
If you have goten into a router, then discovering what the internal network is, is trivial. No matter how much obstication you do, the network interfaces are inspectable. So they may as well be the same as changing them is no protection at all.
Example case
http://www.wheninmanila.com/uk...
There is no evidence the OP is any more than an average programmer. Regardless you cant be a programmer without problem solving skills, and while i agree that skills are variable, that just means that they are more or less able to meet the requirements of the job.
Software engineering requires skilled people. And the job requirment is given to require abilities and skills beyond what for example a store checkout operator would require to meet the requirments of thier job description. Thats also why a developer generaly is paid more than a store clerk.
Having those abilities does not however give somebody the right to be considered a special class of worker, in that they can ignore thier work for hire contracts. The ability to be creative is an expectation , given that software development except in a few very limited cases is still a craft and not a science. A developer has more in common with an artisan, than a scientist.
What you seem to be suggesting is a form of elitism that suggests that these people are "special" and the normal rules of the workplace dont apply to them.
For the tasks that he has been directed to do --- yes.
After all that is what he is employed to do, use his brain to provide solutions, if there are no neurons firing there then the company would be better cutting him loose and employing somebody else with more active cranial contents.
For gods sake, he is hired to be a programmer/developer, he is supposed to be creative. If human creativity was not required to solve these problems then there would be an application sitting in his seat instead of him.
He is not a contractor, he is an employee......
"He is presumably putting the special efforts of his own brain and creativity into it; which is not merely hours of manual labor"
When you hire a programmer, designer, or engineer, they are expected to have a brain, make special effort and be creative (inovative) in thier solutions. Its kinda part of the job description, and if you are paying them for thier work all of the above is pretty much a given.
Its got to be a millenial..