Нещодавно я приєднався до девелоперського проекту і мені раптом було призначено роботу провідного розробника. Моя основна відповідальність - розбити програмувальну частину проекту на завдання, дати ці завдання іншим розробникам, а потім переконатися, що частини працюють разом.

Проблема в тому, що я не маю поняття, як це зробити. Я провів свої вихідні з олівцем і папером, намагаючись розібратися, але я продовжую складати список завдань, над якими слід працювати послідовно, а не паралельно. Я думав, можливо, розділити його на функції, але тоді ви закінчите завдання, які потребують редагування тих самих файлів, що може зажадати повністю переписати ціле завдання через те, як ми на початку розвитку. Я міг би змусити деяких розробників зачекати, поки програма трохи повніша і простіша у створенні завдань, але тоді я мав би людей, які сидять на руках, хто знає скільки тижнів.

Я мав розмову з моїм начальником про свою кваліфікацію робити це, і мені не було дано вибору в цьому питанні. Я поняття не маю, що роблю, тому будь-які поради та підказки в правильному напрямку були б дуже вдячні.

Правильна відповідь на ваше запитання заповнює кілька книг . Я придумаю перелік слів про гудіння, які мені приходять в голову з цього приводу, Google і книги зробить для вас все інше.

1. Основи

   • Не йдіть наодинці . Постарайтеся максимально залучати своїх товаришів по команді.
   • Подорожі легкі .
   • Демократія, але не надто багато. Іноді справа не в тому, що задовольняє найбільшу кількість людей, а в тому, що шкодить найменшій кількості людей.
   • Зберігайте, що (потрібно зробити) і як (це робиться) роздільно .
   • Дізнайтеся про Scrum ("що"), XP (екстремальне програмування, "як"), Kanban ("скільки"), Lean ("що ні") та DevOps ("з ким").
   • Lean також стосується потоку : для загальної ефективності ефективність потоку зазвичай важливіша, ніж ефективність індивідуального.
   • Дізнайтеся про майстерність програмного забезпечення , чистий код та прагматичне програмування .
   • Хороша архітектура - це максимізація кількості прийнятих рішень .
   • Scrum / XP / Lean / Agile - це максимізація обсягу незавершеної роботи : YAGNI .
   • Первинна вартість програмного забезпечення є те , що ви можете легко змінити його. Те, що він робить те, що має робити, важливо, але це лише його вторинне значення.
   • Віддайте перевагу ітеративному та поступовому підходу, використовуйте часові рамки майже для всього, особливо зустрічей, зробіть закон Паркінсона своїм другом, оскільки застосовується Закон Гофстадтера.
   • Збалансуйте структуру команди з розумінням закону Конвея та етапів розвитку команди .
   • Програмування - це суттєвість, це наука , інженерія , мистецтво та ремесло все одночасно, і вони повинні бути в рівновазі.
   • Тільки тому, що Scrum / XP / XYZ корисний для когось (включаючи мене), не обов'язково означає, що це добре для вас / підходить для вашого оточення. Не сліпо слідкуйте за ажіотажем, зрозумійте це спочатку.
   • Огляньте та адаптуйте! (Scrum Mantra)
   • Уникайте копіювання - раз і тільки раз! (XP Mantra) aka DRY - Не повторіть себе ака SPOT - Єдина точка істини

