Over a million developers have joined DZone.

Our Development Process: 1.5 Years Later

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

1.5 years ago I wrote a post that described our development process. It is interesting to see what’ve changed.

Legend:

  1. Survived
  2. Removed
  3. Added

Context

  • Product development (quite large web application)
  • Two development teams: Core and Integration Several Mini-teams.
  • Quite mature product: 46 years
  • Technology: C#, ASP.NET We are moving to full Javascript front end, ExtJS jQuery, NHibernate, ESB

Process

  • Development team has all the power to try new practices, keep working practices and remove bad practices. There’s a little no push from scrum master side.
  • We form mini-teams for every Epic. Mini-team consists of 2-3 developers, tester and designer (half-time). It is full responsible for Epic implementation. Usually mini-teams lives several months.
  • We do not use iterations.
  • We do use releases, but often it is just a set of all the features implemented last month. We do not plan releases.
  • We do not have iteration planning meeting, but discuss every user story JIT before implementation on a meeting with PO + Testers + Developers.
  • We do not estimate stories and bugs, just a very brief estimate like (“oh, this will be a large story, let’s split it”).
  • We split stories, but sometimes not as aggressively as required. It is still our weak side. Sometimes user stories are too big.
  • We release new builds every week (sometimes 2 builds per week). The goal is to release every day, but we do not have a good automated functional tests coverage so far. Automated tests have been improved significantly during last 18 months. We’ve migrated to Jenkins recently and parallel tests aggressively. Now all tests run ~40 minutes and test runs on every push.
  • Smoke testing of the build still takes 3 hours (32 testers).
  • We have a limit of 3 user stories or bugs in progress.
  • We have retrospective meetings every 2 weeks. Retrospective replaced by JIT meeting. We have an Issue Board with limit of 3 items. When limit is hit, we have a meeting.
  • We sometimes have technical user stories (for example, remove jQuery from application), but that is rare.
  • We use Kanban Board in TargetProcess heavily and have a large screen in development room.
  • We have a flat hierarchy in the company. There are only two layers and no boundaries between the layers. No formalism at all. Also we do not have positions like Senior Developers, Junior Developers, etc. All people are equal (however, there are informal leaders).
  • We track spent/remaining time on tasks and stories.We don’t track time anymore

Development practices

  • We develop each user story or bug in a separate branch. Master is always ready for release (after smoke testing). We use Git.
  • Pair programming on all user stories and complex bug fixes. Sometimes people work alone on smaller/simpler problems. Pair programming is used on complex tasks only.
  • Developers switch pairs every day, even if user story is not completed yet. The goal is to a have fresh look, knowledge spreading and real collective code ownership. We removed pair switching, it appeared to be distracting and annoying for people.
  • Before story implementation, pairs discuss possible solutions. It is quite formal.
  • TDD. All the new code is covered by unit tests. Situation is worse on JavaScript side, we just started TDD adoption for UI. We have strong JavaScript testing suite now. Also we use BDD as much as possible.
  • We use Cruise Control and have quite many different setups. Smoke builds, release builds, etc. Functional tests run in parallel and it takes 1 hour to run them all. We use Jenkins now and it takes about 40 minutes to have a new build with all tests ran.
  • Automated functional tests are based on Selenium. We’ve created a framework in C# especially for our application to simplify tests creation. Tests coverage is not good so far, but we are working on it (there are 2 automation testers in our team).

ToDo

  • We still want to add performance tests into automated builds. We have performance tests already, but not as a part of new build so far.
  • We want to split user stories better. Much better.
  • We are incorporating User Experience into development process. This is our main goal for the next year. It includes Customers UX Community creation, interactive prototypes for all user stories, usability testing. We are doing steady progress here and have defined UX process. However, UX injection takes more time than expected. As usual.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of Michael Dubakov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}