“මිථ්‍යා මිනිසාගේ මාසය” සිට “ශල්‍ය කණ්ඩායම” රටාවට සිදු වූයේ කුමක්ද?

මීට වසර ගණනාවකට පෙර, මම The Mythical Man-Month කියවන විට, වෙනත් මූලාශ්‍රවලින් මා දැන සිටි බොහෝ දේ මට හමු විය. කෙසේ වෙතත්, 1975 සිට පොත තිබියදීත්, එහි අලුත් දේවල් ද විය. ඒවායින් එකක් වූයේ:

ශල්‍ය කණ්ඩායම

මිල්ස් යෝජනා කරන්නේ විශාල රැකියාවක සෑම අංශයක්ම කණ්ඩායමක් සමඟ සම්බන්ධ කර ගත යුතු නමුත් කණ්ඩායම හොග්-බට්චරින් කණ්ඩායමකට වඩා ශල්‍ය කණ්ඩායමක් මෙන් සංවිධානය කළ යුතු බවයි. එනම්, එක් එක් සාමාජිකයා ගැටලුව කපා හැරීම වෙනුවට, එක් අයෙකු කැපීම සිදු කරන අතර අනෙක් අය ඔහුගේ effectiveness ලදායීතාවය සහ tivity ලදායිතාව ඉහළ නැංවීමට හැකි සෑම සහයෝගයක්ම ලබා දෙයි.

මෙය මෘදුකාංග සංවර්ධන කණ්ඩායමක් සංවිධානය කිරීම සඳහා ඉතා සිත්ගන්නාසුලු රටාවකි, නමුත් වෙනත් කිසිදු මෘදුකාංග ඉංජිනේරු පොතක එය කිසි තැනක සඳහන් කර නැත.

ඇයි ඒ?

• එවකට “ශල්‍ය කණ්ඩායම” පවා අසාමාන්‍යද?
• නැත්නම්, එය උත්සාහ කර අසාර්ථක වී තිබේද?
  • එසේ නම්, එය අසාර්ථක වූයේ කෙසේද?
  • එසේ නොවේ නම්, වර්තමාන මෘදුකාංග ව්‍යාපෘතිවල එම රටාව ක්‍රියාත්මක නොවන්නේ ඇයි?

"මිථ්‍යා මිනිසා-මාසය" එළියට ආවේ මම විද්‍යාලය ආරම්භ කළ වසරේ සිට වන අතර එය වර්තමාන ස්වභාෂාව වන UUUGE භාවිතා කිරීමට විය! :-) ඔබ තේරුම් ගත යුතු දෙය නම් දැන් මෘදුකාංග සංවර්ධනය කළ ආකාරයෙහි වෙනසයි. ආපසු දවසේ (ටීඑම්) බොහෝ කේතීකරණ කටයුතු මුලින්ම සිදු කළේ කඩදාසි මත ය, පසුව යතුරු පුවරුව මතට තල්ලු කර (ඔබ එය අනුමාන කළ) පන්ච් කාඩ්පත් මත කියවා, පසුව කියවා, සම්පාදනය කර, සම්බන්ධ කර, ක්‍රියාත්මක කර, ප්‍රති results ල ලබා ගත් අතර ක්‍රියාවලිය නැවත සිදු විය. CPU කාලය මිල අධික වියසහ සීමිත සම්පතක් වන අතර ඔබට එය නාස්ති කිරීමට අවශ්‍ය නොවීය. ඩිටෝ සහ ඒ හා සමානව තැටි අවකාශය, ටේප් ඩ්‍රයිව් වේලාව යනාදිය. (කම්පනය සහ භීෂණය!) දෝෂ වලට තුඩු දුන් සම්පාදනයක දී හොඳ CPU කාලය නාස්ති කිරීම ... හොඳයි, හොඳ CPU කාලය නාස්ති කිරීමකි. මෙය 1975 දී සිදු විය. 1960 ගණන්වල මැද භාගයේ සිට අග භාගය වන ෆ්‍රෙඩ් බ ok ක්ස් සිය අදහස් වර්ධනය කරමින් සිටියදී ඊටත් වඩා වැඩි වියමිල අධික, මතකය / තැටිය / ඊටත් වඩා සීමිත යනාදිය යනාදිය. රැකියා ඉදිරිපත් කිරීම, ප්‍රති .ල සඳහා (සමහර විට පැය ගණනක්) බලා සිටීම. රොක්ස්ටාර් මචන් සංවර්ධක මිනිසා ලිවීමේ කේතය විය. ඔහුගේ කණ්ඩායම් / ලිපිකරුවන් / කනිෂ් develop සංවර්ධකයින්ගේ ලෞකික දේ කළ යුතුව තිබුණි.