2. Процес зриву роботи "Який світ"

   • Зберіть вимоги як Історії користувачів / Історії роботи в Блокування продукту .
   • Користувач (з історії користувача) схожий на Actor (в UML), схожий на Persona, схожий на Role .
   • Вдосконалюйте Історії користувачів, поки вони не відповідають визначенню Вашої команди щодо готовості на основі INVEST (незалежний, договірний, цінний, оціночний, малий, перевіряється). (Scrum Meeting: уточнення відставання )
   • Сортуйте Блокування продукту за значенням бізнесу .
   • Не починайте роботу над історією раніше, ніж вона буде готова (готовий відповідно до визначення готового).
   • Використовуйте Планування покеру, щоб оцінити зусилля Історій в Story Points . Використовуйте порівняння триангуляції для забезпечення узгодженості оцінок.
   • Вчорашня погода - найкраща оцінка, сподіваюся, найгірша.
   • Розділити історії, якщо вони занадто великі.
   • Удосконалити культуру доставки за допомогою визначення Виконано .
   • Не приймайте реалізацію Історії користувача до того, як вона закінчена (зроблено згідно з Визначенням виконано).
   • Кілька команд, що знаходяться на одній базі коду, повинні узгодити та поділити одне і те ж Визначення Готово (особливо Стандарти кодування ).
   • Перевірте свій прогрес за допомогою графіків Burndown .
   • Регулярно перевіряйте зі своїми зацікавленими сторонами, чи потрібна команда, що дійсно потрібно. (Scrum зустріч: спринт огляд )

3. Розбиття історії

   • Список та опис користувачів / персон / акторів / ролей (власник продукту)
   • Епічні -> Історії (Історія користувача або Історія роботи) (Власник продукту)
   • Історія -> Критерії прийняття (власник продукту)
   • Історія -> Підзадачі (Команда розробників)
   • Критерії прийняття -> Тести прийняття (Spec: Власник продукту, Impl: Команда розробників)
   • Почніть з пішохідного скелета, який є мінімалістичним " Кінцем до (напівзакінчення)" .
   • Створіть MVP - мінімально життєздатний продукт .
   • Розгорніть MVP, використовуючи SMURFS - спеціально набір маркетингових, корисних, звільняються наборів функцій .

4. "Як світ" реалізація

   • Використовуйте OOA / D , UML та CRC карти , але уникайте великого дизайну наперед .
   • Реалізуйте об'єктно-орієнтовані , структуровані та функціональні водночас максимально незалежно від мови програмування.
   • Використовуйте Контроль версій (бажано розподілений ).
   • Почніть з тестів на прийняття .
   • Застосовуйте TDD , дозволяючи, щоб Три Закони TDD провели вас через цикл « Червоно-зелений-рефактор» , з правилом одиночного затвердження , 4 А , GWT (дано тоді) від BDD .
   • " Тестові одиниці - це тести, які швидко проходять ." - Майкл Пір'я
   • Застосовуйте принципи SOLID та пакет для управління зв'язком та згуртованістю . Приклад: S у SOLID є SRP = єдиний принцип відповідальності, значно зменшує кількість редагувань. злиття-конфлікти в командах.
   • Знайте закон Деметера / Скажи, не питай .
   • Використовуйте безперервну інтеграцію , якщо можливо, навіть безперервну доставку (DevOps).
   • Використовуйте власність колективного коду на основі узгодженого загального стандарту кодування (який повинен бути частиною визначення "Готово" ).
   • Застосовуйте безперервне вдосконалення дизайну (fka Безперервне рефакторинг).
   • Вихідним кодом є Дизайн . Все-таки випереджальне мислення є незамінним, і ніхто не буде заперечувати кілька хороших уточнюючих діаграм UML.
   • XP не означає, що день не день архітектури, це означає, що кожен день - це день архітектури. Це фокус на архітектурі, а не дефокус, а фокус - у коді.
   • Зберігайте технічний борг низьким, уникайте чотирьох дизайнерських запахів Крихкість , Жорсткість , Нерухомість і В'язкість .
   • Архітектура - це бізнес-логіка, а не механізм стійкості та доставки.
   • Архітектура - це командний спорт ( в архітектурі немає "Я" ).
   • Шаблони дизайну , рефакторинг та пріоритетні приміщення трансформації .
   • Код проекту - це ТРЕТ-Трійця з пріоритетами: 1. Код автоматизації , 2. Код тестування , 3. Код виробництва .
   • Регулярно перевіряйте разом з колегами по команді, чи можна покращити те, як вона працює. (Scrum Meeting: Sprint Retrospective )
   • Тести повинні бути ПЕРШИМИ - швидкими, незалежними, повторюваними, самовивіреними та своєчасними.

Наведений вище список, безумовно, неповний, а деякі частини можуть бути навіть спірними!

