Phase 4: Development & Coding

Phase 4: Development & Coding

Modernization Overlay: Apply the 2026 Modernization Addendum controls (AI assist + RTG linkage) before phase exit.

Purpose

Build the product according to design specifications using agreed-upon tech stack and coding standards.

Duration

12-16 weeks (depending on complexity)

Key Activities

4.1 Development Environment Setup

• Lead: DevOps Engineer

• Activities:

  • Docker setup for local development

  • Database initialization (schema + seed data)

  • Dependencies installation

  • Development API keys setup

  • IDE configuration (linting, formatting)

Deliverable: [ProjectCode]-Dev-Environment-Setup.md

4.2 Sprint Planning & Execution

• Lead: Scrum Master / Project Manager

• Cadence: 2-week sprints

Sprint Planning (Every 2 weeks, 2 hours):

1. Backlog Refinement

• Clarify user stories

• Discuss technical approach

• Resolve blockers

2. Sprint Planning Meeting

• PM presents prioritized stories

• Team estimates effort (Planning Poker)

• Team commits to stories for sprint

• Define Sprint Goal

Sprint Goal Example: "Implement core payment processing with 3 test scenarios"

3. Create Sprint Backlog

• ├─ [PAYAPP-US-050] Process payment - 5 pts

• ├─ [PAYAPP-US-051] Handle payment errors - 3 pts

• ├─ [PAYAPP-US-052] Email receipt - 2 pts

• ├─ [PAYAPP-TEST-001] Payment test suite - 8 pts

• └─ [PAYAPP-OPS-001] Payment service monitoring - 3 pts

Total: ~21 story points (typical velocity)

Daily Standup (15 minutes, every day at 10 AM):

Each developer answers:

• What did I accomplish yesterday?

• What will I work on today?

• Are there any blockers?

Example:

Dev: "Yesterday I completed the login API endpoint (PAYAPP-US-001). Today I'm starting the password reset feature (PAYAPP-US-005).

Blocker: Need database migration script to add reset_token column."

Sprintly Development Workflow:

1. Create Feature Branch

git checkout -b feature/PAYAPP-US-050-payment-processing

(naming: feature/[JIRA-ID]-[description])

1. AI-Assisted Implementation (Developer-in-the-loop)

• Start from requirement + acceptance criteria context (must include requirement/story ID)

• Generate first draft with Cursor/Copilot (or equivalent)

• Review/edit generated code for correctness, security, and maintainability

• Unit tests as you write (TDD preferred)

• Comments for complex logic

• Meaningful commit messages

3. Commit Code Frequently

git commit -m "PAYAPP-US-050: Implement payment processing API endpoint

• Add /api/v1/payments/process endpoint

• Validate payment method and amount

• Call Stripe API for processing

• Return transaction ID on success

Closes PAYAPP-US-050"

(Reference Jira issue in commit message)

1. Push and Create Pull Request (PR)

git push origin feature/PAYAPP-US-050-payment-processing

Then on GitHub:

• Title: "[PAYAPP-US-050] Implement payment processing"

• Description:

• What does this do?

• Why this approach?

• How to test?

• Screenshots/logs if applicable

• Link to Jira issue

• Request reviewers (min 2)

1. Code Review (24-48 hours)

Reviewer checks:

• Does the code solve the problem? ☐

• Does it follow coding standards? ☐

• Are there security issues? ☐

• Are there performance concerns? ☐

• Are there unit tests? ☐

• Is the code maintainable? ☐

Common comments:

• "Can you add error handling for Stripe timeouts?"

• "This method is 150 lines, can it be split?"

• "Add JSDoc comments to this function"

Developer addresses comments and pushes updates Once approved, reviewer clicks "Approve"

6. Merge to Main

After approval:

• Run final tests (CI/CD pipeline must pass)

• Click "Squash and merge" (1 commit per feature)

• Delete feature branch

• Move Jira issue to "In Review" then "Testing"

7. Deploy to Staging

CI/CD automatically:

• Runs all tests

• Builds Docker image

• Deploys to staging environment

• Runs smoke tests

Developers can test in staging: https://staging.app.com

Coding Standards Document: - File: [ProjectCode]-030-Coding-Standards-v1.0.docx - Contents: ``` JavaScript/Node.js: ├─ Use ES6+ syntax (const/let, arrow functions, destructuring) ├─ Naming: camelCase for variables/functions, PascalCase for classes ├─ Functions: max 50 lines, single responsibility ├─ Comments: Only for “why”, not “what” ├─ Error handling: Always handle promise rejections ├─ Testing: Jest for unit tests, >80% coverage ├─ Linting: ESLint with Airbnb config └─ Formatting: Prettier (4-space indent)

React: ├─ Functional components only (no class components) ├─ Use React hooks (useState, useEffect, useContext) ├─ Props validation with PropTypes or TypeScript ├─ Component size: max 300 lines └─ Testing: React Testing Library

SQL: ├─ Use parameterized queries (never string concat for user input) ├─ Table/column names: snake_case ├─ Always add indexes on foreign keys ├─ Comments for complex queries └─ Use migrations for schema changes

Documentation: ├─ JSDoc for public functions ├─ README for each service └─ Inline comments for tricky logic ```