ගැටළුව වූයේ බ Bro ක්ස්ගේ පොත ප්‍රකාශයට පත් කර වසර 2 ක් ඇතුළත ශල්‍ය කණ්ඩායම පිටුපස ඇති මූලික අදහස් බිඳවැටීමයි:

1. සීආර්ටී ටර්මිනල් සහ ඩිස්ක් ලිපිගොනු යතුරුපන්ච් සහ කාඩ් තට්ටු ආදේශ කිරීමට පටන් ගත්තේය. පරිගණක කාලය අඩු වියදම් බවට පත්විය, පරිගණක කිහිපයක් ලබා ගත හැකි විය, සහ රැකියා ආපසු හැරවීමේ කාලය නාටකාකාර ලෙස පහත වැටුණි. මම විශ්ව විද්‍යාලයට යන විට (මයාමි විශ්ව විද්‍යාලය, ඔක්ස්ෆර්ඩ්, ඔහියෝ, '79 පන්තිය, ඇසීමට ස්තූතියි) හොඳයිරැකියා පිරිවැටුම පැයක් පමණ විය. අවසාන සතිය තුළ - පැය හතරක්, සමහර විට, සමහර විට හය. (අපි වාණිජ සමාගම් සහ විශ්ව විද්‍යාල සමූහයක් සමඟ CPU කාලය සඳහා තරඟ කළෙමු - වාණිජ පරිශීලකයින්ට පළමු ප්‍රමුඛතාවය හිමි විය). මගේ ජ්‍යෙෂ් senior වර්ෂය තුළ, මියාමි ඔවුන්ගේ "හවුල් පරිගණක" විධිවිධානයෙන් මිදී, ඔවුන්ගේම අයිබීඑම් 370/145 කැම්පස් තුළ ස්ථාපනය කර ඇති අතර, ඒ සඳහා මා වැඩ කළ ලස්සන HP මිනි එකක් තිබුනේ ආර්ජේඊ දුම්රිය ස්ථානයක් ලෙසිනි. මිනිත්තු පහකින් හෝ ඊට අඩු කාලයකින් රැකියා. ඔබගේ කේතය HP මතට තට්ටු කිරීම, HP වෙතින් ප්‍රධාන රාමුවට යැවීම, ඔබේ මාපටැඟිලි ඇඹරීම / සිගරට් එකක් පානය කිරීම සහ ඔබේ කේතය මේසය පරීක්ෂා කිරීම අවසන් කිරීමට බොහෝ කලකට පෙර ඔබේ ප්‍රතිදානය නැවත ලබා ගැනීම වටී.

2. ඔබට (හෝ "කළමනාකරණය", දෙවියන් වහන්සේ අප සැමට උදව් කරයි) රොක්ස්ටාර් ශල්‍ය සංවර්ධක මචන් හඳුනාගත හැකිය යන අදහස ශල්‍ය කණ්ඩායමට ඇත. ඇත්ත වශයෙන්ම, එය විය හැකි යැයි මට සැකයි. එහි සිටින සෑම කෙනෙකුටම එය දන්නේ නළු සංවර්ධකයින්, - අධ්යයන 2000% තරම් හොඳම හා නරකම සංවර්ධකයින් අතර ඵලදායිතා වෙනස්කම් පෙන්වා දී ඇත - නමුත් එම පුද්ගලයා හඳුනා එය දිගු කාලයක් තිස්සේ ඔවුන් කපා කේතය තොරවබොහෝ දුරට කළ නොහැකි ය. යමෙකු රොක්ස්ටාර් සංවර්ධකයෙක් දැයි දැන ගැනීමට ඇති එකම ක්‍රමය නම් ඔවුන් සැබවින්ම කේත සංවර්ධනය කිරීමයි - නමුත් ඔවුන් රොක්ස්ටාර් ශල්‍ය සංවර්ධක මචන් නොවේ නම් ඔවුන් කරන්නේ ඔහුගේ කේතය මේසය පරීක්ෂා කිරීම, කාඩ්පත්වලට යතුරු එබීම සහ සිත් ඇදගන්නා සුළු දේවල් ය. පන්ච් කාඩ්පත් පෙට්ටි රැකියා ප්‍රවේශ දෙපාර්තමේන්තුවට යොමු කිරීම, පසුව ප්‍රති results ල බලාපොරොත්තුවෙන් සිටගෙන ඔවුන්ට රොක්ස්ටාර් ශල්‍ය සංවර්ධක මචන් වෙත ආපසු යා හැකි අතර ඇත්ත වශයෙන්ම ක්‍රියාත්මක වන එකම ක්‍රමය කේත කිරීමට ඉගෙන ගැනීම වෙනුවට - කේත ලිවීම, නිදොස්කරණය කේතය, සහ යනාදිය නැවත දවසේ (ටීඑම්) ක්‍රමලේඛන තරඟ නොතිබුණි, තොග පිටාර ගැලීමක් නොතිබුණි, ඔබට පරිගණකයක් නොතිබුණි, ඔබට එය දැනෙන සෑම විටම කේත ලිවීමට යා හැකිය, මෝඩ පොත් සඳහා ඇල්ගොරිතම කිසිවක් නොතිබුණි - ක්‍රමලේඛනය ඉගෙන ගැනීමට ඇති එකම ක්‍රමය පාසැලට යාම සහ ඔබට ටිකක් ක්‍රමලේඛනය කිරීමට සිදු වූ තැනක ප්‍රධාන දෙයකි. නමුත් වැඩසටහන්කරණයper se ගැන බැරෑරුම් ලෙස නොසැලකූ අතර එය මිනිසුන්ට කිරීමට අකමැති දෙයක් ලෙස උපකල්පනය කරන ලදි . මගේ පළමු විද්‍යාල පා course මාලාවේදී (SAN151 - පද්ධති විශ්ලේෂණය පිළිබඳ හැඳින්වීම, ආචාර්ය ටොම් ෂාබර් - ස්තූතියි, ටොම් :-) අපට උපදේශකයා විසින් පවසා ඇත්තේ “... අපට වියදම් කිරීමට සිදුවනු ඇත යන කාරණයට අපට මුහුණ දීමට සිදුවිය. අපි පද්ධති විශ්ලේෂකයින් වීමට පෙර ක්‍රමලේඛකයන් ලෙස වසර කිහිපයක් ”. "අවුරුදු දෙකක්?", මම හිතුවා. "මට මෙය වසර දෙකක් සඳහා පමණක් කළ හැකිද?!?". මම බරපතල ලෙස කම්පා විය. ස්තූතියි, ඔහු වැරදියි, මම එතැන් සිට කේත කරමින් සිටිමි. :-)

