මම මෑතකදී සංවර්ධන ව්‍යාපෘතියකට සම්බන්ධ වූ අතර හදිසියේම ඊයම් සංවර්ධකයාගේ රැකියාව ලබා දෙන ලදී. මගේ මූලික වගකීම වන්නේ ව්‍යාපෘතියේ ක්‍රමලේඛන කොටස කාර්යයන් බවට පත් කිරීම, මෙම කාර්යයන් අනෙක් සංවර්ධකයින්ට ලබා දීම, ඉන්පසු කෑලි එකට වැඩ කිරීමට වග බලා ගැනීමයි.

ගැටලුව වන්නේ මෙය කරන්නේ කෙසේද යන්න පිළිබඳ හෝඩුවාවක් මා සතුව නොමැත. මම මගේ සති අන්තය පැන්සලක් සහ කඩදාසි සමඟ එය ගණනය කිරීමට උත්සාහ කළ නමුත් සමාන්තරව නොව අනුක්‍රමිකව කළ යුතු කාර්යයන් ලැයිස්තුවක් සමඟ මම ඉදිරියට යමි. සමහර විට එය විශේෂාංග වලට බෙදීමට මම සිතුවෙමි, නමුත් ඔබ අවසන් කරන්නේ එකම ලිපිගොනු සංස්කරණය කිරීම අවශ්‍ය වන කාර්යයන් වන අතර, එමඟින් අප කෙතරම් සංවර්ධනයේ මුල් අවධියේ සිටිනවාද යන්න නිසා සම්පූර්ණ කාර්යයක් මුළුමනින්ම නැවත ලිවීමට අවශ්‍ය වේ. වැඩසටහන තව ටිකක් සම්පූර්ණ හා කාර්යයන් නිර්මාණය කිරීම පහසු වන තෙක් මට සමහර සංවර්ධකයින්ට බලා සිටිය හැකිය, නමුත් සති කීයක් දන්නේ කවුරුන් දැයි දැන ගැනීමට මිනිසුන් අතේ වාඩි වී සිටියි.

මෙය කිරීමට මගේ සුදුසුකම් පිළිබඳව මගේ ලොක්කා සමඟ සංවාදයක් පැවැත්වූ අතර මට මේ සම්බන්ධයෙන් තෝරා ගැනීමක් ලබා දී නොමැත. මා කරන්නේ කුමක්දැයි මා දන්නේ නැත, එබැවින් නිවැරදි දිශාවට ඕනෑම ඉඟි සහ නිරුවත බොහෝ සෙයින් අගය කරනු ඇත.

ඔබේ ප්‍රශ්නයට නිසි පිළිතුරක් පොත් කිහිපයක් පුරවයි . මම මේ ගැන මගේ මතකයට එන බුස් වචන ලැයිස්තුවක් ඉදිරිපත් කරමි, ගූගල් සහ පොත් ඔබ වෙනුවෙන් ඉතිරි දේ කරනු ඇත.

1. මූලික කරුණු

   • තනියම යන්න එපා . හැකි තරම් ඔබේ කණ්ඩායම් සගයන් සම්බන්ධ කර ගැනීමට උත්සාහ කරන්න.
   • සැහැල්ලු ගමන් කරන්න .
   • ප්‍රජාතන්ත්‍රවාදය, නමුත් ඕනෑවට වඩා නොවේ. සමහර විට, එය විශාලතම පුද්ගලයින් සංඛ්‍යාව තෘප්තිමත් කරන්නේ කුමක් ද යන්න ගැන නොව, අවම පුද්ගලයින් සංඛ්‍යාවට රිදවන දේ ගැන නොවේ.
   • කළ යුතු දේ (කළ යුතු) සහ (එය සිදු කරන ආකාරය) වෙනම තබා ගන්න .
   • Scrum ("what"), XP (Extreme Programming, "how"), Kanban ("කොපමණ"), Lean ("what not") සහ DevOps ("කා සමඟද") ගැන ඉගෙන ගන්න .
   • කෙට්ටු වීම ද ප්‍රවාහය පිළිබඳ ය : සමස්ත කාර්යක්ෂමතාව සඳහා, ප්‍රවාහ කාර්යක්ෂමතාව සාමාන්‍යයෙන් පුද්ගල කාර්යක්ෂමතාවයට වඩා වැදගත් ය.
   • මෘදුකාංග හස්ත කර්මාන්තය , පිරිසිදු කේතය සහ ප්‍රායෝගික වැඩසටහන්කරණය ගැන ඉගෙන ගන්න .
   • හොඳ ගෘහ නිර්මාණ ශිල්පය යනු ගනු නොලබන තීරණ ගණන උපරිම කිරීමයි .
   • Scrum / XP / Lean / Agile යනු සිදු නොකරන ලද වැඩ ප්‍රමාණය උපරිම කිරීමයි : YAGNI .
   • මෙම මෘදුකාංග මූලික අගය ඔබ හැකි බව ය පහසුවෙන් වෙනස් එය. එය කළ යුතු දේ එය කිරීම වැදගත් නමුත් එය එහි ද්විතීයික වටිනාකම පමණි.
   • පුනරාවර්තන හා වර්ධනාත්මක ප්‍රවේශයකට කැමති වන්න , සෑම දෙයක්ම පාහේ, විශේෂයෙන් රැස්වීම් සඳහා කාල පෙට්ටි භාවිතා කරන්න , පාකින්සන් නීතිය ඔබේ මිතුරා කර ගන්න, මන්ද හොෆ්ස්ටැඩර්ගේ නීතිය අදාළ වේ.
   • කොන්වේගේ නීතිය සහ ටක්මන්ගේ කණ්ඩායම් සංවර්ධනයේ අවධීන් පිළිබඳ අවබෝධයක් ඇති කණ්ඩායම් ව්‍යුහය සමතුලිත කරන්න .
   • ක්‍රමලේඛනය යනු චතුරස්රයකි, එය විද්‍යාව , ඉංජිනේරු විද්‍යාව , කලාව සහ ශිල්ප සියල්ලම එකවරම වන අතර ඒවා සමතුලිත විය යුතුය.
   • ඒක නිසා Scrum / XP / XYZ කෙනෙක් සඳහා හොඳ (මා ඇතුළු) වේ අවශ්යයෙන්ම ඔබ / ඇඳුම් කට්ටල ඔබේ පරිසරය සඳහා එය යහපත් ඉන් අදහස් කරන්නේ නැහැ. උපකල්පනය අන්ධ ලෙස අනුගමනය නොකරන්න, පළමුව එය තේරුම් ගන්න.
   • පරීක්ෂා කර අනුවර්තනය කරන්න! (Scrum Mantra)
   • අනුපිටපත් කිරීමෙන් වළකින්න - එක් වරක් සහ එක් වරක් පමණි! (එක්ස්පී මන්ත්රය) හෙවත් ඩයි - දෝ ඔබම නැවත නැවත නැහැ හෙවත් සත්යය තනි පේදුරු - Spot