Якщо все це вас лякає - не хвилюйтесь, бо це повинно вас налякати! Успіх проектів розробки програмного забезпечення в командах не є легким завданням, і рідко люди мають належну підготовку та освіту в цьому мистецтві. Якщо це вас лякає, ваша інтуїція справно працює, слухайте її. Ви хочете бути готовими. Поговоріть зі своїм начальником, знайдіть трохи часу та тренуйтесь.

Дивитися також

• Хто пише технічні «розповіді користувачів» у scrum

Подальше читання (онлайн)

• Репозиторій узорів Портленда від Ward Cunningham et al
• Принципи ОО Роберта "Дядька Боб" К. Мартіна
• Поради щодо прагматичного програміста

Подальше читання (книги)

• Чистий код Роберта К. Мартіна
• Розробка програмного забезпечення Agile: принципи, зразки та практики Роберта К. Мартіна
• Прагматичний програміст - від мандрівника до магістра Ендрю Ханта та Девіда Томаса
• Ефективна робота зі спадковим кодексом Майкла Перу
• Рефакторинг - вдосконалення дизайну існуючого коду Мартіна Фаулера
• Рефакторинг на візерунки Джошуа Керієвського
• Десятиденна MBA Стівена Сілбігера (sic!)
• Дизайн, керований доменом Еріка Еванса
• Історії користувачів, застосовані Майком Кон
• Об'єктно-орієнтований аналіз та дизайн із додатками Gray Booch et al
• Шаблони дизайну бандою чотирьох
• Тест, керований розробкою Кента Бека
• Екстремальне програмування Кента Бека
• [якщо Java] Ефективна Java Джошуа Блоха

Станьте спритним

Я б запропонував таке:

Редагування тих же файлів

Спочатку скористайтеся Git (або подібною одночасною системою версій). Поки ви редагуєте різні частини одних і тих же файлів, у вас не виникають конфлікти. Якщо у вас виникнуть конфлікти, вони будуть чітко позначені як такі.

Намагатися керувати проектом для багатьох розробників без Git - це ніби намагатися зробити пудинг без чаші для пудингу. Це можливо, але це стане досить безладним досить швидко.

Як було зазначено в коментарях, Git не є панацеєю, але в поєднанні з автоматизованим тестуванням це, безумовно, дуже допомагає.

Перерахуйте всі функції

По-друге, розбийте проект на видимі для користувача функції. Наприклад, "коли користувач підписується, він повинен отримати електронний лист" або "Користувач може додати елемент". Залучайте сюди всіх зацікавлених сторін. Введіть усіх у кімнату, і всі викрикуйте їхні риси.

Це повинні бути видимі користувачеві функції, про стратегію впровадження можна поговорити пізніше.

Запишіть усі пропозиції на індексні картки, навіть німі. Швидко раціоналізуйте список, щоб видалити дублікати, і розкладіть всі картки на великому столі або навіть підлозі.

Додайте будь-які додаткові картки, які потрібні. Скажіть, що ваша програма надсилатиме SMS-повідомлення. Ви можете не знати, як це зробити, тому у вас є питання. Напишіть «Досліджуйте SMS-портали» на картці. Так само і для будь-яких інших великих невідомих. Їх вам доведеться розпакувати пізніше. Ці функції, ймовірно, не перейдуть у ваш перший спринт.

Тепер сортуйте ваші картки по групах, перетасуйте їх, відчуйте їх. Це ваш проект.

Планування покеру

Займіться плануванням покеру. Ще разом з усіма разом дайте всім розробникам картки, на яких написано "1 бал", "2 бали" тощо, до "4 балів". Також картка "більше". Точка приблизно еквівалентна годині.

Перегляньте список функцій по одному. Під час читання функції кожен повинен грати в карту. Якщо одна людина грає 1, а інша грає 4, там є проблема спілкування. Одна людина розуміє особливість, що означає щось відмінне від іншої людини. Проведіть дискусію та опрацюйте, що насправді малося на увазі, та відзначте це на картці.

