4.5.2 · Coding › Software Engineering
Intuition 30-second picture
Purana software dam ki tarah banta tha: sab kuch design karo, sab kuch banao, 2 saal baad ek baar ship karo — aur phir pata chale customer kuch aur chahta tha. Agile kehta hai: chote-chote kaam karne waale stream banaao, unhe baar baar dikhao, aur feedback ke basis par direction change karo. Scrum isse fixed time-boxes mein organize karta hai jise sprints kehte hain; Kanban isse ek continuous flow ki tarah organize karta hai jisme work-in-progress par strict limits hote hain. Dono ek hi dushman se ladte hain: big batches of unverified work .
Intuition Core economic argument
Galat hone ki cost iss baat par depend karti hai ki mistake kitni late discover hoti hai . Agar aap ek saal plan karke ek baar ship karo, toh ek galat assumption ka nuksaan ek saal ka hai. Agar aap har 2 hafte ship karo, toh ek galat assumption ka nuksaan zyada se zyada 2 hafte ka hai. Agile ek bet hai ki feedback frequency > planning accuracy , kyunki software mein requirements khud banate waqt badal jaati hain.
Agile Manifesto (2001) ki 4 values — har ek "LEFT prefer karo RIGHT ke upar", na ki "right ignore karo":
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Ek lightweight framework jisme ek chota cross-functional team har fixed-length sprint (usually 1–4 weeks ) mein product ka ek potentially shippable increment deliver karta hai, 3 roles, 5 events (ceremonies), aur 3 artifacts ke guidance mein.
Definition 3 accountabilities
Product Owner (PO) — what aur why ka malik. Product Backlog ko order karke value maximize karta hai. Priorities ke liye single voice.
Scrum Master (SM) — team kaise kaam karti hai ka malik. Ek servant-leader jo blockers hatata hai aur process ko protect karta hai. Project manager nahi hai jo tasks assign kare.
Developers — kaise banta hai ke malik. Self-organizing; ye decide karte hain ki wo kitna commit kar sakte hain aur kaise karna hai.
Common mistake "Scrum Master = boss / project manager"
Kyun sahi lagta hai: wo meetings chalate hain aur status check karte hain, toh manager jaisa lagte hain.
Fix: SM ke paas kaam assign karne ya priorities set karne ki koi authority nahi hoti . Team self-organize karti hai; PO prioritize karta hai. SM ki power influence + impediments hatana hai. Agar SM log bata raha hai ki kya code karna hai, toh wo Scrum nahi hai.
Product Backlog — product ko jo bhi chahiye ho sakta hai uska ordered master list. PO ka owned, kabhi "done" nahi hota.
Sprint Backlog — wo slice jo team is sprint ke liye pull karti hai + usse deliver karne ka plan.
Increment — saare completed items ka sum jo Definition of Done (DoD) meet karte hain — "actually finished" ke liye shared checklist (tested, reviewed, integrated).
Definition Ceremonies (time-boxed events)
Sprint Planning — is sprint mein kya banana hai + kaise. (Kyun? Ek shared, achievable goal banana.)
Daily Scrum / Standup — ~15 min: maine kya kiya, kya karunga, kya block kar raha hai. (Kyun? Blockers jaldi surface karo, roz re-plan karo.)
Sprint itself — wo time-box jisme kaam hota hai; scope renegotiate ho sakta hai lekin goal fixed hota hai .
Sprint Review — increment ko stakeholders ko demo karo, feedback lo. (Kyun? Product inspect karo.)
Sprint Retrospective — team apne process par reflect karti hai aur improvements choose karti hai. (Kyun? Process inspect karo.)
Common mistake Review vs Retrospective confusion
Kyun sahi lagta hai: dono sprint end par hote hain aur dono mein "peeche dekhna" hota hai.
Fix: Review = product (kya hum sahi cheez bana rahe hain? stakeholders ko dikhao). Retro = process (hum kaise kaam kiya, sirf internal team). Mnemonic: Rev iew = v isible product; Ret ro = t eam.
Intuition Points mein estimate KYU karo, hours mein kyun nahi?
Insaan absolute time mein bure hote hain ("ye 6 ghante lega") lekin relative size mein theek hote hain ("ye us se double hai"). Isliye teams story points assign karti hain (often Fibonacci-ish: 1,2,3,5,8) relative effort/complexity capture karne ke liye.
Velocity = ek team jo story points complete karti hai per sprint, recent sprints ka average. Ye ek measured , empirical number hai — kabhi aisa target nahi jo aap push up karo.
Maano p i = sprint i mein complete hue points. Last n sprints mein:
Worked example Velocity se forecasting
Past 3 sprints mein 18, 22, 20 points complete hue. Backlog = 240 points.
Step 1: v ˉ = ( 18 + 22 + 20 ) /3 = 20 . Average kyun? noisy 22 ko smooth karta hai.
Step 2: sprints = ⌈ 240/20 ⌉ = 12 . Ceiling kyun? 240/20 yahan exactly 12 hai, toh 12 sprints.
Agar backlog 250 hota: ⌈ 250/20 ⌉ = ⌈ 12.5 ⌉ = 13 sprints. Kyun? bacha hua 10 points ke liye bhi ek poora sprint chahiye.
Common mistake "Velocity push up karo = zyada productive"
Kyun sahi lagta hai: bada number zyada output lagta hai, toh managers velocity targets set karte hain.
Fix: velocity team ke apne scale ke relative hoti hai . Teams targets hit karne ke liye points inflate kar sakti hain ("point inflation") bina zyada kaam kiye. Velocity ek planning tool hai, performance KPI nahi. Do teams ki velocities compare karna meaningless hai.
Ek method jo kaam ko cards ki tarah ek board par visualize karta hai (jaise To Do → In Progress → Review → Done ) aur columns par Work-In-Progress (WIP) limit enforce karta hai. Isme koi fixed sprints, koi roles, koi time-boxes nahi hote — jab capacity free hoti hai kaam continuously pull hota hai.
Intuition WIP limit KYU? (traffic-jam idea)
Ek saath 10 cheezein start karo aur sab "90% done" par forever atki rahengi — context-switching aur waiting aapko maar deti hai. WIP limit karo aur aap pehle finish karo phir naya kaam shuru karo , toh cheezein actually Done tak pahunchti hain.
Common mistake "Kanban ke koi rules nahi, ye bas ek board hai"
Kyun sahi lagta hai: no sprints/roles ki wajah se casual lagta hai.
Fix: Kanban ka ek strict rule hai WIP limit . Uske bina aapke paas sirf ek to-do list hai aur Little's Law se W baar badhta rahe ga. Board easy part hai; limit respect karna discipline hai.
Scrum
Kanban
Cadence
Fixed sprints (time-boxed)
Continuous flow
Kaam limit kaise
Sprint backlog (per sprint)
WIP limit (per column)
Roles
PO, SM, Devs
Koi prescribed nahi
Mid-cycle change
Sprint mein avoid kiya jaata hai
Kabhi bhi
Key metric
Velocity
Lead/cycle time (Little's Law)
Best kab
Kaam batches mein plannable ho
Kaam unpredictably aaye (jaise support)
"PO Steers, SM Smooths, Devs Solve" roles ke liye.
"Plan, Stand, Sprint, Show, Reflect" = 5 ceremonies in order (Planning, Standup, Sprint, reView/Show, Retro/Reflect).
Kanban: "Limit WIP, Watch the flow, Little's Law" — L = λW .
Recall Feynman: 12-saal ke bachche ko explain karo
Imagine karo tum ek party ke liye cookies bake kar rahe ho lekin exactly nahi pata log kaunsa flavor pasand karenge.
Scrum way: har 2 hafte tum ek choti batch bake karte ho, apne doston ke paas laate ho, aur poochte ho "yummy?" Phir next batch adjust karte ho. PO decide karta hai pehle kaunsa flavor try karna hai, Scrum Master ensure karta hai oven kaam kare aur koi distract na kare, aur tum (the bakers) decide karte ho kaise banana hai.
Kanban way: tumhare paas ek board hai — "to mix", "to bake", "to taste". Ek rule hai ki oven mein sirf 2 trays ho sakti hain ek waqt mein. Toh tum kabhi 10 trays start karke adhi-adhi nahi chhodte. Ek waqt mein kam trays = har cookie plate tak jaldi pahunchti hai. Wahi last baat Little's Law hai: agar 5 cookies per minute finish ho rahi hain aur 15 kitchen mein hain, toh har cookie 3 minute wait karti hai.
Agile fundamentally kis problem se ladhta hai? Large batches of unverified work — galat hone ki cost badhti hai jitna late discover karo.
3 Scrum roles list karo aur har ek kya own karta hai. Product Owner (what/why , backlog order karta hai); Scrum Master (process , blockers hatata hai); Developers (how it's built , self-organize karte hain).
Sprint Review aur Sprint Retrospective mein difference? Review product inspect karta hai (stakeholders ko demo); Retrospective process inspect karta hai (sirf team ki internal reflection).
5 Scrum ceremonies in order batao. Sprint Planning, Daily Scrum (standup), the Sprint, Sprint Review, Sprint Retrospective.
3 Scrum artifacts kya hain? Product Backlog, Sprint Backlog, Increment (Definition of Done meet karta hua).
Velocity define karo aur isse forecast kaise karte hain. Average story points completed per sprint, v ˉ = n 1 ∑ p i ; sprints needed = ⌈ B / v ˉ ⌉ backlog B ke liye.
Velocity ko performance target KYU nahi banana chahiye? Ye team ke apne scale ke relative hai; targeting karne se point inflation hoti hai. Ye planning tool hai, KPI nahi, aur teams compare nahi ho sakti.
Little's Law state karo aur uske teen variables batao. L = λW ; L =WIP (items in system), λ =throughput, W =average lead/cycle time.
WIP limits delivery faster kyun banate hain? Little's Law W = L / λ se: constant throughput λ par WIP L lower karne se lead time W cut hoti hai — kam simultaneous items, kam waiting.
Kanban vs Scrum cadence aur key metric? Scrum = fixed sprints, metric velocity. Kanban = continuous flow with WIP limits, metric lead/cycle time.
Ideal burndown remaining-work formula? R ( d ) = W ( 1 − d / D ) — constant rate W / D per day assume karke linear fall.
Kanban ka ek strict rule kya hai? WIP limit per column — uske bina Little's Law se lead time unboundedly badhti rahti hai.
Software Development Life Cycle (SDLC) — Agile ek SDLC model hai Waterfall ke mukable.
Waterfall Model — big-batch approach jiske against Agile react karta hai.
Little's Law — queueing theory result jo Kanban mein reuse hota hai.
Lean Manufacturing — Kanban ka origin (Toyota production system).
Continuous Integration & Delivery (CI-CD) — wo engineering practice jo shippable increments ko real banati hai.
Project Estimation & Story Points — velocity ke peeche relative sizing.
Big Batches of Unverified Work