2. "කුමන ලෝකය" වැඩ බිඳවැටීමේ ක්‍රියාවලිය

   • ලෙස එකතු අවශ්යතා පරිශීලක කථා / රැකියා කථා බවට නිෂ්පාදන ගොඩගැහිලා තියෙන්නේ .
   • පරිශීලක සමාන (පරිශීලක කතන්දර) නළුවා (සමගින් දී) සමාන පුද්ගලයා සමාන කාර්යභාරය .
   • INVEST (ස්වාධීන, සාකච්ඡා කළ හැකි, වටිනා, ඇස්තමේන්තුගත, කුඩා, අත්හදා බැලිය හැකි) මත පදනම්ව ඔබේ කණ්ඩායමේ සූදානම් වීමේ අර්ථ දැක්වීම සපුරාලන තෙක් පරිශීලක කතන්දර පිරිපහදු කරන්න . (Scrum Meeting: Backlog Refinement )
   • පිළිවෙලට නිෂ්පාදන ගොඩගැහිලා තියෙන්නේ විසින් ව්යාපාරික අගය .
   • කතන්දරයක් සූදානම් වීමට පෙර එහි වැඩ ආරම්භ නොකරන්න (සූදානම් යන්නෙහි අර්ථ දැක්වීම අනුව සූදානම්).
   • කතන්දර ස්ථානවල කතන්දරවල උත්සාහය තක්සේරු කිරීමට සැලසුම් පෝකර් භාවිතා කරන්න . ඇස්තමේන්තු වල අනුකූලතාව සහතික කිරීම සඳහා ත්‍රිකෝණ සංසන්දනය භාවිතා කරන්න .
   • ඊයේ කාලගුණය හොඳම තක්සේරුවයි, නරකම දේ බලාපොරොත්තු වන්න.
   • කතන්දර විශාල නම් ඒවා බෙදන්න .
   • සිදු කළ අර්ථ දැක්වීමකින් බෙදා හැරීමේ සංස්කෘතිය වැඩි දියුණු කරන්න .
   • එය වෙනවා පෙර පරිශීලක කතාවක් ක්රියාත්මක කිරීම පිළිගන්නේ නැහැ සිදු සිදු (හරි අර්ථ දැක්වීම අනුව සිදු).
   • එකම කේත පදනමක් මත සිටින කණ්ඩායම් කිහිපයක් එකම අර්ථ දැක්වීම (විශේෂයෙන් කේතීකරණ ප්‍රමිති ) සමඟ එකඟ විය යුතුය .
   • බර්න්ඩවුන් ප්‍රස්ථාර සමඟ ඔබේ ප්‍රගතිය පරීක්ෂා කරන්න .
   • කණ්ඩායම ලබා දෙන්නේ සැබවින්ම අවශ්‍ය වන්නේද යන්න ඔබේ පාර්ශවකරුවන් සමඟ නිතර පරීක්ෂා කරන්න. (Scrum Meeting: Sprint Review )

3. කතන්දර බිඳවැටීම

   • ලැයිස්තුව හා විස්තර පරිශීලකයන් / පර්සොනා / ක්රියාකාරීන් / භූමිකා (නිෂ්පාදන අයිතිකරු)
   • එපික් -> කතන්දර (පරිශීලක කතාව හෝ රැකියා කතාව) (නිෂ්පාදන හිමිකරු)
   • කතාව -> පිළිගැනීමේ නිර්ණායක (නිෂ්පාදන හිමිකරු)
   • කතාව -> උප කාර්යයන් (දේව් කණ්ඩායම)
   • පිළිගැනීමේ නිර්ණායක -> පිළිගැනීමේ පරීක්ෂණ (පිරිවිතර: නිෂ්පාදන හිමිකරු, Impl: Dev කණ්ඩායම)
   • ඇවිදීමේ ඇටසැකිල්ලකින් ආරම්භ කරන්න, එය අවම අන්තයේ සිට (අර්ධ-අවසානය) වේ.
   • MVP සාදන්න - අවම ශක්‍ය නිෂ්පාදනයක් .
   • SMURFS භාවිතා කරමින් MVP පුළුල් කරන්න - විශේෂයෙන් අලෙවිකරණය කළ හැකි, ප්‍රයෝජනවත්, නිදහස් කළ හැකි විශේෂාංග කට්ටල .