Якщо ви погоджуєтесь, що функція "більше", ця функція занадто велика. Ви повинні зламати цю функцію. Робіть це так само, як і раніше.

Як ви домовились, запишіть цифри на картках різною кольоровою ручкою.

Бали кращі за години

Використання окулярів замість годин віднімає мачо "Подивіться, як швидко я можу кодувати", чим ми часто займаємось розробники. Це тонка різниця, але я виявив, що це працює досить добре.

Тепер складіть спринт

Спринт - це швидкий вибух до мети. Визначтеся із довжиною спринту, можливо, 5 або 10 днів. Помножте кількість днів на кількість розробників на кількість балів на день.

Припустимо, що спочатку 6 балів на день на розробника. Це досяжна кількість. Якщо у вас 5 осіб, це 5 * 5 * 6 = 150 балів. Спільно з усіма розробниками та керівництвом виберіть функції зі списку, до 150 балів. Це ваш спринт.

Ніколи не спокушайтеся стискати більше, ніж підходить. Занадто багатообіцяючий завдає шкоди всім у довгостроковій перспективі, включаючи вас.

Тут вам потрібно буде врахувати залежності. Наприклад, налаштування навколишнього середовища, очевидно, має бути включено в перший спринт. Це насправді порівняно легко зробити, коли всі присутні. У вас 6 мізків у приміщенні, всі говорять "це залежить від цього" і т. Д. Потім можна перемішувати карти навколо, щоб продемонструвати залежності.

Після того, як у вас є спринт, до нього нічого не можна додати, він заблокований на 5 днів. Повзання функцій підкреслить команду, пошкодить моральний стан і сповільнить усіх. Врешті-решт повзання зупинить проект. Як керівник команди, ви повинні захистити свою команду від повзучості. Якщо надходить новий запит на функцію, його потрібно додати до наступного спринту. ЯКЩО наступний спринт вже заповнений, щось інше треба вивезти.

Ніколи не піддавайся спокусі забивати зайві. Занадто багатообіцяюча ситуація дає вам щасливий клієнт близько 1 дня, а потім 4 дні напруженості в команді, і, врешті-решт, декілька нещасних клієнтів, коли команда не може доставити вчасно.

Тепер переходьте до цього.

Роздайте картки, запитайте, хто хоче чим займатися. Ви маєте повну видимість того, що робиться, і ви можете порахувати бали, що позначаються до нуля. Майте штаб-квартиру на початку кожного дня, щоб усі знали, хто над чим працює, і що було зроблено.

5 або 6 пристойних мотивованих розробників, які працюють разом, як підрозділ над чітко визначеними керованими цілями, можуть досягти неабиякої кучерявої кількості речей за 5-денний спринт.

Підтримуйте видимість

Переконайтесь, що кожен може бачити, який статус проекту. Bluetack всі карти до стіни. Зліва - картки, над якими ще не працює. Праворуч зроблені картки.

Коли розробник працює над карткою, вони знімають її зі стіни і ставлять на свій стіл. Це підтримує видимість і не дає людям занадто сильно наступати на пальці.

Існують технологічні альтернативи індексованим карткам, але нічого не обійдеш, коли на стіні є масивний паперовий дисплей статусу проекту.

По можливості, будьте всі в одній кімнаті протягом тривалості проекту. Запропонуйте зацікавленим сторонам якомога більше, в ідеалі кожен день.

Випалювати

Ви можете графік балів, які просуваються до нуля, на діаграмі перезарядки. Якщо ваша лінія найкращого пристосування перетинає нуль, перш ніж вдатися до обмеження часу, ви, швидше за все, на шляху. Якщо ні, то, можливо, вам доведеться повідомити свого клієнта зараз, перш ніж ви наблизитеся до граничного терміну.

Якщо ви збираєтеся невдачі, невдачі рано.

Можна зробити спалювання за допомогою програмного забезпечення, але я віддаю перевагу просто великий папір на стіні. Намалюйте та напишіть по всьому.

Автоматизоване тестування