3. ශල්‍ය වෛද්‍ය කණ්ඩායම උපකල්පනය කරන්නේ ක්‍රමලේඛකයින් සාපේක්ෂව දුර්ලභ සම්පතක් බවයි. ඇත්ත වශයෙන්ම එයට තවත් වසර කිහිපයක් ගතවිය, නමුත් 80 දශකයේ මුල් භාගයේ පළාත් සභා පැමිණීමත් සමඟ ඕනෑම ගීක්කරුවෙකුට සම්බන්ධ විය හැකි දෙයක් බවට පත්විය. පරිගණකවල මිල පහත වැටෙන්නට පටන් ගත්තේය, සංවර්ධන මෙවලම්වල මිල පහත වැටීමට පටන් ගත්තේය, ඒ සියල්ලම හිම කැට ටර්බෝ පැස්කල් - වර්තමාන ප්‍රමිතීන්ට අනුව එය එතරම් නොවූ නමුත් එකල එය බාස්කට් 40 ක් සඳහා සම්පූර්ණ පැස්කල් IDE එකක් විය. දැන් ඕනෑම කෙනෙකුට ක්‍රමලේඛයට පිවිසිය හැකිය - ඔබට පරිගණකයක් ලබා ගත හැකි නම්, සහ අයිබීඑම් විසින් පීසීජර් තැබීමට තීරණය කළ විට (ඔව්, මගේ පළමු පරිගණකය අයිබීඑම් හි ලොකුම වැරැද්දකි :-) එම තුර්කියෙන් මිදීමට ඩොලර් 500 කට විකිණීමට ඇත, මුදල් සෑම තැනකම සිටින ගීක්වරු මාසයක් සඳහා ඔවුන්ගේ කුලී ගෙවීම් මඟ හැරියහ ("ඔව්, අහ්, මම දනිමි, නමුත් මම, අහ් ... මගේ උවුලාව කැඩී ගොස් ශල්‍යකර්මයක් කිරීමට සිදු විය .. .උහ් ... ඔව්, ලබන සතියේ, ප්‍රශ්නයක් නැහැ, ස්තූතියි, මිනිසා ...) සහ ගිනි විකුණුම් මිල ගණන් වලට ඔවුන්ව උරා ගත්තා. පරිගණකය භාවිතයට ගත හැකි වන පරිදි අපි ඇඩෝන සඳහා ගෙවූ මුදලට වඩා වැඩියෙන් වියදම් කළෙමු. ("ඔව් මචං, ලබන සතියේ, නිසැකවම, බොහෝ විට ..." :-).

මට ඇත්තටම කනගාටුදායක කාරණය නම්, අද පවා ඔබ මිනිසුන්ගෙන් “මිථ්‍යා මිනිසා-මාසය” කියවා ඇත්දැයි හෝ එහි ප්‍රධාන පාඩම තේරුම් ගෙන ඇත්දැයි ඇසුවොත් (“ප්‍රමාද වූ ව්‍යාපෘතියකට සම්පත් එකතු කිරීම පසුව සිදු කරයි”) ඔවුන් ඔබට හිස් එකක් ලබා දෙයි බැලූ බැල්මට - ඉන්පසු OS / 360 සංවර්ධනය කිරීමේදී එම වසර ගණනාවකට පෙර සිදු වූ වැරදි සිදු කිරීමට ඉදිරියට යන්න. පැරණි සියල්ල නැවත අලුත් ය:: -}