4. "කොහොමද ලෝකය" සාක්ෂාත් කර ගැනීම

   • OOA / D , UML සහ CRC කාඩ්පත් භාවිතා කරන්න , නමුත් ඉදිරියෙන් ඇති විශාල මෝස්තරයෙන් වළකින්න .
   • ක්රියාත්මක වස්තුව-අභිමුඛ , ව්යුහගත සහ ක්රියාකාරී නොතකා වැඩසටහන්කරණ භාෂාවේ, හැකි තරම් එම අවස්ථාවේ දී.
   • අනුවාද පාලනය භාවිතා කරන්න (වඩාත් සුදුසු ලෙස බෙදා හරිනු ලැබේ ).
   • පිළිගැනීමේ පරීක්ෂණ වලින් ආරම්භ කරන්න .
   • අදාළ TDD , එම ඉඩ TDD තිදෙනෙකු නීති මගින් ඔබට පැදවීමට රතු-කොළ-Refactor-සයිකල් , සමග තනි-කැපවෙනවා-පාලනය , 4 ඒ ' , GWT (එවිට විට සලකන) සිට BDD .
   • " ඒකකය ටෙස්ට් තරග වේ වේගයෙන් ධාවනය වන පරීක්ෂණ ." - මයිකල් පිහාටු
   • කප්ලිං සහ සහජීවනය කළමනාකරණය කිරීම සඳහා SOLID සහ පැකේජ මූලධර්ම යොදන්න . උදාහරණය: SOLID හි S යනු SRP = තනි වගකීම් මූලධර්මය වන අතර එය සංස්කරණ ගණන සැලකිය යුතු ලෙස අඩු කරයි. කණ්ඩායම් තුළ ඒකාබද්ධ-ගැටුම්.
   • ඩිමීටර් නීතිය දැනගන්න / කියන්න, අහන්න එපා .
   • අඛණ්ඩ බෙදාහැරීම (DevOps) පවා අදාළ නම් අඛණ්ඩ ඒකාබද්ධතාවය භාවිතා කරන්න .
   • එකඟ වූ පොදු කේතීකරණ ප්‍රමිතියක් මත පදනම්ව සාමූහික කේත හිමිකාරිත්වය භාවිතා කරන්න (එය අර්ථ දැක්වීමේ කොටසක් විය යුතුය ).
   • අඛණ්ඩ සැලසුම් වැඩිදියුණු කිරීම (fka අඛණ්ඩ ප්‍රතිනිර්මාණය) යොදන්න .
   • ප්‍රභව කේතය නිර්මාණයයි . තවමත් පෙර සිතීම අත්‍යවශ්‍ය වන අතර යූඑම්එල් රූපසටහන් පැහැදිලි කිරීම සඳහා කිසිවෙකු විරුද්ධ නොවනු ඇත.
   • එක්ස්පී යන්නෙන් අදහස් කරන්නේ කිසිදු දිනයක් ගෘහ නිර්මාණ දිනයක් නොවන බවයි, එයින් අදහස් වන්නේ සෑම දිනකම ගෘහ නිර්මාණ දිනය බවයි. එය ගෘහ නිර්මාණ ශිල්පය කෙරෙහි අවධානය යොමු කිරීමක් මිස නිර්‍මාණයක් නොවන අතර අවධානය කේතය තුළ ඇත.
   • ඔබේ තාක්ෂණික ණය අඩු මට්ටමක තබා ගන්න , මෝස්තර හතරේ සුවඳ, අස්ථාවරත්වය , දෘඩතාව , නිශ්චලතාව සහ දුස්ස්රාවිතතාවයෙන් වළකින්න .
   • ගෘහ නිර්මාණ ශිල්පය යනු ව්‍යාපාර තර්කනය ගැන මිස අඛණ්ඩතාව සහ බෙදා හැරීමේ යාන්ත්‍රණයන් ගැන නොවේ.
   • ගෘහ නිර්මාණ ශිල්පය යනු කණ්ඩායම් ක්‍රීඩාවකි ( ගෘහ නිර්මාණ ශිල්පයේ 'මම' නැත ).
   • නිර්මාණ රටා , Refactoring හා පරිවර්තන ප්රමුඛ කාර්යාල පරිශ්රයේ .
   • ව්‍යාපෘති කේතය යනු ප්‍රමුඛතා සහිත ATP- ත්‍රිත්වයයි : 1. ස්වයංක්‍රීය කේතය , 2. පරීක්ෂණ කේතය , 3. නිෂ්පාදන කේතය .
   • කණ්ඩායම ලබා දෙන ආකාරය වැඩිදියුණු කළ හැකිද යන්න ඔබේ කණ්ඩායමේ මිතුරන් සමඟ නිතර පරීක්ෂා කරන්න. (Scrum Meeting: Sprint Retrospect )
   • පරීක්ෂණ පළමු විය යුතුය - වේගවත්, ස්වාධීන, නැවත නැවත කළ හැකි, ස්වයං-වලංගු සහ කාලෝචිත.

ඉහත ලැයිස්තුව නිසැකවම අසම්පූර්ණ වන අතර සමහර කොටස් විවාදාත්මක විය හැකිය!

මේ සියල්ල ඔබව බියගන්වන්නේ නම් - කරදර නොවන්න, මන්ද එය ඔබව බිය ගැන්විය යුතුය ! කණ්ඩායම් තුළ මෘදුකාංග සංවර්ධන ව්‍යාපෘති සාර්ථක කර ගැනීම පහසු කාර්යයක් නොවන අතර කලාතුරකින් මෙම කලාව පිළිබඳ නිසි පුහුණුවක් හා දැනුමක් ඇති පුද්ගලයින් වේ. මෙය ඔබව බියගන්වන්නේ නම්, ඔබේ බුද්ධිය නිසියාකාරව ක්‍රියාත්මක වේ, එයට සවන් දෙන්න. ඔබට සූදානම් වීමට අවශ්‍යයි. ඔබේ ලොක්කා සමඟ කතා කරන්න, යම් කාලයක් හා පුහුණුවක් ලබා ගන්න.

මෙයද බලන්න

• තාක්ෂණික 'පරිශීලක කථා' සීරුවෙන් ලියන්නේ කවුද?

වැඩිදුර කියවීම (මාර්ගගතව)

• පෝට්ලන්ඩ් රටා නිධිය වෝඩ් කනිංහැම් සහ වෙනත් අය විසිනි
• OOD හි මූලධර්ම රොබට් "මාමා බොබ්" සී. මාටින්
• ප්‍රායෝගික ක්‍රමලේඛ ඉඟි

වැඩිදුර කියවීම (පොත්)

• පිරිසිදු කේතය රොබට් සී. මාටින් විසිනි
• කඩිනම් මෘදුකාංග සංවර්ධනය: මූලධර්ම, රටා සහ පරිචයන් රොබට් සී. මාටින් විසිනි
• ප්‍රායෝගික ක්‍රමලේඛකයා - ගමනේ සිට මාස්ටර් දක්වා ඇන්ඩ rew හන්ට් සහ ඩේවිඩ් තෝමස් විසිනි
• මයිකල් ෆෙදර්ස් විසින් උරුම කේතය සමඟ ective ලදායී ලෙස වැඩ කිරීම
• ප්‍රතිනිර්මාණය කිරීම - මාටින් ෆෝලර් විසින් පවත්නා කේතයේ සැලසුම වැඩි දියුණු කිරීම
• රටාවන්ට ප්‍රතිනිර්මාණය කිරීම ජෝෂුවා කෙරෙව්ස්කි විසිනි
• ස්ටීවන් සිල්බිගර් විසින් දස දින MBA (sic!)
• වසම්-මෙහෙයවන නිර්මාණය එරික් එවාන්ස් විසිනි
• පරිශීලක කථා මයික් කෝන් විසින් යොදන ලදි
• ග්‍රේ බූච් සහ වෙනත් අය විසින් වස්තු-නැඹුරු විශ්ලේෂණය සහ යෙදුම් සමඟ සැලසුම් කිරීම
• හතර කල්ලිය විසින් මෝස්තර රටා
• කෙන්ට් බෙක් විසින් මෙහෙයවන ලද සංවර්ධනය පරීක්ෂා කරන්න
• කෙන්ට් බෙක් විසින් අතිශයින්ම වැඩසටහන්කරණය
• [ජාවා නම්] ජෝෂුවා බ්ලොච් විසින් Java ලදායී ජාවා

වේගවත් වන්න

මම පහත සඳහන් දේ යෝජනා කරමි.

එකම ලිපිගොනු සංස්කරණය කිරීම

පළමුව, Git (හෝ ඒ හා සමාන සමගාමී අනුවාද පද්ධතියක්) භාවිතා කරන්න. ඔබ එකම ලිපිගොනු වල විවිධ කොටස් සංස්කරණය කරන තාක් කල් ඔබට ගැටුම් ඇති නොවේ. ඔබට ගැටුම් ඇති වුවහොත් ඒවා පැහැදිලිව සලකුණු වනු ඇත.

