4. Как вы сказали — «Даже если он работает правильно, скорее всего он не идеально вписывается в архитектуру приложения и/или плохо написан. Вполне вероятно, что его потом бредет тяжело поддерживать.»
Соответственно этот подход не решает задачу, так как оставляет работу незаконченной
5. Если принять во внимание пункт 3 то таких ситуаций возникать не должно. Доделал простую неинтересную задачу и переключился на интересную
6. Если переключаться между недоделанными задачами возникают дополнительные сложности
А постоянная интеграция тут причем?
Вы имели в виду этап под названием сопровождение продукта наверное?
И вы перепутали пользовательские истории со спецификацией продукта.
Пользовательская история как раз описывает только изменение в системе с точки зрения пользователя.
И никак не полную функциональность модуля или подсистемы.
Поэтому то что тут называется доработками в случае СКРАМ как раз описывается в виде пользовательских историй.
После того как история выполнена ее можно в общем-то выбрасывать потому что определение DONE должно включать в себя обновление спецификации продукта если таковая предусмотрена правилами проекта.
А по мне так код на продакшене чаще всего уже достаточная спецификация.
Старайтесь всегда упростить работу — меньше ошибок в итоге совершите и больше сил останется для чего-то производительного.
Производительное — то что даст работающий функционал пользователям.
Я тоже такую тенденцию заметил. Причем чем удачнее проект тем хуже кодобаза.
Пришла в голову такая идея — проекты делаются ради какой-то цели.
И идеальный код обычно не лежит и рядом с целью.
Ну и срабатывает наиболее экономически выгодный вариант — главное чтобы цель была достигнута.
Иначе можно всю жизнь точить мачете в ожидании идеального архитектурного решения.
А ведь код — это всего лишь инструмент для достижения цели.
Часто бывает что в состявшийся проект зовут спецов которые ругаются, переделывают архитектуру.
Но ведь первоначальная цель проекта уже достигнута.
База клиентов есть, доход есть — можно и код выравнивать.
Виноват — не виноват, если работа не прет, надо что-то делать.
Например менять специальность, или проект, или свое что-то организовывать, или попедалить, или в отпуск сходить.
Ходить туда где нет огня — значит отдавать часть своей жизни (возможно единственной) за блястящие кругляшки.
Поэтому или надо педалить с интересом или также с интересом идти домой.
И никакой ПМ тут ни при чем. Совсем и всегда.
тока интереснее работать там где не приходится создавать челленджи самому.
ну или хотя бы создавать их вместе с товарищами по проекту. иначем можно и дома кнопки давить.
а что если нет у вас еще экспертизы в нужной области?
а может и вообще область новая?
и откуда такая уверенность что умножив на два у вас все получится?
а как же COCOMO, FP или хотя бы Story Points
то о чем вы говорите применимо для маленьких проектов
и мне кажется что вы слишком все упрощаете
тем самым даете ложно оптимистическое представление молодым специалистам
я конечно с вами согласен что в общем случае все сводится к правилу
можешь оценить — оценивай, не можешь — декомпозируй
но вот реализация ентой процедуры довольно сложная штука
поэтому я и не согласен что это так просто как вы говорите
в большой компании где пишут под заказ чаще все по другому.
хотя я больше в таких и не работаю… но:
пресейл — контракт — работа
и первое с третьим может совсем быть не связано
и вы можете сколько угодно ругать пресейл но они задачу выполнили.
дальше задача реализовать проект с прибылью и чтобы заказчик остался доволен.
это смысл такого бизнеса.
а вы процесс оценки так расписали как будто это простейший алгоритм в общем случае.
что на практике очень редко бывает для не типовых задач.
кои наиболее интересными являются.
Соответственно этот подход не решает задачу, так как оставляет работу незаконченной
5. Если принять во внимание пункт 3 то таких ситуаций возникать не должно. Доделал простую неинтересную задачу и переключился на интересную
6. Если переключаться между недоделанными задачами возникают дополнительные сложности
Спасибо за конструктивную критику!
Вы имели в виду этап под названием сопровождение продукта наверное?
И вы перепутали пользовательские истории со спецификацией продукта.
Пользовательская история как раз описывает только изменение в системе с точки зрения пользователя.
И никак не полную функциональность модуля или подсистемы.
Поэтому то что тут называется доработками в случае СКРАМ как раз описывается в виде пользовательских историй.
После того как история выполнена ее можно в общем-то выбрасывать потому что определение DONE должно включать в себя обновление спецификации продукта если таковая предусмотрена правилами проекта.
А по мне так код на продакшене чаще всего уже достаточная спецификация.
Старайтесь всегда упростить работу — меньше ошибок в итоге совершите и больше сил останется для чего-то производительного.
Производительное — то что даст работающий функционал пользователям.
Пришла в голову такая идея — проекты делаются ради какой-то цели.
И идеальный код обычно не лежит и рядом с целью.
Ну и срабатывает наиболее экономически выгодный вариант — главное чтобы цель была достигнута.
Иначе можно всю жизнь точить мачете в ожидании идеального архитектурного решения.
А ведь код — это всего лишь инструмент для достижения цели.
Часто бывает что в состявшийся проект зовут спецов которые ругаются, переделывают архитектуру.
Но ведь первоначальная цель проекта уже достигнута.
База клиентов есть, доход есть — можно и код выравнивать.
Например менять специальность, или проект, или свое что-то организовывать, или попедалить, или в отпуск сходить.
Ходить туда где нет огня — значит отдавать часть своей жизни (возможно единственной) за блястящие кругляшки.
Поэтому или надо педалить с интересом или также с интересом идти домой.
И никакой ПМ тут ни при чем. Совсем и всегда.
ну или хотя бы создавать их вместе с товарищами по проекту. иначем можно и дома кнопки давить.
так моя мысль выглядит понятнее?
а что если нет у вас еще экспертизы в нужной области?
а может и вообще область новая?
и откуда такая уверенность что умножив на два у вас все получится?
а как же COCOMO, FP или хотя бы Story Points
то о чем вы говорите применимо для маленьких проектов
и мне кажется что вы слишком все упрощаете
тем самым даете ложно оптимистическое представление молодым специалистам
я конечно с вами согласен что в общем случае все сводится к правилу
можешь оценить — оценивай, не можешь — декомпозируй
но вот реализация ентой процедуры довольно сложная штука
поэтому я и не согласен что это так просто как вы говорите
ведь получить визу это только начало. а что же ожидает после переезда? даже думать страшно…
в большой компании где пишут под заказ чаще все по другому.
хотя я больше в таких и не работаю… но:
пресейл — контракт — работа
и первое с третьим может совсем быть не связано
и вы можете сколько угодно ругать пресейл но они задачу выполнили.
дальше задача реализовать проект с прибылью и чтобы заказчик остался доволен.
это смысл такого бизнеса.
а вы процесс оценки так расписали как будто это простейший алгоритм в общем случае.
что на практике очень редко бывает для не типовых задач.
кои наиболее интересными являются.