এখন পর্যন্ত আমরা requirement বুঝেছি, user stories এবং acceptance criteria লিখেছি, এবং আমাদের engineering context establish করেছি।

এখন একটি important question:

একটি engineering task কখন সত্যিই complete?

শুধু code লেখা শেষ হলে?

Local machine-এ run করলে?

Tests pass করলে?

Pull Request merge হলে?

Production-এ deploy হলে?

Real engineering team-এ "done" শব্দটির clear meaning থাকা দরকার।

এই lesson-এ আমরা Definition of Done, বা সংক্ষেপে DoD, establish করব।

এটি আমাদের পুরো course project-এ একটি shared quality bar হিসেবে কাজ করবে।

---

Why "Done" Is Ambiguous

ধরে নিন engineer বলল:

BACKEND-104 is done.

কিন্তু "done" বলতে সে কী বোঝাচ্ছে?

Possibility:

I finished writing the code.

অথবা:

The code compiles.

অথবা:

I tested the happy path manually.

অথবা:

The Pull Request is open.

অথবা:

The Pull Request has been merged.

অথবা:

The change has been deployed successfully.

সবগুলো আলাদা state।

যদি team-এর প্রত্যেকের "done" সম্পর্কে আলাদা interpretation থাকে, planning এবং delivery unreliable হয়ে যায়।

---

Definition of Done কী?

Definition of Done হলো team-এর shared agreement:

কোন minimum conditions satisfy হলে একটি work item complete হিসেবে consider করা যাবে।

For example, একটি backend task-এর জন্য team বলতে পারে:

Implementation completed

Acceptance criteria satisfied

Relevant automated tests added

Existing tests pass

Code reviewed

Required documentation updated

CI passes

এই list feature-specific behaviour নয়।

এটি team-wide quality expectation।

---

Acceptance Criteria vs Definition of Done

এই দুইটি concept খুব সহজে confuse হতে পারে।

ধরা যাক story:

As a customer,
I want to cancel an eligible order,
so that I can stop an order I no longer want.

Acceptance Criteria হতে পারে:

A customer may cancel their own unpaid order.

A paid order cannot be cancelled in v1.

Cancelling an order restores reserved inventory.

An already-cancelled order cannot be cancelled again.

এগুলো feature behaviour।

অন্যদিকে Definition of Done:

Relevant tests exist.

Code is reviewed.

CI passes.

Documentation is updated where needed.

এগুলো delivery quality।

So:

Acceptance Criteria
      ↓
Is the feature behaviour correct?

Definition of Done
      ↓
Has the work been completed to the team's quality standard?

---

A Feature Can Satisfy Acceptance Criteria but Still Not Be Done

Suppose engineer order cancellation implement করেছে।

Behaviour correct।

Manual testing-এ কাজ করছে।

Acceptance Criteria satisfy করছে।

কিন্তু:

no automated tests

PR review হয়নি

CI failing

তাহলে feature behaviour correct হলেও work team standard অনুযায়ী complete নয়।

এটাই Definition of Done-এর value।

---

Definition of Done Is Not a Personal Checklist

DoD ideally individual engineer-এর personal preference নয়।

এটি team agreement।

Why?

Because one engineer যদি বলে:

I don't usually write integration tests.

আরেকজন যদি বলে:

I consider every feature incomplete without them.

তাহলে quality inconsistent হবে।

Shared DoD expectation align করে।

---

Our Course Project Definition of Done

আমাদের Order Management Backend-এর জন্য আমরা একটি practical Definition of Done ব্যবহার করব।

সব item-এর জন্য সব point একইভাবে apply নাও করতে পারে।

কিন্তু default quality bar হবে:

1. The agreed scope is implemented.

2. Acceptance criteria are satisfied.

3. Relevant validation and failure behaviour are handled.

4. Relevant automated tests are added or updated.

5. Existing automated tests pass.

6. The code builds successfully.

7. The change follows the project's established design and conventions.

8. Required database migrations are included when persistence changes.