Git නොමැතිව බහු-සංවර්ධක ව්‍යාපෘතියක් කළමනාකරණය කිරීමට උත්සාහ කිරීම හරියට පුඩිං පාත්‍රයක් නොමැතිව පුඩිං සෑදීමට උත්සාහ කිරීමක් වැනිය. එය කළ හැකි නමුත් එය ඉතා අවුල් සහගත වනු ඇත.

අදහස් දැක්වීමේදී පෙන්වා දී ඇති පරිදි, Git යනු කෝකටත් තෛලයක් නොවේ, නමුත් ස්වයංක්‍රීය පරීක්ෂණ සමඟ සංයෝජනය වීම නිසැකවම විශාල වශයෙන් උපකාරී වේ.

සියලුම අංග ලැයිස්තුගත කරන්න

දෙවනුව, ව්‍යාපෘතිය පරිශීලක දෘශ්‍ය අංග බවට පත් කරන්න. උදාහරණයක් ලෙස "පරිශීලකයා ලියාපදිංචි වූ විට ඔවුන්ට විද්‍යුත් තැපෑලක් ලැබිය යුතුය" හෝ "පරිශීලකයාට අයිතමයක් එක් කළ හැකිය". මෙහි සියලුම පාර්ශවකරුවන් සම්බන්ධ කර ගන්න. සෑම කෙනෙකුම කාමරයකට ගෙන්වා ගන්න, සෑම කෙනෙකුම ඔවුන්ගේ අංගයන් කෑ ගසන්න.

මේවා පරිශීලකයාගේ දෘශ්‍යමාන අංග විය යුතුය, ඔබට පසුව ක්‍රියාත්මක කිරීමේ උපාය මාර්ග ගැන කතා කළ හැකිය.

ගොළු අය පවා දර්ශක කාඩ්පත්වල සියලුම යෝජනා ලියන්න. අනුපිටපත් ඉවත් කිරීම සඳහා ලැයිස්තුව ඉක්මනින් තාර්කික කර, සියලු කාඩ්පත් විශාල මේසයක් මත හෝ බිම පවා තබන්න.

අවශ්‍ය ඕනෑම අමතර කාඩ්පතක් එක් කරන්න. ඔබගේ යෙදුම කෙටි පණිවිඩ ඇඟවීම් යවන බව පවසන්න. එය කරන්නේ කෙසේදැයි ඔබ නොදන්නවා විය හැක, එබැවින් ඔබට ප්‍රශ්නයක් ඇත. කාඩ්පතක "කෙටි පණිවුඩ ද්වාර විමර්ශනය කරන්න" ලියන්න. ඒ හා සමානව වෙනත් විශාල නොදන්නා අය සඳහා. ඔබට මේවා පසුව ඉවත් කිරීමට සිදුවේ. මෙම විශේෂාංග බොහෝ විට එය ඔබගේ පළමු ස්ප්රින්ටයට ඇතුළත් නොකරනු ඇත.

දැන්, කණ්ඩායම් කාඩ් නිරාකරණය ගැන ඔවුන්ට කවර තුලටම, ලබා ගැනීමට හැගීම ඔවුන් වෙනුවෙන්. මෙය ඔබේ ව්‍යාපෘති විෂය පථයයි.

සැලසුම් පෝකර්

පෝකර් ගහන්න යන්න. තවමත් සියල්ලන් සමඟ එක්ව, "ලකුණු 1", "ලකුණු 2" යනාදී සියලු සංවර්ධකයින්ගේ කාඩ්පත් "ලකුණු 4" දක්වා දෙන්න. එසේම "තවත්" කාඩ්පතක්. ලක්ෂ්‍යයක් දළ වශයෙන් පැයකට සමාන වේ.

විශේෂාංග ලැයිස්තුව එකින් එක හරහා යන්න. ඔබ අංගයක් කියවන විට, සෑම කෙනෙකුටම කාඩ්පතක් වාදනය කළ යුතුය. එක් අයෙකු 1 ක් ද තවත් අයෙකු 4 ක් ද ක්‍රීඩා කරන්නේ නම් එහි සන්නිවේදන ගැටලුවක් තිබේ. එක් පුද්ගලයෙකු අනෙක් පුද්ගලයාට වඩා වෙනස් දෙයක් අදහස් කිරීමට ලක්ෂණය තේරුම් ගනී. සාකච්ඡාවක් පවත්වා ඇත්ත වශයෙන්ම අදහස් කළ දේ සකස් කර එය කාඩ්පතේ සටහන් කරන්න.

විශේෂාංගයක් "වැඩි" බව ඔබ එකඟ වන්නේ නම්, එම අංගය ඉතා විශාලය. ඔබ එම අංගය බිඳ දැමිය යුතුයි. පෙර පරිදිම මෙය කරන්න.

ඔබට එකඟතාවයක් ඇති බැවින්, කාඩ්පත්වල අංක වෙනත් වර්ණ පෑනකින් ලියන්න.

ලකුණු පැය වලට වඩා හොඳයි

පැය වෙනුවට ලකුණු භාවිතා කිරීමෙන් අප සංවර්ධකයින් බොහෝ විට නිරත වන "මට කොතරම් වේගයෙන් කේත කළ හැකිදැයි බලන්න" යන කාරණය ඉවත් කරයි. එය සියුම් වෙනසක්, නමුත් එය හොඳින් ක්‍රියාත්මක වන බව මට පෙනී ගොස් ඇත.

දැන් ස්ප්රින්ට් එකක් රචනා කරන්න

ස්ප්‍රින්ට් යනු ඉලක්කයක් කරා වේගයෙන් පුපුරා යාමකි. ස්ප්රින්ට් දිග තීරණය කරන්න, සමහර විට දින 5 ක් හෝ 10 ක්. සංවර්ධකයින්ගේ සංඛ්‍යාවෙන් දින ගණන ලකුණු ගණන අනුව දිනකට ගුණ කරන්න.

මුලින් එක් සංවර්ධකයෙකුට දිනකට ලකුණු 6 ක් උපකල්පනය කරන්න. මෙය අත් කරගත හැකි අංකයකි. ඔබට පුද්ගලයින් 5 ක් සිටී නම්, එය ලකුණු 5 * 5 * 6 = ලකුණු 150 කි. සියලුම සංවර්ධකයින් සහ කළමනාකාරිත්වය සමඟ එක්ව, ලැයිස්තුවෙන් විශේෂාංග 150 ක් දක්වා තෝරන්න. ඒක ඔයාගේ ස්ප්‍රින්ට් එක.

