К сожалению у разработки ПО есть один довольно значительный аспект. Обычно за его разработку нужно платить деньги разработчику, а эти деньги нужно взять у заказчика.
А заказчика меньше всего волнует процесс, его волнует результат. Поэтому на рынке будет выигрывать тот, кто покажет заказчику костыльное приложение вместо прилизанного ТЗ.
Поверьте на слово — идеальный код, законченный к моменту провала проекта — гораздо хуже, чем плохонький, но работающий и решающий чьи-то проблемы.
Кроме того — если программисты не отвечают за сроки, то откуда вообще их брать?
В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.
Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление.
Надеюсь вы не имеете в виду, что сроки выполнения задач должны определять менеджеры вместо программистов?
Возможно я неправ, но мне кажется вы имеете в виду, что гугление дает обрывочную и неполную информацию, в то время как чтение документации дает целостную картинку в голове, что, в свою очередь, приводит к более полному понимаю и более эффективному использованию знаний.
Но это справедливо только тогда, когда документация написана качественно. А это к сожалению не так в подавляющем большинстве случаев. И тогда на помощь приходит SO, на котором товарищи помогают обойти грабли, не учтенные в документации.
Не вижу причин противопоставлять эти два метода получения знаний.
Получение прибыли является главной ценностью любого коммерческого предприятия по определению. А удовлетворенность заказчика — хороший инструмент достижения главной цели.
Но все же ни удовлетворенность заказчика, ни гонка за прибылью не противоречат ни вовлеченности разработчиков в проект, ни их личной творческой реализации. Все перечисленное вполне совместимо.
В описанной же ситуации мы видим пример карго-культа, то есть скопировали некоторые внешние атрибуты скрама при полном непонимании их сути.
Честно говоря весь описанный негатив не имеет к Скраму никакого отношения.
Скажу больше — правильное внедрение Скрама предполагает, что разработчики кроме технических задач глубже погружаются в проблемы бизнеса, их видение проблем проекта становится шире и выходит за рамки чисто технических задач.
Конечно, многим нравится замыкаться на решении чисто технических задач и такие люди не любят думать о проблемах бизнеса. Для интровертов, а их в ИТ немало, это естественно. Но говорить, что из-за Скрама люди перестали чувствовать себя частью компании — значит противоречить духу Скрама.
Статья 3 ТК РФ. Запрещение дискриминации в сфере труда
Никто не может быть ограничен в трудовых правах и свободах или получать какие-либо преимущества в зависимости от пола, расы, цвета кожи, национальности, языка, происхождения, имущественного, семейного, социального и должностного положения, возраста, места жительства, отношения к религии, убеждений, принадлежности или непринадлежности к общественным объединениям или каким-либо социальным группам, а также от других обстоятельств, не связанных с деловыми качествами работника.
Scrum сам по себе вообще не о качестве кода и решении технических проблем.
Scrum обращает внимание на технические проблемы тогда, когда они становятся проблемой бизнеса. Например когда добавление новых фич занимает слишком много времени, когда количество багов чрезмерно отталкивает пользователя и т.д.
Scrum — это средство погрузить разработчика в бизнес, а бизнес в разработку.
Есть факты, а есть домыслы.
У меня нет полной уверенности, что Землей не управляют жидорептилоиды, но без фактов я не распространяюсь о своих ощущениях.
Мы говорим, что условно СОРМ незаконен, потому что нарушается более важный закон, то есть прослушка незаконна, и закон незаконен.
Чисто юридически СОРМ опирается на закон и нет никакого противоречия в этих законах, поскольку лазейка для него есть в самой конституции. Если под более важным законом вы подразумеваете нечто, более важное, чем Конституция, то это уже дискуссионный вопрос.
Поэтому все разговоры о незаконности СОРМ совершенно бессмысленны.
Бороться и обсуждать надо не со сбором этих данных, а с незаконным злоупотреблением этими данными.
Хотя, конечно, легче всего поддаться протестному настроению и, не разобравшись в теме, кричать про кровавую гэбню и т.д. Без внятного эффекта, впрочем.
Однако оперировать «чистыми» долларами тоже не совсем корректно, надо вводить коэффициент ППС.
А заказчика меньше всего волнует процесс, его волнует результат. Поэтому на рынке будет выигрывать тот, кто покажет заказчику костыльное приложение вместо прилизанного ТЗ.
Кроме того — если программисты не отвечают за сроки, то откуда вообще их брать?
В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.
Мне кажется, что разработчики часто не отвечают за свои прогнозы.
Но иногда отвечают и таких разработчиков ставят сеньорами и тимлидами.
Надеюсь вы не имеете в виду, что сроки выполнения задач должны определять менеджеры вместо программистов?
Но это справедливо только тогда, когда документация написана качественно. А это к сожалению не так в подавляющем большинстве случаев. И тогда на помощь приходит SO, на котором товарищи помогают обойти грабли, не учтенные в документации.
Не вижу причин противопоставлять эти два метода получения знаний.
Но все же ни удовлетворенность заказчика, ни гонка за прибылью не противоречат ни вовлеченности разработчиков в проект, ни их личной творческой реализации. Все перечисленное вполне совместимо.
В описанной же ситуации мы видим пример карго-культа, то есть скопировали некоторые внешние атрибуты скрама при полном непонимании их сути.
Скажу больше — правильное внедрение Скрама предполагает, что разработчики кроме технических задач глубже погружаются в проблемы бизнеса, их видение проблем проекта становится шире и выходит за рамки чисто технических задач.
Конечно, многим нравится замыкаться на решении чисто технических задач и такие люди не любят думать о проблемах бизнеса. Для интровертов, а их в ИТ немало, это естественно. Но говорить, что из-за Скрама люди перестали чувствовать себя частью компании — значит противоречить духу Скрама.
У нас так.
Scrum обращает внимание на технические проблемы тогда, когда они становятся проблемой бизнеса. Например когда добавление новых фич занимает слишком много времени, когда количество багов чрезмерно отталкивает пользователя и т.д.
Scrum — это средство погрузить разработчика в бизнес, а бизнес в разработку.
Голосуют строем в едином порыве?
У меня нет полной уверенности, что Землей не управляют жидорептилоиды, но без фактов я не распространяюсь о своих ощущениях.
Между тем, в США тоже есть люди, которые считают, что республиканцы и демократы в определенном сговоре.
Чисто юридически СОРМ опирается на закон и нет никакого противоречия в этих законах, поскольку лазейка для него есть в самой конституции. Если под более важным законом вы подразумеваете нечто, более важное, чем Конституция, то это уже дискуссионный вопрос.
Поэтому все разговоры о незаконности СОРМ совершенно бессмысленны.
Бороться и обсуждать надо не со сбором этих данных, а с незаконным злоупотреблением этими данными.
Хотя, конечно, легче всего поддаться протестному настроению и, не разобравшись в теме, кричать про кровавую гэбню и т.д. Без внятного эффекта, впрочем.
Вот что бывает, когда аргументов нет, а очень хочется победить в споре.
Самое интересное, что я хотел дать вам цитату, чтоб показать, что разговор о СОРМ, но оказалось, что именно вы и начали говорить о СОРМ.
Таким образом вы заведомо оклеветали меня. Любопытно — зачем? Для победы в споре это не поможет.
Уровень дискуссии зашкаливает.