9. Required API documentation is updated when API behaviour changes.

10. Required technical documentation is updated when the change affects documented decisions or behaviour.

11. The change is reviewed through a Pull Request.

12. Review feedback is resolved.

13. CI passes.

14. The change is safe to merge according to the known scope and risks.

Later, deployment-related work-এর ক্ষেত্রে rollout এবং production verification-এর additional conditions থাকতে পারে।

কিন্তু Module 1-এর জন্য এটিই আমাদের baseline।

---

1. The Agreed Scope Is Implemented

প্রথম condition obvious মনে হতে পারে।

কিন্তু common problem হলো engineer ticket-এর কিছু অংশ implement করে এবং কিছু silently skip করে।

Example ticket:

Allow administrators to deactivate products.

Suppose acceptance criteria:

Administrator can deactivate a product.

Deactivated products cannot be ordered.

Historical orders remain unchanged.

Engineer শুধু:

product.active = false

implement করল।

কিন্তু order creation এখনও inactive product allow করছে।

তাহলে code আছে, কিন্তু agreed scope implement হয়নি।

---

Do Not Implement More Than the Agreed Scope Either

Definition of Done শুধু missing behaviour prevent করে না।

Scope creep-ও avoid করতে সাহায্য করে।

Suppose ticket:

Allow administrators to deactivate products.

Engineer additionally implement করল:

product deletion
archiving
scheduled activation
bulk import
product version history

এগুলো useful হতে পারে।

কিন্তু requested work-এর অংশ নয়।

Extra functionality:

more code
more tests
more review
more risk
more maintenance

create করে।

Done হওয়ার goal হলো agreed work complete করা, unrelated feature add করা নয়।

---

2. Acceptance Criteria Are Satisfied

Acceptance Criteria আমাদের feature-level contract।

Implementation complete বলার আগে engineer ideally প্রতিটি criterion review করবে।

Example:

AC-1
An order must contain at least one item.

AC-2
Every referenced product must exist.

AC-3
Quantity must be positive.

AC-4
Requested inventory must be sufficient.

Completion review:

AC-1 → implemented and tested

AC-2 → implemented and tested

AC-3 → implemented and tested

AC-4 → implemented and tested

এটি simple habit, কিন্তু missed behaviour significantly reduce করতে পারে।

---

3. Failure Behaviour Must Be Considered

Happy path implementation enough নয়।

Suppose ticket:

Integrate payment provider.

Happy path:

Provider returns success
    ↓
Order marked paid

কিন্তু known failure cases:

payment declined

provider error

timeout

যদি ticket-এর agreed scope এসব include করে, Done হওয়ার আগে behaviour handle করতে হবে।

আমাদের principle:

A backend feature is not complete if only its easiest execution path works.

---

4. Relevant Automated Tests Must Exist

Testing আমাদের Definition of Done-এর core part।

"Relevant" word important।

প্রতিটি method-এর জন্য test লিখতে হবে—এমন rule নয়।

বরং important behaviour এবং risk protect করতে tests ব্যবহার করব।

Examples:

Order total calculation
→ domain/unit test

Order creation with database
→ integration test

Customer cannot access another customer's order
→ API/security integration test

Payment provider failure behaviour
→ controlled integration/service test

Test type problem-এর উপর depend করবে।

---

Why Manual Testing Is Not Enough

Manual testing useful।

বিশেষ করে development-এর সময়।

কিন্তু only manual verification-এর problem:

not automatically repeatable

easy to forget

regression detection is poor

আজ feature কাজ করছে।

দুই মাস পরে অন্য engineer change করল।

Automated test থাকলে expected behaviour automatically verify করা যায়।

---

Tests Should Protect Behaviour

Bad testing mindset:

Every class needs a test because coverage must increase.

Better:

Which behaviour would be expensive or dangerous to break?

For our project:

inventory cannot become invalid

order total must be correct

customer ownership must be enforced

failed payment cannot mark order paid

এগুলো strong candidates।

---