ගැළපෙන ප්‍රමාණයට වඩා මිරිකීමට කිසි විටෙකත් පෙළඹෙන්න එපා. ඕනෑවට වඩා පොරොන්දු වීම ඔබ ඇතුළු දිගු කාලීනව සියලු දෙනාටම රිදවයි.

ඔබ මෙහි පරායත්තතා සැලකිල්ලට ගත යුතුය. නිදසුනක් ලෙස, පරිසර සැකසුම පැහැදිලිවම පළමු වේගයට ඇතුළත් කළ යුතුය. සෑම කෙනෙකුම සිටින විට මෙය සැබවින්ම පහසුය. ඔබට කාමරයේ මොළ 6 ක් ඇත, සියල්ලම "මෙය මෙය මත රඳා පවතී" යැයි කියනු ලැබේ. යැපීම් පෙන්වීම සඳහා ඔබට කාඩ්පත් මාරු කළ හැකිය.

ඔබ ඔබේ ස්ප්‍රින්ට් එක ලබාගත් පසු එයට කිසිවක් එකතු කළ නොහැක, එය දින 5 ක් සඳහා අගුළු දමා ඇත. විශේෂාංග රිංගීම කණ්ඩායම අවධාරණය කරයි, චිත්ත ධෛර්යයට හානි කරයි සහ සියලු දෙනාගේ වේගය අඩු කරයි. අවසානයේදී, ක්‍රිප් විසින් ව්‍යාපෘතියක් නවතා දමනු ඇත. කණ්ඩායම් නායකයා ලෙස ඔබ ඔබේ කණ්ඩායම විශේෂාංග වලින් ආරක්ෂා කළ යුතුය. නව විශේෂාංග ඉල්ලීමක් පැමිණේ නම්, එය ඊළඟ ස්ප්රින්ටයට එක් කළ යුතුය. ඊළඟ ස්ප්රින්ට් එක දැනටමත් පිරී තිබේ නම්, වෙනත් දෙයක් පිටතට ගත යුතුය.

වැඩිපුර මිරිකීමට කිසි විටෙකත් පෙළඹෙන්න එපා. ඕනෑවට වඩා පොරොන්දු වීමෙන් ඔබට දින 1 ක් වටිනා ප්‍රීතිමත් සේවාදායකයෙකු ලබා ගත හැකි අතර ඉන් දින 4 ක කණ්ඩායම් ආතතියද, අවසානයේදී කණ්ඩායමට නියමිත වේලාවට ලබා දීමට නොහැකි වූ විට අවාසනාවන්ත සේවාදායකයින් කිහිප දෙනෙකුද සිටී.

දැන් ඒකට යන්න.

කාඩ්පත් භාර දෙන්න, කුමක් කිරීමට අවශ්‍යදැයි විමසන්න. සිදු කෙරෙන දේ පිළිබඳව ඔබට පූර්ණ දෘශ්‍යතාවයක් ඇති අතර, ඔබට බිංදුව දක්වා ලකුණු ගණනය කළ හැකිය. සෑම දිනකම ආරම්භයේදීම ස්ථාවරව සිටින්න, එවිට කවුරුන් කුමක් කරන්නේද සහ කුමක් කර ඇත්ද යන්න කවුරුත් දනිති.

පැහැදිලිව නිර්වචනය කළ හැකි කළමණාකරණ අරමුණු සඳහා ඒකකයක් ලෙස එකට වැඩ කරන යහපත් අභිප්‍රේරිත සංවර්ධකයින් 5 ක් හෝ 6 ක් දින 5 ක වේගයකින් ඉතා සුළු ප්‍රමාණයක් ලබා ගත හැකිය.

දෘශ්‍යතාව පවත්වා ගන්න

ව්‍යාපෘතියේ තත්වය කුමක්දැයි සැමට දැකගත හැකි බවට වග බලා ගන්න. සියලුම කාඩ්පත් බිත්තියට බ්ලූටැක් කරන්න. වම් පසින් තවමත් ක්‍රියාත්මක නොවූ කාඩ්පත් ඇත. දකුණු පසින් කාඩ්පත් කර ඇත.

සංවර්ධකයෙකු කාඩ්පතක් මත වැඩ කරන විට, ඔවුන් එය බිත්තියෙන් ඉවතට ගෙන ඔවුන්ගේ මේසය මත තබයි. මෙය දෘශ්‍යතාව පවත්වා ගෙන යන අතර මිනිසුන් එකිනෙකාගේ ඇඟිලි මතට නැගීම වළක්වයි.

දර්ශක කාඩ්පත් සඳහා තාක්‍ෂණික විකල්ප තිබේ, නමුත් බිත්තියේ ව්‍යාපෘති තත්ත්වය පිළිබඳ විශාල කඩදාසි සංදර්ශනයක් තිබීම කිසිවක් පරාජය නොකරයි.

හැකි නම්, ව්‍යාපෘතියේ කාලසීමාව සඳහා සියලු දෙනා එකම කාමරයේ සිටින්න. සෑම දිනකම පාර්ශවකරුවන් හැකිතාක් දුරට සිටින්න.

බර්න්ඩවුන්

බර්න්ඩවුන් ප්‍රස්ථාරයකින් ඔබේ ලකුණු බිංදුව දෙසට ප්‍රස්ථාරණය කළ හැකිය. ඔබ ඔබේ කාල සීමාවට පැමිණීමට පෙර ඔබේ හොඳම යෝග්‍යතා රේඛාව බිංදුව ඉක්මවා ගියහොත්, ඔබ බොහෝ දුරට ගමන් කරයි. එසේ නොවේ නම්, ඔබ නියමිත දිනට ආසන්න වීමට පෙර ඔබේ සේවාදායකයාට දැන් දැනුම් දිය යුතුය.

ඔබ අසමත් වීමට යන්නේ නම්, ඉක්මනින් අසමත් වන්න.

ඔබට මෘදුකාංග භාවිතයෙන් බරක් සෑදිය හැකිය, නමුත් මම කැමතියි බිත්තියේ විශාල කඩදාසි කැබැල්ලකට. එය පුරා අඳින්න.

ස්වයංක්‍රීය පරීක්ෂණ

ඔබට එකවර එකම දේ මත වැඩ කරන බහු සංවර්ධකයින් සිටින විට, ඔවුන් වරින් වර එකිනෙකාගේ කේතය බිඳ දමනු ඇත. සන්නිවේදනය සහ දෘශ්‍යතාව මේ සඳහා උපකාරී වේ, නමුත් ගැටළු සොයා ගැනීමට උපකාර කිරීම සඳහා ඔබට යම් තාක්ෂණයක් හඳුන්වා දීමට අවශ්‍ය වනු ඇත.