4.3 Code Quality & Review Process

• Lead: Tech Lead

• Tools: GitHub (code review), SonarQube (code analysis)

Automated Code Quality Checks (in CI/CD):

When code is pushed:

1. Linting (ESLint)

• Check for style violations

• Fail if critical issues found

2. Unit Tests

• Run entire test suite

• Require >80% coverage

• Fail if any test fails

3. Code Analysis (SonarQube)

• Detect code smells

• Find potential bugs

• Check security vulnerabilities

• Flag unused code

4. Build

• Compile/transpile code

• Create deployment artifacts

5. Deploy to Staging

• Spin up fresh environment

• Run database migrations

• Deploy Docker image

All must pass before code can be merged.

4.4 Git Workflow & Version Control

• Repository Structure: See Repository & Naming Conventions section

• Branch Strategy: Git Flow

Main branches:

• ├─ main (production-ready code)

• │├─ All code deployed to production │├─ Every commit is tagged with version │└─ Protected (PRs required, 2+ approvals) │

• └─ develop (staging/development branch)

• ├─ Code deployed to staging env

• ├─ Integration happens here

• └─ Protected (PRs required, 1+ approval)

Feature branches (temporary):

• ├─ feature/PAYAPP-US-050-payment-processing

• ├─ feature/PAYAPP-US-051-payment-errors

• ├─ hotfix/PAYAPP-BUG-123-login-crash

• └─ (deleted after merging)

Releases:

├─ release/v1.0.0 (created from develop) │├─ Only bug fixes and release tasks │└─ After testing, merged back to main │ └─ Tags: ├─ v1.0.0 (on main, production ready) ├─ v1.0.1 (hotfix) └─ v1.1.0 (next release)

GitHub Conventions:

PR Title Format:

[PAYAPP-050] Payment processing implementation

Commit Message Format:

PAYAPP-050: Implement payment processing endpoint

• Add /api/v1/payments/process endpoint

• Validate payment method and amount

• Call Stripe API

• Add unit tests

• Add error handling for Stripe errors

Closes PAYAPP-050

4.5 Continuous Integration Setup

• Tool: GitHub Actions (or CircleCI)

• File: .github/workflows/ci.yml

CI Pipeline Stages:

On every push:

1. Lint & Format Check (2 min) eslint --fix prettier --check

2. Unit Tests (5 min)

npm test -- --coverage

1. Code Analysis (3 min)

• sonar-scanner

1. Build (3 min)

• npm run build

docker build

5. Deploy to Staging (3 min)

docker push kubectl deploy

6. Smoke Tests (2 min)

curl https://staging.api/health npm run smoke-tests

Total: ~18 minutes from commit to staging deployment

4.6 Feature Flag Strategy

• Purpose: Deploy features to production while hiding them from users

• Tool: LaunchDarkly or custom flag service

Example:

if (featureFlags.isEnabled('advanced-reporting')) { // Show advanced reporting UI return <AdvancedReporting />; } else {

// Show coming soon placeholder return <ComingSoon />; }

// In production: // 1. Feature is fully deployed but hidden // 2. Enable for 5% of users to test // 3. Monitor metrics (performance, errors) // 4. Gradually roll out to 100% // 5. Once stable for 1 week, remove flag

4.7 Sprint Review & Retrospective

• Lead: Scrum Master

• Frequency: End of every sprint (every 2 weeks)

Sprint Review (1.5 hours):

Goal: Demonstrate completed work to stakeholders

1. Demo (60 min)

Each story that reached "Done":

• Developer shows feature

• Live walkthrough

• Q&A from stakeholders

Example:

Dev: "Here's the payment processing feature.

You enter amount, select payment method, click Pay, and receive confirmation. Works offline too - queues payment for later."

Stakeholder: "Great! Does it handle errors?"

Dev: "Yes, shows error message if Stripe API fails."

2. Product Updates (15 min)

• Metrics review (users, revenue, retention)

• Roadmap adjustments based on feedback

• Next sprint priorities

3. Celebration (15 min)

• Recognize team achievement

• Highlight best practices

• Share lessons

Retrospective (1 hour):

Goal: Identify improvements for next sprint

Facilitator asks 3 questions:

1. "What went well this sprint?"

Team answers and votes on themes

Examples:

• Strong code reviews caught 5 bugs early

• Quick decision on payment API choice

• Good cross-team collaboration

2. "What didn't go well?"

Examples:

• 2 days lost waiting for DB credentials

• Payment service API docs unclear

• Didn't have time for performance optimization

3. "What will we do differently next sprint?"

Action items:

• Send credentials ahead of time (Action: DevOps) ☐

• Request better API docs from Stripe (Action: Backend Lead) ☐

Schedule performance optimization sprint (Action: PM) ☐

Owner assigns accountability and timeline.

Review action items at start of next retrospective.

Development Deliverables

Success Criteria

✅ All P0 features coded and merged ✅ >80% test coverage on critical paths

✅ No critical SonarQube issues

✅ CI/CD pipeline 100% success rate

✅ Staging environment stable and deployable

✅ Code review feedback consistently addressed

✅ All dependencies integrated and working