බව එම සංකල්පය සමහර අංග ඇත ඇත අද සමහර විට ක්රියාත්මක වන බව තවත් පැති තියෙනවා වැලකී .

කණ්ඩායම් කුඩා ලෙස තබා ගැනීම Agile ක්‍රමවල මූලික ලක්ෂණයකි, නමුත් එය Agile වලින් පිටත ක්‍රියාත්මක වේ.

හරස්-ක්‍රියාකාරී කණ්ඩායම් ද ඇජිල්හි ප්‍රධාන ආහාර වේ, නමුත් ඇජිල්ට පිටතින් ද පොදු ය.

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

ඒ හා සමානව, පද්ධති පරිපාලකගේ කාර්යභාරය (මිල්ස්ගේ ශල්‍ය කණ්ඩායමේ කොටසක් නොව, පසුගිය වසරවල සාමාන්‍ය හරස් ක්‍රියාකාරී කණ්ඩායමක කොටසක්) ඩිවෝප්ස් වැනි සංකල්ප මගින් යල් පැන ඇත (මෘදුකාංග ඉංජිනේරුවරයාගේ භූමිකාවට සිසැඩ්මින්ගේ භූමිකාව උරා ගනිමින්) , වේදිකාවක්-සේවාවක් ලෙස, යටිතල පහසුකම්-සේවාවක් ලෙස, සහ උපයෝගිතා පරිගණකකරණය (සිසැඩ්මින්ගේ භූමිකාව “වෙනත් කෙනෙකුගේ ගැටලුවක් බවට පත් කිරීම”), හෝ යටිතල පහසුකම්-කේතයක් ලෙස (පද්ධති පරිපාලනය මෘදුකාංග ඉංජිනේරු විද්‍යාව බවට පත් කිරීම).

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