Коли у вас є декілька розробників, які працюють над одними і тими самими матеріалами одночасно, вони, ймовірно, час від часу будуть порушувати код один одного. Комунікація та наочність допомагають у цьому, але ви, мабуть, захочете впровадити певну технологію, яка допоможе знайти проблеми.

Тестування одиниць - це процес написання тестів для кожної окремої частини кодової бази (в ідеалі кожного методу). Ваші одиничні тести слід виконувати часто, з можливістю кожного збереження. Існує багато інструментів, які можуть допомогти у цьому, наприклад, Karma або Rspec.

Тестування в кінці до кінця включає тестування вашого проекту в цілому, трактування внутрішніх справ як чорного поля. Базуйте ці тести на своїх бізнес-вимогах високого рівня, наприклад: "Користувач може зареєструватися" або "Користувач може переглянути список елементів". Транспортер є хорошим прикладом тестування рамок до кінця.

Існують цілі книги, написані на тестуванні, але наявність принаймні декількох тестів на прийняття може допомогти вам не порушити нічого, коли ви працюєте над своїм проектом.

Уникнення технічної заборгованості та завершення роботи

Технічна заборгованість - це концепція, яка описує речі, які доведеться прибрати пізніше. Поширеним джерелом боргу є риси, які були позначені як зроблені, але які ніколи не були "зроблені-зроблені". Зроблена функція зареєстрована в Git, затверджена зацікавленою стороною та має тест.

Не перевіряйте свої функції, поки вони не будуть готові. Ніколи не масажуйте графік. Знову ж таки, це шкодить усім у довгостроковій перспективі, включаючи вас.

Це одна з причин, чому ми спочатку за день розробляємо лише 6 балів на розробника. Готово вимагає додаткової роботи, але чудово почуває себе та дає команду поштовх.

Редагування тих же файлів саме по собі не є проблемою. Проблема є лише в тому випадку, якщо ви редагуєте одну і ту ж функцію, щоб зробити дві різні речі.

В основному те, що я б робив, - розділити проект на окремі "особливості". Одне може бути пов'язане з обробкою мережевих протоколів, а інше - з файлом конфігурації, а ще з обробкою БД. Особливості - це великі речі.

Далі потрібно розділити ці функції на завдання (розповіді). Це повинні бути прості речі, наприклад, "коли користувач натисне кнопку, програма завантажить файл", "коли програма запуститься, вона завантажить файл конфігурації" тощо.

Деякі завдання доведеться виконувати послідовно ("програма буде розбирати всі поля в конфігураційному файлі" доведеться прийти після "програма завантажить файл конфігурації"). Інші не будуть (ви можете працювати в БД і мережі одночасно).

Але, швидше за все, ви зробите це неправильно, і ось тут виникає досвід. Ви зірвете лише невеликий шматочок (або багато), помилитеся в оцінках часу, і ваш проект займе трохи більше часу, ніж повинен мати. Наступного разу вам стане краще.

Я б також запропонував прочитати «Екстремальне програмування» Кента Бека. Чудова книга, яка допомогла мені, коли я збирався бути менеджером проекту.

Це зводиться до того, що вам потрібно розбити свою програму на функціональні модулі, а потім ввести контракти (інтерфейси та контракти з даними) між різними модулями. Кожен модуль може бути переданий іншому розробнику. Коли ви все з’єднаєте разом, договори гарантують, що ці модулі коректно спілкуються між собою.

Переконайтеся, що ви застосовуєте TDD на розробниках, щоб гарантувати, що всі модулі працюють індивідуально.

Щоб навести приклад того, що я маю на увазі:

Скажімо, ви хочете, щоб хтось із ваших розробників створив реєстратор SQL.

Ви визначаєте інтерфейс і запитуєте одного з ваших розробників ( або створюєте історію, якщо ви використовуєте Agile ), що вам потрібен спеціальний реєстратор SQL відповідно до наступних специфікацій:

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 для цього проекту.

Інші відповіді говорили про аспекти програмування, але я просто хотів згадати аспект управління програмою. Почну з відмови: я не керівник програми. Я взяв один курс на аспірантурі для управління програмами, і мій досвід роботи передбачає торги для невеликих проектів, які зазвичай не перевищують 500 годин і ніколи не перевищують 1000 годин.

