Our Development Process: 1.5 Years Later
Our Development Process: 1.5 Years Later
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
- Product development (quite large web application)
Two development teams: Core and IntegrationSeveral Mini-teams.
- Quite mature product:
- Technology: C#,
- Development team has all the power to try new practices, keep working practices and remove bad practices. There’s
a littleno 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 (
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
- 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
alluser 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.
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).
- 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.
Published at DZone with permission of Michael Dubakov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.