අවසාන වශයෙන්, එම සංකල්පය තුළ පිළිස්සූ සමහර උපකල්පන යල් පැන ගිය ඒවා ය. උදාහරණයක් ලෙස, එය නිශ්චිතව ප්‍රකාශ කර නොතිබුණද, කණ්ඩායම පිහිටුවා ඇත්තේ කණ්ඩායමේ එක් පුද්ගලයෙකුට (ශල්‍ය වෛද්‍යවරයාට) ඇත්ත වශයෙන්ම පරිගණකයක් ඇති ආකාරයටය. ඇත්ත වශයෙන්ම, ලිපිය ලියන අවස්ථාව වන විට, කණ්ඩායමේ එක් පුද්ගලයෙකුට පමණක් නොව, සමස්ත කණ්ඩායමකටම එක් පරිගණකයක් තිබිය යුතුය යන අදහස පවා දිගු කිරීමකි. (1980 දී ස්මාල්ටෝක් නිකුත් කරන විට පවා එහි අසාර්ථකත්වයට හේතු වූ එක් කරුණක් වූයේ පද්ධතිය සකසා තිබීමයි. සෑම සංවර්ධකයෙකුටම සහ සෑම පරිශීලකයෙකුටම තමන්ගේම පරිගණකයක් තිබීම - ඒ වන විට සම්පූර්ණයෙන්ම සිතාගත නොහැකි විය.)

ඒ නිසා, කෙටි: මම හිතන්නේ නැහැ සංකල්පය විස්තර කර ඇති පරිදි හරියටම ක්රියාත්මක කර ඇති, නමුත් එය සමහර අංග අනිවාර්යයෙන්ම ඇත ක්රියාත්මක, සමහර අංග අනවශ්ය ලෙස දැකිය අතර ක්රියාකාරීව වැලකී, සමහර යල් පැන ගිය අතර, සමහර බොහෝ විට යහපත් අදහස් වේ ™, නමුත් කිසිවෙකු එය නොකරයි.

එය ඉස්සර විශ්ව විද්‍යාල අධ්‍යාපනයක් අද්විතීය දෙයක් වූ අතර තෝරාගත් කිහිප දෙනා අතර ඉංජිනේරුවන් ද විය. පරිගණක මිල අධික වූ අතර කණ්ඩායම් අර්ථ දැක්වූ ව්‍යාපාර රෝයි සමඟ ව්‍යාපෘතිවල වැඩ කළහ. මේවා එතරම් සුලභ නොවීය.

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

8: 2 ආධාරකයේ ආර්ථික විද්‍යාව: ඉංජිනේරු අනුපාතය තවදුරටත් අර්ථවත් නොවේ. ඉංජිනේරුවන් ඔවුන්ගේම සහාය විය යුතුය. සංවර්ධන කණ්ඩායමකට effective ලදායී ලෙස සම්බන්ධ වීමට ප්‍රමාණවත් අධ්‍යාපනයක් හා කුසලතා ඇති නූතන මිනිසෙකු කිසියම් ආකාරයක තමන්ගේම සංවර්ධනයක් නොකිරීමට තරම් මිල අධිකය.