ඒකක පරීක්ෂාව යනු ඔබේ කේත මාලාවේ එක් එක් කොටස සඳහා පරීක්ෂණ ලිවීමේ ක්‍රියාවලියයි (ඉතා මැනවින් එක් එක් ක්‍රමය). හැකි නම් සෑම ඉතිරියක් සමඟම ඔබේ ඒකක පරීක්ෂණ බොහෝ විට ක්‍රියාත්මක කළ යුතුය. මේ සඳහා උපකාරී වන බොහෝ මෙවලම් තිබේ, උදාහරණයක් ලෙස කර්මය හෝ රුපෙක්.

අවසානය සිට අවසානය දක්වා පරීක්‍ෂණය යනු ඔබේ ව්‍යාපෘතිය සමස්තයක් ලෙස පරීක්‍ෂා කිරීම, අභ්‍යන්තරය කළු පෙට්ටියක් ලෙස සැලකීමයි. මෙම පරීක්ෂණ ඔබේ ඉහළ මට්ටමේ ව්‍යාපාරික අවශ්‍යතා මත පදනම් කරන්න, උදාහරණයක් ලෙස: "පරිශීලකයාට ලියාපදිංචි විය හැකිය" හෝ "පරිශීලකයාට අයිතම ලැයිස්තුවක් දැකිය හැකිය". Protractor යනු වෙබ් පාදක පරීක්ෂණ රාමුවක් අවසන් කිරීම සඳහා කදිම නිදසුනකි.

පරීක්ෂණ සඳහා ලියා ඇති සම්පූර්ණ පොත් තිබේ, නමුත් අවම වශයෙන් පිළිගැනීමේ පරීක්ෂණ කිහිපයක් තිබීම ඔබේ ව්‍යාපෘතියේ වැඩ කරන විට කිසිවක් කැඩී නොයන බවට වග බලා ගත හැකිය.

තාක්ෂණික ණය වලින් වැළකී කටයුතු කිරීම

තාක්ෂණික ණය යනු පසුකාලීනව පිරිසිදු කළ යුතු දේවල් විස්තර කරන සංකල්පයකි. ණය සඳහා පොදු ප්‍රභවයක් වන්නේ සිදු කරන ලද ලෙස සලකුණු කරන ලද නමුත් කිසි විටෙකත් “සිදු නොකළ” අංගයන් ය. සිදු කරන ලද අංගයක් Git වෙත පරීක්ෂා කර, පාර්ශවකරු විසින් අනුමත කර ඇති අතර පරීක්ෂණයක් ඇත.

ඔබගේ අංගයන් අවසන් වන තුරු ඒවා පරීක්ෂා නොකරන්න. කිසි විටෙකත් ප්‍රස්ථාරය සම්බාහනය නොකරන්න. නැවතත්, මෙය ඔබ ඇතුළු දිගු කාලීනව සියලු දෙනාටම රිදවයි.

අප මුලින් දිනකට එක් සංවර්ධකයෙකුට ලකුණු 6 ක් පමණක් උපුටා දැක්වීමට මෙය එක් හේතුවකි. කළ දේ අමතර වැඩක් කළත්, එය විශිෂ්ට යැයි හැඟෙන අතර කණ්ඩායමට ශක්තියක් ලබා දෙයි.

එකම ලිපිගොනු සංස්කරණය කිරීම තනිවම ගැටලුවක් නොවේ. වෙනස් කාරණා දෙකක් කිරීමට ඔබ එකම ශ්‍රිතය සංස්කරණය කළහොත් එය ගැටළුවක් පමණි.

මූලික වශයෙන් මා කරන්නේ, ව්‍යාපෘතිය වෙනමම 'විශේෂාංග' ලෙස බෙදීමයි. එකක් ජාල ප්‍රොටොකෝලය හැසිරවීම හා තවත් එකක් වින්‍යාස ගොනුවකට සම්බන්ධ විය හැකි අතර තවත් එකක් ඩී.බී. විශේෂාංග විශාල දේවල්.

ඊළඟට, ඔබට එම අංග කාර්යයන් (කථා) ලෙස බෙදීමට අවශ්‍යය. ඒවා සරල දේවල් විය යුතුය, "පරිශීලකයා බොත්තමක් ක්ලික් කළ විට, වැඩසටහන ගොනුව පටවනු ඇත", "වැඩසටහන ආරම්භ වූ විට, එය වින්‍යාස ගොනුව පටවනු ඇත" යනාදිය.

සමහර කාර්යයන් අනුක්‍රමිකව සම්පූර්ණ කිරීමට සිදුවනු ඇත ("වැඩසටහන මඟින් වින්‍යාස ගොනුවේ සියලුම ක්ෂේත්‍ර විග්‍රහ කරනු ඇත" "වැඩසටහන මඟින් වින්‍යාස ගොනුව පටවනු ඇත"). අනෙක් අය එසේ නොකරනු ඇත (ඔබට එකවර DB සහ ජාලයේ වැඩ කළ හැකිය).

නමුත් බොහෝ දුරට, ඔබ එය වැරදියට කරනු ඇත, අත්දැකීම් එන්නේ එතැනිනි. ඔබ ඉතා සුළු ප්‍රමාණයක් (හෝ ගොඩක්) අසමත් වනු ඇත, කාලය තක්සේරු කිරීම වැරදියි, ඔබේ ව්‍යාපෘතියට තිබිය යුතු ප්‍රමාණයට වඩා ටිකක් වැඩි කාලයක් ගතවනු ඇත. ඊළඟ වතාවේ ඔබ වඩා හොඳ වනු ඇත.

කෙන්ට් බෙක් විසින් රචිත "අන්ත වැඩසටහන්කරණය" කියවීමට මම යෝජනා කරමි. මම ව්‍යාපෘති කළමණාකරුවෙකු වීමට ආසන්නව සිටියදී මට උපකාර කළ විශිෂ්ට පොත.

එය පහළට පැමිණෙන්නේ ඔබ ඔබේ යෙදුම ක්‍රියාකාරී මොඩියුලවලට බිඳ දමා විවිධ මොඩියුල අතර ගිවිසුම් (අතුරුමුහුණත් සහ දත්ත ගිවිසුම්) හඳුන්වා දිය යුතු බැවිනි. සෑම මොඩියුලයක්ම වෙනත් සංවර්ධකයෙකුට භාර දිය හැකිය. ඔබ සියල්ල නැවත එකතු කළ විට මෙම මොඩියුල එකිනෙකා සමඟ නිවැරදිව සන්නිවේදනය වන බවට ගිවිසුම් සහතික කරයි.

මොඩියුල සියල්ලම තනි තනිව ක්‍රියාත්මක වන බවට සහතික වීම සඳහා ඔබ සංවර්ධකයින් මත TDD බලාත්මක කරන බවට වග බලා ගන්න.

මා අදහස් කළ දෙයට උදාහරණයක් ඔබට දීමට:

