Development process

[yoursurrogategod]

Hi.  I _think_ that this is an appropriate location for this topic.

 

I'm just curious what your development processes are like.  At the moment our process is nonexistent at best in my company.  My previous employer had a solid dev process (spec, reviews, write code, reviews, develop tests, review the tests, test the product, review the results, etc.)  How do you guys do things?

[trq]

We use a cross between kanban and scrum at my work. All our work is prioritised to a degree further up the food chain before it even gets to us developers, but the kanban / scrum process allows us to prioritise it further once we have it in our sites.

 

We've only really been working this way for probably the last 6-7 months though, but yeah, it has improved both quantity and quality imo.

[yoursurrogategod]

We use a cross between kanban and scrum at my work. All our work is prioritised to a degree further up the food chain before it even gets to us developers, but the kanban / scrum process allows us to prioritise it further once we have it in our sites.

 

We've only really been working this way for probably the last 6-7 months though, but yeah, it has improved both quantity and quality imo.

Where do you work?

[trq]

I work for a company in Sydney. We develop administration software for schools.

[ManiacDan]

I work for a payment gateway.  For legal reasons, our progress has to be strongly packaged and released in very rare bundles.  We have a team higher up the chain that delivers a prioritized list of items to us every other Monday.  We do 2-week "sprints," finishing the 2-week block of tickets monday->friday, then we move the entire codebase as a block to the QA server, branch the codebase to sprint2, and start over on the next batch the following Monday.  Meanwhile, QA tests sprint1 while we develop sprint2.  The NEXT sprint, we work sprint 3 while QA tests sprint2 and the second round of QA re-tests sprint1 in our staging environment.  We can go up to 20 sprints without a production release, all of the sprints piling up in the staging environment until we do a production push for all the sprints at once.  Any bugs found by QA must be fixed in the sprint in which they were discovered (we have a rotating set of 3 development environments so we can back-fix up to 6 weeks back), and then forward-merged into any sprints "ahead" of the fix version.

 

Yes, it's ridiculous.

[thomasw_lrd]

I work for a company in Sydney. We develop administration software for schools.

 

I assume you mean Australia?  I live in the USA, and would love to move to Australia. 

 

I'm the only member of our dev team work for a small startup in the finance industry.  So we don't really have any process in place.  It's just code, release, fix problems as they come in, and try to keep too many things from piling up on my plate. 

[scootstah]

I work for a payment gateway.  For legal reasons, our progress has to be strongly packaged and released in very rare bundles.  We have a team higher up the chain that delivers a prioritized list of items to us every other Monday.  We do 2-week "sprints," finishing the 2-week block of tickets monday->friday, then we move the entire codebase as a block to the QA server, branch the codebase to sprint2, and start over on the next batch the following Monday.  Meanwhile, QA tests sprint1 while we develop sprint2.  The NEXT sprint, we work sprint 3 while QA tests sprint2 and the second round of QA re-tests sprint1 in our staging environment.  We can go up to 20 sprints without a production release, all of the sprints piling up in the staging environment until we do a production push for all the sprints at once.  Any bugs found by QA must be fixed in the sprint in which they were discovered (we have a rotating set of 3 development environments so we can back-fix up to 6 weeks back), and then forward-merged into any sprints "ahead" of the fix version.

 

Yes, it's ridiculous.

 

Holy shit. That sounds stressful.

[ManiacDan]

 

Holy shit. That sounds stressful.

Then imagine your code controls billions of dollars of real-time financial data, must be 100% secure from attacks, and is regularly audited by both government and private sector auditors.

[yoursurrogategod]

I work for a payment gateway.  For legal reasons, our progress has to be strongly packaged and released in very rare bundles.  We have a team higher up the chain that delivers a prioritized list of items to us every other Monday.  We do 2-week "sprints," finishing the 2-week block of tickets monday->friday, then we move the entire codebase as a block to the QA server, branch the codebase to sprint2, and start over on the next batch the following Monday.  Meanwhile, QA tests sprint1 while we develop sprint2.  The NEXT sprint, we work sprint 3 while QA tests sprint2 and the second round of QA re-tests sprint1 in our staging environment.  We can go up to 20 sprints without a production release, all of the sprints piling up in the staging environment until we do a production push for all the sprints at once.  Any bugs found by QA must be fixed in the sprint in which they were discovered (we have a rotating set of 3 development environments so we can back-fix up to 6 weeks back), and then forward-merged into any sprints "ahead" of the fix version.

 

Yes, it's ridiculous.

How does your dev environment even look like?  A bunch of virtual machines?

 

And the whole worrying about your code secure 100%, I'd have a heart-attack :-) .

[ManiacDan]

VMs, some stand-alone servers, and then entire racks for staging (2 environments - 1 rack each) and production (1 environment, 4 racks)