(ආශ්‍රිත ආර්ථික විද්‍යාව යනු "සේවා අංශයේ පිරිවැය රෝගයයි.")

මෙම රටා මොබ් ක්‍රමලේඛනය මෙන් මට බොහෝ සෙයින් පෙනේ:

මුළු කණ්ඩායමම (QA, සංවර්ධකයින් සහ අවශ්‍ය නම් නිෂ්පාදන හිමිකරු පවා) එකම වේලාවක එකම ගැටලුවක ක්‍රියා කරයි. නැගී සිටීම, ඉහළ සන්නිවේදනය, සජීවීව සෘජුවම යොදවා නැත.

Http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/ වෙතින්

මැර වැඩසටහන් වල මූලික සංකල්පය සරල ය: එකල එක් කාර්යයක් සඳහා මුළු කණ්ඩායමම කණ්ඩායමක් ලෙස ක්‍රියා කරයි. එනම්: එක් කණ්ඩායමක් - එක් (ක්‍රියාකාරී) යතුරුපුවරුව - එක් තිරයක් (ඇත්ත වශයෙන්ම ප්‍රක්ෂේපකය). එය හරියට පූර්ණ කණ්ඩායම් යුගල වැඩසටහන් කිරීම වැනි ය.

එය ක්‍රියාවෙන් බලන්න: https://www.youtube.com/watch?v=dVqUcNKVbYg

මෙම කණ්ඩායම් ආකෘතිය 305 වන පිටුවේ ස්ටීව් මැක්කොනෙල් විසින් වේගවත් සංවර්ධනය - වල් මෘදුකාංග කාලසටහන් හීලෑ කිරීමෙහි නැවත සඳහන් කර ඇත. එහිදී එය ප්‍රධාන වැඩසටහන්කරු කණ්ඩායම ලෙස හැඳින්වේ.

මෙම ආකෘතිය ඇති වූයේ කණ්ඩායමේ දක්ෂතා ඇති නිසා සහ පරිගණක සම්පත් සීමිත වූ බැවිනි. ජෙනියස් දුර්ලභ වන නිසාත්, සර්වබලධාරී පරිගණක සහ බෙදා හරින ලද අනුවාද පාලනයක් නිසාත් අපට මෙහෙයුම් මේසයේ බොහෝ දෑ සඳහා ඉඩකඩ තිබේ.

වෙනත් යොමු කිරීම්:

බේකර්, එෆ්. ටෙරී. "නිෂ්පාදන ක්‍රමලේඛනයේ ප්‍රධාන ක්‍රමලේඛක කණ්ඩායම් කළමනාකරණය," අයිබීඑම් සිස්ටම්ස් ජර්නලය, වෙළුම. 11, නැත. 1, 1972, 56-73 පි.

බේකර්, එෆ්. ටෙරී සහ හාර්ලන් ඩී. මිල්ස්. "ප්‍රධාන වැඩසටහන් කණ්ඩායම්." දත්තකරණය, 19 වන වෙළුම, අංක 12 (1973 දෙසැම්බර්), 58-61 පි.

මගේ අනුමානය නම් බොහෝ කුඩා ස්වයං-සංවිධාන කණ්ඩායම් කෙසේ හෝ තථ්‍ය ශල්‍ය කණ්ඩායම් ආකෘතියක් බවට පත්වීමට නැඹුරු වනු ඇති බවයි.

මා සිටි අවසන් කණ්ඩායම් දෙක පුද්ගලයන් තිදෙනෙකු හෝ හතර දෙනෙකුගෙන් සමන්විත වන අතර, සාමාන්‍යයෙන් එක් ජ්‍යෙෂ් senior යෙක් (ශල්‍ය වෛද්‍යවරයෙක්), අතරමැදි (සම නියමු) සහ කනිෂ් / යන් / විශේෂ ists යින් කිහිප දෙනෙකුගෙන් සමන්විත වේ. වර්තමානයේ බ ok ක්ස් සඳහන් කළ පරිදි ශල්‍ය කණ්ඩායමේ සමහර භූමිකාවන් පුරවා ඇත්තේ ස්ක‍්‍රම් මාස්ටර්ස් සහ සයිසැඩ්මින් හෝ වලාකුළු සපයන්නන් විසිනි. ප්‍රභව පාලනය එවකට පැවති බව මතක තබා ගන්න, git තරම් බලවත් දෙයක් පමණක් නොව.