5. Existing Tests Must Still Pass

New feature-এর tests pass করছে, কিন্তু existing test fail করছে।

Then work is not Done।

Why?

Because software change isolated নয়।

New behaviour existing behaviour break করতে পারে।

Example:

New cancellation logic added

কিন্তু existing test:

Paid orders remain active

fail করছে।

এটি regression।

So DoD includes:

existing automated tests pass

---

Regression কী?

Regression হলো এমন situation যেখানে নতুন change-এর কারণে previously working behaviour break হয়ে যায়।

Example:

Before:

Product browsing works.

After inventory-related refactor:

Product browsing returns no products.

New feature may work।

But overall system worse হয়েছে।

Automated regression tests এই ধরনের issue catch করতে সাহায্য করে।

---

6. The Application Must Build Successfully

Developer IDE-তে code run করছে।

কিন্তু clean build fail করছে।

Example:

./gradlew build

fails।

Then change complete নয়।

Why?

Because:

local IDE state

এবং:

reproducible project build

same thing নয়।

Our source repository should contain enough information for automated environment to build the application।

---

Clean Build Matters

Engineer-এর machine-এ previous generated file বা cached dependency accidentally available থাকতে পারে।

CI clean environment-এ সেই hidden dependency থাকবে না।

এই reason-এ build pipeline গুরুত্বপূর্ণ।

---

7. Project Conventions Must Be Followed

Suppose project-এর established pattern:

Controller
    ↓
Application/Service logic
    ↓
Domain
    ↓
Persistence

কিন্তু new engineer সব business logic controller-এর মধ্যে লিখে দিল।

Feature work করতে পারে।

Tests pass-ও করতে পারে।

কিন্তু maintainability degrade হয়।

Definition of Done-এ তাই established architecture এবং conventions follow করার expectation থাকে।

---

Convention Does Not Mean Blind Copying

Project convention follow করা গুরুত্বপূর্ণ।

কিন্তু existing pattern obviously problematic হলে blindly copy করা নয়।

Engineer should raise concern।

For example:

Existing code duplicates validation everywhere.

তখন discussion প্রয়োজন হতে পারে।

কিন্তু একটি ticket implement করার সময় silently completely new architecture introduce করাও risky।

---

8. Database Changes Need Migrations

Suppose feature নতুন field require করে।

Developer local database manually alter করল:

ALTER TABLE orders ADD COLUMN status VARCHAR(50);

Application তার machine-এ কাজ করছে।

কিন্তু migration file নেই।

Then অন্য environment জানবে না schema কীভাবে update করতে হবে।

Definition of Done:

Persistent schema change হলে corresponding versioned migration থাকতে হবে।

আমাদের project-এ Flyway ব্যবহার করা হবে।

---

Application Code and Schema Must Move Together

Imagine:

New application version expects orders.status

কিন্তু deployment database-এ column নেই।

Result:

application failure

Versioned migration application evolution এবং database evolution coordinate করতে সাহায্য করে।

---

9. API Changes Need Documentation

Suppose new endpoint:

POST /orders

implement হলো।

কিন্তু API contract documentation update হয়নি।

অন্য client team কীভাবে জানবে:

request shape

response shape

validation rules

possible errors

?

Later আমরা OpenAPI ব্যবহার করব।

API behaviour change হলে API documentation/code contract sync থাকতে হবে।

---

Documentation Should Be Relevant

Definition of Done-এ:

Documentation updated

বললেই every ticket-এর জন্য README rewrite করা নয়।

Only relevant documentation।

Examples:

API behaviour change

Update API documentation।

Important architecture decision change

Update ADR/RFC where appropriate।

Deployment configuration change

Update operational documentation where needed।

Pure internal refactor with no external impact

Maybe no documentation update required।

---

Documentation Is Part of the System

A common mistake:

Code is the real work.
Documentation is optional.

But certain knowledge code থেকে easy বোঝা যায় না।

For example:

Why did we choose this transaction boundary?

Why don't we physically delete products?