Але мені довелося допомогти визначити завдання в лабораторії, де мені довелося тримати 2-3 людини зайнятими протягом 2-4 місяців (неповний робочий день та повний робочий день). Одне, що мені справді допомогло, було використання програмного забезпечення для управління проектами, як Microsoft Project (я не впевнений, чи є там безкоштовна версія, але, можливо, у вашого роботодавця є щось подібне ... запитайте у свого керівника, яке програмне забезпечення для управління програмою використовується у вашій компанії). Зокрема, я досить небагато використовую графіки Ганта, що є переглядом за замовчуванням у Microsoft Project. Визначивши всі завдання та як довго ви думаєте, що вони займуть, ви можете отримати візуалізацію, з якою грати.

Діаграма Ганта мені найбільше допомагає через його візуалізацію. Бачити завдання на папері мені не дуже допомагає, але бачити гарні фотографії та діаграми, безумовно, є. Microsoft Project також дозволяє встановити попередники та дати початку, головна ідея - «Знайти мінімальну кількість завдань, які потрібно виконати для початку завдання X». Принаймні, в моїх невеликих проектах кількість «справжніх» попередників досить мала. Насправді, в одному проекті у мене була проблема, що майже все можна було зробити одночасно, і мені довелося синтезувати два паралельних контури, які були дещо згуртованими. Наприклад, я намагався переконатися, що якщо розробник A коли-небудь торкнувся графічного інтерфейсу, вони працюватимуть над завданнями, близькими до GUI.

Здається, що ви багато цього робили вже в ручці та папері, але мені завжди корисно реально бачити графіки Ганта. Переглядаючи завдання, що вишикуються послідовно, насправді змушує мене подумати: "Зачекайте, чи справді завдання X потрібно виконати перед завданням Y? (В моєму досвіді поки що я здивований, як часто відповідь насправді" ні ")"

Схоже, ви закінчили бути розробником, щоб бути інженером програмного забезпечення. Зрозумійте, що управління роботою не є дизайнерською вправою, але вони йдуть рука об руку. Вам потрібно керувати виконаною роботою, і це залежить від того, як розвивається ваша компанія. Якщо у вас є час і ресурси, то погляньте на прийняття спритної методики - в Інтернеті є гори письмових матеріалів. Знайдіть той, який працює для вас, але пам’ятайте, що, як і все інше, це не безкоштовно. Прийняття будь-яких методів передбачає навчання, навчання та невдачі, перш ніж досягти успіху. Якщо у вас немає пропускної здатності, щоб обробити прийняття більш всеохоплюючої методики, то рішення планування етапу може стати для вас відповіддю. Якщо у вас є список послідовних завдань, це може бути так , що ви не знайшли послідовності , які можутьбути паралельним. Можливо, також ви хочете сегментувати свою розробку на більш загальні завдання, такі як тестування та реалізація. Це само по собі не вирішує проблему звітності, але ви керуєте якістю. Ваш прогрес може бути послідовним списком, але ваші ролі паралельні. Просто пропозиція. Дизайн, який відображає роботу, яку виконують люди, називається структурою розбивки на роботу.

Є багато хороших пропозицій, які запропонували інші люди, але пам’ятайте, що ви керуєте роботою. Іноді ви можете зіставити робочі концепції в дизайн / архітектуру, іноді не вдається це зробити так легко. Завжди є спосіб структурувати роботу так, щоб її можна було відслідковувати. Я пропоную повернутися до вашого менеджера і запитати його, що важливо для нього, коли мова йде про повідомлення проекту про стан проекту. Це почне розповідати, як підходити до того, що ти робиш. Якщо це графік, то ви хочете зосередитись на звіті про прогрес. Якщо це якість, то ви хочете повідомити про набір метрик, які вам доведеться придумати. Якщо це коштує, то, напевно, ви захочете подивитися на зусилля. Усі ці речі також можуть відповідати завданням чи виходити із них.