බෙසොස්ගේ පීසා දෙකේ රීතිය ගැන සිතන්න. ඒක තමයි ඔයාගේ ස්වයං-සංවිධාන ශල්‍ය කණ්ඩායම.

HP වෙතින් පිටපතක් ඒ හා සමාන දෙයක් යෝජනා කළේය:

• සෑම මෘදුකාංග ඉංජිනේරුවරයෙකුටම බහු කළමණාකරුවන් සහ බහු සහායක පුද්ගලයින් අවශ්‍ය වේ.
• සෑම ඉංජිනේරුවෙකු සඳහාම තාක්ෂණික ලේඛකයෙකු, පරීක්ෂකයෙකු, ගොඩනැගීමේ කළමනාකරුවෙකු සහ මෙවලම් සාදන්නෙකු සිටිය යුතුය.

පුවත්පත පූර්ව වෙබ් දිනවල පැවති අතර වරින් වර එය විහිළුවක් ලෙස ගෙන එන ලදී. සෑම වසරකම එය ගෙන එන විට, විවරණය "හාස්‍යජනක හාස්‍යජනක" සිට "සමහර විට අප එය කළ යුතුය" යන්නට වඩා ටිකක් වැඩි විය.

තථ්‍ය පරීක්ෂණ සැලසුම් කිරීම කුප්‍රකට දුෂ්කර බැවින් එය බොහෝ විට මතයක් ලෙස පවතී. ව්යාපෘති පිළිබඳ සමහර සමීක්ෂණ සහ ඒවායේ නිම කිරීමේ අනුපාත තිබිය හැකිය.

අන්තර්ජාලය, ඒකාබද්ධ සංවර්ධන පරිසරයන් සහ මෘදුකාංග සංවර්ධන කට්ටල වැඩිවීම නිසා ශල්‍ය වෛද්‍ය කණ්ඩායමක අවශ්‍යතාවය කොතරම් අතිරික්ත වී ඇත්දැයි මම කල්පනා කරමි .

• ශල්‍ය වෛද්‍ය: ක්‍රමලේඛකයෙක්
• සම නියමු: යුගල ක්‍රමලේඛකයින් , සම සේවකයින්, ස්ටැක්එක්ස්චේන්ජ් හෝ අයිආර්සී වැනි සබැඳි ප්‍රජාවන්
• පරිපාලක: මෘදුකාංග ව්‍යාපෘති කළමනාකරුවෙකු විසින් සාමාන්‍යයෙන් ගනු ලබන කාර්යභාරය
• සංස්කාරක: ජාවඩොක් හෝ ඩොක්සිජන් වැනි ප්‍රලේඛන-ජනක යන්ත්‍ර ඒකාබද්ධ කරන IDEs; මෘදුකාංග සංවර්ධන කට්ටල වලින් ලියකියවිලි
• ලේකම්: විද්‍යුත් තැපැල් සේවාදායකයා, ව්‍යාපෘති කළමනාකරණ මෙවලම් වන ට්‍රැකර්ස් සහ අදින්න ඉල්ලීම්, සමාගම් චැට් රූම් සහ තැපැල් ලැයිස්තු
• වැඩසටහන් ලිපිකරු: ප්‍රතික්‍රියාකාරක කේතයට අමතර හැකියාවක් සහිතව ව්‍යාපෘති සැලසුම් පිළිබඳ තොරතුරු ගබඩා කිරීම; මෘදුකාංග සංවර්ධන කට්ටල වලින් ලියකියවිලි සහ උදාහරණ
• මෙවලම්කරු: සමස්ත විවෘත මූලාශ්‍ර ප්‍රජාව
• පරීක්ෂකයා: ක්ෂණික පදනමක් මත, පරීක්ෂණ කට්ටල සහ පරීක්ෂණ පුස්තකාල පරීක්ෂා කරන්න. නමුත් ඇත්ත වශයෙන්ම නිෂ්පාදන කේතය සඳහා වෙනම QA ක්‍රියාවලියක් අවශ්‍ය වේ.
• භාෂා නීති lawyer යා: මාර්ගගත ලියකියවිලි, ස්ටැක්එක්ස්චේන්ජ්