Why is retry disabled for this payment call?

এই reasoning ADR/RFC/PR description-এ থাকতে পারে।

---

10. Technical Decisions Must Stay Consistent

Suppose existing ADR বলে:

Historical products are not physically deleted
because orders must preserve historical references.

New feature এসে product deletion introduce করল, কিন্তু ADR বা design revisit করা হয়নি।

Then change potentially inconsistent।

Done-এর আগে engineer check করবে relevant documented decision violate হচ্ছে কি না।

---

11. Pull Request Review Is Required

Our simulated engineering workflow direct merge নয়।

Change PR-এর মাধ্যমে review হবে।

Why review?

Reviewer check করতে পারে:

Does behaviour match the requirement?

Are edge cases handled?

Is the design understandable?

Are tests meaningful?

Are there security concerns?

Are there migration risks?

Is scope larger than necessary?

Reviewer শুধু syntax checker নয়।

---

Code Review Is Not About Proving Who Is Smarter

Healthy review goal:

improve correctness
share context
catch risk
maintain consistency

Bad review culture:

personal preference battles

nitpicking without value

showing superiority

Course-এর later engineering workflow module-এ code review detail করব।

এখন শুধু এটুকু establish করছি:

Review আমাদের Definition of Done-এর অংশ।

---

12. Review Feedback Must Be Resolved

PR review হয়েছে মানেই Done নয়।

Suppose reviewer comment:

This path can reduce inventory before order persistence.
If persistence fails, state may become inconsistent.

Author comment ignore করে merge করল।

Review process-এর value হারিয়ে গেল।

Feedback resolve করার possible outcome:

code changed

বা:

discussion confirms current design is correct

বা:

follow-up work explicitly agreed

But unresolved meaningful feedback রেখে Done claim করা উচিত নয়।

---

13. CI Must Pass

Continuous Integration pipeline automatedভাবে verify করবে project-এর key quality checks।

Our initial CI expectation:

build

automated tests

Later additional checks থাকতে পারে, but we will not invent unnecessary pipeline complexity now।

If CI red:

work is not Done

even if:

works on my machine

---

Why CI Is Trusted More Than Personal Environment

Developer environment unique হতে পারে।

CI standardized।

If:

Developer A
Developer B
CI

সব একই source থেকে reproducibly build/test করতে পারে, confidence বাড়ে।

---

14. Known Risks Must Be Acceptable

Sometimes code correct এবং tests pass, but change still risky।

Example:

Migration rewrites a huge table.

বা:

Payment behaviour changed.

বা:

Authorization logic changed.

Definition of Done-এর deeper question:

Are known risks understood and appropriately handled?

For small work:

no special rollout concern

হতে পারে।

For risky production change:

rollout plan
monitoring
rollback plan

later প্রয়োজন হতে পারে।

সব task-এর জন্য heavyweight process নয়।

Risk অনুযায়ী process।

---

Definition of Done Is a Minimum, Not Maximum

Suppose DoD says:

Relevant tests added.

Engineer যদি critical concurrency behaviour নিয়ে কাজ করে, শুধু একটি minimal test enough নাও হতে পারে।

Definition of Done baseline।

Good judgement still প্রয়োজন।

---

Definition of Done Should Not Become Bureaucracy

Bad DoD:

47 checkboxes
12 mandatory documents
3 approval committees
5 reports

even for trivial typo।

এতে team process follow করতে বেশি সময় spend করবে than delivering value।

Good DoD should protect meaningful quality।

আমাদের course project-এ baseline intentionally compact।

---

Different Work May Need Additional Conditions

Suppose simple internal refactor।

DoD:

behaviour preserved
tests pass
review complete
CI passes

enough হতে পারে।

কিন্তু database migration:

migration validated

additional consideration।

External payment change:

failure behaviour tested

important।

Production deployment change:

rollback considerations

relevant।

So:

One baseline Definition of Done, plus work-specific completion criteria.

---

Definition of Ready Is Different

Some teams another concept use করে:

Definition of Ready

এটি বলে work implementation শুরু করার জন্য sufficiently understood কি না।

For example:

scope clear
acceptance criteria available
blocking questions resolved

আমরা এই course-এ separate formal Definition of Ready introduce করছি না।

কারণ unnecessary process layer দরকার নেই।

কিন্তু conceptually Module 1-এর আগের lessons exactly সেই কাজই করছে:

Understand requirement
Clarify behaviour
Define acceptance criteria
Understand context

তারপর implementation planning।

---

Don't Confuse "Merged" With "Delivered"

Suppose PR merged।

Does that mean customer feature পেয়েছে?

Necessarily না।

Flow হতে পারে:

Code Complete
    ↓
Reviewed
    ↓
Merged
    ↓
Built
    ↓
Deployed
    ↓
Verified

Later shipping module-এ আমরা delivery lifecycle detail করব।

এই stage-এ engineering ticket merge-ready হওয়াকে baseline completion হিসেবে ব্যবহার করতে পারি।

Production-specific change-এর সময় Definition of Done expand হবে।

---

Ticket Statuses Can Reflect Reality

Real team workflow example:

To Do
  ↓
In Progress
  ↓
In Review
  ↓
Done

Some teams:

Ready for Deployment

বা:

Released

separate রাখে।

Exact workflow company-specific।

আমাদের জন্য important হলো status যেন actual work state communicate করে।

---

"Code Complete" Can Be a Useful Intermediate State

Engineer বলতে পারে:

Implementation is complete, but the ticket is still in review.

এটি precise communication।

Better than:

It's basically done.

"Basically done" usually ambiguous।

---

Example: Order Creation Ticket

Suppose future ticket:

BACKEND-125
Implement order creation workflow

Acceptance Criteria:

Order contains at least one item.

Products must exist.

Quantity must be positive.

Inventory must be sufficient.

Backend calculates total.

Any invalid item causes the full request to fail.

Before marking Done:

[✓] Required behaviour implemented

[✓] Domain/business validations implemented

[✓] Unit tests added where relevant

[✓] Integration tests added for workflow

[✓] Existing tests pass

[✓] Build passes

[✓] No unrelated scope added

[✓] API documentation updated if endpoint changed

[✓] PR opened

[✓] Review completed

[✓] Feedback resolved

[✓] CI passes

এখন "Done" meaningful।

---

Example: Database Migration Ticket

Suppose ticket:

Create persistence schema for products.

Completion should include:

migration file committed

application mapping works with the schema

integration test runs against expected database structure

clean environment can apply migrations

build/tests pass

review completed

Local manually-created table যথেষ্ট নয়।

---

Example: Documentation-Only Ticket

Suppose ticket:

Document order cancellation design decision.

এখানে:

database migration

irrelevant।

API test

irrelevant।

Definition of Done blindly every checkbox apply করবে না।

Relevant conditions apply করবে।

This is why engineering judgement matters।

---

Example: Bug Fix

Suppose production bug:

Order total rounds incorrectly.

Good Done expectation:

root behaviour understood

bug fixed

regression test added

existing tests pass

review complete

CI passes

Important:

Bug fix ideally future regression prevent করবে।

শুধু line change নয়।

---

A Useful Question Before Marking Done

Ask:

If I disappear after merging this change, does the repository contain enough code, tests, migrations, and context for the team to safely own it?

যদি answer no হয়, কাজ probably complete নয়।

---

Ownership Changes the Meaning of Done

Tutorial mindset:

I made it work.

Professional mindset:

The team can now safely own this change.

Difference huge।

Production code personal code নয়।

Once merged, team collectively maintain করবে।

---

"Works Today" vs "Can Be Maintained Tomorrow"

A rushed implementation may work today:

// large method
// duplicated logic
// no tests
// hidden assumptions

But next change difficult।

Definition of Done maintainability-এর minimum expectation protect করে।

---

DoD and Technical Debt

Sometimes deadline-এর কারণে team intentionally compromise করতে পারে।

