Pull to refresh

Comments 12

Действительно. А ведь очень интересный доклад! Почините, пожалуйста!
Автор сам себе противоречит. Команды выглядят одинаково, одна деливерит другая нет, хотя арсенал инструментов вроде одинаковый. А все просто надо начинать с команды, если это не команда, а группа людей, то синергитической составляющей нет :)
И аджаил тут совсем не при чем. Хотя есть некоторые полезные вещи, на случай если менджер не знает :)
Вообще вся эта возня с аджайлом наводит на мысль, что появилась куча IT недоменеджеров, которые не знают как управлять и ищут любой шаблон, по которому можно показать, что он может что-то сделать.
> «если это не команда, а группа людей, то синергитической составляющей нет :)»

вам менеджер выше на 10 листах рассказал, что нужно повесить на человека ответственность, и все заработает
такие они, менеджеры
Ну да, ну да :) А где можно посмотреть какие продукты были сделаны этими менеджерами? Так сказать перейти от слов к делу и проанализировать фракционность деливери: твердое, кашеобразное или совсем жидкое.
" Вы пишете новый кусочек компонента и постепенно переключаете на него функционал до тех пор, пока все не перепишете. У вас может одновременно работать несколько дублирующих функционалов. Пока все у вас не будет доделано."

Вот это то и страшно. Поддерживать дублирующиеся элементы в продакшене. Наслаждаться не только новыми багами, но и старыми, даже — древними, вылезшими из-за нетипичного использования старого кода.

Всё-таки, аджайл для рефакторинга и для построения архитектуры не подходит. Фичи — да, архитектура — нет. Она либо есть, либо её нет. Маленькими кусочками не улучшается.
Как это выглядит «про маленькими кусочками», чтобы получалось и улучшалось:
1 этап — ваш софт это сплошной код. Добавление новой функции, постоянно оборачивается тем, что что-то падает.
2 этап — в вашем софте код начинает разбиваться на блоки, касающиеся работы отдельного функционала. Новая функция добавляется как новая размеченная область. Когда мы хотим доработать старую функцию, мы её переписываем и делаем как и новую отдельной размеченной областью. Постепенно сплошной код разносится на эти отдельные «полянки»/разделы.
Система становится более устойчивой к обновлениям. Изменения в коде известной функции, уже не отражается на коде соседней. Количество ошибок снижается, но те что появляются указывают на то, что для работы определенной функции мы меняем какие-то стратегические вещи / витальные сущности, которые используются для работы другими функциями и требуется переписывать логику их работы на такие изменения.
3 этап — в софте появляется «платформа» — это базовый функционал, которым пользуются все функции для выполнения своих задач, и она задает для них правила игры. Мы начинаем отторгать функциональный блок в отдельное приложение / дополнение к платформе. Постепенно, функция за функцией.
То есть вы в принципе не верите, что плохую архитектуру нельзя улучшить? Мой опыт говорит о том, что это возможно, но требует значительно больших усилий и квалификации, нежели построить архитектуру с нуля. Но для больших продакшн решений, переписать все заново — не самое лучшее решение, хотя бы потому, что не изменив подходы и команду, вероятность получить что-то принципиально лучше нет, больше вероятность растерять все требования, которые накопились и были реализованы в существующей системе. Единственно правильный способ на мой взгляд — это именно постепенное улучшение, но не каждая команда это способна и не с каждым проектом это рентабельно.
Agile-практики ради Agile-практик — это абсолютно бессмысленная вещь

100%. А зачастую именно это и видно :)
Если вам требуется усилие для того, чтобы понять, работает ли ваша система управления проектами – она не работает.
Only those users with full accounts are able to leave comments. Log in, please.