මම හිතන්නේ ඔබ The Mythical Man Month හි පරිශ්‍රය දෙස බැලිය යුතුය. වැඩිපුර ක්‍රමලේඛකයින් බඳවා ගැනීම ගැටළු සහගත / කල් ඉකුත් වූ මෘදුකාංග ව්‍යාපෘතියක් නරක අතට හැරේ. ගැටළුව වන්නේ සන්නිවේදනය සහ අලුතින් එකතු කරන ලද ක්‍රමලේඛකයින් ව්‍යාපෘතියේ වේගවත් කිරීම සඳහා (පවතින සංවර්ධනයෙන් කාලය ගතවේ), තාක්‍ෂණය සහ සමහර විට වසම ම ය.

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

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

මම තර්ක කරන්නේ, සැලසුම් කිරීම, ක්‍රියාත්මක කිරීම, පරීක්ෂා කිරීම, ප්‍රලේඛනය කිරීම, ගොඩ නැගීම, යෙදවීම, මෙහෙයුම් යනාදිය විශේෂ ists යින් විසින් සිදු කරනු ලබන අද්විතීය භූමිකාවන්ට වෙන් කරන තරමට, අපි “ශල්‍ය කණ්ඩායම්” දර්ශනය අනුගමනය කරන තරමට (සමහර විට හරියටම විස්තර කර ඇති ආකාරයට නොවේ) ).

මගේ අත්දැකීම් අනුව, සෑම පුද්ගලයෙකුටම සෑම කාර්යයක් සඳහාම හැකියාව තිබිය යුතුය යන ඩිවෝප්ස් දර්ශනය යනු හොග්-බට්චරින් ආකෘතියට නැවත පැමිණීමකි (එය නරක යැයි කීම නොවේ, වෙනස් ය).

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

ඩිවෝප්ස් ලෙස මම විශාල ක්‍රියාවලියක් සහ පොදු කාර්ය ස්වයංක්‍රීය කරමි. කණ්ඩායමේ, මුළු කණ්ඩායමේම, සංවර්ධකයින්ගේ, QA පරීක්ෂකයින්ගේ තොරතුරු තාක්‍ෂණය කළමණාකරනය දක්වාම පහසු කරවන තාක්‍ෂණයන් සහ මෙවලම් මම ගවේෂණය කරමි. මගේ කාර්යභාරය වූයේ ක්‍රියාවලිය තේරුම් ගැනීමයි, ඔව්; නමුත් එම ක්‍රියාවලිය භාවිතා කරමින් (දුක් විඳින) කණ්ඩායම (සැබෑ මිනිසුන්) වෙත මගේ දෑස් යොමු කර තබා ගැනීමෙන් මට එය සම්පූර්ණයෙන්ම විනිවිද පෙනෙන මට්ටමකට ගෙන ඒමට හැකි වූ අතර ඒ පිළිබඳ වෛෂයික දෘෂ්ටියක් ලබා ගැනීම සඳහා ප්‍රයෝජනවත් දත්ත රාශියක් ලබා ගනිමින් කවදාවත් නොපැහැදිලි "විශාල පින්තූරය".

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

ඉතින් ඔව්, මම හිතන්නේ ඒ භූමිකාව අදටත් ජීවමානයි. නමුත් එය පරිණාමය වූයේ එවකට පැවති දෙයට වඩා බව පිළිගත යුතුය.