ඔබගේ සංවර්ධකයින්ගෙන් එක් අයෙකු SQL ලොජරයක් තැනීමට ඔබට අවශ්‍ය යැයි කියමු.

ඔබ අතුරු මුහුණතක් නිර්වචනය කර පහත දැක්වෙන පිරිවිතරයන්ට අනුව SQL විශේෂිත ල ger ු-සටහනක් ලබා ගැනීමට කැමති බව ඔබේ සංවර්ධකයින්ගෙන් ( හෝ ඔබ Agile භාවිතා කරන්නේ නම් කතාවක් සාදන්න) විමසන්න :

interface ILogger
{
    void Log(string message, int level);
}

මම පසුව සංවර්ධකයෙකුගෙන් බලාපොරොත්තු වන්නේ පහත සඳහන් දේ ය:

1. ලොගර් සඳහා SQL විශේෂිත ක්‍රියාත්මක කිරීම

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. ක්‍රියාත්මක කිරීම වැනි ඕනෑම යැපෙන කේතයක් SqlLogRepository

3. ඉල්ලූ දේ අනුව ඒකකය හෝ විහිළු පරීක්ෂණ. ඉහත නඩුවේ ව්‍යාජ පරීක්ෂණයක් (අපට වෙනත් බාහිර පරායත්තතා ඇති), හෝ එය උදා වැනි සරල උපයෝගීතා ශ්‍රිතයක් නම් String.ReverseCharacters(string input), වෙනස් අවස්ථා කිහිපයක් පරීක්ෂා කරන ඒකක පරීක්ෂණ බැලීමට මම කැමතියි.

මෙයින් අදහස් කරන්නේ:

ඔබට සහ ඔබේ කණ්ඩායමට මෙම අතුරු මුහුණත භාවිතයෙන් සංවර්ධනය දිගටම කරගෙන යා හැකිය. උදා

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

ඔබේ කේතය ක්‍රියාත්මක වීමට පෙර ක්‍රියාත්මක කිරීමට අවශ්‍ය නම් SqlLogger, ඔබට මෙය සරල ලෙස නිර්මාණය කළ හැකිය NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

මේ අතරතුර ඔබට එය පරීක්‍ෂා කළ හැකි ආකාරය මෙයයි (යැපුම් එන්නත් කිරීම සඳහා ICO දෙස බැලීමට මම යෝජනා කරමි)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

සාරාංශය

ඔබේ ව්‍යාපෘතියේ ප්‍රමාණය ගැන මට කිසිම අදහසක් නැත, නමුත් මෙය තරමක් අසීරු කාර්යයක් විය හැකි අතර, ඔබ මීට පෙර කිසි විටෙකත් සංවර්ධන පෙරමුණ ගෙන නොමැති නම්, මම ඔබට යෝජනා කරන්නේ ඔබ මෙම කාර්යය ඉතා බැරෑරුම් ලෙස සලකන අතර ඉදිරි සති කිහිපය ඔබ තරම් කියවා ගත කරන ලෙසයි. මෘදුකාංග නිර්මාණය සහ ගෘහ නිර්මාණ ශිල්පය පිළිබඳ. හා ඉතා විනිවිද ඔබේ වැඩ කටයුතු ගැන ( මෘදුකාංග තත්ත්ව ආදිය ) වෙනත් ආකාරයකින් ඔබට ඉක්මනින් ඔබ ගැඹුරු අවුල් ඔබ පිටතට ලබා ගැනීමට කෙසේ දැයි මා දන්නේ නැහැ බව ඔබට පෙනී යනු ඇත.

මම ඔබට තරයේ යෝජනා කරන්නේ ඔබ නිර්මාණය සහ වස්තු දිශානත පරමාදර්ශය කියවන ලෙසයි. මෙම ව්‍යාපෘතිය සඳහා ඔබ OOP මත දැඩි ලෙස විශ්වාසය තබනු ඇත.

අනෙක් පිළිතුරු ක්‍රමලේඛන අංශ ගැන කතා කර ඇත, නමුත් මට අවශ්‍ය වූයේ වැඩසටහන් කළමනාකරණ පැතිකඩ ගැන සඳහන් කිරීමට ය. මම වියාචනයකින් ආරම්භ කරමි: මම වැඩසටහන් කළමනාකරුවෙක් නොවේ. වැඩසටහන් කළමනාකරණය සඳහා මම උපාධි මට්ටමේ එක් පා course මාලාවක් හැදෑරූ අතර මගේ සේවා පළපුරුද්ද සාමාන්‍යයෙන් පැය 500 ට අඩු හා කිසි විටෙකත් පැය 1000 ට නොඅඩු කුඩා ව්‍යාපෘති සඳහා ලංසු තැබීමේ වේලාවන් ඇතුළත් වේ.

නමුත් මට 2-3 දෙනෙකු මාස ​​2-4 ක් (අර්ධකාලීන හා පූර්ණ කාලීන) කාර්යබහුල කර තබා ගත යුතු විද්‍යාගාරයක් සඳහා කාර්යයන් අර්ථ දැක්වීමට මට උදව් කිරීමට සිදුවිය. මයික්‍රොසොෆ්ට් ප්‍රොජෙක්ට් වැනි ව්‍යාපෘති කළමනාකරණ මෘදුකාංග භාවිතා කිරීම මට සැබවින්ම උපකාර කළ එක් දෙයක් (එහි නිදහස් මෘදුකාංග අනුවාදයක් තිබේදැයි මට විශ්වාස නැත, නමුත් ඔබේ සේවායෝජකයාට ඒ හා සමාන යමක් තිබේදැයි ... ඔබේ අධීක්ෂකගෙන් විමසන්න කුමන ආකාරයේ වැඩසටහන් කළමනාකරණ මෘදුකාංගයක් භාවිතා කරන්නේද යන්න ඔබේ සමාගමේ). විශේෂයෙන්, මම ගැන්ට් ප්‍රස්ථාර තරමක් භාවිතා කරමි, එය මයික්‍රොසොෆ්ට් ව්‍යාපෘතියේ පෙරනිමි දසුනයි. සියලු කාර්යයන් නිර්වචනය කිරීමෙන් සහ ඔවුන් කොපමණ කාලයක් ගතවනු ඇතැයි ඔබ සිතන්නේද, ඔබට සෙල්ලම් කිරීමට දෘශ්‍යකරණයක් ලබා ගත හැකිය.