Example:

We cannot complete the ideal refactor before release.

Then debt should be explicit।

Not:

hide it and mark everything perfect

Potential approach:

Current change is safe for release.

Known limitation documented.

Follow-up ticket created.

But follow-up ticket দিয়ে core acceptance criteria skip করা যাবে না।

---

Follow-Up Ticket Is Not an Escape Hatch

Bad:

Security validation missing.
We'll create a follow-up.

If security validation required for current feature correctness, ticket Done নয়।

Reasonable follow-up:

Current API satisfies agreed requirement.

Additional performance optimization
is desirable but not required for v1.

Difference হলো:

required correctness

vs:

future improvement

---

Quality Is Cheaper Before Merge

Bug coding-এর সময় catch করা easiest।

Then:

test

cost একটু বেশি।

Then:

review

Then:

staging

Then:

production

Production incident পর্যন্ত গেলে customer impact এবং investigation cost significantly increase করতে পারে।

Definition of Done early quality gates encourage করে।

---

Review the Diff, Not Just the Result

Suppose acceptance criteria satisfy হয়েছে।

কিন্তু implementation accidentally:

changes unrelated files

removes validation elsewhere

introduces unnecessary dependencies

PR review change scope inspect করবে।

Small, focused changes review easier করে।

---

Small Work Items Help Definition of Done

Ticket যদি বিশাল:

Build entire ordering system

তাহলে:

Is it done?

answer difficult।

Small ticket:

Implement product creation API

clearer।

This is one reason আমাদের next lesson-এ backlog smaller engineering tickets-এ break করা হবে।

---

Definition of Done Helps Planning

Suppose engineer estimate করছে:

This feature is one day of coding.

কিন্তু real completion includes:

implementation
tests
review iteration
migration
documentation

Then one day assumption inaccurate হতে পারে।

DoD planning-এর সময় full work দেখতে সাহায্য করে।

---

DoD and Team Trust

If every engineer knows:

Done means tested, reviewed, and CI green

then teammates status update trust করতে পারে।

No need to ask:

Did you add tests?

Does it actually build?

Did anyone review it?

Shared standard communication overhead reduce করে।

---

Our Definition of Done Document

Repository-তে আমরা lightweight document রাখতে পারি:

# Definition of Done

A work item is considered complete when all relevant conditions below are met.

## Behaviour

- Agreed scope is implemented.
- Acceptance criteria are satisfied.
- Relevant failure and validation behaviour is handled.

## Quality

- Relevant automated tests are added or updated.
- Existing tests pass.
- The application builds successfully.
- The change follows established project conventions.

## Data and API Changes

- Required database migrations are included.
- API documentation is updated when API behaviour changes.
- Relevant technical documentation is updated when needed.

## Review

- The change is submitted through a Pull Request.
- Review feedback is resolved.
- CI passes.

## Risk

- Known risks are understood and acceptable for the scope of the change.

এই document আমাদের baseline হবে।

---

What We Deliberately Did Not Add

আমরা DoD-তে add করিনি:

mandatory multiple approvals

mandatory performance benchmark for every ticket

mandatory ADR for every change

mandatory deployment for every code task

arbitrary coverage percentage

কারণ এগুলো current context-এ justified নয়।

---

Why We Are Not Setting a Code Coverage Percentage

Example policy:

80% code coverage required.

Simple এবং measurable।

কিন্তু coverage quality guarantee করে না।

You can write tests that execute code without meaningfully verify behaviour।

Example:

service.createOrder(request);

test executes method but meaningful assertion নেই।

Coverage increases।

Confidence not necessarily।

আমাদের approach:

Test important behaviour and risk deliberately.

Coverage metric later useful signal হতে পারে, but we won't use arbitrary percentage as Definition of Done।

---

Why We Are Not Requiring an RFC for Every Ticket

RFC useful when design scope large বা decision significant।

But ticket:

Add quantity validation

এর জন্য 10-page RFC wasteful।

Our documentation principle remains:

Ticket
for bounded work

ADR
for important architectural decisions

RFC
for larger technical proposals

Use the lightest mechanism that preserves needed context।

---

Why DoD Will Evolve

Team এবং system mature হলে Definition of Done evolve করতে পারে।

Later we may discover:

deployment verification is essential

বা:

migration rollback planning needs explicit attention

বা:

certain security checks should become standardized

Then team baseline update করতে পারে।

DoD static law নয়।

It is an engineering agreement।

---

DoD Should Reflect Actual Practice

Worst case:

Documentation says:

All changes require automated tests.

Reality:

Half the team skips them.

Then DoD is fiction।

Better small standard that team actually enforces than huge checklist nobody follows।

Our course project-এ আমরা established DoD consistently use করব।

---

Completion Review

Ticket Done করার আগে engineer quick self-review করতে পারে:

Did I implement only the agreed scope?

Did I satisfy every acceptance criterion?

Did I consider meaningful failure paths?

Are the important behaviours protected by tests?

Did I accidentally break existing behaviour?

Does the project build cleanly?

Are migrations/documentation included where needed?

Is the change understandable to the reviewer?

Have review comments been resolved?

Is CI green?

Are there known risks I have not communicated?

এই habit practical।

---

Definition of Done and Production Ownership

Later course-এ system production-এ যাবে।

তখন Done-এর meaning আরও operational হবে।

Example:

Deployment completed

Health checks are healthy

Expected metrics look normal

No obvious error-rate regression

Migration succeeded

আমরা সেই stage-এ appropriate delivery criteria add করব।

এখন implementation workflow-এর baseline establish করছি।

---

Engineering Principle

এই lesson-এর core principle:

Code written is not the same as work completed.

Professional completion means:

correct behaviour
+
appropriate tests
+
review
+
reproducible build
+
required documentation
+
understood risk

আর সবচেয়ে important mindset:

A change is done when the team can safely own it, not merely when the author stops typing.

---

Where We Are Now

Module 1-এর journey:

Product Requirement
        ↓
Requirement Analysis
        ↓
Functional vs Non-Functional Requirements
        ↓
User Stories and Acceptance Criteria
        ↓
Engineering Context
        ↓
Definition of Done
        ↓
Initial Engineering Backlog

আমাদের product behaviour sufficiently clear।

Engineering environment clear।

Quality bar-ও clear।

এখন আমরা implementation work plan করতে পারি।

---

Summary

এই lesson-এ আমরা শিখেছি:

• "Done" শব্দটির team-wide shared meaning থাকা দরকার।
• Definition of Done একটি minimum quality bar।
• Acceptance Criteria feature behaviour define করে; Definition of Done delivery quality define করে।
• Code লেখা শেষ হলেই work complete নয়।
• Relevant automated tests completion-এর অংশ।
• Existing tests এবং clean build pass করতে হবে।
• Database changes versioned migrations-এর মাধ্যমে deliver করতে হবে।
• API বা technical documentation relevant হলে update করতে হবে।
• Pull Request এবং code review আমাদের workflow-এর অংশ।
• Meaningful review feedback resolve করতে হবে।
• CI green না হলে work Done নয়।
• Known risks understand এবং communicate করা দরকার।
• Definition of Done context অনুযায়ী apply করতে হয়; blindly every checkbox নয়।
• Arbitrary coverage target, unnecessary RFC, বা excessive approval আমরা baseline-এ যোগ করছি না।
• Definition of Done bureaucracy নয়; predictable engineering quality তৈরি করার mechanism।
• A professional change becomes team-owned software, not just author-owned code।

পরের lesson হলো Creating Our Initial Engineering Backlog।

সেখানে আমরা এখন পর্যন্ত agreed product stories এবং engineering context ব্যবহার করে project-এর প্রথম বাস্তব engineering tickets তৈরি করব, dependencies বুঝব, work-এর order ঠিক করব, এবং implementation শুরু করার জন্য একটি realistic backlog তৈরি করব।