ගැන්ට් ප්‍රස්ථාරය මට බොහෝ සෙයින් උපකාරී වන්නේ එහි දෘශ්‍යකරණය නිසාය. කඩදාසි මත කාර්යයන් දැකීම මට බොහෝ සෙයින් උපකාරී නොවේ, නමුත් ලස්සන පින්තූර සහ ප්‍රස්ථාරයක් දැකීම නිසැකවම උපකාරී වේ. මයික්‍රොසොෆ්ට් ප්‍රොජෙක්ට් මඟින් ඔබට පූර්වගාමීන් සහ ආරම්භක දිනයන් සැකසීමට ඉඩ සලසයි, ප්‍රධාන අදහස වන්නේ “X කාර්යය ආරම්භ කිරීම සඳහා සම්පූර්ණ කළ යුතු අවම කාර්යයන් සොයා ගන්න” යන්නයි. අවම වශයෙන් මගේ කුඩා ව්‍යාපෘති වලදී, 'සැබෑ' පූර්වගාමීන්ගේ ප්‍රමාණය තරමක් කුඩාය. ඇත්ත වශයෙන්ම, එක් ව්‍යාපෘතියක සෑම දෙයක්ම පාහේ සමගාමීව කළ හැකි බවට මට ගැටලුවක් ඇති වූ අතර තරමක් සංයුක්ත වූ සමගාමී මාර්ග දෙකක් සංස්ලේෂණය කිරීමට මට සිදුවිය. උදා: මම සංවර්ධක A කවදා හෝ GUI ස්පර්ශ කර ඇත්නම්, ඔවුන් GUI ට ආසන්න කාර්යයන් සඳහාද ක්‍රියා කරන බවට වග බලා ගැනීමට මම උත්සාහ කළෙමි.

පෑන සහ කඩදාසි යන තාක් දුරට ඔබ මේ වන විටත් බොහෝ දේ කර ඇති බවක් පෙනේ, නමුත් ඇත්ත වශයෙන්ම ගැන්ට් ප්‍රස්ථාර දැකීම ඇත්තෙන්ම ප්‍රයෝජනවත් බව මට පෙනේ. අනුපිළිවෙලින් පෙලගැසී ඇති කාර්යයන් දෙස බැලීමෙන් මට සිතෙන්නේ "ඉන්න, X කාර්යය Y කාර්යයට පෙර සැබවින්ම කළ යුතුද? (මගේ අත්දැකීම් අනුව, පිළිතුර ඇත්ත වශයෙන්ම 'නැත' යන්න කොපමණ වාරයක්දැයි මම පුදුමයට පත් වී සිටිමි)"

ඔබ සංවර්ධකයෙකු සිට මෘදුකාංග ඉංජිනේරුවෙකු වීම දක්වා උපාධිය ලබා ඇති බව පෙනේ. වැඩ කළමනාකරණය කිරීම නිර්මාණ අභ්‍යාසයක් නොවන බව වටහා ගන්න, නමුත් දෙදෙනා අත්වැල් බැඳ ගනී. ඔබ විසින් සිදු කරනු ලබන වැඩ කළමනාකරණය කළ යුතු අතර, එය ඔබේ සමාගම සංවර්ධනය කරන්නේ කෙසේද යන්න මත රඳා පවතී. ඔබට කාලය හා සම්පත් තිබේ නම්, ඉක්මන් ක්‍රමවේදයක් අනුගමනය කිරීම දෙස බලන්න - අන්තර්ජාලයේ ලිඛිත ද්‍රව්‍ය කඳු තිබේ. ඔබ වෙනුවෙන් වැඩ කරන එකක් සොයා ගන්න, නමුත් අනෙක් සියල්ල මෙන් එය නොමිලේ නොවන බව මතක තබා ගන්න. ඕනෑම ශිල්පීය ක්‍රමයක් අනුගමනය කිරීම යනු ඔබ සාර්ථක වීමට පෙර පුහුණුව, ඉගෙනීම සහ අසමත් වීමයි. වඩාත් පුළුල් ක්‍රමවේදයක් අනුගමනය කිරීමට ඔබට කලාප පළලක් නොමැති නම්, සන්ධිස්ථාන සැළසුම් කිරීම ඔබට පිළිතුර විය හැකිය. ඔබ සතුව අනුක්‍රමික කාර්යයන් ලැයිස්තුවක් තිබේ නම්, ඔබට හැකි අනුක්‍රමයන් හමු නොවීම එය විය හැකියසමාන්තරකරණය කරන්න. ඔබේ සංවර්ධනය පරීක්ෂා කිරීම සහ ක්‍රියාත්මක කිරීම වැනි සාමාන්‍ය කාර්යයන් වලට බෙදීමට ඔබට අවශ්‍ය විය හැකිය. එය, වාර්තා කිරීමේ ගැටලුව තනිවම විසඳන්නේ නැත, නමුත් ඔබ ගුණාත්මකභාවය කළමනාකරණය කරයි. ඔබේ දියුණුව අනුක්‍රමික ලැයිස්තුවක් විය හැකි නමුත් ඔබේ භූමිකාවන් සමාන්තර වේ. යෝජනාවක් පමණි. මිනිසුන් විසින් කරන ලද කාර්යයන් සිතියම් ගත කරන සැලසුමක් වැඩ බිඳවැටීමේ ව්‍යුහයක් ලෙස හැඳින්වේ.

අනෙක් අය ඉදිරිපත් කළ හොඳ යෝජනා රාශියක් ඇත, නමුත් ඔබ වැඩ කළමනාකරණය කරන බව මතක තබා ගන්න. සමහර විට ඔබට වැඩ සංකල්ප සැලසුම් / ගෘහ නිර්මාණ ශිල්පයට සිතියම් ගත කළ හැකිය, සමහර විට ඔබට එය එතරම් පහසුවෙන් කළ නොහැක. වැඩ කටයුතු නිරීක්ෂණය කිරීමට සෑම විටම ක්‍රමයක් ඇත. ඔබේ කළමනාකරු වෙත ආපසු ගොස් ව්‍යාපෘතියේ තත්වය සන්නිවේදනය කිරීමේදී ඔහුට වැදගත් වන්නේ කුමක්දැයි විමසන්නැයි මම යෝජනා කරමි. එය ඔබ කරන දෙයට ප්‍රවේශ වන්නේ කෙසේදැයි ඔබට කියන්නට පටන් ගනී. එය කාලසටහනක් නම්, ඔබට ප්‍රගතිය වාර්තා කිරීම කෙරෙහි අවධානය යොමු කිරීමට අවශ්‍යය. එය ගුණාත්මක නම්, ඔබට ඉදිරිපත් කළ යුතු ප්‍රමිතික කට්ටලයක් පිළිබඳව වාර්තා කිරීමට ඔබට අවශ්‍යය. එහි පිරිවැය නම්, ඔබට බොහෝ විට උත්සාහය දෙස බැලීමට අවශ්‍ය වනු ඇත. ඒ සෑම දෙයක්ම කාර්යයන් තුළට හෝ පිටතට සිතියම් ගත කළ හැකිය.