Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).
Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.
По мере того, как росло число непосредственно разработчиков, проект привлекал инвестиции и нанимал новый управленческий персонал; появлялись технические директора, HR-отделы, куча административного персонала и бесчисленная армия менеджеров всех мастей.
Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики. К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества. Теперь это отлаженный бизнес-процесс, целью которого является зарабатывание денег. Но доведенный до апофеоза этот процесс может подавить в разработчиках тягу к креативу и заинтересованности в развитии проекта.
Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.
Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка. Менеджеры придумывали задачу, скидывали в IT-отдел и ждали реализации, попутно считая время, затраченное на разработку и тестирование. Разработчикам и тестировщикам было велено списывать время на выполнение задачи в TargetProcess. Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.
С их точки зрения всё, конечно, логично: быстрее сделали – а значит, понесли меньше расходов, быстрее выполнили контракт, получили деньги и премии. Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
После месячного негодования страсти немного поутихли, и отдел разработки понемногу свыкся с участью «отвертки».
Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.
Тут вспоминается выступление bobuk о том, как нужно обращаться с разработчиками. Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понравиться не всем.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
В итоге вся эта система стала приводить к маленькому локальному коллапсу. Разработчики растеряли весь энтузиазм и стали относиться к разработке формально. Есть задача – делаем, нет задачи – не делаем. Кроме того, почасовой отчет по времени оставлял привкус того, что за твоей спиной непрерывно кто-то стоит и наблюдает, как ты нажимаешь кнопки.
Естественно, с точки зрения Менеджмента ситуация была более радужной, они получили полный отчет по времени, затраченном на разработку любого проекта, и понимание того, кто чем занимается почти в реал-тайм.
Но разработчики — тоже люди, и начали не выдерживать. Буквально за месяц компанию покинули 3 ключевых разработчика ядра. Замену которым в настоящий момент взять просто негде. Они работали в компании с самого момента основания и фактически сделали компанию тем, чем она является сейчас. Нагрузка на остальных разработчиков стала возрастать в геометрической прогрессии; отдел разработки зашатался как карточный домик, разработчики, которые работали в компании по 5 лет, стали уходить, т.к. перестали чувствовать себя частью компании, превратившись в «отвертку».
Резюме
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Агрессивный переход на такие потоковые методологии разработки приводит к «формализации» отношений внутри компании. Результатом резких внедрений стало то, что менеджмент теперь лучше видит, что происходит в компании, но ключевых разработчиков в компании уже нет.
Говорить о том, что эти сотрудники виноваты сами, тем, что не смогли адаптироваться, или поступили высокомерно – как по мне, так это ошибка. Возможно, сам процесс внедрения Agile был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
Комментарии (539)
lair
10.01.2017 15:56+40У меня только один вопрос: при чем тут Scrum/Agile? Ровно тот же эффект получается с любой (неправильно примененной методологией) с оценкой времени и внешней постановкой задачи. Какие специфичные для скрама особенности привели к описанному в посте результату?
qw1
10.01.2017 20:33+27Кажется, я понял автора. Попробую описать свой опыт до и после прихода скрама.
Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт! Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня, и сделаю revert changes, отложив до следующего раза (а в следующий раз сделаю за 1.5 часа, потому что оно варилось у меня в голове целый месяц и пришло понимание, как это должно быть сделано). Через планирование и приоритеты вся магия пропадает. Может, у меня плохое настроение я бы сегодня поковырял старые баги из трекера. Но нет — наверху висит рефакторинг, который я выпрашивал целый месяц — будь добр, вперёд и с песней, или что я скажу завтра на митинге? Нет, спасибо, я не предложу взять такую фичу в спринт. Остаётся только свободное время (вечера и выходные), что не всем подходит. Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.
Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.lair
10.01.2017 21:10+6Ну так и в вашем случае — при чем тут скрам? Возьмите любую методологию планирования, которая выглядит (грубо) как:
- дай разработчику оценить задачи
- выбери период времени
- накидай задач в этот период в соответствии с приоритетами и оценкой
- в конце периода проверь выполнение
- повторить
Вы получите все те же самые спецэффекты, которые у вас описаны. Их величина будет зависеть от того, как именно выполняется шаг 3, и это определяется тем, кто занимается планированием.
Ну и дальше немного общих рассуждений, никак не связанных со скрамом:
Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Ээээ. Вы это серьезно? А мне казалось, что давать и выполнять собственные обещания — это нормально, а не тяжело. Собственно, это наша работа, нет? (это неплохо описано у Мартина в Clean Coder, кстати)
Второе — нет времени остановиться и посмотреть/подумать.
Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт!
Ну так если вы не знаете, как оно пойдет, то и ваш менеджмент не знает, чего от вас ожидать. А это в бизнесе очень неудобно. Кто-то готов на такие риски, кто-то нет.
Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.
Аналогично, если спринты у вас оставляют ощущение выжатости — вы (или ваш менеджмент) что-то делаете не так.
Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»)
Подобные "разговоры" тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.
Впрочем, это все тоже сильно зависит от того, как именно обсуждаются результаты планирования. Если менеджмент адекватно относится к "я это не успел, потому что ко мне пришли и попросили то-то показать" — можно и не заниматься буквоедством в оценке.
qw1
10.01.2017 21:32+4Вы всё правильно написали, но много где называют «скрамом» то, что им не является.
>>Второе — нет времени остановиться и посмотреть/подумать.
Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Идеология скрама подавляет спонтанные идеи?
вы (или ваш менеджмент) что-то делаете не так.
Конечно, всё не так. Каждый спринт меняется состав задач и приоритеты в середине спринта. Часто берём задачи без полного понимания и оценки, потому что это очень важная задача важного человека, надо её в спринт пропихнуть, а там определимся по ходу дела. Часто возвращаемся к срочному мелкому (и крупному) допиливанию фич прошлого спринта, потому что то, что сделано, пользователям не понравилось (ну вот так, они думали, что хотят это а оказалось, что это выглядит не так, как они представляли и уже хотят другое).
Менеджемент знает обо всех проблемах, но не может пойти против избалованных пользователей. Ведь «мы (IT) — сервис и должны быть клиентоориентированными». Так что скрам у нас — чистая фикция.lair
10.01.2017 21:35Вы всё правильно написали, но много где называют «скрамом» то, что им не является.
Если кто-то где-то что-то не так называет, то это проблема того, кто не так называет, а не того, чем называют.
В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
20% свободного времени. Или просто подойти к менеджменту и поговорить.
Идеология скрама подавляет спонтанные идеи?
Идеология предварительного планирования подавляет спонтанные идеи.
Конечно, всё не так.
Ну вот видите. И скрам у вас — чистая фикция, и описанные вами проблемы — не от скрама. Но почему-то претензии все равно к скраму.
ApeCoder
13.01.2017 12:26Идеология предварительного планирования подавляет спонтанные идеи.
Идеология предварительного абсолютно точного планирования 100% времени со буквальным следованием плану без пересмотра убивает спонтанные идеи :)
Агилисты часто цитируют:
План — ничто. Планирование — все. – Дуайт Эйзенхауэр
varicap
12.01.2017 00:59+1Ваш (ну, или не ваш) стартап просто превратился в бизнес.
Из творческой мастерской, где можно в любой момент переключиться на проверку идей, просмотр логов, тестирование новых интересных плюшек — в инструмент по зарабатыванию денег. Программистов переставили от художественного холста к конвейеру.
А по скраму вы работаете или ещё по какой методике — не имеет никакого значения.
malbaron
15.01.2017 12:48Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
Идеология скрама подавляет спонтанные идеи?
Если ваша творческая идея требует совсем уж много времени — у нас это прекрасно согласовывается с руководством. Обсуждается на митингах (еще чего коллеги и посоветовать умного могут).
Учитесь общаться с людьми.
Руководство не заинтересовано просто выжать из вас соки.
Руководство заинтересовано получить результат.
Если ваше творческое исследование направлено на развитие коммерческого проекта и у проекта есть небольшая финансовая подушка — то вас поддержат, будьте уверены.
Если будете молчать — то исход очевиден.
По этому поводу анекдот:
— У меня плохие отношения с женой.
Я после операции, мне нужно кашки есть, а она готовит мне котлеты.
Доктор сказал мне что нужно следить за питанием.
У меня развилась изжога.
Жена, гадюка такая, виновата.
— А ты сказал жене, что доктор тебе велел придерживаться строгой диеты?
— Нет.
— И почему тогда жена виновата?
qw1
15.01.2017 14:26+1Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.
Ладно, когда это место прижмёт, вот тогда и поставят задачу. Причём разработчику, который не любит оптимизациями заниматься (потому что у него загрузка меньше).ApeCoder
16.01.2017 09:08У нас член команды добавляет тикет в таком случае который может быть приоритезирован или отвергнут овнером.
malbaron
16.01.2017 10:57+1Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.
Что значит: «пусть сам ставит задачу, если ему надо»?
Это же только ты, закопавшись в детали, изнутри видишь, где это тормозит и всего 2-4 работы.
Видишь — скажи.VolCh
16.01.2017 11:17+2Если видят, что тормозит все, то поставить задачу должно руководство, если считает это проблемой. Если видишь только ты (понимаешь, например, что поиск по индексированному полю не должен быть таким долгим), то и проблемы нет :)
ad1Dima
16.01.2017 13:53Вижу такую проблему, которая приведёт к таким последствиям для пользователя. И пусть решают.
Femistoklov
11.01.2017 21:22+2Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Подобные «разговоры» тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.
Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?lair
11.01.2017 21:45"Закладывается" столько, сколько нужно, чтобы оценка приближалась к реальности. Если разработчик знает, что после дня собственно разработки ему еще нужен день "походить под отладчиком" и "посмотреть на логи", значит оценка задачи — не день, а два. Если разработчик — или тимлид, или менеджмент — знает, что после завершения задачи еще полдня неизбежно уйдет на объяснения, как тестировать — значит, надо приплюсовать эти полдня к оценке.
(а 20/80 и так далее — это не для задачи, это вообще свободное время, оставляемое в итерации на исследования)
pnovikov
12.01.2017 13:44Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.lair
12.01.2017 13:48Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
Это вопрос, скажем так, неочевидный. Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется "сколько времени займет эта задача" и "к когда ты сделаешь эту задачу" — одно легко выводимо из другого.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты»
Так я и не про скрам говорю, а про абстрактную систему планирования в вакууме.
pnovikov
12.01.2017 14:01одно легко выводимо из другого.
Теоретически да. Практически — такой подход переворачивает в голове разработчика процесс оценки с попытки определить объем работ по задаче и проанализировать риски на «набрать себе лукошко задач и разгребаться с ними». Вы можете поделить время до дедлайна разделив кол-во дней в часах на кол-во задач и получить нужную вам (а не разработчику) оценку. Разработчик (как и любой человек) не способен к быстрой оценке объемов работы. Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше. Рекомендую попробовать.lair
12.01.2017 15:03+1Проблема в том, что у меня регулярно бывает ситуация "вот есть десять задач из роадмапа, надо оценить, какая сколько займет, чтобы понять, в каком порядке их выгодно делать, и на какие версии делать анонс". Задачи, очевидно, не одинаковые по сложности (иногда на порядок).
VolCh
12.01.2017 15:34Собственно, это основная причина для чего нужна оценка времени — составить план работ на текущий список задач.
pnovikov
18.01.2017 05:59Боюсь, вы путаете приоритеты и оценку по времени.
Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».VolCh
18.01.2017 15:18Не путаю. Приоритеты зависят от оценок. Грубо, задача очень важная, но при оценке в неделю другие задачи от 15 минут до пары часов всего дня на 3 подождут, но при оценке в месяц — сначала сделать их.
Это бизнесу решать к какой мелочевке надо приступать моментально, а какую можно копить годами.
s-kozlov
13.01.2017 06:00+1Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше.
Простите, но не верю. Если человек не может приблизительно оценить отдельно задачи А, Б и В, на чем основана его оценка «успею все три сегодня»?malbaron
15.01.2017 13:25+1Простите, но не верю. Если человек не может приблизительно оценить отдельно задачи А, Б и В, на чем основана его оценка «успею все три сегодня»?
На безудержном оптимизме разработчиков в своих оценках
Читайте Брукс «Мифический человеко-месяц».s-kozlov
15.01.2017 14:54+1Везде эти оптимисты… И в скрамовском planning poker оптимисты насчет оценок, и в настоящем покере тоже оптимисты, у которых дырявый стрит из 3 карт обязательно соберется на ривере.
malbaron
15.01.2017 16:03Везде эти оптимисты… И в скрамовском planning poker оптимисты насчет оценок, и в настоящем покере тоже оптимисты, у которых дырявый стрит из 3 карт обязательно соберется на ривере.
Настоящий покер — не тот пример.
В покере-то как раз в этом весь смысл (ну 50% смысла) игры.
Это же игра!
А если рассматривать покер с финансовой точки зрения — покер без блефа не даст вам превратить его в источник заработка, а навсегда останется всего лишь хобби (к слову, даже неинтересным хобби, ибо без блефа покер не покер).
А название planning poker отражает всего лишь юмор создателей, не стоит тащить в Scrum принципы покера из реальной жизни. Они всего лишь отдаленно похожи, не более того.
s-kozlov
15.01.2017 16:12В покере-то как раз в этом весь смысл (ну 50% смысла) игры.
Это же игра!
Для хорошего игрока партнер с таким мышлением — отличный источник заработка (fish).
Lofer
15.01.2017 20:33Можно рассматривать «planning poker» Scrum, как идентификацию и оценку риском методом методом экспертной оценки и прецедентов.
Тогда все становится на свои места :)
azsx
13.01.2017 02:49Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.
Например, мне надо подготовить 6 бумажек, которые я бы сделал за 3 часа + час запаса. Но так как начало года — это безумие, когда меня разрывают по телефону, а кто не дозванивается приходит лично — то я сделал эти бумажки в тот же день только потому что задержался на работе. Или делал бы их два дня.
То есть в среднем надо 4 часа, но реальность — это не сферический конь в вакууме.lair
13.01.2017 11:57… и как вам поможет оценка "успеешь к такому-то времени"?
(Но вообще, конечно, приведенная вами ситуация — классический пример несовпадения планируемых оценок с реальностью. Ну да, бывает. Не повод не планироваться вообще.)
azsx
14.01.2017 16:46и как вам поможет оценка «успеешь к такому-то времени»?
Обычно я представляю «внезапную» нагрузку неким средним числом по времени. Также очень помогает ориентироваться сколько человек сейчас в отделе и все ли работают полный день, чтобы делегировать некоторые работы другим.
Но вообще да, лучше взять в два раза больше времени чем требуется и сделать не торопясь, передохнуть и перепроверить, чем ограничить себя во времени заранее.
при этом ориентир «это требуется завтра после обеда», значительно понятнее, чем «данная работа займёт два часа». Причина — я не фрилансер и выполняю более чем одну задачу за день. В моём рабочем дне надо выделить два часа.lair
14.01.2017 17:40В моём рабочем дне надо выделить два часа.
Разве не в этом цель планирования?
azsx
14.01.2017 18:15Разве не в этом цель планирования?
Цель планирования в контексте обсуждения — это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу. Моя задача выполнять работу из моей должностной инструкции, в которой множество пунктов «следить, чтобы всё работало». Обратите внимание, я работаю по принципу первой части статьи.
Если у нас спор, то хочется узнать суть спора.
Fesor
14.01.2017 18:53это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу.
Это не конечная цель. Конечная цель все же определиться успевает ли команда сделать скоуп работы, или что именно успевает сделать команда. Оценка от разработчика — это очень примерное число которое дает какое-то представление о временных затратах. Есть еще масса переменных которые влияют на конечный результат но как правило типичный менеджер (да и разработчики) их не учитывает.
VolCh
14.01.2017 23:48А может цель изначально определить когда конкретный скоуп будет закончен?
Fesor
15.01.2017 13:52Поскольку проект в большинстве случаев имеет какой-то фиксированный бюджет, нет гарантии что в этот бюджет уложится весь скоуп работ. Так что в этой ситуации нужно заблаговременно знать что примерно не успеют сделать разработчики. Именно по этой причине приоритезация задач важна, чтобы закидывать неважные задачи на конец разработки.
Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство), то тут уже скрамы не помогут ничем, поскольку будет все хорошо или нет уже зависит только от оценки данной на самом раннем этапе при выборе этого фиксированного скоупа/бюджета.
khim
15.01.2017 19:44Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство)
В момент когда так начинает делать ваше начальство — пора искать другую работу.
Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).
И дальше — уже неважно, какие умные слова вы на это вешаете…malbaron
15.01.2017 20:51В момент когда так начинает делать ваше начальство — пора искать другую работу.
Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).
Так говорят ленивые или глупые разработчики.
А умные придумывают оптимизации. И потом этими оптимизациями пользуются во всем мире.
RAD-development, фреймворки и т.п.
Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.
qw1
15.01.2017 23:47+1Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.
Там был скрам?
— Ну как продвигается спринт?
— Да никак, отстаньте, я фреймворк пилю. Через 2 месяца будет готов, тогда и полетим…
malbaron
15.01.2017 13:07Это вопрос, скажем так, неочевидный. Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.
У меня был один знакомый разработчик, которое сие сильно затрудняло.
Загадка быстро открылась: он делал «левую» работу и ему было проще в голове посчитать «до какого», чем «сколько займет».
VolCh
12.01.2017 15:32+1Если на вопрос «сколько это займет времени?» я ещё хоть как-то могу прикинуть ответ в человеко-часах, то на вопрос «сколько ты успеешь к такому-то времени?» только один ответ: «не знаю, может я к этой задаче вообще не приступлю к такому-то времени».
malbaron
15.01.2017 13:02Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
Пример с токорем не корректный.
Он их в день 100 штук точит, потому и не знает сколько уйдет на одну, тут ему больше подумать нужно, разделить арифметически.
А кто, кроме самого разработчика может сказать сколько времени ему нужно на конкретную задачу?
Было бы правильнее, чтобы это время ему сверху спускал CEO, что ли.
Проблема оценки сроков имеется только до уровня middle.
Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.VolCh
15.01.2017 19:51Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.
Зависит от последствий этого озвучивания. Иногда лучше разделить на три.
pnovikov
18.01.2017 06:07Как говорил один мой знакомый — как раз — CEO — не умножай оценку. Ни на 2, ни на 3 — не спасет. И-таки да, в большинстве случаев не спасает.
malbaron
18.01.2017 11:33Как говорил один мой знакомый — как раз — CEO — не умножай оценку.
С высоты 20 летнего опыта разработки скажу, что то был плохой CEO. Скорее жополиз начальства.
Или он имел ввиду другое: разработчик, сообщай мне исходные оценки, я сам умножу их на 3. То есть во избежание коэффициента 9 в итоге.
Правило об оптимистичности разработчиков в оценках известно уже 50 лет как.
Детально рассказано об этом из опыта разработки операционной системы в IBM.
Книга Брукса «Мифический человеко-месяц» — книга тоненькая, можно легко прочитать.
malbaron
15.01.2017 12:54Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?
Вообще не проблема.
Для проверки какой-то серьезной гипотезы у нас менеджер проекта явным образом выделяет время.
Не только автоматически 10/20/30%, а еще и явным образом — «проверишь? да. когда результат? послезавтра скажу» — и все, человек официально занят делом, проверяет гипотезу.
Просто беседуйте с коллегами, с руководством, говорите, что вам нужно.
Они ваши мысли не читают.
Не все они являются специалистами в вашей сфере — иначе бы вас попросту не наняли бы.
Вас наняли в том числе и потому, чтобы вы, пользуясь вашими профессиональными знаниями (которых нет у других людей, которых нет у руководства), рассказывали что и где и как тут надо сделать.
pnovikov
11.01.2017 09:44+3Большие рефакторинги надо относить на отдельную стадию разработки и согласовывать с управленческим звеном/клиентами. Т.е. «пока нет срочных задач». Исследование фреймворков надо относить на отдельных людей вне команды работы над продуктом, а потом вливать эти знания обратно в команду через тех самых отдельных людей. Но это особая управленческая магия, которая многим не по зубам.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.avost
12.01.2017 09:30+2А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент.
Угу. Если процесс позиционируется как средство решения конкретных проблем, но в подавляющем большинстве случаев их не решает, а только усугубляет, то дело, конечно, в погоде на марсе, а не в процессе! Верующие в скрам, такие верующие…
Fesor
12.01.2017 10:34-1проблемы автора в том как он следует своим процессам. Например процессы не регламентируют способ оценки или что должно в нее входить, это разработчики должны как-то сами для себя родить и следовать этому. Они же явно не закладывают в оценку кучу активностей и оттого страдают. Причем тут скрам?
В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея. Если бы это было так, никто бы не придумывал XP/FDD/Kanban. Но и говорить что скрам никогда не работает это уже другая крайность.
А что до решения проблем, обычно со всеми этими загонами по скрамам проблемы хорошо прячутся. Для того что бы лучше их выявлять и добавлять практики решающие конкретные проблемы еще до всех этих скрамов и модных линов была придумана теория ограничений.
ApeCoder
13.01.2017 11:43В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея.
Я понимаю, почему нельзя считать такой постулат догматом, но почему нельзя мыслить этими катерогиями?
Почему хотя бы нельзя задаться вопросом, "А скрам ли это?" "А правильно ли мы его готовим?"?
Если бы это было так, никто бы не придумывал XP/FDD/Kanban.
Может их придумали не потому, что скрам нехорош, а потому что он хорош, но можно лучше :)
VolCh
13.01.2017 13:03Почему хотя бы нельзя задаться вопросом, «А скрам ли это?» «А правильно ли мы его готовим?»?
К нам пришёл ПМ и сказал: «Да будет скрам, а я будут продакт аунером и скрам-мастером.» И увидели мы, что скрам это плохо для нас. Что имеете в виду под скрамом вы — мы не знаем. То, что было у нас — практически совпадает с описанием на вики. Если вы считаете, что там неправильно, то поправьте, чтобы мы не называли скрамом, то, что было у нас.
pnovikov
12.01.2017 12:34Поверьте, если вы пытаетесь тапком забивать гвозди, а они не забиваются — то это ваша и только ваша вина.
avost
12.01.2017 14:01Если на тапке написано — предназначен для забивания гвоздей, то виноват тапок и те религиозные фанатики, которые веруют и проповедуют, что тапок способен забивать гвозди, а те, у кого не получилось — сами виноваты. Даже несмотря на то, что тапком таки иногда можно забить гвоздь в неслишком замороженное сливочное масло. У вас отличная аналогия — спасибо!
chieftain_yu
12.01.2017 14:17Мне кажется, даже если тапок и вправду предназначен для забивания гвоздей, возможно в том числе и неправильное его применение. Как на кадрах 11 и 12.
Широко известный в узких кругах источнник
pnovikov
12.01.2017 14:17Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)avost
12.01.2017 20:10+1Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
Отчего же? Я — могу. Поэтому и считаю скрам антиаджайлом. А вот верующие не могут. Они считают, что если им удалось забить гвоздь тапком в масло, то им можно забивать и в бетонную стену, а если не получилось — ну, не тапок же виноват, в самом деле — значит у вас был "неправильный" скрам.
Source
13.01.2017 23:37+1Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
В бетонную стену и молотком лучше гвозди не забивать…
Fesor
11.01.2017 12:54Самое главное, скрам — это постоянный стресс.
Постоянный стресс свидетельствует о плохом планировании а никак не следствие какой-то методологии.
Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает.
Если разработчик не закладывает время на митинги, попить кофе, подумать… то он сам себе злой буратино. Есть еще риски которые тоже имеет смысл закладывать.
В целом неспроста многие оценивают все это добро в относительных единицах измерения (стори поинты, t-shirt sizes и т.д.) что бы уйти от времени и упростить оценку. Лично мне больше всего нравится t-shirt sizes (small, medium, large, xlarge, etc) на основе которого оценивается сложность. А сколько это займет по времени — это уже менеджер может из джирки посчитать (если задачи нормально дробятся).
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт!
Закладывайте просто 20% времени на погашение технического долга. Не хватает — 30%. Больше — тогда есть вопрос что вы там устраняете. Возможно те рефакторинги которые вы делаете просто не нужны. Разработчики очень часто болеют подобным.
Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня
Подобные волшебные рефакторинги допускаются только если у вас система покрыта автотестами на 100% иначе шанс схлопотать регрессию заоблочный. Вы не сможете руками все проверить. И опять же очень большой вопрос почему у вас возникает необходимость в таких рефакторингах. Есть задачи которые затрагивают все 250 файлов? Сильно в этом сомневаюсь. Чаще всего разработчику просто хочется пострадать перфекционизмом.
Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками
Разговоры/митинги закладываются в оценку. И все становится чуть проще.
p.s. Есть еще очень крутая штука для оптимизации процессов — теория ограничений называется.
malbaron
15.01.2017 12:37Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Читайте классику: Брукс «Мифический человеко-месяц».
И просто оценивайте проект с коэффициентом 3.
Тогда у Вас будет время на логи.
;)
А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Вы не «Вася вышел в поле погулять да ворон посчитать», а "инженер по разработке программного обеспечения".
И ваша задача — все это учитывать, вас для этого и наняли. Потому оклады разработчикам нынче и существенно выше средних зарплат в других профессиях.
malbaron
15.01.2017 12:42Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.
Когда хотят 20% рабочего времени в танчики играть да в контактике шариться, то забывают упомянуть, что это взято по примеру Google:
1. А у них изначально высококвалифицированнейшие специалисты работают.
2. У Google есть финансовая подушка.
Мы проводили этот эксперимент.
Львинная доля сотрудников восприняла 20% как возможность заниматься совсем уж не относящимися к делу вещами. Да, да, да — танчики и вконтактик.
Только самые высококвалифицированные и высокооплачиваемые у нас поняли все правильно. И развивали себя и наш проект и родственное ПО.
Mephistophele
17.01.2017 11:38+1Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Вы путаете, в SCRUM'е нет понятия commitment, в нем есть понятие прогноз. Т.е. возможно задача будет сделана, возможно и нет. При этом это не проблема если какая-то задача не войдёт в спринт или «вывалится» из него.
Основная проблема в данном топике, а точнее их две:
1. Это куча stakeholder'ов, которые переросли в Product Owner'ов, коих как раз должен быть один и только один(!).
2. Итальянская забастовка, устроенная разработчиками.
при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача
. Возможно в данном вопросе я и не прав, но походу скрам мастера у них не было или работал он через ректум, бо подобные вопросы с менеджментом должен утрясать именно он.
sshikov
10.01.2017 21:09+2Особенности… э, ну, никакие, Кроме того, что какая-то методология все-таки была изначально, пусть и не была нигде формализована, но работала, и ее изменение (без какого-то реального обоснования) на «перспективную», а прямо сказать — на «модную» и вызвало то что вызвало.
Т.е. буквально — да, Agile тут не при чем. А фактически — очень даже.lair
10.01.2017 21:12А теперь представьте, что старую методологию заменили не на Agile, а просто на строгое формальное планирование (я как раз комментарием выше его описал). Что-то изменится в посте? Думаю, нет.
Так что "при чем" тут не Agile, а (неумело сделанное) планирование.
sshikov
10.01.2017 21:25+2Ну в общем да. Фактически тоже самое наверное было бы при попытке внедрить любую другую методологию.
Я собственно с этим и не спорил — наоборот. Проблема как правило не в методологиях, а в том, что внедряют их управленцы, которые а) сами давно забыли (если вообще умели) разрабатывать б) хотят в конечном счете обычно понятно чего — выжать из разработчиков побольше, заплатить поменьше.
И очень редко, если вообще когда-либо понимают, что эффективнее работают довольные работой люди.sshikov
10.01.2017 21:26Впрочем, я видел примеры когда пытаются внедрить Agile разработчики. В этом случае — в 100% потому что «модно» (даже если на самом деле уже и не так). Результаты в этом случае почему-то тоже плачевные.
ggrnd0
10.01.2017 23:46+2А тут как с прокалыванием уха.
Если не знаешь как правильно — останешься без половины уха.
По тексту автор еще и войны за приоритеты задач менеджмента упомянул.
Как по мне, если менеджмент не способен договориться между собой, доверять управление им не следует вообще. В конце концов, банально по проектам могли распределить квоты, и сами менеджеры в рамках своих квот собственным задачам приоритет и ставили…
Но опять же, мы тут обсуждаем какой менеджмент плохой.
А может там так же понабрали малоопытных представителей, студентов.
Вот они как бы и виноваты, но не они же виноваты, а тот кто команду менеджмента сформировал.
А KPI? Что у них с KPI было? Может он у них был такой строгий, что без стресса премию не получишь вообще. А без стресса еще и оштрафуют или уволят?
А рядом программисты сидят. Пиво пьют, пиццу заказали, байки травят, да и вообще весело работают…
Хоть автор и не указал этого, но уверен у менеджмента был KPI. И с самым менеджментом никто не церемонился…
Если кто и виноват — то это не просто менеджмент, а топ-менеджмент (генеральный и прочие бесы совета директоров). В конце концов, неужели никто не предпринимал попыток решить данный конфликт сверху?
Всегда можно докопаться до перво причин, и их исправить.
Не докопались? Не исправили? Сами виноваты…
lair
10.01.2017 21:29-1… вот и выходит — что Agile/Scrum тут ни при чем. И пост не про "обратную сторону Agile", а про (обратную ли?) сторону плохого руководства.
rahna
12.01.2017 23:23+2Читая статьи про Agile/Scrum и разбор полетов в комментариях, всегда встречаю такой вывод — если не сработало, значит, делали неправильно.
Подозреваю, что это неверное суждение.lair
12.01.2017 23:25Но в данном случае и правда хорошо видно, что делали неправильно. И дело не в том, что Scrum/Agile хорошие — про это у меня нет достаточно собственного опыта обсуждать, — а в том, что описанное в статье можно получить и без их применения, достаточно просто использовать ту же тактику.
gkislin
11.01.2017 01:51+4Agile при том, что в данной реальной истории внедряли именно его. И автор, на мой взгляд отлично проанализировал последствия этого «внедрения».
chieftain_yu
11.01.2017 15:55+1В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?
На мой взгляд, проблема в другом — не в конкретной методологии, а с переходом компании из состояния «джентльмен джентльмену верит на слово» и «мы тут кучка энтузиастов, работающих на одно большое дело» к состоянию «мы — солидная компания, народу много, кто чем занимается — с кондачка не ухватишь, уровней управления много — надо больше правил и отчетности».
Это вполне обычный шаг в развитии компании от небольшой к крупной.
И многим людям, кто вполне нормально и радостно жил в обычной среде «Серега, надо срочно впендюрить вот такую загогулину» — и Серега хватал загогулину без постановки задачи в трекере и начинал ее впендюривать, в бюрократизированной среде стало тоскливо — пространства для маневра нет, героизм твой никто не оценит, менеджеры бодаются, а у программистов чубы трещат. Потому и двинули.
Не конкретная методология виновата, а стадия развития компании.VolCh
11.01.2017 16:36-1В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?
Переход в целом мягче чем переход между Ubuntu 14.04 и 16.04 на которых Symfony крутится. Проблемы с BC конечно были и есть, но в принципе ничего такого, чтобы сорвать работу целого отдела надолго.
prituriwe
11.01.2017 15:29После прочтения та же мысль. Проблема не в фреймворка, а в менеджменте в целом. Не просчитали риски изменений. Ну и логирование времени совершенно обычная практика для аутсерса. Странно что это вызвало такой коллапс в отделе. А в серами вообще нет времени, есть только SP, которые про сложность задач. Оценка в часах и привязка к 40 часам в рабочей неделе от бизнеса.
ServPonomarev
10.01.2017 16:05+25Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.
ivkomn
10.01.2017 16:46+2И можно возобновить дискуссию о том, что управленец обязан разбираться в том, чем управляет и при необходимости заменить того, кем управляет.
Перефразирую, сегодня в фаворе не безкорыстные творческие созидающие личности, а подхалимы, показушники и вот грустно… каков итог этого процесса?lolikandr
10.01.2017 18:08+4Сказано же: «Задачам стали присваивать приоритеты»
Если менеджер сам не знает и при этом не консультируется у разработчика как надо разрабатывать, то какого качества от него приоритеты будут приходить?
Конечно будут ставить наименьший приоритет всем задачам сопровождения — обновлению библиотек и фреймворков, рефакторинг, исследование киллер-фичи и т.д.
Вменяемые разработчики или будут отстаивать свою позицию (но недолго) или уйдут.
Останутся те, которые уйти не могут/не хотят и те, которым наплевать на задачи сопровождения.
И да, никакого отношения к Agile это не имеет.sshikov
10.01.2017 21:11+3Ну, понимаете, отношения-то не имеет, и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они. При этом как резонно отмечено уже я нескольких комментах — ничего не понимая в том, чем управляют.
Lofer
10.01.2017 23:17и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они
Есть Product Owner, с ОБЯЗАННОСТЬЮ сформировать backlog спринта.
Этого более чем достаточно. Если он не в состоянии этого сделать, то утопить такого менеджера, что бы не мучался…
Команда, в данном случае, выступает как инструмент оценки для product owner-а
Bulletproof
11.01.2017 02:24+1Соглашусь, что я вижу в данном случае больше проблему со стороны внедренцев и менеждеров, от себя добавлю, что устроив срач они полностью убили внутреннюю атмосферу, хотя изначально надо было приходить, смотреть как оно работает и по чуть-чуть что-либо менять и за каждым изменением наблюдать, какое оно дает результат.
mev3101
11.01.2017 18:03+1Скорее беда в тех кто этих менеджеров набирал. Обычная, в общем то история. Нанимается некий специалист из числа узнанных на конференции с жаром рассказывающий как он внедрял и какую выгоду получила компания. Тот не имея представления о истории и сложившейся внутренней культуре компании начинает «роботизировать» рабочий процесс.
В этой истории смущает одно. Если компания формировалась с уровня стартапа, то почему внедрение системы шло без участия разработчиков. Откуда взялся такой упёртый и оторванный топ-менеджмент.
mgkitman
11.01.2017 18:03Вот блин на все 100% согласен, особенно при том, что Scrum подразумевает то, что в процесс разработки менеджмент вообще не должен лезть к разработчикам, для этого есть скраммастер, а это вообще специфическая должность, поскольку он должен с одно стороны пинать разработчиков с другой зад им подтирать, и это только малая доля идеологии Scrum. А получается так, что повесили доску со стикирами и стали каждый день пинать программистов и обозвали это все модным словом.
malbaron
15.01.2017 21:11Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.
Вот не нужно считать все подряд начальство полными идиотами. Не, наемный менеджер, руководящий другим наемным менеджером может быть и таким запросто.
Но реально заинтересованное лицо (владелец-управлящий) или просто компетентный менеджер прекрасно понимает что «все в этом мире что-то стоит».
Давайте я вам пример попроще продемонстрирую:
Менеджеры-продажники должны продавать.
Им разрешается продавать в кредит.
Круче тот, кто больше продал? Да. Но факт продажи проверяется не про отданным покупателям без денег в кредит товарам, а по реально полученным от покупателей деньгам.
Так же и здесь:
Зачем, думаете, все эти часы считаются? Только чтобы разработчиков в зарплатах урезать?
Нет, в том числе и чтобы оценивать себестоимость.
Чтобы было видно и в том числе такую вещь как: менеджер протолкнул 100500 фич принесших 1 млн. долларов, но стоивших в разработке при этом 2 млн. долларов. А другой менеджер протолкнул фич на 500 000 при себестоимости разработки фич в 300 000.
Кто из этих менеджеров полезнее для фирмы?
Менеджеров с дурной инициативой — прекрасно и быстро увольняют/понижают. Видел неоднократно.
azShoo
10.01.2017 16:17+17Заголовок про скрам и аджайл, в тексте про:
отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка.
Понимаю, обидненько. Только процессы тут не при чем.
почасовой отчет по времени оставлял привкус того, что за твоей спиной непрерывно кто-то стоит и наблюдает, как ты нажимаешь кнопки.
Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
Individuals and interactions over processes and tools
А это напрямую противоречит вашему утверждению.
Так может быть, проблема не в аджайле, а во внедренцах?
P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
Iceg
11.01.2017 09:38+1Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
То есть обновить фреймоворк это считается за юзер-стори?
нет вещей и задач, которые не могут быть завернуты в UserStory
А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.VolCh
11.01.2017 10:00«То есть обновить фреймоворк это считается за юзер-стори?»
Я, как эксплуататор/разработчик, делаю *pm outdated в корне и вижу всё зеленое :)
Lofer
11.01.2017 13:07+1А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.
Есть такая штука, как «декомпозиция задач». И есть рекомендация «делать задачи короткими». Из практики 8...24 часа, иначе просто теряется контроль.
Если команда разработки нарежет/декомпозирует UserStory «Все Хорошо» на перечень измеримых и вменяемых задач — значит так надо. Согласен менеджер с этим подходом или нет — это только проблема менеджера.khim
11.01.2017 15:17+2Согласен менеджер с этим подходом или нет — это только проблема менеджера.
Объясните менеджеру что происходит на понятном ему языке — и проблема станет проще.
Пример. Приходите вы в автосалон, приносите лампочу фиолетового цвета и говорите «хочу чтобы фары так светили».
Не проблема — получаете счёт на $100500. Датализация примерно такая:
1. Демонтаж двигателя.
2. Сьём бампера.
3. Замена лампочики ($0.05).
4. Установка бампера на место.
5. Монтаж двигателя.
6. Юстировка колёс.
Дальше — можно обсуждать почему так получилось, что вместо одного пункта «3», который хотел увидеть заказчик у нас появилось вот это вот всё и почему лампочку можно сменить только сняв бампер, а снять его можно только демонтировав двигатель… Но главный-то вопрос: делать будем или нет?
И также можно показать «на пальцах» что такое «рефакторинг» и зачем он нужен: ну дырки мы в бампере в других местах просверлим и вот тогда замена лампочки будет $0.05. Но для этого нам нужно этот бампер снять, то есть демонтировать двигатель и т.п.
Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы.
Ваша задача — правдиво оценить «масштаб бедствия».
P.S. Кстати предложение «дяди Васи» сделать всё за пять минут и один доллар также можно вписать в эту модель: он просто фару отвёрткой расковырять предлагает и вытащить из ниши. То, что потом фары могут вывалиться в момент остановки — его не волнует. Мы так тоже можем — но… под вашу ответственность.Lofer
11.01.2017 17:04Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы
Это навык менджера «считать косты». Если они игнорирует этот этап, или ему не нравится «счет» — уволить его нафиг.khim
11.01.2017 17:25+1Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5. А тут… Ну и начинается вышеописанное.
После нескольких подходов «дяди Васи» (который ведь ещё и премии получит) желание работать дальше над этой системой того… улетучивается.Lofer
11.01.2017 17:40Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5.
Это как раз и есть «идиоты за 5$». За чей счет банкет, если ценник 50$? За счет разработчика? Компании?
Подписался за 5, а стоит 50? Ну так выплати из своего кармана остальные 45 :)
А что бы такого не было, и прописали процессы типа «мойте руки после туалета....», что бы не было "… а тог@вн# в вентиляторснег в башка попадет, совсем мертвый будешь".
Fesor
12.01.2017 12:20-1Единственный срок который есть — конец спринта
Конец спринта не должен восприниматься как дедлайн. Это метка в календаре и не более. Если вы завалили очередной спринт, просто берете меньше работы. Первые пару спринтов полюбому завалятся пока мы команду формируем. Причем даже если команда уже сработанная для каждого проекта все по новому может быть.
azShoo
12.01.2017 13:57Не совсем. В качестве результатов каждого спринта ожидается положительный прирост функциональности приложения. Это, в общем-то, довольно прямым текстом задекларировано.
Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).VolCh
12.01.2017 15:35Поправка: не в продакшене, а в продакшене и готовое к нему.
azShoo
12.01.2017 16:07Не очень понимаю суть поправки. То, что что-то оказалось в продакшене подразумевает, что это «что-то» прошло весь SDLC и соответствует всем критериям для попадания в продакшен. Разве нет?
«Готовое к нему, но не в продакшене» — не считается. То, чем не может пользоваться бизнес — не сделано.VolCh
12.01.2017 16:36Бизнес может пользоваться, когда захочет. Но пока не захотел. Простой пример — какую-то важную фичу приурочили к какой-то важной дате, менеджер сильно перестраховался со сроками, но всё прошло хорошо. Фича передана эксплуататорам, а они ждут этой даты для деплоя.
aavezel
10.01.2017 16:22+6Увольте скрам-мастера, в скраме нет времени на выполнение задач, там оно заменено на story points.
ivkomn
10.01.2017 16:40+1В конечном-то итоге в спринт можно набрать Х story-points, положить длину спринта в Y дней и получить размер:
1 story point = Y / X.
Но в описании методологии времени нет, это да, и story point — сложность элементарной задачи. Однако, кому какое дело :)aavezel
10.01.2017 17:02Такое, во первых, можно использовать, когда есть только один разработчик. Потому, как время выполнения задачи у разных разработчиков будет разным. В пределе в десятки раз. Во вторых, мы рассчитаем понятие средней продолжительности SP команды, которая будет плавать из спринта в спринт с отклонением в пару-тройку размеров средней продолжительности SP ))). Т.е. сказать что мы запланировали на спринт 21 SP со средней продолжительностью 3 часов каждая, итого 63 часа, а по сути от 40 до 180 часов.
По сути SP является нефизическим вознаграждением команды. Т.е. на ретроспективе можно поздравить команду и сказать, что по SP мы повысили производительность по сравнению с прошлым спринтом, в 2 раза. Ну или наоборот.azShoo
10.01.2017 17:59+1Нет, теоретический коэффициент SP/day есть и у каждого человека, и у команды в целом.
Это важная и нужная метрика, позволяющая более-менее нормально планировать работу в команде.
Другое дело, что этот коэффициент всегда динамичен и меняется от спринта к спринту.
Цель команды — выдать максимум SP в продакшен к концу спринта без овертаймов, стресса и баттхёртов. Цель «менеджмента» и процессов — создать условия для этого роста производительности.
Например, если выполнение 1 SP у команды занимает с каждым спринтом всё больше времени, то тут есть ряд возможных причин:
1) Калибруется оценка задач в SP и «элементарная задача», являющаяся одним сторипоинтом, разрастается.
2) Мотивация команды падает и работают медленнее.
3) Накапливается легаси и костыли и внесение даже простых правок начинает занимать больше времени.
4-999) ещё много возможных причин.
Для анализа этих причин есть ретроспектива, как и для анализа того, что в текущем спринте позволило нам сделать больше SP, чем в предыдущем.
Есть ещё более сложные сценарии, типа SP/day у команды растёт, а у конкретного человека падает. Это может быть потому, что он задолбался, а остальные фигачат за него. А может быть потому, что он стал больше времени тратить на саппорт коллегам, ревью и прочие не функциональные задачи.
Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
Но, прежде чем внедрять трекинг времени, нужно чётко и ясно донести до команды зачем это делается. Что бы все (включая «менеджеров») понимали, что это делается не для того, что бы посмотреть что ты делал 8 часов рабочего дня (не дай бог читал хабр), и не для того, что бы потом кого-нибудь уволить «потому что слишком мало сторипоинтов делаешь». А для того, что бы более комфортно _для команды_ планировать объем спринтов.
При этом для этих целей:
1) Вполне допустима определенная «погрешность» в оценке затраченного времени. Точность до часов тут нафиг не сдалась. Т.е. шкала оценок «1 час — 4 часа — 1 день — 3 дня — неделя» вполне ясно дает понять ситуацию.
2) Ни в коем случае не намекает нерадивым менеджерам, что разработчик обязательно должен натрекать 40 часов в неделю на задачи, и не дай бог он там хабр читал. Это простое самодурство и синдром вахтёра, аджайл тут ни при чём.
TLDR
Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
TheShock
10.01.2017 20:19Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
Зачем? Есть спринт 2 недели, команда из 4 человек сделала за спринт задач на 90 СП, лид — 20, синьйор — 30, мидл — 25, джун — 15.
SP\day = 9 у команды, синьйор не очень убежал от мидла из-за того, что делает значительно качественнее, а лид загружен коммуникацией и обучением джуна.
Где тут трекинг времени?)azShoo
10.01.2017 21:42+1Затем, что это так работает только если предположить, что команда делает только запланированные задачи.
Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
2) То, что я описывал выше.TheShock
10.01.2017 22:22Вообще это и есть задача ретроспективы. За спринт сделали 60, а не 90, как обычно? Почему? Было много багфиксов? Как можно уменьшить количество багфиксов? Трекать стоит только незапланированные задачи и то — достаточно на доверии к программисту:
— Как думаешь, почему твоя эффективность в СП в этом спринте вдвое меньше?
— Всунули 5 багофиксов, один из которых съел 2 дня, было 3 двухчасовых митинга и ещё полдня котенка для дочки директора рисовал.
Но обычно количество таких задач стабильно и отражается соответствующе на стори-поинтах. Повысили качество кода, ввели код-ревью, лучше протестировали, как результат — меньше багофиксов в след спринте и +10 сп производительности.
svoka
10.01.2017 22:36По-хорошему должно закладываться сколько-то процентов времени под то, что обязательно впихнут какой-нить багофикс или еще чего.
Т.е. если у вас в неделе условно 10sp, то задач планируется на 8sp, с учетом того что обязательно что-то пойдет не так. Во время ретроспективы эти проценты если надо корректируются.TheShock
10.01.2017 22:59Альтернативный способ — есть «задачи, которые сделаем гарантированно» и «задачи, которые постараемся». Вот «задачи, которые постараемся» и скидываем в случае необходимости багфикса.
azShoo
10.01.2017 23:14Вы предлагаете постфактум разбирать, почему успели меньше, чем запланировали.
Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.
Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.AsTex
11.01.2017 01:23А еще при оценке пользоваться планнинг покером, с целью максимально быстро оценить затраты на выполнение задач всей командой, нежели ориентироваться на «Я выполню задачу за 5 часов», и накидывать еще 20% потому что «это не точно»
VolCh
11.01.2017 09:20+1Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Как по мне, то наоборот их надо включать в спринт по мере возникновения, чтобы как раз получать реальную картину: «сделано за спринт 90 SP из запланированных 100SP, из них 50 SP запланированных в начале спринта задач, 20 SP — внезапно вытащенных из бэклога новых, 20 SP — технических задач типа багфиксов»azShoo
11.01.2017 14:19+1Есть разные мнения на этот счёт.
По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
Это значительно упрощает всем жизнь, на мой взгляд.
В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
Virasio
10.01.2017 19:46Я по скраму работал мало, но когда 9-10 лет назад его вводили там где я работал, то объясняли, что story points не прямо пропорционально времени. У нас использовались, кажется, первые 7 простых чисел. Хотя могу ошибаться, давно было.
Iceg
11.01.2017 09:42Как считать трудозатраты в элементарных задачах? Что вообще считать элементарной задачей? Как сравнить две задачи на элементарность?
pnovikov
11.01.2017 09:56О, интересную тему подняли.
Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.
Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
ihs
11.01.2017 10:03Себя увольте. Нет в скраме никаких стори поинтс, потому как в скраме вообще элементы бэклога/спринтлога могут быть вовсе не в формате User Story описаны.
В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
mikhailt
10.01.2017 16:24-3Если вы запутались в трех ролях Scrum, страшно даже подумать, что бы было, если бы вы попытались примерить что-нибудь типа RUP, с его тремя десятками ролей. Там-то действительно предписывается с десяток менеджеров.
Рефлектируйте дальше, это полезно :)
vadim_ig
10.01.2017 16:41+11Проблема в менеджерах, а не аджайле, как собственно и сказали практически в каждом комментарии. Оценивать работу нужно в стори поинтах, всячески избегая их привязки к реальному времени. Т.е. они нужны только для относительной оценки юзер стори — «А сложнее/проще Б» — не более. Другими словами, А (2 стори поинта) не в десять раз сложнее Б (20 стори поинтов), а просто сложнее. Если руководство упорно привязывается к цифрам, можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды. Очень опасны сравнительные графики производительности команд в стори поинтах, так как одни могут оценивать задачи как 1-2-3-.., а другие 100-1000-10000, но это совсем не значит, что задачи второй команды серьезнее — просто им так комфортнее и нагляднее… Без подготовленного менеджемта, аджайл неминуемо превращается в цирк.
azShoo
10.01.2017 18:02+2На пару комментов выше уже ответил на эту тему, не совсем с вами согласен.
Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.vadim_ig
10.01.2017 19:45Ну фраза «производительность мерить придется» звучит, конечно красиво… Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе. Любое давление (а этом может быть просто табличка «Команда-количество стори поинтов» на кухне) приведет к удушению всех возможных бонусов в зародыше. Например, если изначально производительность команды привязывается к стори поинтам, разработчики просто начнут завышать оценки («Раскидаем по ходу дела»), чтобы сдержать это, придется ограничить максимальное количество поинтов на спринт, но тогда можно просто брать этот максимум и делить на количество юзер стори, а тогда зачем вообще тратить время на планирование…
azShoo
10.01.2017 20:20Производительность команды — это то, сколько изменений в системе команда успевает делать за спринт.
Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
Эти вещи по умолчанию связаны. Их нельзя «развязать».
Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.
По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.
2) Он считает, что продукт овнер ему враг и опасается, что если назовет реальную оценку — его потом вздрючат в случае чего. Аджайл так не работает, да и вообще работать в коллективах с такими настроениями вредно для психического здоровья.
Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
Elmot
10.01.2017 21:52+2Собственно аджайл — это еще способ переложить заботу о пересчете стори пойнтов в календарные дни из голов разработчиков в голову product owner. И он же должен изолировать команду от внешнего давления. За то ему и деньги платят (причем обычно больше, чем разработчикам). В описанном случае product owner толи отсутствовал вообще, толи провалил свою работу целиком и полностью. И да, скрам мастера тоже не надо по объявлению набирать. Если он видит, что такой трэш происходит и ничего не делает — ему не грош цена, а меньше. В описанном случае у него отрицательная стоимость.
Так что в описанном случае аджайла как такового вообще не было. Был довольно стандарный провал в управлении компанией в фазе превращения из стартапа во взрослый бизнес. Не они первые, ни они последние с такими проблемами.
Следующий вопрос к менеджменту компании — смогут ли они переломить ситуацию, так или иначе наладить работу по-новой и спасти бизнес, либо бизнес скатится в обычное УГ, покоптит небо еще какое-то время и развалится.
TheShock
10.01.2017 22:32Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе
Ну так если начали вводить методологию — для этого были предпосылки, например отсутствие возможности планирования. А если такая возможность отсутствует, то нету никакого шанса родить её за две недели. Хоть вы заставите программиста в минутах все оценить и подписать кровью — это из разряда написать себе в штаны чтобы согреться.
TheShock
10.01.2017 20:24+4можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды
когда команде было сложно перейти от оценки времени к новой системе мы использовали такие стори-поинты:
— задача элементарная
— задача легкая
— задача средняя
— задача тяжелая
— задача очень тяжелая
А менеджер уже приводил эти к значениям 2-3-5-8-13 или как там ему необходимо для своих менеджерских дел.
cyber_genius
10.01.2017 16:42+1Боюсь у нас та же проблема, ввели недавно agile и много ключевых людей поуходило, хорошо что не все, а то бы конец. Правда у нас не так всё печально, отчёты надо писать только раз в день и немного больше свободы дают по времени, но т.к. мы работаем с железом то тут всё не просто, потому что железо по умолчанию непредсказуемо.
mikhailt
10.01.2017 16:45+1Проблемы внедрения Скрама хорошо разобраны в книге Майкла Кона "Succeeding with Agile: Software Development Using Scrum"
В том числе и трансфер ролей там разобран.
v_sadist
10.01.2017 16:49+1Уважаемый Keks650, боюсь проблема компании не в самом Скрам, а в идиотизме управленцев (то что вы описали, кроме как идиотизмом назвать нельзя). В Скраме есть стори поинты описывающие сложность задачи — при чем тут вообще «время»?.. Во-вторых половину задач в нашем беклоге генерируем мы сами, не ожидая ничего от бизнеса. И в конце концов в Agile (да и не только) есть такое прекрасное слово «Нет, мы не будем это делать».
Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».
YemSalat
10.01.2017 19:44у нас тоже так «удачно» внедрили «Девопс»
это как? (правда интересно)v_sadist
10.01.2017 19:51+3Сидели мы, бед не знали, как нашего начальника (директор по инфраструктуре) убрали, и наняли «директора по девопсу». Дядя пришел, раздал всем опросники с вопросами про культуру и вот это вот все, поставил задачу изучать модные тулзы по автоматизации и так далее… и ничего из этого не вышло, т.к. менеджменту удобнее было держать огороженные друг от друга отделы инфраструктуры, тестировщиков и разработки. Никаких объединений над общей задачей, никакой blameless культуры (когда случался факап, вместо решения проблемы искали крайних, которых поставить проблему решить, а потом всенародно отчитывали. Про «проблема не на нашей стороне» вообще молчу — классика.
Закончил девопс дядя тем, что когда из хэд офиса уволили единственного хелпдеска, сидел и людям почту настраивал.
А затем и его уволили и наняли «директора по инфраструктуре».ggrnd0
11.01.2017 00:54А как и почему вы уволили «директора по инфраструктуре»?
Или до этого еще не дошло?v_sadist
11.01.2017 11:38Уволили очень просто — предложили несколько окладов и сказали, что в услугах более не нуждаются.
По оф версии директор по инфраструктуре мыслил классическим подходом со всеми этими чейндж реквестами, многоуровневой валидацией и тд, и якобы не мог переобуться в супергибкий девопс. Потому его убрали и нашли дядю, который знает все модные подходы и технологии.
Проблема в том, что девопс подразумевает тесное взаимодействие. Можно сколько угодно совать тулзы по автоматизации, деплоить код по нажатии кнопки в джире, но blameless culture в мозгах некомпетентных (мягко говоря) управленцев не ложилась никак.
А по неоф данным, старый (изначальный) директор по инфре был слишком упертый и слишком яростно защищал свою команду (т.е. меня и моих коллег), вот его и турнули, но это уже условности.
А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.ggrnd0
11.01.2017 12:44> В головах нерадивых менеджеров
1) заводишь аутсорс компанию.
2) знакомым менеджерам рассылаешь предложение о сотрудничестве с откатом в 1.5%
3)…
4) профит
> и в облако
Чес слово, я сам не хочу серваками заниматься. И на мой взгляд облако вполне себе нормальный выход.
Облоко дороже до первого затопления;)
malbaron
16.01.2017 18:48А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
И?
Сталкивался — как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес. Она за ради денег, а не за ради «поразрабатывать бы что нибудь крутое задорого, не взирая на себестоимость».azsx
17.01.2017 02:53+1как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес.
Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.
Чаще всё иначе. Программисты стоящие за воротами лучше бы за ними и оставались. Новый программист не может править чужой код и начинает его переписывать (топчется на месте). Вы не только полгода не платили зарплату, но и не имели возможности заработать на опытном программисте.
Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
Может проще сразу эффектного менеджера увольнять?malbaron
17.01.2017 05:51Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.
Смотрите шире — разработчик сам закиснет на работе по поддержке.
Новый программист не может править чужой код и начинает его переписывать (топчется на месте).
Это отдельная проблема.
Но.
Но неужели вы думаете, что огромные коллективы разработчиков, создающие большие системы, сумели каким-то чудесным образом избежать текучки в коллективе?
Чем больше народу работает, — тем больше «потоки свежей крови», это естественный факт.
Так что, смею утверждать, что вы просто не видели нормального кода, если считаете, что это непреодолимая проблема.
Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
Может проще сразу эффектного менеджера увольнять?
Конкретный пример приведу:
Была разработана платежная система.
3 человека разработчиков. Очень высокая квалификация.
Под конец разработки был нанят один попроще квалификацией.
Разработка была завершена.
Оставалось следить за системой, баги редкие фиксить — этим и занялся тот последний принятый на работу «квалификацией попроще».
Кроме разборов с багами в его задачи входило изредка писать очередные платежные шлюзы для новых поставщиков услуг и дружественных платежных систем (что делалось на раз-два, так как API были уже созданы и проработаны в мелочах как надо).
Иногда им писались отчеты.
Зачем там 3 высококвалифицированных спеца на этом этапе?
Прошло не полгода, а 2 года…
Фирма вышла на рынок другой страны — нужно было адаптировать платежную систему.
В частности локализация оказалась не предусмотрена штатно — и потребовала глубоких доработок, неподъемных для программиста, сидящего на поддержке.
Снова наняли высококвалифицированных разработчиков — других, естественно, а не тех, что систему изначально создали.
Это конкретный пример из жизни.azsx
17.01.2017 12:20Новых трёх высококвалифицированных специалистов уже уволили?
malbaron
17.01.2017 14:21Новых трёх высококвалифицированных специалистов уже уволили?
Для локализации и пр. задач нанимали всего двух высококвалифицированных.
Задача выполнена.
Да, давно уволены.
Они бы и сами ушли — им же не интересно работать по мелким текущим задачкам.
Тем более коих мало на такую толпу народа.azsx
17.01.2017 15:22Я с подобным встречался только в не сложных web проектах. Значит я ошибался.
qw1
17.01.2017 17:59+1По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.
malbaron
17.01.2017 21:37-2По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.
Хотелок у всех нескончаемо.
Все дело в бабле. Никто вечно не будет спонсировать хотелки на полную катушку.
Разделение жизненного цикла продукта на более и менее интенсивную разработку — совершенно естественно.
Аналогия с домом:
Дом построен — каменщики ушли.
Пришли маляры.
Прошли годы.
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Но каменщики не вернуться уже никогда.azsx
18.01.2017 02:36+1Но каменщики не вернуться уже никогда.
В моём городе каменщиков возвращали через суд. Эксперименты с зарплатой строителям во время бума строек привели к тому, что работяги много воровали, например, цемента. В результате новый дом и внешняя стена лопнула. Мужик подал в суд и выиграл, вернулись краны, каменщики и блок стены поменяли. Но аналогия совсем не к месту!
У программистов своя работа. Пишет, например, программист ХХ тысяч строк кода. И вы можете как Ванга нагадать, что в этом коде есть ошибки, при чём много критических. Далее, посмотрев на результат большая часть заказчиков осознаёт, что делать надо было совсем иначе. Плюс много хотелок.
Для многих сайтов программисты после создания сайта не нужны совсем. Логика простая (обработать запрос юзера и сформировать ему хтмл страницу с БД), самописы без внешних непредсказуемых библиотек и всё… Нужны модераторы, корректоры, юристы, рекламщики. Но не программисты.
Но мой опыт показывать, что если после написания программ начинают увольнять программистов — то это всё. Ваш опыт другой.malbaron
18.01.2017 15:29Но аналогия совсем не к месту!
У программистов своя работа.
Есть этапы создания ПО и этапы его эксплуатации.
Я вас уверяю, какое-нибудь торговое предприятие, вложившееся в внедрение и адаптацию под себя 1С, совсем не мечтает заниматься этим ежемесячно годами.
Делают просто:
1. Нельзя работать, ПО не позволяет.
2. Делаем ПО.
3. Запускаем ПО в эксплуатацию
4. Пользуемся ПО.
5. Фиксим баги
Пункты 2 и 3 несообразно дороги.
Но их терпят ради пункта 4.
Пункт 5 должен быть копеечным, иначе это плохое ПО.
Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.
Это все же не типичные заказчики. Их бизнес и есть ПО.
А все что существует в нашем виде материального — сделано предприятиями традиционного типа.
Для них экономически лучше будет купить новый крутой станок, чем очередной раз переписывать программу управления производством.
Fesor
18.01.2017 02:45+2Но каменщики не вернуться уже никогда.
Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.
Когда разработку ПО сравнивают со страительством есть одна простая ошибка восприятия, которая ломает все дальнейшие аналогии. Как правило в инженерном деле можно выделить две стадии — проектирование и собственно постройка (design + build) причем фаза строительства не очень то дешевая и исправлять ошибки проектирования на этой фазе очень дорого.
В разработке ПО же "сборка" процесс незатратный. По сути это время работы компилятора/деплоймент. То есть с точки зрения трудозатрат разработка ПО это только процесс "проектирования", что сильно меняет подход к этому делу в плане процессов и разработки. Мы в любой момент можем вызвать "каменщиков" и изменить проект.
malbaron
19.01.2017 22:28Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.
Если это не ИТ-фирма, а ИТ только обслуживающая служба, то реквест придет ой как не скоро.
Годами держать ненужный штат предлагаете?Fesor
20.01.2017 09:38Годами держать ненужный штат предлагаете?
Аутсорс не зря придумывали. Если изменения происходят раз два в год, то держать штат смысла нет. Но если риски от того, что изменения не будут сделаны вовремя высоки (каждый день задержки будет приносить убытков компании больше чем посадить человека в штат) то имеет смысл держать в штате человека.
VolCh
18.01.2017 15:15Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.
MurzikFreeman
10.01.2017 17:02+7Не методология виновата. Виноваты манагеры. Ради достижения своих целей одна группа, не очень нужных в компании лиц, решила поставить раком людей, действительно в компании нужных. Так уж повелось у «эффективных менеджеров», считать людей «отвёртками», забывая, что как только разработчик начинает чувствовать себя отвёрткой, к проекту он начинается относиться соответственно. Пока у них есть уверенность, что любого можно заменить, это будет продолжаться до бесконечности.
time2rfc
10.01.2017 17:03Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде
Люблю SCRUM как раз за то что УЧИТЫВАЕТ взаимоотношения в команде, знаю что напишу банальщину, но есть подозрение что у вас не правильно приготовили SCRUM.
RainM
10.01.2017 17:27+3получается везде scrum готовят неправильно? Может быть проблема в нем самом?
time2rfc
10.01.2017 17:30Возможно Вам просто не везло, у нас вся компания(порядка 27 команд) работают по SCRUM и таких проблем нет.
azShoo
10.01.2017 18:06+2В ПО есть баги, получается везде ПО пишут неправильно?
Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.avost
12.01.2017 16:51+1В ПО есть баги, получается везде ПО пишут неправильно?
Именно так. Иначе не существовало бы такого разнообразия
серебряных пульметодологий разработки и индустрии впариветелей этих методологий.azShoo
12.01.2017 17:03Нет, это не так. Потому что термин «неправильно» подразумевает существование термина «правильно».
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
Важна их частота и степень их влияния.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.avost
12.01.2017 22:18На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок
Бездоказательное утверждение.
Даже если у вас будет неограниченное время и бюджет.
Прро формальное доказательство правильности программ слыхали? Иногда оно бывает даже автоматическим.
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы
Можно использовать инструмент с которым скорее всего будут проблемы. А можно его не использовать и этих проблем избежать
azShoo
12.01.2017 22:32+1Да, и формальное доказательство предполагает либо слабую логическую сложность программы, либо доказательство в рамках одной тестовой модели.
Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.
Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.VolCh
13.01.2017 07:44Проблема в том, что:
а) у каждой методологии есть области применимости, но обычно явно они не описаны
б) список решаемых проблем тоже часто явно не обозначен
в) а уж цена, которую придётся платить, тем более не обозначена
Ну или, может, всё это есть в толстых книжках, но внедрятели их не читают. Или читают, но плохо. И внедряет, обычно, не команда, а руководство. Команд — это объект внедрения, а не субъект.
TheShock
12.01.2017 22:43+2Прро формальное доказательство правильности программ слыхали?
Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:
— формальное описание корректное
— формальное описание полное
Обычно баги получаются не из-за механической ошибки, а из-за неправильной или неполной обработки данных. А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя.avost
13.01.2017 04:29+1Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:
Угу. Вы ещё скажите, что наше восприятие мира не соответствует действительности и поэтому не бывает по без ошибок. Отделяйте мух от котлет. Написать правильную программу (полностью соответствующую формальному описанию) можно. В исходной формулировке ничего не было про правильность постановке задачи.
А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя
(пожимая плечами) в вашей постановке были бесконечные ресурсы. (И при чём здесь проверка всех ветвей? Как и теоремы, программы доказываются не брутфорсом, как правило) Но раз вы меняете правила и формулировки по ходу дела, то конкретно вам ничего доказать нельзя. Продолжение беседы на таких условиях не кажется мне осмысленным.
qw1
13.01.2017 20:51В исходной формулировке ничего не было про правильность постановке задачи.
Но и про наличие готового формального описания тоже ничего не было. Чтобы этим способом написать правильную программу, нужно правильное формальное описание, а получить его (гарантированно правильное) неизвестно как.VolCh
14.01.2017 10:24Правильная программа — программа, соответствующая формальному описанию. Даже если оно неправильное, то программа ему соответствующая всё равно правильная. Может бесполезная, может даже вредоносная в каких-то кейсах, но правильная.
qw1
14.01.2017 11:17+1То есть, правильное ПО не относится к
ПО, которое будет работать без ошибок
VolCh
14.01.2017 15:52Оно работает без ошибок — полностью согласно формальному описанию.
qw1
14.01.2017 19:42Предположим, что ваше трактова термина «ошибка» верная. Тогда почти всё современное ПО не содержит ошибок, потому что не составлено формальное описание. Однако, множество существует множество дефектов, которые признаны ошибками. Противоречие. Исходное предположение неверно.
VolCh
14.01.2017 23:50Раз не составлено формального описания, значит ПО не может ему соответствовать, а значит не может считаться безошибочным.
qw1
15.01.2017 00:30Ошибка — несоответствие формальному описанию.
Если нет формального описания, то ошибок тоже нет?VolCh
15.01.2017 01:23+1Значит есть несоответствие. Вся программа — формально большая ошибка, если что-то принимает на вход и что-то отдаёт, хотя формальное описание пустое.
qw1
15.01.2017 14:32С таким убеждением можно подходить к любой команде разработчиков и заявлять: «вся ваша программа — большая ошибка».
— А в чём ошибка?
— Не скажу, сначала сделайте формальное описание.
Интересно, куда вас пошлют после такого диалога…Source
15.01.2017 14:40+1Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
malbaron
15.01.2017 14:53Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
Мы (комментирующие тут) что — все до единого в космической индустрии служим?
Откуда такие вопросы вообще в голову пришли?
qw1
15.01.2017 15:32Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
А если для программы составлено формальное описание, и проведено доказательство корректности, но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?VolCh
15.01.2017 19:53«У меня нет оснований считать, что программа безошибочна».
qw1
15.01.2017 20:31Но зато у вас нет оснований считать, что программа ошибочная, если интуитивно понятно, что она работает неправильно, а формального описания нет.
VolCh
15.01.2017 22:39Если есть какое-то описание и поведение ему не соответствует, значит программа ошибочная. Если нет никакого описания, то нет никаких оснований считать ошибочная она или нет. Может ТЗ состояло в выдаче kernel panic.
Source
16.01.2017 00:13но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?
Вы меняете условия на ходу. Обсуждался случай, когда достоверно известно об отсутствии формального описания, цитата: "Если нет формального описания, то ошибок тоже нет?"
TheShock
15.01.2017 01:28Даже если оно неправильное, то программа ему соответствующая всё равно правильная
То есть ответственность за корректное с точки зрения бизнес-логики поведение мы перекладываем с программы на формальное описание? Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?Source
15.01.2017 02:11Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?
Да можем конечно… С математикой же мы как вид как-то справляемся. Так же и программа может быть представлена в декларативном виде. Есть особо сложные случаи, но подавляющее большинство программ реально формализовать… Другой вопрос, что это кучу времени займёт при текущем состоянии IT-индустрии (что не говори, а она ещё только на начальном уровне развития).
s-kozlov
15.01.2017 07:59+1С математикой же мы как вид как-то справляемся.
Справиться с математикой гораздо проще, т.к. она, вообще говоря, не описывает реальный мир.Source
15.01.2017 13:24Вообще говоря, в описании реального мира математика продвинулась куда дальше, чем программирование (см. математическая физика). Но по сути и то и то работает с упрощенными моделями реальности. Формальное описание — это и есть модель.
malbaron
15.01.2017 13:31-1Справиться с математикой гораздо проще, т.к. она, вообще говоря, не описывает реальный мир.
Точно, точно.
То-то мы строим высоченные здания и уверены (из расчетов), что они не рухнут.
Или на каждом шагу в быту, даже без перепроверок, суммируем и умножаем и не пересчитываем соответствие на деле сумм и произведений нашим расчетам.
Точно точно — математические расчеты не относятся к реальному миру.
И 2*пи*р никакого отношения к кругу не имеет — нужно линейкой перемерять.
Вы путаете:
Математика априори абстрактна. Но это не означает, что она не имеет отношения к реальному миру.
Тут все дело в модели, а не в математике как таковой.
Именно модель и связывает реальный мир и математику.
Бизнес-процессы в больших масштабах ложаться на математику (на статистику, если быть точным).
s-kozlov
15.01.2017 15:10Но это не означает, что она не имеет отношения к реальному миру.
Где я утверждал, что математика не имеет отношения к реальному миру?
Еще раз: математика не описывает реальный мир. В реальном мире нет точек, треугольников и числа пи. И тем не менее математический аппарат успешно применяется для моделирования реальности. Тут нет противоречия.
Математика априори абстрактна.
Физика тоже абстрактна (вспомните хотя бы «материальную точку»), и тем не менее она описывает реальный мир, хоть и неточно.malbaron
15.01.2017 16:09Физика тоже абстрактна (вспомните хотя бы «материальную точку»), и тем не менее она описывает реальный мир, хоть и неточно.
Очевидно ж — почему.
Ведь физика — это именно что моделирование реальности.
А модели — это как раз то, что связывает математику с реальностью.Fesor
15.01.2017 19:37Не забываем что математические модели это все же больше теория. Не зря же помимо нее обычно делают настоящую модель и проводят симуляции на ней. Не зря после моделирования каркрэша на комьютере по итогу всеравно проводят реальные испытания. Это позволяет существенно снизить издержки на производство и тестирование, но это не гарантия успеха.
На эту тему есть неплохой докладик: https://youtu.be/9IPn5Gk_OiM?t=11m29s
там как раз про устранение человеческого фактора в разработке ПО за счет использования формальных методов.
VolCh
15.01.2017 11:13Да, разделение ответственностей. Описание отвечает за описание :) бизнес-логики, а программа за реализацию описанного.
Полноценного продукта с UI, взаимодействием с ОС и т.п. — только в теории, наверное. Конкретно бизнес-логики — думаю, вполне возможно. Вернее, возможно создать полностью верифицируемое формальное описание проходящее тесты на полноту и не противоречивость. Естественно, если эксперты или аналитики что-то напутают, то такое описание будет с ошибками.
Fesor
14.01.2017 18:58а получить его (гарантированно правильное) неизвестно как.
Тут в дело вступает психология. Люди плохо описывают необходимые детали из головы. С другой стороны, когда человеку показывают не то, что он хотел, он уже выдаст намного более полезный список отличий из которых это формальное описание можно будет сформировать.
То есть если у вас нет четкого формального описания программы, его можно составить путем получение обратной связи от клиентов (пользователей системы по хорошему). А из этого мы можем сделать логическое заключение — нам нужно выстраивать работу таким образом, чтобы цикл обратной связи был меньше. И есть целая масса способов собирать фидбэк не вкладывая безумные усилия в разработку. Начиная прототипами и мокапами и заканчивая gherkin сценариями с описанием поведения системы (specification by example, bdd).
qw1
14.01.2017 19:52из которых это формальное описание можно будет сформировать.
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).
То есть, если у нас конвертор из doc в png (для простоты — первая страница), то имеем входной предикат D(x,y) — утверждение, что x-й байт входного документа есть y, и с помощью правил формального описания можно доказать набор P(x,y) — утверждений, что x-й байт выходного документа есть y. Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?
И это ещё пакетное преобразование. С интерактивными программами вообще ужас.Fesor
14.01.2017 20:22+1Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение
Нет конечно. Вообще пожалуй мой комментарий лишь говорил о том что можно получить вменяемые требования по которым можно делать работу. Некое "абстрактное в вакууме" описание будет оставаться все таким же абстрактным.
Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов?
То что вы описали никому не нужно. Вообще на эту тему есть неплохой доклад Грэга Янга. Там как раз про "миллионы формул" и "все возможные word документы" найдутся тезисы.
В целом же я не вижу никакого смысла в "формальном описании" которое сложнее реализации. Реализация задачи может считаться формальным описанием?
qw1
14.01.2017 23:37я не вижу никакого смысла в «формальном описании» которое сложнее реализации
Мы в этой ветке обсуждаем доказательство правильности программ системами логического вывода.
А что есть «формальное описание» в ваших терминах?
qw1
14.01.2017 23:41Реализация задачи может считаться формальным описанием?
Да. Но чтобы сделать правильную реализацию нужна другая правильная реализация?Fesor
15.01.2017 13:56Прототипы, мокапы, модели и т.д. могут восприниматься как "другая" возможно правильная реализация. Эта реализация должна быть на порядки дешевле "настоящей" и должна служить источником фидбэка для уточнения требований дабы со временем сформировать уже итоговый продукт или отдельные его фичи.
qw1
15.01.2017 14:38Прототип, как правило, не учитывает всякие сложные случаи, на тяп-ляп относится к безопасности (отсутствует супер-тщательная валидация входных данных), на него равняться нельзя.
Fesor
15.01.2017 15:50и тут в дело вступает управление рисками. Лучше делать систему так, чтобы быстро реагировать на риски а не пытаться их все предотвратить. Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?
s-kozlov
15.01.2017 16:20+1Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?
Чтобы этот один раз не нанес гораздо больший ущерб, чем стоимость нескольких человекомесяцев.malbaron
15.01.2017 16:26Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?
Чтобы этот один раз не нанес гораздо больший ущерб, чем стоимость нескольких человекомесяцев
Давно известно, что если оставить право оценивать важности таких вещей разработчикам — то они расставят приоритеты совсем не так, как финансово целесообразно предприятию. Что в конечном итоге может привести к потери финансовой устойчивости предприятия.
Это вопросы менеджеров и выходит за тему данной статьи.
Lofer
15.01.2017 13:50В целом же я не вижу никакого смысла в «формальном описании» которое сложнее реализации. Реализация задачи может считаться формальным описанием?
Извиняюсь, что сломаю ваше мнение о «невозможно» и "… дороже чем..".
Логика тут немного другая. Есть бюджет проекта, скажем 100 денег.
Есть два варианта решения:
- 10 денег — аналитика «тяп-ляп»
- 20 денег — срач/менеджемент по ходу проекта
- 60 денег — ваять-кодить решение (пару-тройку раз переделав)
- 10 денег — тестить
или
- 40 денег — аналитика «формально корректная»
- 10 денег — срач/менеджемент по ходу проекта
- 30 денег — ваять-кодить решение (сделано сразу верно)
- 20 денег — тестить
Так получилость, что у меня было штук 6 похожих проектов сделанные этими двумя разными подходами и мог сравнить метрики проектов.
Фактически получалась «перемена мест слагаемых» :)
Выбор решения состоит в балансе между знанием предметной области и предоставлением MVP.
В большинстве случаев этот выбор — проблема психологии. Клиенту все равно «куда говорить» — в draft проекта или «формальную бумажку», главное что бы его слушали и записывали. А в код или UML- ему пофиг. Главое что бы к моменту Х все было готово.
s-kozlov
15.01.2017 08:05Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).
Согласно этому определению, исходный код любой программы — формальное описание этой программы.
Теперь вы сможете ответить на свой вопрос согласно своему определению формального описания.
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
qw1
15.01.2017 14:40Ладно, поправлюсь
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?
malbaron
15.01.2017 14:59Ладно, поправлюсь
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?
Программы пишутся не просто так, не только ради удовольствия.
Посему всегда нужно ставить вопрос: а это надо, это кому надо, это действительно надо?
Описания (вполне себе нормальные) существуют в мире ПО.
Вот только до абсурда их доводить не надо никому.qw1
15.01.2017 15:42Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».
malbaron
15.01.2017 16:16-1Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».
Я просто много лет как не джун. И знаю, что рулит практическая польза. И только она.
Это только джунов и студентов может всерьез интересовать «правота абсолютно формального описания».
Кто поопытнее — могут это обсуждать только в качестве стёба или троллинга.
И так будет до тех пор, пока компьютерные программы не начали писать сами себя в индустриальных масштабах.
Программистам абсолютно формальное описание нужно только для того, чтобы прикрыть свою задницу (программа написана согласно описанию — отвалите с вашими претензиями, лучше дайте денег за выполненную работу).
Но ведь никто не будет применять для вашего наказания абсолютного оружия. Так что абсолютно формальное описания — явный перебор и напрасная трата времени.
Согласитесь, что даже в внутри вашего предприятия никто не будет всерьез на официальных совещаниях тратить на это время. Разве что в курилках. Единственная возможность обсосать эту тематику — на формах типа этого.
Программируем мы для удовольствия или для денег.
В коллективе программирующих ради удовольствия вас также далеко пошлют с этим формальным описанием — вы все удовольствие коллегам испортите.
В коммерческом проекте бизнес сначала посмотрит на абсолютно формальное описание с интересом и спросит — а как оно себя окупает. После получения ответа (никак) бизнес также потеряет всякий интерес к абсолютно формальному описанию.
malbaron
15.01.2017 14:05Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
Даже более того…
Вы никогда не слышали слово «бриф»? Эта штука используется, чтобы формализовать требования к чисто творческим вещам: фотография, графика, дизайн, видео.
На бриф потом напирают дизайнеры, требующие от заказчика оплаты — соответствует брифу, давайте деньги.
Пример брифа.
Вы в курсе как планируется сериал «Игра престолов»? Да, да, да там бесстыдно написано в плане серии «показать голую женщину в полный рост спереди». Что в результате реализуется в виде исполнения наемником с сидящей на коленях проституткой песни Rains of Castamere (S05E09)
Так что формализовать можно даже такие не формализуемые, казалось бы вещи.
А вы про какие-то программы.
Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания. Но это никому и не нужно. Программы реализуются ради того, чтобы они пользу приносили, а не ради формального соответствия.
Индустрия ПО существует. Еще ой как существует.
И бизнес требует определенности, поэтому формальные описания вполне себе существуют.
Если вы о них не знаете, — это просто объясняется тем, что вы еще не senior, а то может и не крепкий middle.
Все к вам придет в свое время, не нужно бежать впереди паровоза.Source
15.01.2017 14:27+1Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания.
Кхм, в этой ветке речь идёт о формальном доказательстве отсутствия ошибок в программах. А Вы говорите об обычной спецификации, это совсем другая тема.
malbaron
15.01.2017 16:21Кхм, в этой ветке речь идёт о формальном доказательстве отсутствия ошибок в программах. А Вы говорите об обычной спецификации, это совсем другая тема.
Это уже придумано до нас.
Просто посмотрите как это реализовано в космической индустрии (стоимость ошибки страшно высока, бюджеты же на реализацию достаточно хороши). Почти 50 лет как.
;)
Здесь же пытаются притянуть за уши изначально бессмысленную задачу.
Никому не нужно это формальное доказательство, когда бизнес сравнит стоимость его и фактически принесенную пользу.
Source
16.01.2017 00:26+1Вы умеете внимательно читать? Перечитайте, пожалуйста, эту ветку с начала и поймите, что тут обсуждают теоретическую возможность формального доказательства при условии неограниченного времени и бюджета, а не его практическую целесообразность.
malbaron
16.01.2017 08:02-2Вы умеете внимательно читать? Перечитайте, пожалуйста, эту ветку с начала и поймите, что тут обсуждают теоретическую возможность формального доказательства при условии неограниченного времени и бюджета, а не его практическую целесообразность.
Что тут обсуждать-то?
Невозможно.
Ибо:
1. Программа получает числа на входе.
2. На выходе отдает квадраты входных чисел.
3. С вероятность 0,00000000000000001 выдает в ответ всегда 0, вне зависимости от входного числа.
Пункты 1,2 соответствуют формальному описанию.
Пункт 3 — специально вложенная ошибка, боящимся не получить свои деньги программистом (ну делают так некоторые козлы).
Финиш.VolCh
16.01.2017 09:34+2Верификация выявит третий пункт.
malbaron
16.01.2017 11:27-2Верификация выявит третий пункт.
Если бы верификация все выявляла, то не требовалось бы «формальное описание программы».VolCh
16.01.2017 13:50Формальное описание для того и нужно, чтобы верифицировать программу на соответствие ему.
malbaron
16.01.2017 14:16Ну не выявит, не выявит 100%. Пример выше.
Выявит только формальное описание равнозначное самой программе. Что лишает его всяческого смысла.
VolCh
16.01.2017 16:58Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.
malbaron
16.01.2017 17:05Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.
Если верификация реальна и она проще программного кода (а иначе какой в ней практический смысл) и при этом 100% гарантировано все режимы работы программы проверяет — давайте писать верификационный код. А ПО и будет переводить его в программный уже.
;)
VolCh
16.01.2017 17:09Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.
malbaron
16.01.2017 17:15Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.
Формальное описание, на основании которого, как вы писали, будет делаться верификация — это совсем не процесс. А тоже объект.
Вот вы хотите верифицировать.
И у вас для этого есть формальное описание.
Верификация 100%.
Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно. Ее из 100% формального описания выведет автоматика за вас.
То есть куда не погляди — практического смысла это лишено.
Потренироваться тут в комментариях в слепом десятипальцевом методе набора текста на клавиатуре только?VolCh
16.01.2017 17:45«Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно.»
Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.malbaron
16.01.2017 17:55Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.
Проверка корней уравнения — это подобно всего лишь тестированию программы, так же проверяется частный случай.
Здесь же в комментариях замахиваются на общую проверку со 100% гарантией. Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.
Вот я и спрашиваю, если программы пока еще пишут люди, а не другие программы — то какой в этом смысл? Ну кроме как языком побалякать.VolCh
16.01.2017 18:06Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.
malbaron
16.01.2017 18:32Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.
Это если бы вы под проверкой подразумевали простое тестирование частных случаев — было бы просто.
Если же мы рассматриваем, как тут, «доказательство» — это другой коленкор.VolCh
16.01.2017 20:02Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.
По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.malbaron
16.01.2017 20:06-1Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.
По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.
Прошло уж 20 лет как Пролог умер, а человечество еще не продвинулось в индустриальных масштабах к таким проверкам даже для консольных утилит, не говоря уж про GUI.qw1
16.01.2017 21:07+1Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.
Другое дело, он в тырпрайзах не применяется. Но он и раньше не применялся, когда был якобы жив.malbaron
16.01.2017 21:14Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.
Преподают.
Но это не имеет к Прологу отношения.
Учился на математическом.
Ничего мы на Прологе не моделировали.
Даже более древний Фортран где-то там ограниченно применялся (в математической физике, вроде), но уж не как не Пролог.
Я его так, для себя почитал.
Source
16.01.2017 18:34+1Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.
Естественно написать корректную (с гарантированным отсутствием багов) программу сложнее, чем некорректную. И, разумеется, писать корректные программы экономически невыгодно, по крайней мере на текущем этапе развития индустрии. Какой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.malbaron
16.01.2017 18:42акой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.
Еще раз:
В комментариях никто даже не вышел на верную постановку задачи.
О каком развитии теории по решению задачи тут может идти речь?
Source
16.01.2017 20:41+2А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Когда Вы уже ветку с начала перечитаете и осознаете, что тут никто и не собирался никаких задач ставить.
Сформулируйте лучше цель вашего активного оффтопика… Вы хотите привести доказательство, что формальная верификация невозможна никогда и ни при каких условиях или тупо покапитанить что это долго, дорого и не во всех случаях возможно?malbaron
16.01.2017 21:32-2А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Разумеется, не ожидал.
Если бы вы начали (если бы вы могли) обсуждать всерьез — 99% ваших собеседников бы скисло и вышло из беседы.
Интересно ведь просто языком побалякать, а не думать.
А тут думать пришлось серьезно, хотя бы чтоб прочитать и понять комментарий.
Я другого ожидал (ожидаю)
На Хабре частенько можно почитать упоминания об интересных вещах.
А дальше уже самому пойти копать.
Здесь же даже направление не смогли задать за несколько дней не то чтобы формулировки/постановки проблемы — хотя бы к ним приблизиться или упомянуть, а кто уже где подобные вещи решал/решать пытается.
Да и не старались.
Вот я и говорю — пустопорожняя беседа. В которой по сути проблемы никто ничего сказать и не может. Ни фразы.
Source
16.01.2017 23:06+1Вам не кажется забавным, что эта "пустопорожняя беседа" по большей части состоит из Ваших собственных комментариев, на которые Вам изредка отвечают разные люди?
А по поводу ссылок, я Вам дал ссылки на Agda, на символьное выполнение программ и т.п. Уже успели ознакомиться?
В качестве практического применения символьное выполнение используется для автоматической генерации юнит-тестов.
Что касается Agda, то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.malbaron
16.01.2017 23:19-1то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.
Ну вот наконец-то, единственное золотое зерно.
Все остальное — тлен и плевелы (плевела? плевел? )
И почему мне нужно было ваш шпинять два дня, чтобы его получить?
Отчего бы вам сразу не выставить такой (легчайший, что вполне достаточно) акцент на Idris?Source
16.01.2017 23:41+1Ну, Вы ворвались в ветку с заявлениями типа формальное описание — это бриф, а формальное доказательство — то же самое, что тестирование. Исходя из этого сложно сделать вывод, что тема Вам хоть капельку интересна, т.к. все заявления мимо кассы.
На самом деле тема очень обширная. Хоть пока и не мейнстримная. И то, что Eiffel, Coq и Prolog не используются широко в повседневной разработке вовсе не значит, что они умерли, идеи их живут и развиваются. Рано или поздно это всё придёт и в мейнстрим, т.к. цена ошибок в ПО с каждым годом только растёт.
s-kozlov
16.01.2017 17:13Если верификация реальна и она проще программного кода (а иначе какой в ней практический смысл) и при этом 100% гарантировано все режимы работы программы проверяет — давайте писать верификационный код. А ПО и будет переводить его в программный уже.
Слышали о проблеме P и NP? Полагаю, нет.malbaron
16.01.2017 17:22Слышали о проблеме P и NP? Полагаю, нет.
Ага. Имею не техническое программистское, а математическое ВУЗовское образование. Так что напрасно умничайте терминами.
Обсуждаемая тематика в комментариях являет собой не более чем способ поважничать, так ни один автор из комментариев не то, что не подошел к решению проблемы (да это и не возможно в таком формате беседы), а даже никто и сформулировать-то грамотно задачу не сподобился.
Ибо понимает — есть пределы его ума. P и NP — а дальше сказать нечего.
Но этих букв достаточно, чтобы зрители благововели?
Господа, вы тут уже не первый день из пустого в порожнее переливаете.
Ни в практическом смысле пользы нет ни в математическо-теоретическом вы даже к правильным словам так подойти и не можете.
s-kozlov
17.01.2017 06:39+2Имею не техническое программистское, а математическое ВУЗовское образование
… наличие которого не мешаем вам нести феерический бред вроде «давайте писать верификационный код. А ПО и будет переводить его в программный уже» или «Ее из 100% формального описания выведет автоматика за вас».
Так что напрасно умничайте терминами
Обычно слово «умничать» употребляют люди, которые не в теме и хотят, чтобы за это почему-то было стыдно собеседнику. Так вот, мне ни капельки не стыдно за ваше невежество.
P и NP — а дальше сказать нечего.
Но этих букв достаточно, чтобы зрители благововели?
Я думал, что этих букв достаточно, чтобы собеседник с якобы высшим математическим догадался, что логика «найти решение не сложнее, чем проверить его» не работает. Ну или хотя бы погуглил, если не в теме.
s-kozlov
17.01.2017 06:41Господа, вы тут уже не первый день из пустого в порожнее переливаете.
Ни в практическом смысле пользы нет ни в математическо-теоретическом вы даже к правильным словам так подойти и не можете.
Ну так уйдите из этой ветки, раз не видите пользы. Останутся те, кто видит.
Source
16.01.2017 12:46Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?
malbaron
16.01.2017 14:21-2Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?
Prolog умер лет 20 назад.
Вы здесь занимаете пустопорожней беседой, господа.
malbaron
15.01.2017 14:10-1Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).
И такое существует и активно применяется
Скажем, http://swagger.io/ мы используем.
Только зачем вам машиночитаемое формальное описание?
Вам же с ним жить, кому это нужно в реальной практики постановки задач, кроме таких вещей как API
Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?
Ничего этого не нужно.
OCR существует. Делаем обратное преобразование и проверяем (даже тестами можно, автоматически).
avost
17.01.2017 01:42Отчего же неизвестно? В очень многих случаях очень даже известно. Почти вся автоматика от микроволновок до "вояджеров" так работает.
Abo111
10.01.2017 17:03+8На мой взгляд дело не в методологии а в цели ее внедрения. Если стали внедрять — значит недовольны текущим положением. Предположу, что хотели сократить расходы на разработку. Видимо цели добились — самые старые и наверное самые высокооплачиваемые ушли. Экономия налицо.
Далее вероятно будет как в этом сценарии.
Merkat0r
10.01.2017 17:47+1Не, обычно внедряют не потому, что не довольны, а потому что *модно*. Смотрите-ка, а у %условныйгугл% СКРАМ и нас на курсах MBA ему учили — это круто! надо внедрять!
А! И, ни коем случае не забыть теперь считать человекочасы!
Ну, а дальше по накатанной — найм эффективного манагера(главное умеющего красиво ссать в уши и петь диферамбы) и спуск в тартарары
RainM
10.01.2017 17:21+3Рискну сказать, что если методологию внедряют повсеместно плохо, может быть все-таки что-то не так с методологией? Постоянно слышу про «вы неправильно используете Agile/Scrum/...» — покажите мне, где они используются правильно?
P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
fastwit
10.01.2017 17:37-2Считается, что в команде есть хотя бы один компетентный разработчик, способный оценить задачу с минимальной погрешностью. В процессе игры в «планнинг покер» он может разъяснить свое видение решения остальным членам команды, а также помочь в разбиении этой задачи на подзадачи. Ошибка в неделю — это фокус фактор уровня джуниоров, которые только вчера увидели код, который им предстоит написать.
Исключением могут быть задачи на исследование, но даже в этом случае обычно можно разбить задачу на несколько этапов и реализацию оставить на следующий спринт, когда будет известен подход.RainM
10.01.2017 17:54+1Вы действительно считаете, что определение подхода исследовательской задачи (даже без реализации) может быть оценено? Если да — скажите область, интересно. В моей области это нереально, к сожалению.
fastwit
10.01.2017 18:06Область эта именуется software development, где, собственно, и применяется Agile. Сложно оценить научные задачи, бывает сложно оценить производственные задачи, но это предметная область и этим занимаются отдельные люди. На agile-доску программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны, не думаю, что вы изобретаете новые. Оценить применимость того или иного алгоритма, а также композицию этих алгоритмов для решения конкретной проблемы — посильная задача.
RainM
10.01.2017 18:15+3>> программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны.
Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.YemSalat
10.01.2017 21:17+1Да нет же, никаких «готовых» ответов нету — есть бизнес задачи, а разработчиков просят оценить их «примерно»
Поэтому поинты обычно идут в геометрической прогрессии: 2, 4, 8, 16 (ну или там размеры футболок), чтобы не было соблазна пытаться давать точные оценки трудозатрат. Просто чтобы у бизнеса складывалось понимание что вот эта задача вроде как простая, займет максимум день, а вот эта посложнее, дня на 2-3 и т.д.
Чтобы у менеджеров было примерное представление о сложности заданий. Ну и заодно насколько трезво члены команды оценивают свои силы.
fastwit
11.01.2017 11:39Это же очевидно. На доске оказываются конкретные задачи после планирования и оценки, эти задачи содержат в себе информацию о том, что нужно сделать. Это уже ответ. Вопросы были немногим ранее, во время планирования спринта и обсуждения требований. Согласен, что Agile не применим в случаях, когда команда сидит свесив руки и асболютно не понимая, что нужно предпринять для достижения результата. Agile и Scrum — это о взаимодействий заказчиков и исполнителей, а также внутри команды исполнителей. Нигде не прописано, что если задача оказалась больше и перекочевала еще в пару спринтов после, то нужно отрубать кому-то руки. Прописано лишь то, что все заинтересованные лица будут об этом информированны как можно раньше. Одна из важнейших особенностей Agile в том, что команда учится и развивается, поэтому ошибки в оценках несмертельны.
BalinTomsk
10.01.2017 21:42+1---На agile-доску программистам
а что если в команде не software devеlopers, а principal software engineers и они сами себе ставят задачи? И таких компаний немало.
У меня были задачи что я и через месяцы не знал можно ли ее довести до конца и когда закончу.
А reverse engineering? Там можно месяцами ковырятся и в любой момент — сказать все, писец, дальше хода нет.ad1Dima
10.01.2017 21:57+1У меня были задачи что я и через месяцы не знал можно ли ее довести до конца и когда закончу.
Что за атомарная и неделимая задача такая. Есть пример?khim
10.01.2017 23:34+5Да легко. Нужно разобраться почему важная игра одного из наших партнёров на устройстве падает при установке аппа от Facebook'а или Skype, но отлично работает без.
Расследование, занявшее месяц, показало что в старых версиях Android'а sem_wait работает не по POSIX'у, а новые версии это воспроизводят только если апликуха собрана под старую версию, эта ошибка «стреляет» если вложить старую версию Unity в новый апп и обеспечить достаточную нагрузку на систему, после чего GC в mono с некоторой вероятностью вынесет живые обьекты.
И? Сколько у вас будет «поинтов» это задачу? Оно ведь отлично вопроизводится — ну сколько может потребоваться времени, на то, чтобы с этой плёвой ошибкой разобраться?ad1Dima
11.01.2017 07:28+1Если у вас все задачи такие, то вероятно именно вашему процессу agile подходит.
Если же задача разовая. Начнём с того, что у вас нет постановки, как она к вам пришла. Но допустим это стабильные, но рандомные креши при высокой нагрузке. Лично я бы никогда не назвал данную задачу плевой, потому что это явный признак проблем с памятью. Кто вам сказал, что она плёвая?
После того как мы сразу определились, что задача не плевая, то сразу можно предположить, что для ее решения понадобится как минимум спринт. Вот вам и оценка: максимум строипойнтов, которые вы можете вместить, на предварительное исследование и попытку решения. Причем лучше тоже разбить на два этапа: стредняя по сложности задача на предварительное исследование и сложная задача на исправление.
После исследования можно уточнить оценку. И сразу же через день-два (а не через месяц) осознать что проблема серьёзнее. После этого у команды есть возможность оперативно подключить дополнительные ресурсы.ad1Dima
11.01.2017 14:40Если у вас все задачи такие, то вероятно именно вашему процессу agile подходит.
Не подходит, конечно, имелось ввиду.
fastwit
11.01.2017 10:56Мне не ясно в чем трудность оценки? Ставите максимальную оценку и если нужно в конце спринта тащите ее в следующий. При этом на daily standup проговариваете, что сделали и что собираетесь сделать, чтобы все были в курсе ваших «баталий».
Есть два типа вопросов «сколько поинтов?»:
- Я сомневаюсь стоит мне поставить X или Y поинтов
- Никто не знает как подступиться к задаче — максимальное количество поинтов. Это будет индикатором для мнеджера, что задача сложная и со сроками надо быть аккуратными.
ggrnd0
11.01.2017 01:21> Алгоритмы все известны, не думаю, что вы изобретаете новые.
Я не претендую, и даже не собираюсь.
Чего в общем-то нельзя сказать о заказчиках=)
azShoo
10.01.2017 18:22Во первых, сильно зависит от исследовательских задач. Для большинства из них можно дать вполне конкретные сроки сколько ресурсов съест, например, знакомство с возможными технологиями для использования и их comparison.
Во вторых, для исследовательских задач эстимейт — не значит, что «через N часов у меня будет алгоритм».
Это значит что в этом спринте вы потратите N часов на исследование этого вопроса, а оставшиеся M будете заниматься другими задачами.
При этом по истечении этого эстимейта вполне нормальным (и ожидаемым) результатов будет являться «Попробовал следующие варианты, ни один из них не подходит для наших целей потому-то, потому-то. Есть ещё такие варианты, но на их исследование нужно ещё X времени».
dvayanu
10.01.2017 18:54+2Для этого существует тайм-бокс. Отводится столько-то времени, что успел, то успел.
Пример задача разработать интеграцию API Печкина, с которой ещё никто никогда не работал. Берется тайм-бокс, и 3 дня играется с этой API. По истечении трёх дней опытный разработчик сможет оценить конкретную задачу точнее, как минимум разбить её на маленькие UserStories.
fastwit
11.01.2017 11:26Хотелось бы знать, что у вас за область такая? Применимость Agile и конкретно Scrum, естественно, всегда обусловленна процессами. Мне для личного интереса. Мой коллега пишет свою следующую книгу о применении гибких методологий в научно-производственных процессах. Я думаю, ему будет интересно узнать об областях, где принцип «разделяй и властвуй» не работает или не может быть оценен сверху.
Ниже звучали комментарии о том, что к таким областям могут относится reverse engineering или поиск багов в сторонних инструментах/библиотеках. Но это разовые задачи, а точнее баги, на счет которых в Agile тоже есть методы оценки и управления. Нельзя отказываться от процесса, только из-за одного исключения. Более того, с каждым таким исключением, компетенции команды растут и риски таких задач снижаются.RainM
11.01.2017 11:49+1Системное программирование/компиляторы/производительность. Замена инструкции А на Б приводит к регрессии на 20% по производительности. Инструкции делают одно и то же, с очень похожими таймингами. Оказалось прицина в code alignment'е. Т.е. скедулинг другой инструкции триггерил проблему совершенно в другом месте. Да и многие проблемы с производительностью из этой корзины.
Или другое: не работает раскрутка стека из обработчика сигналов. Оказалось, что причина в некорректной работе dl'я (dynamic linker). И такие задачи всплывают регулярно.
P.S. А что за коллега? Есть предыдущие публично доступные публикации на эту тему?
VolCh
11.01.2017 16:26Конкретно Scrum очень плохо себя показал в ситуациях, когда на одной команде несколько проектов в активной фазе разработки. И ещё несколько в активной поддержке.
chieftain_yu
11.01.2017 16:28А уж если одно лицо заинтересовано в разработке новых фич, а другое — в поддержке уже выпущенных, а разработчиков на все не хватает…
azShoo
10.01.2017 18:13А по какой причине одна и та же задача может занять 1 день, а может неделю?
Не сарказм, правда интересно. Я могу понять разброс в два раза, может даже в три. Ошибка в оценке в 7 раз по понятным и не меняющимся требованиям?
Я вот вижу три возможные причины:
1) Неполные и меняющиеся требования. Т.е. хотели одно (и делать это 1 день), потом захотели другое (и делать это неделю).
На этот случай скоуп спринта фиксируется и меняется толькоценой жизни менеджеровпо средством выкидывания других задач из спринта, и то только в случае, если работы можно распараллеливать.
2) Неясность реализации. Т.е. задача выглядит простой (на 1 день), но в процессе реализации всплывает много побочных факторов, требующих доработки.
И тут два пути: если есть подозрение, что такие проблемы могут возникнуть — сначала берется задача на исследование, что бы точно понимать объем работы, и только потом берется задача на реализацию.
Если с точки зрения разработчика проблем возникнуть не должно, понятно как это укладывается в текущую архитектуру и никаких рисков нет, а потом они появляются — значит есть высокая связанность и слабая прозрачность архитектуры приложения. Такие случаи пост-фактум разбираются на ретро, заводятся задачи на рефакторинг и редизайн кода.
3) Проблема оценки. Человек, оценивавший задачу не компетентен и\или страдает завышенным ЧСВ «я сделаю это с трёх нот».
С обоими случаями надо работать внутри команды — учить людей оценивать нормально, обеспечивать знакомство людей с кодом, оценивать задачи командой. Вариантов довольно много.VolCh
10.01.2017 20:38+2Баги в используемых инструментах. Время решения задачи включает время обнаружения, локализации и фикса бага.
azShoo
10.01.2017 21:46Баги в используемых инструментах — это нормальная история, но это риски.
Профачил сроки в 10 раз, собрались на ретро — обсудили, что на задачи, требующие использования сторонних инструментов нужно закладывать больше буффер, потому что грустненько.
Если такие истории случаются каждый раз — искать более подходящие инструменты.
zenkz
10.01.2017 22:44Даже без учёта требований и оценок одну и ту же задачу можно сделать быстро, а можно сделать продуманно и качественно. Один разработчик держит в голове кратчайший путь и даёт оценку к примеру 3, а другой знает подводные камни или связанные области и даёт оценку 15. И тот и другой дали правильную оценку. Поэтому так важно обсуждать оценки, поднимать вопросы и подчёркивать возможные проблемы, а не просто брать минимальную оценку.
azShoo
10.01.2017 23:17А кто-то призывал брать минимальную оценку?
Я нет. Более того, я склоняюсь к тому, что при планировании стоит брать максимальную из незавышенных искусственно оценок.Merkat0r
11.01.2017 02:08Бесполезно, менеджер в *типо скраме* объявит клиенту — через 2ч будет готово
azShoo
11.01.2017 14:30Это уже проблема менеджера в «типо скраме».
Эстимейты устанавливает команда. Thats all, folks.
Если кто-то не может сказать менеджеру «Сорян, друг, но нет» — это уже его проблемы.Merkat0r
11.01.2017 14:36Только на разборе с такими-же манагерами только топ, почему клиент не доволен или вообще ушел — будет объявлено, что это все прогеры виноваты, не смогли запилить вот ооооочень простую фишку по всего-то добавлению маленького магазинчика на сайт :)
Этож *типа скрам* — угадайте кому полетят все шишкиad1Dima
11.01.2017 14:43+1Этож *типа скрам* — угадайте кому полетят все шишки
При нормальном директоре - менеджеру в догонку.
kellas
11.01.2017 10:54Нет времени на полный анализ, срок нужно назвать в течении 5 мин. обычно.
Если «берется задача на исследование» — а сколько времени займёт исследовние? Нужно брать задачу «исследование для оценка сроков исследования»?
Т.е. перфразировав — оценка сложности задачи может занять от 1 до 7 дней — после этого будет точно известно сколько времени займёт её выполнение =)
dm_wrike
11.01.2017 01:10P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
Если вы достаточно точно оценивает задачи на спринт в среднем, то что вы достаточно сильно промахнулись с оценкой отдельных задач не так страшно. Где то больше, где то меньше, — если в сумме за спринт вы добились результата не так важно что одну задачу вы переоценили а другую недооценили. Точные оценки требуют времени, а время можно потратить с большей пользой. Но и вообще игнорировать оценки нельзя, это бардак.
TheShock
11.01.2017 02:06P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
Это и есть ошибка человека, который привык эстимировать в часах и воспринимает СториПоинты как их аналог и именно потому мы использовали систему без цифр. Задача сложная или средняя? Если б в этой задаче не было рисков вы б назвали ее средней? То риски делают ее сложной. А время уже менеджер выводит, есть средние задачи, которые делаются день, а есть такие, которые делаются три дня, в среднем за счет объема оценка усредняется. А хорошему менеджеру не очень важно, что в силу технических причин именно эта задача заняла на два дня больше, чем любая другая с такой же оценкой в СП. Уже в среднесрочной перспективе эти два дня не играют никакой роли.
erthad
11.01.2017 12:33Разбивать на более мелкие задачи не пробовали?
Я понимаю, если руки чешутся взять и все нахерачить, скучно сидеть час-другой, расписывать большую задачу на десяток-другой элементарных.
Но мы же вводя скрам хотим предсказуемости, правильно? Другим способом предсказуемости не добиться.
fastwit
10.01.2017 17:33+2Есть прописная истина, что Agile может быть внедрен только при полном принятии и понимании с двух сторон — закачика и исполнителя. В противном случае будет много проблем. В том числе и подобных описанным. К слову сказать, разработчики — это активные участники процесса, но вами описано абсолютно пассивное их поведение. Они имеют все возможности «урезать» или «растянуть» спринт. Но самое главное, один из мощнейших инструментов Scrum'а — это ретроспективы и рефлексия команды, где можно высказаться и предложить улучшения процесса.
Наряду с этим, меня тревожит, что разработчики — такие умные и классные — не сдюжили изучить методологию и ее интсрументы, а также донести свои мысли до менеджмента. Мы не в Северной Корее, чтобы «писаться на ковер» при разговоре с начальством. А если организация устроена именно так, что разработчик не может «сказать королю, что он голый», то уход разработчиков совершенно не связан с внедрением каких-то там методологий. Они сделали то, что скорее всего давно хотели сделать и в этом они — большие молодцы!erthad
11.01.2017 12:41-1Если они разбежались в течение всего лишь месяца, значит скорее всего они уже давно были готовы уйти, а закручивание гаек лишь подтолкнуло их к этому.
an24
10.01.2017 17:52Так, судя по всему, ваши разработчики недовольны элементами тайм менеджмента, а не собственно scrum. Учет рабочего времени всегда вызывает недовольство, так как его никто не умеет правильно внедрять. Например, есть такое понятие как утилизация рабочего времени. Обычно, оно равно, примерно, 80%. Если все 100% времени распределять на задачи у вас вообще весь коллектив сбежит. Потом, на исправление багов нужно планировать определенный объем времени. Потом, есть задачи вне проектов (обучение, технологические задачи и т.д.). На них тоже планируют время.
vc54
10.01.2017 17:56+3Интересно было бы почитать мнение менеджеров этой же компании. Думаю не всё там так, как описывает автор.
asirazhi
10.01.2017 17:57+2Согласен с автором. Недавно внедрял Скрам и чуть не наступил на эти грабли излишнего закручивания гаек. Вовремя осознал и остановился. Надо уметь балансировать и иметь подход к разрабам. Тоже слышал такое от Бобука.
Одно из самых сильных что может убить компанию это оторванность менеджмента от земли и незнание, что происходит в цеху. К сожалению, это очень часто в наших компаниях. Западные компании с самого начала внедряют механизмы позволяющие владеть ситуацией.zenkz
10.01.2017 22:49+1К разработчикам не нужно «иметь подход» и «закручивать гайки». Разработчики не подчинённые, а члены команды. Если менеджеры не разбираются в кухне разработки, то пусть лучше идут на завод управлять, где конвеер выдаёт определённое число деталей в сутки и их задача будет в том, чтобы заставлять работяг это требование выполнять.
evocatus
10.01.2017 23:50Если менеджеры не разбираются, то пусть идут в ларёк сникерсами торговать или улицы мести. Потому что разбираться нужно на любой руководящей должности. Иначе первым делом новоявленный начальник ломает подчинённую ему структуру до состояния, которое он способен понять (часто нежизнеспособное).
sp0ck
10.01.2017 18:09-1Любой бизнес всегда хочет знать «через сколько» он получит свою фичу. Если вся бизнес-задача уместилась в спринт, то все просто — это значит 1 фича в 2 неделя-спринта. Это бизнесу понятно. Но есть бизнес-задачи, которые могут длиться несколько спринтов, и любой менеджер захочет сразу знать сколько спринтов ему ждать результата. Значит в часы придется перевести, чтобы успокоить менеджера.
Например, во всем известной jira по дефолту оценка scrum'овских задач делается в часах.
maxutusopus
10.01.2017 18:09+2К сожалению, настоящее понимание Scrum'а втречается не часто. По сути — это как раз полная изоляция манагеров от команды разработчиков. Scrum'а master должен играть роль сторожевой собаки и пресекать любые поползновения любителей подогнать и надавить. Остальное все — детали, которые каждая команда подгоняет под себя и проект.
YuriEmelianov
11.01.2017 18:03Уважаемый, бы попутали? Это не задача СМ-ра а задача ПО! СМ-р не знаимается ролью сторожевой собаки!!!
s_berez
10.01.2017 18:38+1Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало.
Ну вот это как бы не то чтобы и хорошо, не то чтобы и плохо. Не все йогурты одинаково полезны, и не любая инициатива останется безнаказанной. В рамках SCRUM всё множество задач (backLog) изолируется спринтом(неделя например), и это очень удобно в первую очередь девелоперам, потому что никто тебе во время спринта никто не сможет поменять консистенцию спринта, поставить сверх срочную задачу (если не считать аварий и дичайших форсмажоров). И если у вас было не так, то у вас возможно это и было проблемой.
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени.
Можно у вас уточнить, это происходило только до внедрения SCRUM или так-же и после внедрения? Просто если в недельном спринте в команде из 4-5 человек каждый работает над 3-5 проектами сразу, то это игра в SCRUM. Только при этом создаются документальные прецеденты, вроде: «Если я сделал задачу А за 4 часа, значит я и впредь и всегда буду делать её за 4 часа и все другие девелоперы будут делать не меньше чем за 4 часа, иначе ситуация подлежит разбору и нервотрёпке.»
Я тоже соглашусь с asirazhi. Тут скорее всего не столько скрам виноват, как закрученные гайки таймменеджмента.
Вот еще вещь, которая режет глаз.
Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Ну то что, менеджеры конфликтуют в этом ничего страшного. А вот касались ли эти конфликты разработчиков? Между разработчиками и менеджерами должен быть один стейкхолдер, который оставит эти конфликты за скобками и создаст и донесёт внятный план на 1 спринт, на 4, и на 16 вперёд(на скрам грумингах это делается), чтобы разработчики могли правильно распланировать скорость внедрения новых фич и реализацию багов (технического долга).
И последнее:
А у вас точно все по канону было:
Ежеспринтовые пленинги, ежедневные стендапы, срединедельный груминг, демо и ретроспектива в конце спринта?
devlato
10.01.2017 18:48Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Это очень странно, поскольку по-хорошему надо бы делить разработчиков на команды с областью ответственности за определённые проекты/проект/части проекта, да и у «менеджеров», как вы их тут назвали, должно быть то же самое – каждый должен быть ответственен за какую-то часть и должен работать с определённой командой, привязанной к этой части.
у них обязательства перед заказчиками и никого не волнует занятость разработчиков
Разработчики сами по себе заняты? Или их опять-таки занимают все менеджеры подряд? Почему менеджеры не ставят перед заказчиками реальные сроки, исходящие от разработчиков?
Судя по всему, вся проблема всё-таки в гнилых эффективных говноменеджерах, которых понабрали хрен знает откуда, а не в методологии. Не нужно винить молоток в том, что строитель разбил им ваше стекло.
Lofer
10.01.2017 19:05+1в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики.
Кто-то сильно «солгал» когда запускал этот проект :) С таким же успехом могли менять коврики у мышей с синих на фиолетовые. Менеджеры — безграмотные дауны… увы.
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
Мы начинаем ценить работу других людей, только когда начинаем делать ее сами :)
Знаешь как сделать быстрее — давай знания. Если не знаешь — заткнись и не мешай. Менеджеры — идиоты… увы.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами.
А какие претензии к разработке? заказал задачи — получите задачи.
Удивляет, что есть технологические задачи?
Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
См начало: Кто-то сильно «солгал» когда запускал этот проект, поскольку хотел «уделать» своих конкурентов :)
Что и требовалось доказать: мы менеджеры безграмотные-дауны-имибицилы перегрыземся, между собой потому что не можем поуправлять между собой. А так как мы менеджеры-идиоты «все в белом», то мы еще и г#вн@ в вентилятор накидаем, что бы всем было не скучно…
Скрам, к тому что вы описали не имеет ровным счетом никакого отношения. Это просто безграмотная команда менеджеров, и с любым инструментом управления, получился бы точно такой-же п… ц.
То, что разработчики делают оттуда ноги — это самое разумное что они могут сделать, после того как доедят свой попкорн. увы.
Можно, было бы, сделать аудит процессов и привести систему в порядок, но это из разряда фантастики.
Shamov
10.01.2017 19:11+7К сожалению, в данном конкретном случае Скрам не является главной проблемой. Хотя он и отстой, но описание событий больше похоже на что-то вроде: "Всё началось с того, что я сломал ноготь. Затем мне всадили нож под ребро. Затем ещё один нож в спину. Далее разрядили обойму в живот. А затем полоснули опасной бритвой по горлу. После чего я умер. Вот такие дела, котаны. Оказывается, сломанный ноготь — это верная смерть."
Притом, что исходный поинт абсолютно верный — Скрам действительно формализует процесс разработки. Т.е. перераспределяет приоритеты между формой процесса разработки и его содержанием в пользу формы и в ущерб содержанию. Закономерным образом это не нравится тем разработчикам, которые предпочитают "быть разработчиками", но зато очень нравится тем, кто предпочитает "работать разработчиком". Тем не менее, с этим всё равно можно работать. Нужно просто одновременно с внедрением Скрама массово набирать тех, кому нравится "работать разработчиками". А разработчиков-основателей постепенно переводить на некритичные участки работы или же вообще на тренерскую работу. И даже если исходить из того, что зайцы могут как-то стать ежиками, то это в любом случае отдельная задача, которую нужно как-то решать. Недостаточно просто внедрить систему, удобную для ежиков, там, где работают зайцы. Само по себе такое внедрение зайцев в ежиков не превратит.
Lofer
10.01.2017 19:30Притом, что исходный поинт абсолютно верный — Скрам действительно формализует процесс разработки.
Любой SDLC формализует и пытается его сделать предсказуемым для бизнеса. От этого никуда.
Нужно просто одновременно с внедрением Скрама массово набирать тех, кому нравится «работать разработчиками»
Это не так, поскольку не запрещает делать ПО вам удобным (экономически обоснованным) способом.
Если карго-культ, то да… «это не нравится… постепенно переводить на....»
th0
10.01.2017 20:06+3Если методология-костяк, описываемая несколькими принципами, превращается в священную корову с каноничным писанием на много-много страниц, объясняющих как же на самом деле надо правильно понимать и трактовать, чтобы не пополнить представительный набор примеров успешного развала коллективов, то что-то все же в методологии не так божественно, как кажется на первый или второй взгляд.
Проблема, конечно, чаще всего связана с насильственным внедрением; наличием ADD практик в компании; неверным выбором скрама в качестве методологии, которая сделает всем хорошо; упованием на волшебный авось и ту самую кривую, что путем коротких итераций и рестроспектив выведет на устойчивую орбиту эффективного зарабатывания бабла. Скрам зачастую не подходит. Компании, их клиенты/стейкхолдеры и область деятельности, требования к доставке — разные. Это стоит признать, а не продолжать насаждать карго-культ и поедать кактус на скорость.
Имел возможность наблюдать исход людей, подвергнутых испытанию скрамом. Видел утрату технической компетенции в команде. Отношусь к этой методологии скептически.
nicholas_k
10.01.2017 20:06Честно говоря весь описанный негатив не имеет к Скраму никакого отношения.
Скажу больше — правильное внедрение Скрама предполагает, что разработчики кроме технических задач глубже погружаются в проблемы бизнеса, их видение проблем проекта становится шире и выходит за рамки чисто технических задач.
Конечно, многим нравится замыкаться на решении чисто технических задач и такие люди не любят думать о проблемах бизнеса. Для интровертов, а их в ИТ немало, это естественно. Но говорить, что из-за Скрама люди перестали чувствовать себя частью компании — значит противоречить духу Скрама.VolCh
10.01.2017 21:01Необязательно. У компаний могут меняться ценности, например главной ценностью объявляют удовлетворенности заказчика. Или банальную прибыль.
nicholas_k
10.01.2017 22:49Получение прибыли является главной ценностью любого коммерческого предприятия по определению. А удовлетворенность заказчика — хороший инструмент достижения главной цели.
Но все же ни удовлетворенность заказчика, ни гонка за прибылью не противоречат ни вовлеченности разработчиков в проект, ни их личной творческой реализации. Все перечисленное вполне совместимо.
В описанной же ситуации мы видим пример карго-культа, то есть скопировали некоторые внешние атрибуты скрама при полном непонимании их сути.VolCh
11.01.2017 09:58+2Получение — да, максимизация любой ценой — нет. Изначально компания могла создаваться по принципу: «есть функциональная ниша на рынке, в которых другие продукты в этой сфере или вообще не представлены, или эта функциональность реализована в „комбайнах“ для галочки. Мы можем сделать продукт, который будет делать только эту вещь и будет делать её отлично, плюс интеграция с комбайнами. Коммерческая цель — прибыль достаточная для неспешного развития и выплаты нам (стартовой команде) зарплаты и дивидендов процентов на 50 в сумме большей чем средняя по рынку зарплата для разработчиков, менеджеров и т. д. — нам миллионы не нужны, просто хороший для наших позиций доход при занятии любимым делом в команде единомышленников».
Под эти принципы находится главный инвестор (или им становится один из менеджеров, заложивший квартиру, напрмиер), всё хорошо несколько лет, но всё чаще поступают от клиентов просьбы (подкрепленные готовностью платить больше обычного) добавить ту или иную функциональность из того или иного комбайна, вместо интеграции с ним, поскольку комбайн брали для двух фич, одна из которых работает хорошо, другая для галочки и заменена нашим продуктом и, по сути, из комбайна используется только одна фича. В такой ситуации у менеджмента/инвестора возникает большой соблазн не просто реализовать эту фичу отдельным продуктом, который её делает тоже отлично, собрать под него отдельную команду и обеспечить глубокую интеграцию двух продуктов, а начать делать в отличном продукте одной фичи вторую фичу для галочки, в лучшем случае нормально, силами той же команды, максимум добавив несколько человек к ней, чтобы не срывать график релизов основной фичи. Сработало, пускай без энтузиазма, но сделали, а зарплата плюс дивиденды на 100% больше средней зарплаты по рынку мотивировали технарей-соучредителей довести работу по второй фичи для конца — кто-то ипотеку закрыл досрочно, кто-то смог позволить себе ребёнка.
Думали на этом успокоиться и вернуться к основной фиче продукта. Но главному инвестору понравилась увеличившаяся прибыль, возможно кому-то из технарей (или их женам) тоже и они продавливают решение «делаем новый комбайн, прогибаясь под хотелки клиентов — смотрите как удачно получилось по деньгам». Набирается народ по принципу «ты начальник — я дурак, я начальник — ты дурак», возможно новый главный инвестор ищется, которому первоначальный дух до лампочки, его лишь возврат инвестиций интересует, и хорошо если из дивидендов, а не изначально планирует продажу компании. Всё, первоначального духа в компании нет, это не компания одной фичи и дохода немного большего чем средняя зарплата, это компания одного комбайна с целью максимизации прибыли для инвестора. Всё. Ядро (прежде всего технари) начинают относиться просто как к работе за деньги, дивиденды (если они есть, а инвестор вполне может продавить решение полной реинвестиции прибыли) рассматривая как часть зарплаты, они уже не могут влиять на бизнес-решения, хорошо если технические принимают в духе «мы посовещались и я решил».
T13Nemo
10.01.2017 20:06+12Исяходя из кейса, я бы сказал, что команда отлично работала по Agile до тех пор, пока его не попытались внедрить -)
Важно понимать, что Agile — это культура, а не конкретная методология.
Культура, в основе которой лежат манифест и принципы.
Я вижу, что команда нарушила основной тезис манифеста:
Individuals and interactions over processes and tools (http://agilemanifesto.org/)
На мой взгляд ошибка менеджмента заключается в том, что был выбран некоректный KPI.
Scrum — это не о том, чтобы делать быстро, а о том, чтобы быстро получать обратную связь от клиента и реагировать на данные изменения.
Таким образом я бы измерял Customer Satisfaction и Amount of References, чтобы понять — насколько клиенты довольны продуктом и как часто готовы его рекомендовать, чтобы получить новые продажи. (Собственно, наша команда такие KPI и имеет). А уже потом — on time, on budget.
Нужно понимать, что Agile и scrum в частности — это не silver bullet. Нужно отдвать себе отчёт в том, какие преимущества и какие ограничения он принесёт. Понимать готовность бизнеса и клиентов к работе по таким процессам.
Культуру за день не изменить.
А вот нагрузить всех негативом — запросто. Данная статья — отличная иллюстрация. Ставлю на то, что теперь любой из команды разработчиков и менеджмента будет клеймить Agile и Scrum, не понимая того, что у них он был, а потом они его зачем-то сломали в пользу измерения часов и усиления контроля (что — полностью противоположно принципам). Такие дела.zenkz
10.01.2017 22:51+6«Команда отлично работала по Agile до тех пор, пока его не попытались внедрить» — спасибо за отличное описание пробемы. Фразу — «в избранное» и на стену некоторым «менеджерам» в кабинет.
ilja903
10.01.2017 20:06+4Вообще я пришел к выводу, что скрам это аджаил для мэнеджмента. Все эти оценивания примеривания, надзор, таим трекинг и вечное желание сделать больше поинтов противоречат самой сути манифеста.
Во-первых, это постоянная вражда из-за стори поинтов, кто больше сделал, кто главнее и тд.
Во-вторых, в угоду поинтам пишется говнокод.
В-третьих, зацикленность на маленьких задачах пораждает проблемы при рефакторинге легаси.
В-четвертых, уж не знаю почему, но каждый мэнэджер хочет больше поинтов каждый спринт, но при этом не учитывается инфляция этих поинтов. Например на создание первой кнопки уходит 4 поинта. Но при повторном таске кнопка оценивается в 1 или 0 поинтов. Автоматизировать что-либо по сути не выгодно — у хорошего разработчика затрачивается больше поинтов, чем у джуна. В глазах менеджмента он тормоз.
Можно сказать что мы не правильно готовим, но я уже столкнулся с похожей проблемой в 3 разных организациях. И если это так тяжело готовить, то стоит ли оно того? Где гарантия, что при идеальном скраме не придет новый оунер и не устроит вышеописанный хаос. И не дорого ли средней организации увольнять всех пмов, чтобы набрать скрам мастеров?
Про то что разработчики не в Северной Корее можно не читать — большинство людей не хотят спорить, бегать, прыгать — они хотят приходить на работу, спокойно её делать и уходить домой на час раньше с улыбкой на лице.
asoukhoruchko
10.01.2017 20:06+1Мне кажется, тут проблема не в процессе, а в его непонимании (во-первых) и отсутствии эффективной коммуникации между разработчиками и менеджерами во-вторых.
Те же проблемы миграции между версиями фреймворков легко объясняются понятием Technical Debt, и тыканьем в статьи о том, как он управляется через призму Скрама. Также до менеджмента надо доносить, что есть технические стори — которые дают выигрыш в производительности в будущем.
Ну и строго говоря, скрам как процесс рассчитан как раз на гармоничное сосуществование менеджеров и разработчиков, когда одни могут эффективно доносить до других те проблемы, которые надо решить для жизнедеятельности проекта и со стороны разработки, и со стороны управления. А то, что описываете вы это попытка бездумно навязать только одну точку зрения в экстремальном виде, прикрываясь переходом на новый процесс.
При этом с одной стороны, менеджеры явно зарвались, а с другой стороны, во всей команде разработки не нашлось людей, которые смогли бы эффективно донести свою позицию до руководства. Что тоже странно.VolCh
10.01.2017 21:07То есть вместо статей о подводных камнях апгрейда фреймворка читать статьи о подводных камнях методологии управления, внедренной сверху.
asoukhoruchko
10.01.2017 23:26+1Это не подводные камни методологии, а следствия особенностей разработки ПО, не понятных менеджерам, особенно привлеченным со стороны. Истина про «скупой платит дважды» зачастую очень сложна, поэтому часто прослеживается «а чего это вы время тратите на непонятную фигню — давайте лучше вот эту фичу прикрутим». При чём, чем дальше человек от разработки, тем чаще такая логика встречается.
И такая проблема встречается всегда, когда начинают трекать время и задавать вопросы.
При этом есть обратная сторона — если время совсем не трекать, и дать разработчикам делать всё, что их душе угодно — можно на выходе получить очень красивое с технологической стороны решение, которым никто не будет пользоваться. Обратная сторона не всегда случается, конечно же, потому что некоторые разработчики достаточно опытны, чтоб понимать потребности бизнеса. Но это та же история, что и с крутым менеджментом — всё просто и без проблем работает.
avost
10.01.2017 20:23+11Скрам удобен для манагеров. Скрам неудобен для разработчиков. Поэтому он внедряется не разработчиками (которым он только добавляет головняка и поэтому он им нафиг не нужен), а менеджерами (которые, таким образом сваливают свои обязанности на разработчиков).
Поэтому манагеры описывают скрам с восторгом, а недовольных разработчиков, сбежавших от нечеловеческой методологии обвиняют в том, что у них был "неправильный" скрам. Причём, отчего-то почти у всех получается именно "неправильный" скрам. По-моему, скрам — это анти-эджайл.
Отдельные случаи успешного внедрения "снизу", насколько я понимаю, редки и являются лишь статистическими выбросами.azShoo
10.01.2017 21:49А чем вам, как разработчику, не удобен скрам?
Ну, если можно, то развернуто и по пунктам. При этом постарайтесь, пожалуйста, абстрагироваться от сферического вотерфолл в вакууме, когда «мне просто дали идеально проработанное тз на 500 страниц, а я написал код, который идеально работает», а всё таки придти к жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Ну, и я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще.qw1
10.01.2017 22:08А кто-нибудь видел настоящий скрам, а не СкрамНО? Только не по мнению скрам-мастера, Owner-a или ещё кого-то, а именно по мнению разработчика.
azShoo
10.01.2017 22:15Я видел scrumban, один раз в российских реалиях, пару раз в международных.
Плюс, пара знакомых которые так же вполне успешно и счастливо работают по довольно каноничному scrum, без всего перечисленного в вашей статье.
asoukhoruchko
10.01.2017 23:30Я видел скрам на 2 долгих проектах. Отличный процесс, в котором когда надо ужимался скоуп для того, чтоб впихнуть технические стори, постоянно закрывался технический долг и даже сроки когда надо двигались.
Проблема не в процессе, а в очень небольшом количестве грамотных менеджеров. Да и разработчиков, которые постоянно думают не только о красивом решении проблемы, но и о потребностях бизнеса — очень немного.
selivanov_pavel
10.01.2017 23:43Я видел работающий скрам. Внедрение было не очень приятное, но в итоге получилось достаточно удобно, и проект в итоге вытянули(внедрять начали, когда осознали, что со сроками немножко печаль). Но там скрам-мастером поставили технического специалиста, и задачи в беклог шли в том числе от разработчиков. В наш админский беклог они шли вообще практически только от самих админов и от смежных отделов.
VolCh
11.01.2017 10:24+1Как минимум, потерей времени на организацию процессов. Было: есть разработчики, есть «девелоперс аунер», ставятся задачи, дается оценка в часах, выставляется очередность, диаграммы Ганта или что-то вроде них показывают дедлайны. Часто очередность меняется (особенно при изменении оценки в ходе) и вообще появляются новые первоочередные задачи, но все менеджеры Ганту видят сдвиги своих задач и, если что-то не так, разбираются сами между собой. Разработчик если и тратит время на процессы, то только чтобы внести в треккер первоочередную задачу, поставленную большим боссом устно. Премии платятся за внедренные по плану «эпики», очень важные для бизнеса.
Внедряется скрам, обычно сверху и «по учебнику», разработчики становятся участниками планирования, тратя на это время, которое могли бы потратить на задачи. И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то. До этого обязательств не было, была оценка. Как минимум, меняет моральный настрой, если внезапная первоочередная задача не позволила выполнить все задачи спринта, не позволила выполнить обязательства. Особенно, если задачи можно было бы успеть решить вместе с первоочередной, не тратя время на скрам-ритуалы. И да, премии, перестают платиться — зачем платить за исполнение обязательств? Максимум платятся как оплата за сверхурочные, чтобы всё закончить спринт по плану, если продакт аунер решил и смог пробить.
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Менеджер подает руководству красивые планы, но перестает нести персональную ответственность за их выполнение — это же решение команды.
ApeCoder
13.01.2017 11:07И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то.
В современном скраме этого нет. Даже нет оценки того, что можно сделать за спринт. Есть предсказание
"The Development Team works to forecast the functionality that will be developed during the Sprint"
"As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Не могу с ходу привести цитату, но мне кжется, это вообще антипаттерн.
VolCh
13.01.2017 13:08Пока у нас не внедряли скрам, к нашим оценкам относились именно как к предсказаниям, прогнозам. Как начали внедрять, все стали воспринимать как обязательство. Собственно митинги ближе к концу спринта начинались с фразы «ребята, уже понятно, что свои обязательства выполнить не сможем, давайте посмотрим что сможем доделать».
Во, кстати, с целью спринта. У нас было: «реализовать фичу А в системе 1, фичу Б в системе 2 и пофикстить баг в системе 3№.ApeCoder
13.01.2017 15:00А какой был размер спринта? Планирование осуществлялось с учетом накопленной статистики о скорости команды или разработчики оценивали в календарных днях?
Кстати, Интересный доклад о том, что оценка имеет вероятностный характер и про NoEstimates
avost
11.01.2017 21:18+3А чем вам, как разработчику, не удобен скрам?
Ну, если можно, то развернуто и по пунктам1 "митингами"
2 "митингами"
3 "митингами"
4 выполнением за менеджеров (части) их обязанностей
5 работой в режиме постоянного стресса
жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Вообще-то аджайл не про это придумали. А вот скрам — про это. И поэтому он — антиаджайл.
я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще
Менеджерам неудобен аджайл. Менеджерам удобен скрам. Он позволяет скинуть часть их работы на бедолаг разработчиков.
azShoo
12.01.2017 11:06+1Не уверен, специально вы передергиваете, или по незнанию.
Во первых, аджайл придумали именно про это. Что бы не отсылать вас в глубины умных книжек, просто оставлю вам статью на википедию.
Если вы прочитаете хотя бы её, то там подробно изложено что и зачем. Короткие итерации — из-за постоянно меняющихся требований. Беспрерывная доставка — из-за необходимости развивать продукт динамично. И т.д.
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
По поводу претензий, я специально попросил развернуто, потому что ваши пункты не звучат конструктивно.
Окей, целых три пункта про митинги. Какие митинги в скрам делают вашу работу столь невыносимой?
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса? Я не видел более удачных способов синхронизировать между собой, это или полный хаос и «каждый в своём углу херачит неизвестно что» или бредовые письменные репорты и прочий ад.
В любом случае, даже если предположить что вам глубоко положить на то, чем занимаются ваши коллеги по команде — вполне можно потратить 10 минут в день, что бы _они_ знали, чем занимается команда.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два? Опять же, мне не кажется, что это безумное количество времени, которое нельзя потратить, что бы попытаться вместе с коллегами улучшить процесс работы.
Самый муторный из оных — планирование спринта, с разбором и оценкой задач и вот этим всем. Эта штука может сожрать дохрена времени. Но, надо понимать, что единственная его цель — что бы команда понимала, что нужно сделать. Если вам приходят уже понятные и проработанные требования, то разбор задач на 3 недели для 15 человек занимает… от двух до трех часов. С декомпозицией, оценкой и вот этим всем.
Неприятно, но 2-3 часа в неделю на три недели работы — как-то немного маловато, что бы при этом со слюной у рта кричать «ДОСТАЛЕ МИТИНГИ!!11».
Если планирование, оценка и декомпозиция занимает больше времени — значит на ней объясняются и выясняются требования. Чем более неясны требования — тем дольше будет разбор задач. Но, нужно понимать, что все эти вопросы в любом случае всплыли бы, просто скорее всего позже — когда код (или по крайней мере его часть) уже написана и внесение изменений будет дороже.
Т.е. вы тратите время на митинг сейчас, что бы не перепиливать задачи в последний момент. На мой взгляд — вполне оправданное вложение времени.
В целом, на трехнедельный спринт вы потратите от 5 до 8 часов. Больше никаких обязательных митингов, затрагивающих типичного разработчика, в скраме нет.
8 часов из 120 — это дофига? Я вот так не думаю.
P.S. Все это, конечно, работает только при одном важном условии. Должен выполняться один из важнейших принципов Agile Manifesto:
Projects are built around motivated individuals, who should be trusted
Причем, выполнять его должны не только менеджеры и «заказчики», выполнять его должны в первую очередь разработчики.VolCh
12.01.2017 15:44Но, нужно понимать, что все эти вопросы в любом случае всплыли бы
Уточнить требования нужно одному человеку у другого, а вся команда сидит и слушает…asoukhoruchko
12.01.2017 18:12Угу, и при подходе «одному надо уточнить» очень часто потом вся команда работает в оверхедах, потому что зачем их мнение спрашивать — ониж работать должны.
Плюс к тому люди, которые непосредственно выполняющие какую-то работу вполне могут дать очень дельные комментарии. В итоге, исходя из личного опыта ситуация «один уточняет — другие делают» работает в разы хуже, и для команды, и для клиента.
Возможно, мне просто не везло с уточняющими — поэтому у нас очень разное восприятие того, как лучше.
avost
13.01.2017 03:27+1Во первых, аджайл придумали именно про это.
Нет, не про это. Его придумали для того, чтобы снизить уровень стресса у разработчиков. В принципе, именно это делает норманый менеджер. Но, видимо, нормальных мало :).
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Да, верующие в него так и говорят. Но это не обязательно так и есть. Он напрямую противоречит аджайл манифесту. Пункту первому и немного последнему.
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
Скрам сосредоточен на процессах. Вы сосредоточены на процессах. А первый, но же главный принцип манифеста какой? Напомнить? Individuals and interactions over processes and tools. В скраме определённо processes and tools over individuals and interactions. Поэтому скрам — антиаджайл.
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса?
Да. Это процесс превыше людей. Еженедельный "митинг" — куда ни шло. Ежедневный — бежать.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два?
И это тоже. И далее также. Это всё формальный process over individuals. Антиаджайл.
asoukhoruchko
10.01.2017 23:35+1Скорее, мало кто понимает, что такое скрам. И все выхватывают то, что привлекает их.
А поскольку некоторые менеджеры изначально считают, что они главные — получается палочная система под лозунгом аджайла, на которую навешивают тайм трекинд с загрузкой 8/8.
На моём первом скрам-проекте был нанят внешний скрам-мастер. И первые полгода она чуть ли не палкой била менеджера (PO) во время каждого митинга, пока тот не отучился от привычки раздавать команды в стиле «шоб завтро булО!».
zenkz
10.01.2017 22:31Отличный рецепт как не надо готовить Agile.
Вот список ошибок и советов:
1. Нет равенства в команде. Менеджер — это такой же член команды как и все остальные и с ним можно не соглашаться (обоснованно).
2. Никто в команде не должен продавливать свои решения. Оценка сложности задач делается совместно. Приоритеты выставляются тоже совместно.
3. Увольте менеджеров-прапоршиков. В идеале менеджерами должны становиться те, кто пришёл из разработчиков или аналитиков. Ваши менеджеры не заинтересованы в результате, а заинтересованы сделать больше/заплатить меньше. Пересмотрите KPI или систему премирования менеджеров. В идеале пусть работают за зарплату + премия на всю комаду по прохождению релиза / важной вехи.
4.Ставьте во главу угла не сроки и даже не деньги, а удовлетворённость клиента и удобство продукта
5. Оставляйте простор для творчества. Вносите в беклог предложения и улучшения. Выделяйте 2-4 недели на R&D после каждого большого релиза. (или хотя бы месяц в году).
Конечно у скрама тоже есть проблемы, например:
— Проект часто плывёт по-течению «беклога» и важные архитектурные проблемы не решаются. Из-за этого проект скатывается в разномастный набор фич вместо цельного продукта.
— Как уже было сказано выше — мало времени выделяется на улучшение продукта, которые не будут видны заказчику, но позволят в будущем сократить время разработки и сэкономить на поддержке
Но все эти проблемы решаемы. Не зря же это Agile, т.е. гибкий подход…ilja903
11.01.2017 11:491. Никогда не будет абсолютного равенства в любом обществе, особенно в формальном. Менеджер на то и менеджер. Если не он, то кто-нибудь другой.
2. Я продавливаю идею хорошего кода, тестов и ревью. Если собираемся вместе — начинается балаган и война. Лучшие проекты это часто диктатура адекватного разработчика. + сборы стоят денег
С остальными пунктами согласен. Но их нет в тех материалах которые читают манагеры. На деле скрам похож на систему гос. законов, в случае которых тебя сажают в яму и обвиняют что ты не умеешь готовить.
Aingis
11.01.2017 14:451. Нет равенства в команде. Менеджер — это такой же член команды как и все остальные и с ним можно не соглашаться (обоснованно).
Это всё замечательно, но кто будет зарплату платить? А кто будет считать премию? Или решать кого уволить? Чьё мнение при этом будут спрашивать: команды или менеджера?ad1Dima
11.01.2017 14:51Зарплату платит бухгалтерия. Премию тоже. Индивидуальные подвиги - зло.
В вопросах изменения ставки зарплаты (и увольнения) должны участвовать ключевые сотрудники команды. Один лишь менеджер не может полноценно оценить работу разработчика.RainM
11.01.2017 16:52Да, в моем представлении о идеальном мире тоже есть единороги…
ad1Dima
12.01.2017 07:13не знаю, что вы тут посчитали единорогом. но там где я работал/работаю вопросы повышения з.п. не решаются без тимлидов (разве что менеджеры и так готовы повысить). Знаю фирмы, где вопросы карьерного продвижения вообще решаются на ежеквартальном индивидуальном разговоре с менеджерами и тимлидами.
zenkz
11.01.2017 17:27А при чём тут зарплата и премии? Эти вопросы к конкретному проекту отношения не имеют. В хороших компаниях зарплата и премия считается на основании Performance Review (или вклада сотрудника в развитие компании).
Тут вопрос в том, что менеджер не должен единолично принимать решения не ставя в известность команду, т.к. реализовывать не только ему. Другое дело что после обсуждения с командой именно менеджер примет финальное решение — это и есть его роль.
w4r_dr1v3r
10.01.2017 23:11"<...>ведь у любой монеты, как оказалось <...>" срыв покровов уровня /b или показалось?
elenaelena
11.01.2017 00:13-1Г. является именно скрум, он отнимает по крайней мере 80% времени, там где его применяют со всей тщательностью.
Плюс добавляются люди, которые в большом количестве сильно мешают разработке. У нас было на одного девелопера примерно 20 BA, начальников над кем-то, скрум мастеров, огромного числа людей, который были очень плохими разработчиками, то есть совсем не умели кодировать, а теперь командуют старшими разработчиками.
Скрум приживатеся в компаниях, доход которых не зависит от разработки.zenkz
11.01.2017 00:29+1Скрам как раз-таки лучше всего приживается в чисто ИТ компаниях (особенно конслатинговых). Потому что если это ИТ департамент какой-то большой фирмы, то в лучшем случае получится какое-то подобие скрама из-за неприятия формата со стороны подразделения-заказчика и важности бумажек и прочей бюрократии.
asoukhoruchko
12.01.2017 18:06Судя по описанию — вы работали(те) в весьма странной компании. Какой IT бизнес может выдержать такую нагрузку левыми людьми, представить мягко говоря сложно.
max1gu
11.01.2017 00:15+5Забавно смотреть на ИТ-отрасль, особенно из-за того, что в ней много творческих, увлеченных людей. «К разработчикам надо относиться как к детям» — к сожалению, этим пользуются ушлые менеджеры.
Каждая новая методика или технология воспринимается как панацея.
Но, кроме творчества и влеченности, отличетельной чертой ИТ-отрасли являлется очень узкий гругозор.
Я хочу сказать, что большинство «новых» методик и технологий имеют возраст в несколько десятков лет и 2-3 итерации забвения.
Приведу примеры «килер-фич» из смежной области, управленческого менеджента:
— «ABC-costing». 10-15 лет назад: методика управления накладными расхода. Куча книг, десятки семинаров, много проектов по внедрению. Результат — она забыта. Причина — ни одго успешного проекта внедрения.
— KPI — медодика управления предприятием с использованием «ключевых показателей». Изначально выглядела как некий dush-board предприятия — по 4-5 показателя на производство, финансы, маркетинг и персонал. За посление 15 лет доведена до абсурда — по сути превратилась во внедрение «сдельщины» по всех профессиях. Много компаний превратились в «террариум единомышленников» благодаря этому.
— «описание бизнес-процессов» — здравая в начале идея доведена до бюрократического формализма — к моменту завершания описания всех процессов и создания по ним инструкций компании может уже и не быть. Реально работает в узких отраслях и подсистемах — СМК ISO9000 и низовые процессы по исполнителям при разработке ПО.
— «бюджетирование» — старая как мир идея в очередной раз полюбилась публике 15 лет назад, когда новын бизнесмены прочитали такое в газетах (о том, что оно десятилетиями работало — они ещё не знали). Запустилось множество проектов во многих странах и компаниях. В текущий момент идея жива в кулуарах — реальные работающие системы бюджетирования не выходят дальше Экселя и конкретных людей, знающих специфику именно этой компании и её продукцтов. Ни одной общепринятой технологической платформы все ещё нет.
— «20% времени на личные проекты» — можная фишка для модной компании. Став корпорацией, Гугел как-то незаметно прикрыл лавочку.
В общем, ко всем этим «модным» технлогиям надо выждать время — года 2-3, а лучше 5. В большинстве случаев они перестаю быть модными и исчезают.
Пока ещё не опровергнута классика управления: стратегические цели — план их достижения пошагово — цели и задачи на каждом шаге — тактика по достижению локальных целей и задач.
Имеено по этому шаблону надо оценивать метолики и теории и определять их место.
Отсюда же связка Проектант — инженер — прораб — строитель, ой, CTO — продакт менеджер — проджект менеджер — разработчик.
Почти все таории, описанные выше, пытались покрыть эту цепочку частично или целиком.
Кратко по скруму — это так называемый «простой неправильный ответ на сложный вопрос».
Состоит он из смеси атомарных бизнесс-процессов, обещания счастья для неспециалистов и KPI в творческих профессиях. Уже сам набор компонентов вызывает скепсис по жизнепособности: про стратегию нет вообще ни слова, голая тактика на 2 недели с отжимом продуктивности по KPI — сомнительная на марафонской дистанции аврально-потогоная система.
asoukhoruchko
11.01.2017 00:55+2Скрам появился, потому что клиент часто не понимает, что ему надо. И в результате получает не то, что ему было надо/закрывал проект. Появился он не от хорошей жизни, и не как киллер фича, а как попытка дать ответ на вопрос «как максимально быстро дать клиенту посмотреть, что у нас получается, получить фитбек и внести коррективы». Плюс возможность частых релизов (раз в 1-2 недели).
Это не серебренная пуля, и она далеко не всегда подходит. К примеру, его сомнительно использовать для разработки ПО для ракеты или атомной станции, потому что там требования четко определены на старте и не будут меняться — в этом случае процесс будет скорее мешать. Точно также, в случае мейнтенанс команды скрам подходит плохо, потому что постоянно появляются высокоприоритетные таски, которые должны решаться ASAP. Скрам с его итерациями в этом случае подходит плохо.
Да, Скрам зарождаться начал в 1986 году, а манифест был написан в 2001. «Модная технология» выждала где-то в 3-8 раз больше времени — и исходя из наблюдений количество проектов на нём (и других гибких) только растёт, а вот классика управления (RUP) используется всё реже.VolCh
11.01.2017 10:27Скрам появился, потому что клиент часто не понимает, что ему надо. И в результате получает не то, что ему было надо/закрывал проект.
Скрам не единственное решение этой проблемы, но почему-то самое популярное.asoukhoruchko
11.01.2017 14:38Оно достаточно неплохо работает, если применяется с умом, плюс на слуху, и есть много людей, которым он знаком. Плюс куча инструментов, которые его поддерживают.
2creker
11.01.2017 00:15+2Как тут некоторые написали — scrum это реально постоянный стресс. Более того, постоянно изменяющимся пожелания менеджера по одной задаче ( поправь тут, слушай давай передедаем по-быстрому, тут ведь не долго), необходимость на часовом митинге более менее реально оценить объем работы, практически постоянная работа ( нужно ж и балду погонять, чтоб с мыслями собраться или зачитнуть какую-нибудь статью по твоей теме, чтобы расширить кругозор) — все это истощает. У нас ушло несколько людей по этим причинам
Larrikin
11.01.2017 00:54+1И что, все эти менеджеры/мастера не заметили падения индекса счастья? Значит, это был не скрам, ибо контроль за счастьем по методике прямо в базе прописан.
ilja903
12.01.2017 00:14А можно ссылку на индекс счастья? Нет, серьёзно не слышал просто. Интересно как мерить предлагают.
Larrikin
12.01.2017 06:17Количественная сторона счастьяКак мы можем сделать счастливыми себя, своих подчиненных, своих коллег по команде? Как преобразовать счастье в продуктивный труд, приносящий прибыль?
Чтобы ответить на все вопросы, обратимся снова к Toyota и крестовому походу Тайити Оно, объявленному им против потерь. Ликвидация потерь – высокая цель, приведшая Оно к идее непрерывного совершенствования. Недостаточно достичь определенного уровня производительности и успокоиться на этом. Следует постоянно анализировать рабочие процессы и неустанно улучшать их. Увы, совершенство недостижимо, но любой шаг в его сторону будет оправдан.
Точно так же, как мы распределяем работу на легко управляемые короткие циклы, а рабочее время разбиваем на небольшие промежутки, так и усовершенствование необходимо делить на фазы, чтобы на каждый отрезок времени приходилось по одной фазе улучшения. Понятие «непрерывное совершенствование» в японском языке передается словом кайдзен. Какие помехи можно устранить за один раз и таким образом добиться небольшого улучшения – и так, шаг за шагом, осуществлять идею непрерывного совершенствования?
В методологии Scrum этот вопрос рассматривают в конце каждого спринта во время ретроспективных собраний. Члены группы рассказывают о заданиях, выполненных за прошедший спринт, перемещают рассмотренные задачи в колонку «Сделано» – теперь эти части программы можно продемонстрировать заказчику и выслушать его мнение, а потом приступают к обсуждению того, что получилось хорошо и что можно было бы сделать лучше в этом спринте. Далее они идентифицируют наиболее серьезную помеху и анализируют задачу по ее немедленному устранению в следующем спринте. Так решается проблема непрерывного совершенствования.
Чтобы собрание было действенным, потребуется создать атмосферу доверия и проявить необходимую эмоциональную зрелость. Главное, о чем нужно помнить, – вы никого не обличаете, а рассматриваете рабочий процесс. Почему что-то получилось так, а не иначе? Почему мы это упустили? Что помогло бы нам ускорить темпы? Очень важно, что люди ощущают себя командой, поэтому они сообща как команда берут на себя ответственность за все: и отличные результаты, и ошибки. И они сообща как команда ищут решения. Участники группы должны обладать определенной психологической выдержкой, чтобы их обсуждения были направлены на решение злободневной проблемы, а не на поиски виноватых. Абсолютно недопустимо, чтобы даже один член команды вынужден был занимать оборонительную позицию, – все в группе должны слышать и понимать друг друга.
Если вспомнить цикл Деминга «Планировать, действовать, проверять, корректировать», то очевидно, что ретроспективные собрания несут функцию проверки. Нам нужно подойти к этапу «действовать», то есть кайдзен, и выполнить функции, которые усовершенствуют рабочий процесс. Недостаточно лишь делиться мнениями, нужно приступать к непосредственной работе.
Самый лучший способ добиться непрерывного совершенствования, который мне удалось найти, я назвал индексом счастья. Это простой и весьма эффективный способ понять не только каким должен быть кайдзен, но и какой кайдзен сделает людей самыми счастливыми. Когда я использовал его, он дал впечатляющие результаты.
Вот как функционирует этот способ: в конце спринта каждый участник группы должен ответить на несколько вопросов.
1. Оцените свою роль в компании по шкале от одного до пяти.
2. Оцените компанию в целом по той же шкале.
3. Почему вы так считаете.
4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.
Всего четыре вопроса, решаемых буквально за несколько минут. Участники группы по очереди высказывают свои мнения, любое из которых может послужить причиной активных и глубоких обсуждений. Сообща взявшись за дело, команда довольно быстро предлагает свой кайдзен. Предложенный мной способ позволяет выявить одновременно несколько обстоятельств: что на текущий момент является самым важным и для каждого члена группы, и для всей группы, что они считают наиболее важным для своей компании.
Мы подходим к решающему этапу. Команда, идентифицировав главное препятствие на этот момент, определяет соответствующую фазу улучшения и делает ее основной задачей следующего спринта, каждая такая задача проходит обязательное приемочное тестирование. Как мы можем подтвердить, что улучшение было достигнуто? Для этого следует выработать формулировку успеха, однозначную и отвечающую реальной ситуации. Таким образом, на следующем ретроспективном собрании можно будет с легкостью увидеть, был ли достигнут кайдзен или нет.
Несколько лет назад я захотел расширить свою компанию Scrum. и сделать ее консультационным агентством, предоставляющим полный цикл обслуживания по методологии Scrum. Мы проанализировали динамику своей производительности и выяснили, что за недельный спринт у нас получается сорок очков осуществленных историй. Когда я ввел индекс счастья, первое, что мы обнаружили, – наши пользовательские истории выглядели недостаточно правильными. Они были слишком расплывчатыми, а значит не готовыми перейти в колонку «Сделано». Мы их еще раз проработали и получили вроде бы качественные истории. Но во время следующего спринта они все-таки оказались недостаточно хорошими. Этот недостаток отражался на нашем индексе счастья. В третьем спринте появилась другая проблема. Мы решили ее. И так далее. За считаные недели мы улучшили показатели динамики с 40 баллов за спринт до 120. Всего лишь поинтересовавшись, что делает людей более счастливыми, мы умудрились втрое улучшить свою производительность. В результате счастливее стали не только мы, но и наши клиенты, а прибыль компании просто взлетела до небес. Еще раз повторю: чтобы достичь таких результатов, нужно было только задать вопрос коллективу: «Что сделает вас счастливее?» – и всем вместе выполнить это.
Мы создали диаграммы с нашими показателями и кривыми их изменений за длительное время и обнаружили невероятно удивительные вещи. Как генеральный директор компании я уделяю большое внимание вопросам прибыли, роста и производительности. И я сделал поразительное открытие: в отличие от финансовых показателей, индекс счастья был более прогностическим. Финансовые показатели отражают результаты деятельности, происходившей в прошлом, но когда вы спрашиваете человека, насколько он счастлив, ответ обычно проецируется на будущее. Люди задумываются над тем, довольны ли они своей компанией, будет ли польза от эффекта их деятельности, как в принципе у компании идут дела. В результате, посмотрев на ситуацию их глазами, вы увидите симптомы проблемы, прежде чем она возникнет в реальной жизни. Если вы будете уделять достаточное внимание оценкам своих работников, у вас появится возможность начать действовать немедленно и исправить любой недочет до того, как он превратится в настоящую проблему. На следующей диаграмме видно, что падение уровня счастья происходит на несколько недель раньше падения динамики производительности. Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее.
Джефф Сазерленд.Scrum. Революционный метод управления проектами
dm_wrike
11.01.2017 00:59+9Отличная статья, очень наглядная, но я не согласен с названием поскольку Agile у вас не было даже близко.
Коротко: в компании произошла локальная оптимизация расходов на разработку,
никакого отношения к принципам Agile или Scrum они не имели, хотя слова использовались именно эти.
Субъективно: я бы назвал эту бизнес стратегию плохой,
добившись локальной (только разработка) и краткосрочной (ключевые сотрудники ушли) оптимизации разработки
компания вероятно сократила расходы здесь и сейчас — но потеряла гораздо больше в перспективе.
Ремарка: вы постоянно путаете концепции Agile и Scrum, далее я буду ориентироваться
на то что вы имели в виду только Scrum, поскольку по большей части вы пишете именно про процесс,
а Agile это набор принципов.
Из рассказанного вами очевидно что вы внедряли не Scrum а «НЕСкрам»,
вот несколько примеров.
1. «все разработки были переведены в TargetProcess» — никакой инструмент не имеет отношения к Scrum, и если внедренее Scrum началось с переходна на «новую клевую тулзу» — это была первая большая ошибка.
2. «получаем от менеджеров user-story (задачи что делать)» — здесь три ошибки:
1. в Scrum нет менеджера, есть Produc Owner, его роль никак не коррелирует со словом Manager.
2. «user-story» — это конкретная техника не являющаяся частью Scrum, ее можно использовать если она работает, но есть много других способом описать то что хочется получить которые могут работать лучше в конкретных обстоятельствах. Не факт что user-story то что нужно было действительно вам.
3. тут я не полностью уверен, но кажется что вы «получали» работу которую нужно сделать вместо того что бы «выбирать» какую работу делать (в определенных пределах). С точки зрения waterfall правильно первое, с точки зрения Scrum — второе, кажется у вас было первое.
3. «в конце спринта делаем ретроспективу» — по всей видимости Review вы не проводили, а это обязательно нужно делать.
4. «было велено списывать время на выполнение задачи в TargetProcess. » — это уже за гранью добра и зла, жесткий микроменеджемн и микрооптимизация. Мягко говоря, концепция тайм-трекинга полностью противоречит концепции и духу Scrum.
Я думаю из вашей статьи я смог бы продолжить список пунктов до 10,
но надеюсь и этих примеров достаточно что бы убедить вас что никакого Scrum у вас не было. У вас внедряли некий «Нескрам» и «Неаджайл».
Как конкретно называется методология которую вам пытались навязать,
я не уверен, «программист на час»?
«Методология Скрам, превращающая процесс разработки в конвейер» — нет, это так. Но конвейерную разработку сейчас действительно модно называть «Скрам», и не только в России. Не надо ставить себя выше других :)
«Говорить о том, что эти сотрудники виноваты сами» — обвинять разработчиков конечно глупо, но и общаться с ними «как с детьми» — малодушие.
Разработчики взрослые сознательные люди, со своими комплексами, тараканами, талантами, волей, амбицией и приоритетами, тем не менее, как и все.
Если люди построившие продукт и вложившие в него 5 лет жизни видя все это не встали и не сказали:
— засуньте в себе ж*** ваш таймтрекер
— мы сделали мажорное обновление ключевого фремворка всего за неделю, мы герои
— у нас баг в продакшн, я его исправлю — а вы — подождете
а вместо этого проголосовали ногами. Что ж, это их решение. И на них так же лежит часть отвественности за результат. Хаять Agile конечно легче, он же не может ответить.
Прошу прощения за резкий тон комментария, я старался быть конструктивным.
azsx
11.01.2017 02:53Поддержу общий тренд, внедрение новой методологии разработки не при чём. Вчера у Вас разработчики были главными. Например, время. Им дают реализовать новый набор фич, они говорят — сделаем за неделю. Решают задачу за 3 дня или 3 недели и ни одна собака им тявкнуть не может про время, так как они разработчики! Сегодня власть и ответственность отдали менеджерам. Менеджер не может сказать на пятиминутке «разработчики обещали сделать за неделю, но я к ним через неделю пришёл, а меня на фиг отправили, типа ждите». Как итог менеджер делит задачи, требует соблюдения сроков и так далее. Так и по остальным пунктам, дело не в algine, дело во власти и отвественности.
Что надо делать? Как и все. Продолжайте делить программный код (ооп Вам в помощь). Вместо одного ключевого разработчика нанимайте 20 обычных, снижайте нагрузку на ключевых сотрудников, требуйте, чтобы все кодеры были взаимозаменяемыми. Разработка станет значительно дороже, проект из игрушки превратится в ресурсоёмкого монстра, но зато власть останется в руках у менеджеров.
Вариант вернуть как было, вы явно не рассматриваете.
ps
Сам я негативно отношусь к власти менеджеров, но ситуация такая, какая она есть.
pnovikov
11.01.2017 09:21+2Статья хорошая, а вот вывод автор делает неверный.
На мой взгляд — причина неудачного внедрения в том, что новые цепочки процесса управления во-первых убили напрочь обратную связь между командой разработки и менеджментом (или даже клиентом), во-вторых, само желание «высокого начальства» внедрить Scrum — сиречь, проконтролировать то, что контролировать не нужно (время на разработку) — было ущербным.
Если честно, я вообще не понимаю трекинг времени внутри команды в штате компании. К'мон, ребята, как будто вы заплатите сотруднику меньше денег, узнав что он решил задачу за X времени, когда по вашему скромному мнению она должна занимать Y времени. Вы или выкупаете команду оптом, без вопросов выплачивая фиксированную сумму в месяц и берете на себя все риски неправильной постановки задач, рабочей среды, коммуникаций и оборудования, или, если вам хочется контролировать время — отправляете сотрудников на UpWork с почасовой оплатой (правда, она будет выше в силу накладных расходов разработчиков).
А организовывать грибной менеджмент на сотрудниках на зарплате с допросами почему эта кнопочка заняла столько времени попахивает излишней укомплектованностью управленческого звена кадрами (читай: менеджеров пора выпинывать с работы, или придумывать чем занять).
Хотя с другой стороны — если менеджеру хочется поговорить вместо работы, то рыночно-ориентированный программист никогда не откажет ему в такой возможности. Любой каприз, как говорится, за ваши деньги. Менеджер имеет полное право получить услуги психотерапии усилиями программиста и по его рейту.lair
11.01.2017 10:01+2Трекинг времени полезен, чтобы понимать, на что уходят ресурсы — т.е., он может показать, что на багфикс уходит в два раза больше времени, чем на разработку. Еще он полезен, чтобы корректировать планирующие оценки — т.е. сравнение плановых оценок с реально потраченным временем может иметь стабильную зависимость, которая позволит давать "наружу" более точные оценки.
Важно понимать, однако, что чтобы это работало, трекинг времени не должен использоваться для "а почему это заняло столько времени" со смыслом "что-то ты медленно работаешь".
pnovikov
12.01.2017 12:46Поминутный трекер, поверьте, слабо поможет в этом. Достаточно просто отмечать сколько задачи висят в определенных статусах. И на определенных людях.
lair
12.01.2017 12:47А я и не говорил о поминутном трекинге. Вопрос только в том, как именно организовать измерение "сколько задача висит в определенном статусе".
pnovikov
12.01.2017 12:53Ну вот есть грамотный способ — через статусы в JIRA например. И неграмотный — устанавливая людям на компьютеры тайм-трекер или (о боги, в 2017м-то году!) заставляя репортить время вручную.
lair
12.01.2017 13:21Ну вот есть грамотный способ — через статусы в JIRA например.
Я перевел задачу в Active. Потом ко мне прилетела более важная задача, и я на нее переключился. Потом я вернулся к этой задаче, доделал ее, и перевел в Resolved. Как посчитать реально затраченное на нее время?
Понятно, что правильный ответ — это "при переключении вернуть задачу из Active в предыдущий статус", но в результате то, что мы получим — это и будет таймтрекер, только кнопки у него в других местах расположены и иначе называются. И тут уже вопрос, какой "трекер" команде удобнее — тот, где надо задачи каждый раз между статусами пинать, или тот, где надо каждый вечер указать часы на задачу.
chieftain_yu
11.01.2017 16:25Клиент говорит: «покрасьте зебру в белый!».
Покрасили.
Клиент говорит: «не, белая зебра не смотрится, покрасьте зебру в черный!».
Покрасили.
Клиент говорит: «не, верните все как было!».
Отмыли зебру.
Пришла пора говорить с клиентом о деньгах.
И тут фиксация, куда сколько времени потрачено, может крайне помочь. Потому как клиент искренне не понимает, с чего бы эти перекраски стоят СТОЛЬКО.pnovikov
12.01.2017 12:52Именно об этом я и сказал когда упомянул UpWork. Подойдет так же Paymo, TimeManiac, или ваш любимый тайм-трекер. Просто прелесть UpWork-подхода в том, что он устанавливает прямую (прямее некуда) взаимосвязь между потраченным временем и деньгами. Это порой сильно меняет отношения.
chieftain_yu
12.01.2017 14:11+1В ряде случаев клиент не хочет в T&M.
Клиент хочет фикспрайс.
Клиент договаривается с продавцом на фикспрайс и выдает ТЗ.
На промежуточном показе клиент понимает, что ТЗ он написал неправильно, и вместо деритриниации ему нужна тирьямпампация.
В этот момент и начинается очень интересный этап — обоснование изменения стоимости договора, включаемой в допсоглашение об изменении параметров проекта. Клиенту надо пояснить, почему делать А стоит так дорого — и тут разблюдовка по задачам с указанием фактически понесенных трудозатрат может помочь очень сильно.pnovikov
18.01.2017 06:16Да клиент вообще в большинстве случаев платить не хочет в принципе. Клиенту выгодно быстро, бесплатно и качественно.
А для разблюдовки по часам — я выше где-то писал коммент про WPF-приложуху для разбиения проекта на задачи и оценки. Посмотрите — там как раз я говорю о том, что вы хотите.
ncix
11.01.2017 09:54Полагаю это взгляд со стороны разработки? Хотелось бы услышать взгляд со стороны менеджмента. Какие причины заставили играть с огнём и ломать устоявшуюся систему?
Я сам был в подобной истории, в разработке. Действительно костяк заслуженных-перезаслуженных людей создали кучку продуктов, приносивших компании основные деньги. Но год от года темп падал, задачи висели годами(!), сроки постоянно срывались и разработчики сами ничего не могли и не хотели с этим поделать.
Серия изменений в управлении конечно здорово выкосила ряды и привела в первое время к еще большим просадкам. Компанию постепенно наполняли новые люди, для которых жесткий контроль был изначально привычен. И в конце концов процесс выровнялся.
s-kozlov
11.01.2017 11:08+1Проблема не в аджайле (который вообще не методология), не в скраме, не в его реализации, не в часах и не в сторипойнтах, как пытаются убедить некоторые комментаторы. Читаем внимательно ключевой абзац:
Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки.
Поняли, в чем прикол? Не было никаких проблем, так зачем вводить какие-то скрамы, канбаны и прочую херь?
Скрам без причины — признак дурачины.bromium
11.01.2017 14:32Не было никаких проблем
Ну, мы-то выслушали лишь одну сторону. Уверен, по мнению другой стороны (со стороны владельцев, например) проблемы все-таки были.
s-kozlov
12.01.2017 08:35Что это за проблемы, которые нельзя заранее обсудить с ключевыми сотрудниками? Зуд творчества? Имитация бурной деятельности? Лучше бы переставили у себя дома мебель — меньше ущерба.
Machez
11.01.2017 11:47Актуальность внедрения любого новшества в процесс должно быть обсуждено. Факт. И кстати… Есть такое понятие как «риски»… Вообщем в России как и прежде две беды… Дураки и дороги.
hardtop
11.01.2017 13:37Отличный анти-кейс. Отставив в стороне «это НЕ-Скрам», получается, что среди разработчиков или менеджеров никто не встал и не сказал, что получается фигня. И, видимо, у менеджеров яйца оказались более железными, раз выжили из компании ключевых разработчиков. Грустно, конечно.
bromium
11.01.2017 14:29получается, что среди разработчиков или менеджеров никто не встал и не сказал, что получается фигня
ну да, яиц/ума нет у менеджеров/разрабов, а виноват, конечно же, Agilehardtop
11.01.2017 14:42Да нет же. Я не про Agile. Такая ситуация могла\может быть при любой методологии. Но иногда надо набраться смелости и признаться самому себе, что результат получается плохим. Признаться себе, и донести это до коллег. Это называется отрицательно-обратная связь.
ilja903
12.01.2017 00:25Если менеджер признает, что это все ерунда, то кто-то получит по ушам за потраченные деньги и/или лишиться повышения, своего авторитета в фирме. Разработчик сразу же становится персоной нон грата для всех управленцев.
hardtop
12.01.2017 09:57Если Поезд Проекта под управлением Менеджеров несётся в пропасть (по мнению Программеров), то сами Программеры могут дернуть стоп-кран. Такая функция всегда есть.
Понятно, что все сильные решения кого-то задевают. Но это лучше, чем видеть, что едешь под откос и тихо молчать.
bromium
11.01.2017 14:25+3Понятно, что все высказались уже в подобном ключе, но не удержусь:
Обозвали задачи юзер сторями, срок на их выполнение — спринтами, проджект-менджеров — продакт «овнерами» и потом решили, что все, это у них теперь scrum
Как обычно, scrum превратили в срам, не понимая сути agile/scrum.
Как в известном изречении «они сидели и день, и ночь, и день, и ночь и все думали, как сделать убыточное предприятие прибыльным, ничего в оном не меняя». Здесь да, поменяли. Обозвали одно и то же другими словами — и вперед.
И обвинять в этом Agile/Scrum — это уподобляться тем, кто Интернет считает рассадником порнухи и источником отупления человечества, а Телеграм — пособником террористов. Что, настала пора запрещать и Scrum?
forester11
11.01.2017 17:30+1В скрам и агиле вообще менеджеры (в скраме кстати нет такой роли), скрам мастер, продукт овнер не могут диктовать или влиять на то как девелоперы оценивают стори. Они могут помогать советом, если попросили, но и все — команда по сути автономна, это один из основных принципов агиле.
Это внутреннее дело команды как оценивать и что делать долго а что медленно. Максимум менеджеры могут попросить распилить стори на более маленькие, и если совсем все плохо реарганизовывать/тусовать команды (если совсем не получаетсо).
И уже тут получается что внедряли не Скрам, а под видом Скрама пытались закрутить гайки. Тайм трекинг как таковой не является частью агиле и Скрама в частности.
Вообше имхо любой инструмент/процесс можно ввести так что мало не покажется. Нужен человек который понимает принципы агиле и в состоянии анализировать текущее состояние процессов, находить конфликты и разрешать их. Если же скрам мастер "не приходя в сознание" начинает пихать формальную часть процесса, не блокируя микроменеджмент от менеджеров (который противоречит принципам процесса) то быть беде.
elenaelena
11.01.2017 22:21Для того, что бы оченить сложность чей то задачи, обычно мне надо по крайней мере в течении 15 мин посмотреть на код, а мне это надо? Продакт оуны или скрум мастера обычно в сотстоянии оценить сложность задачи с порядком ошибки «две трамвайные остановки». То есть все эти обсуждения — чистой воды потеря времени, политика и профанация.
В целом скрам — это микроменеджмет, который по определению является наиболее непродуктивной методикой.
Как сейчас хорошо жить в компании без скрума, наконец то можно работать.forester11
12.01.2017 16:28Так самое забавное что в Скраме ненадо напрягать мозг и ванговать размер каждой стори в часах или днях. Я часто использую 4ре градации — легко, средне, сложно и эпик. Если команда затрудняется ответить как сложно делать такую стори — значит у команды нет необходимых знаний и/или стори надо заресерчить и распилить, т.е. брать в спринт не на выполнение а на ремерч и бэклог груминг.
Но когда микроменеджмент умников снаруди не блокируется, то мало того что эстимейты стори пытаются пропихнуть с точностью в часах, так еще и начинают грузить команду мнениями что "много" или "мало".
А это стресс и отбитие органов принятия решений команды, что приводит к меньшей эффективности всей разработки. Имхо.s-kozlov
12.01.2017 17:16заресерчить… ремерч… бэклог груминг… эстимейты стори
Как говорил Доцент, «а теперь, Федя, скажи Васе то же самое, но нормально, на гражданском языке».
kabal375
11.01.2017 17:49+2Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Сдаётся мне, что либо «внедрятели» скрама в компании не интересовались в чём суть скрама, либо автор статьи, либо и те и другой.
Скрам, как он описан в одноимённой книге от его основателя, ставит именно людей (команду) на первое место.
Менеджер не может приоретизировать UserStory. Менеджер не может давить сокращением сроков, требовать отчёта о потерянном времени, и заниматься прочими псевдоуправленческими глупостями.
По сути, scrum/agile — продолжение старых добрых идей Листера и Демарко о кристаллизации команд.
То что у нас внедряется под видом agile — старое доброе линейное гуано в новой обёртке и с новыми терминами.
В немалой степени потому что мало кто имеет интерес к чтению матчасти, всех тянет сразу внедрять в продакшен.VolCh
11.01.2017 18:57Внедряющие может и читают что-то. Но вот абстрактно, приходит ко мне менеджер и говорит «Завтра внедряем скрам». Я «ОК. А что это? Ах, методология управления разработкой. Давай, изложи, что мне делать можно, что нельзя. Лучше в письменном виде на почту. А то приказом по фирме об изменении должностных обязанностей.»
kabal375
12.01.2017 10:01Ну и кто в данном случае будет ответственен за результат? Agile-методология?
VolCh
12.01.2017 10:24+1Ответственен за результат внедрения тот, кто руководит процессом. В данном случае — менеджер. Не смог толком донести суть и детали процесса, не смог мотивировать (причём пряником) поддерживать внедрение, а не изображать его из под палки — его ошибки.
Но вообще слабо представляю, чем менеджер может замотивировать разработчика помочь внедрить скрам. Единственная «плюшка», которая есть для меня в скраме — обещание, что в течение спринта меня никто из бизнеса не дергает. ради этого можно и потерпеть митинги и прочие ритуалы. Но по факту, не знаю ни одной фирмы из первого-второго круга, где вроде бы скрам есть, чтобы это обещание выполнялось.
ShadowHAWK
11.01.2017 18:04Ээээ написали страшилок — ну наверно попался вам не очень толковый Скрам Мастер и сам процесс Скрама у вас похоже перерос в «ритуальность» (ака «карго-культ»). У вас до Скрама всё ведь было идеально, правда? :-)))
Судя по симптомам у вас НЕТ «Product Owner» — раз всякие «мэнеджеры» до бесконечности приоретезируют User Stories — на самом деле должен быть лишь один «мэнеджер» тот самый Product Owner.
И вообще в толковом Скраме разработчикам живётся замечательно — потому как в реальном Скраме нет зоопарка PMов, Мэнеджеров и тд
le1ic
11.01.2017 18:04Одно наблюдение, с одной стороны считается, что микроменеджмент — плохо, с другой, что Scrum — хорошо. По моему опыту изначально первые скажем 10 спринтов все воодушевлены. Но постепенно, как только команда устаканивается, к новой методологии привыкают, люди сходят и вернуться из отпуска, возбуждение пропадает, и люди начинают хакать систему, просто мозг так устроен. Оценки постепенно повышаются, ну или становятся чем-то средним независимо от задач, какая разница если бюджет подбивается только в конце спринта и 1 + 3 + 5 = 3 + 3 + 3. Потом люди начинают максимально формально выполнять требования, в результате вместо того чтобы сразу максимально качественно реализовать какую-то фичу, история превращается в много-спринтовые итерации мелких доделок, либо так и уходит в продакшн в «индусском» качестве. Между командами отношения тоже охладеват, вместо того чтобы в случае срочности помогать друг другу, люди начинают говорить — кладите задачу нам в бэклог, недели через две может быть мы возьмем ее себе в спринт.
k_be
11.01.2017 18:04Правильно ли я понял, что в вашей компании не выделили человека из команды программистов, который бы фильтровал задачи от менеджеров, общался бы с ними на совещаниях, распределял задачи внутри команды программистов, устанавливал бы внутренние приоритеты и т.д.? (Человек должен был быть уважаемым специалистом из команды программистов, иногда называется TeamLead или как-то ещё, но суть от этого не сильно меняется, так как для отдельных подкоманд стоит так же выделять TeamLead-ов).
Просто сложилось впечатление, что у вас в компании была классическая проблема большого количества прямых начальников над одним сотрудником.
Программисты вообще не должны были что-то знать о том, что какому-то менеджеру не хватает их времени.
А момент о том, что «старые» программисты перестали чувствовать себя частью компании вообще никак не связан с методологией. Это была проблема найма людей с улицы (поясню, людей, которые не строили компанию) на руководящие должности. Возможно, у программистов были куда более большие планы на работу в компании и управление. Они просто ощутили некоторую обиду, что человек с улицы получает большую власть, чем они, над продуктом, который они знают лучше. Это проблема любой компании, которая не выращивает управленческий персонал внутри.
В общем, у меня сложилось впечатление, что не в Scrum дело.le1ic
11.01.2017 18:24Человек должен был быть уважаемым специалистом из команды программистов,
Странно, когда формальная методология разработки в конце концов опирается на авторитет и уважение ;)k_be
16.01.2017 12:42Все мы люди… Хотим этого или нет, но полностью устранить межличностные отношения пока никому не удалось, хотя очень много методологий к этому стремятся.
trukhachev
11.01.2017 18:04Я работал в похожей компании, где-то через год работы в компании, пришел новый эффективный менеджер, и жизнь в отделе круто изменилась, правда там такой подход scrum-ом не пытались называть. Каждую пятницу проходили по списку задач с руководителем. И если время не билось (40 часовая неделя) до минут, то говорил, что бездельники, а если чуть завышаешь (чтобы было проще жить), говорил что выдохлись и если не соберемся лишит премии. Меня хватило на месяц. Хотя, сейчас я работаю в компании, где тоже нет честного scrum, но, вроде, всех все устаревает.
inbuckswetrust
11.01.2017 18:04+1А почему вдруг все решили что менджерье и владельцы не понимают что делают?
Проект запущен, нужно срубить бабла здесь и сейчас, посему запускаем кадровую оптимизацию и добровольно выдавливаем дорогих разрабов и заменяем дешевыми кодерами. Профит.
Локальный профит для манагеров и/или руководства на лицо. Переживания пехоты никого не волнует.
Скрам, Ажайл бабло правит этим миром а не аббревиатурки IT-шников.
vlsinitsyn
11.01.2017 18:04+1Я один чувствую некий диссонанс между принципами agile, в которых я готов подписаться под каждым словом, и кучей «методологий», «правильное» и одновременно жизнеспособное внедрение которых по слухам где-то существует но никто не видел?
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
Paulster
11.01.2017 18:04Хочу свою ложку дегтя как менеджер внести. Вина менеджеров безусловно есть, но у меня остались вопросы:
1) На одну команду разработки несколько менеджеров? зачем? почему нет одного ответственного за все что происходит? Одного менеджера вполне хватает чтобы справиться с командой в 7-8 человек без потери фокуса. все остальные — стейкхолдеры и его задача «подружить» все хотелки.
2) За разработку (люди, процессы и тд) должен отвечать руководитель (например технический директор). Почему он не разнес такую систему в пух и прах? Если в компанию может прийти новый сейл и сказать разработчикам как они теперь должны работать, то это как-то неправильно. Повторюсь, за процессы разработки отвечает руководитель разработки. Если профессионалы начали увольняться, то это в первую очередь его ответственность. Должен был навести порядок в головах остального менеджмента.
3) Сложилось впечатление, что до провального внедрения agile, разработчики сами решали что они будут делать и когда. В результате, как по волшебству, продукт начал развиваться, компания расширяться и все были счастливы. У вас не было планирования, оценки, приоритезации? Не верю. Waterfall, agile, любая другая методология не может игнорировать планирование и оценку результата. Иначе у вас не коммерческая организация, а кружок по интересам. Лучшие решения должны быть результатом процесса разработки, а не случайного стечения обстоятельств. Для этого есть тимлиды, руководители разработки и т.д.
Не про Agile статья. «Разруха не в клозетах, а в головах».
yorlin
11.01.2017 18:04Интересно было бы посмотреть, что бы случилось с фирмой, не введя скрам, но так же наберая менеджеров всех мастей. Очень может быть, что ситуация была бы еще хуже, так как под давлением менеджеров творился бы полный хаос. Так вы хоть были «защищены» спринтами. Я ни в коем случае не защищаю скрам, так как сам не являюсь сильным его фанатом(планировать время — задача не из простых, таймтрекинг тоже создает ощущение, что за тобой следят), но мне кажется в вашем частном случае проблема далеко не в скраме.
Наверно поэтому, по крайней време в Европе, стало модным так называемая «плоская иерархия» в компаниях + скрам — когда что попадет в спринт, и как будет продукт дальше развиваться, решают разработчики, но при этом свою работу четко структурируют.ilja903
12.01.2017 00:59В Норвегии в гос заказах прописано, что фирма должна использовать гибкую методологию. Разработчики редко что решают. Все как везде, с поправкой на менталитет.
ftorodent
11.01.2017 18:04+4За последние три года как после внедрения Agile сгнили так же два успешных стартапа
Новый менеджемент прикрываясь модной в этом сезоне методологией находит способ сожрать все ресурсы компании.
Всё по классике.malbaron
16.01.2017 14:27Как же приятно чувствовать себя значимым разработикам, который неудачлив только потому, что ему не дают развернуться тупые менеджеры, всё губящие.
Вот бы всех менеджеров и к стенке?
После чего, поди, Вы сразу станете таким же крутым как Линус? Ну признайтесь? Понадобится всего год-два — и вы в дамках?
Как правило, все иначе:
Человеку нужно придумывать виноватых. А устрани все названные ему «мешающие» факторы — такой человек таки все равно ничего и не добьется.
Ну разве что усовершенствуется в придумывании причин почему у него не получается работать, что ему опять кто-то мешает.
Ведь в том, что ты не особо успешен как разработчик и во всех твоих неудачах кто угодно виноват, только не ты сам.VolCh
16.01.2017 16:59А если вполне успешным себя считаешь, но понимаешь, что если бы менеджеры помогали, то эффективность была бы ещё выше?
malbaron
16.01.2017 17:10А если вполне успешным себя считаешь, но понимаешь, что если бы менеджеры помогали, то эффективность была бы ещё выше?
Эффективность чего?
Тут не эффективность, а невозможность без менеджеров.
Если маленькая группка разработчиков, то она не нуждается в «надсмотрщике». Но нужен менеджер-сейлер (продавец) — он занимается вещами, которыми я не хочу заниматься.
Если это большая группа — то менеджер нужен для организации всех людей в единое целое.
И т.д.
Каждый занимается своим делом (плохо или хорошо, лишние там менеджеры имеются в компании или лишние разработчики, которые балду пинают — другой вопрос).
Если я буду это делать за менеджера — то я и превращусь в менеджера.
Законы человеческого социума неумолимы.
spamas
11.01.2017 18:04-1Не совсем ясна цель этой статьи. Пожурить плохих менеджеров? Так компаний много, работы тоже. Выбирай где тебе по вкусу. Изменить систему все равно не получится, только сменить её.
Можно еще погуглить карго культ и улыбнуться :)VolCh
11.01.2017 19:01+1Как минимум предупреждение для разработчиков: «Если у вас начали внедрять скрам — обновите резюме на линкединах и прочих»,
unclechu
11.01.2017 22:13+2Из-за этой методологии, и вообще из-за всякого тайм-контроллинга и прочего давления, я, не выдержав постоянно нарастающего стресса, ощущения что из тебя пытаются сделать автомат, которому на вход подали задачу, на выход ожидают получить точный и безошибочный временной прогноз, а затем решение, периодически подзаряжая аккумуляторы (деньги), бросил профессию наёмного программиста. С пол года живу на остатки накоплений и до сих пор, как вспоминаю это, никакого желания возвращаться в профессию нет, для себя сидеть кодить что хочу и на чём хочу — сколько угодно, но наёмничать желания никакого не возникает, за любые деньги. Этот скрам/аджайл пришёл повсюду со своими спринтами, тайм-трекингом и каждодневными отчётами, и везде где я его видел, — он всё портил, я в конечном итоге, без того измученный этой парашей, понимал что совершенно недоволен результатом, это полное дно, куча недоделок, незаконченная работа, кругом ошибки и грязь, зато в спринт уложились и отчитались какой-то очередной цепочке по иерархии «выше». Для меня слова аджайл/скрам/канбан/тайм-трекинг прочно ассоциируются с угнетением и паршиво сделанной работой.
elenaelena
11.01.2017 22:34+3Зря вы бросили работу, есть огромное количесво компаний, где скрам просто формальность.
Плюс надо адекватно оценивать задачу, или баг: 1 час для репродукции бага, один час тестирование после того как баг пофиксили, один час обнавлять несколько раз время в jira и писать дескрипшин, сам бак фиксить 15 мин — округляем до часа, то есть получается 4 часа по крайне мере.
Раньше, если по ходу выполнения задачу видил баг, который пофиксит 15 мин, то просто это делал без всяких менеджеров, в компаниях со скрумом это категарическ запрещено. То есть эффективность в данном случае падает в 16 раз, в среднем эффективность работы со скрумом падает в 5 раз.sand14
12.01.2017 09:13Как раз проблема в том, что такой 15-минутный баг вам не дадут оценить в 4 часа. Или по их истечении начнется, как кто-то тут выразился, «охота на медленно программирующих ведьм.»
И вообще, «такой баг делать не 15, а 5 минут».
Те же пропорции для более крупных задач.kabal375
12.01.2017 09:59Тогда это уже не Scrum.
Насколько я помню, в книге «Scrum» специально много раз обращается внимание, что не может быть никакой охоты на ведьм.
«Чем ты занимался?», «Чем ты планируешь заниматься» и «Что тебе мешает в твоей деятельности»?
Никаких «Почему так медленно?»
Задача менеджера — устранять помехи, а не третировать команду.sand14
13.01.2017 12:31Здесь уже отметили, что есть скрам в теории, а есть на практике.
У меня вообще ощущение, что если внедрять скрам и/или аджайл по теоретическим канонам, то получится некая в целом нормальная разработка, которая будет сходиться в одной точке с тем же waterfall, только осовремененным и «с человеческим лицом».
marshinov
11.01.2017 22:52Наймитесь поработать в кол-центр банка. Не на долго: на недельку. Думаю, что вы измените свое отношение к стрессу и снова полюбите профессию:)
Lofer
12.01.2017 01:43Я Вас понимаю. Сам почти год «забил» на все и отдыхал мозгом.
выдержав постоянно нарастающего стресса, ощущения что из тебя пытаются сделать автомат, которому на вход подали задачу, на выход ожидают получить точный и безошибочный временной прогноз
Посмотрите на это следующим образом: На двигателе Ролс Ройса в графе мощность двигателя написан «Достаточная» :)
Ваша «мощность» — Достаточная :) А если от Вас ожидают «минута в минуту» точность оценки, то просто выдайте «достаточную», Если хотят — больше, то возьмите попкорн, откиньтесь на спинку и пусть Вам предоставят технологию, как оценить «минута в минуту» :)
Идиоты не истребимы :)
dim2r
12.01.2017 11:01Для меня слова аджайл/скрам/канбан/тайм-трекинг прочно ассоциируются с угнетением и паршиво сделанной работой.
Эти методологии не учитывают психологический профиль. Среди программистов есть много индивидуалов — интеллектуалов, которые не хотят что бы их беспокоили.
Так же не учитывается, что мозг у мужчин лучше работает когда погружается в одно дело. Когда дел много и надо переключаться, то на это тратится куча сил, иногда больше чем на просто работу.
ilja903
12.01.2017 01:02В канбане нет таим трекинга насколько я знаю
Paulster
12.01.2017 12:04разработчика нет, задачи есть. погуглите метрики канбана.
Fesor
12.01.2017 12:16-1погуглите метрики канбана.
В канбане по дефолту нет вообще никаких метрик кроме "сколько тасок одновременно находятся в in progress". За счет ограничения на количество этих тасок проблемы будут находиться вне зависимости от того следите вы за временем или нет. Главное за ограничениями следить, их бывает часто игнорят и пытаются обойти.
calvin_rus
12.01.2017 10:35+3Работаю в телекоме, долгое время работал в одном средней руки интеграторе, а сейчас стремлюсь в разработку.
Проблема типична. Может просто стартап вырос? Может ли большая компания жить на энтузиазме? Нет, ну только честно. Я, увы, не верю.
Приведу пример из телекома.
Сережа работает в крупной федеральной конторе, а Миша — в маленьких Мухосранских сетях.
Мишина компания все тот-же стартап середины нулевых выросший от пары тупарей до сети на половину города, но душа у сети все таже. Ее хотят купить за копье, Мишиного начальника хотят посадить или штрафануть. А ведь есть за что.
Сережина компания — что-то среднее или крупное.
Миша получает может и не особо меньше Сережи, но не так стабильно. Миша, скорее всего и админ и немного сварщик, и щепотку аварийщик. Ибо постоянно кто-то в офисе заболевает. Сережа половину дня жмет на 2 кнопки, обрабатывая инциденты, и делает то, что вроде никак на работу сети не влияет. Миша понимает же, что каждый клиент — часть его зарплаты, и он в 12 ночи поедет писать конфиг коммутатору, который почему-то решил сгореть, а конфиг был только в голове Миши и его начальника. У Сережи есть четкие нормативы. Что случается после его смены — ему мало интересно, главное — что бы в том не было косяка. Потоп, ли пожар, есть нормативы, и тут главное Сереже вовремя нажать на ту из двух кнопок, которую нажать нужно, что бы не лишиться премии. Конфиги сохраняет специально обученный для этого скрипт.
Технари в крупном провайдере на уровне обслуги. Менежджеры, вообще не понимают, зачем нужны технари. Проводочик ведь воткнул, и лампочки сами заморгали. ARPу технари не повышают. Можно ведь сократить половину и чуть-чуть увеличть нормативы по авариям. Кто заметит разницу по процентам простоя? Наймем девочек на телефон, и напечатаем много красивой рекламы. Пипл схавает. Все сводится в статистический маразм надоя с одного сферического абонента в вакууме и отфутболивание разного рода вопросов между отделами.
Ну ведь караван идет, менеджеры сдают дебильные отчеты в красивых папках главным главнюкам. Те в ответ дают более дебильные задания. Подсчитать количество абонентов пьющих ряженку по утрам. Нет, стойте, лучше проведите сравнение между цветом глаз собак абонентов и наработкой в ночные часы. И главное что бы рекламы было больше. Голустяна там еще не забрали? Вот, давайте с ним!
Плохо это или хорошо? Наверное, скажете вы, лучше быть Мишей. Там интересно. Только вот беда, все меняется, когда у Миши и Сережи появляются дети, жена, которой надо в Тайланд и ипотека. Вот тогда уж проще нажимать 2 кнопки и молчать о своей доли, строя в голове замки из песка, где ты, да ты, подкопишь сотню-другую тысяч мильенов рублей и что-нить свое замутишь. Ну там провайдера VoIP или ОТТ TV. Лет через 15-20, ибо за квартиру половину зарплаты еще отдавать и отдавать.
О чем это я. Простите, не верю в крупные и эффективные фирмы, где балом правят технари, или хотя бы толковые менеджеры. Не, может, они и есть, но я их не видел. Единорогов, к слову, не видел тоже.
dim2r
12.01.2017 11:43Есть математическая теорема об управляющей и управляемой системах, в которой говорится:
Управляемая система должная в каком смысле быть умнее управляемой или по крайней мере на уровне. То есть менеждер должен быть в каком-то смысле умнее программиста. Но это невозможно, если не понизить интеллект программиста. Вот и получается, что умным остается либо тупеть, либо бежать, либо брать власть в свои руки.lair
12.01.2017 12:02То есть менеждер должен быть в каком-то смысле умнее программиста. Но это невозможно, если не понизить интеллект программиста.
Это, простите, почему? Особенно учитывая вашу же оговорку про "в каком-то смысле".
dim2r
12.01.2017 12:41Использую «в каком-то смысле», так как это аналогия. Точное определение можно дать для формальных систем. А человек и социум — система неформализируемая до конца, поэтому можно только обозначить тенденцию
lair
12.01.2017 12:43-1Ну и откуда вы берете тенденцию, что менеджер не может быть "в каком-то смысле умнее" программиста?
Понятно же, что мы не говорим об общем интеллекте, мы говорим о приспособленности к конкретным задачам — иными словами, о специализации. Менеджер умеет управлять, программист умеет программировать. Что в этом такого?
dim2r
12.01.2017 13:03Менеджер умеет управлять, программист умеет программировать. Что в этом такого?
тогда все в порядке.lair
12.01.2017 13:21… а вы говорили, что это невозможно.
dim2r
12.01.2017 13:26иногда возможно, иногда невозможно.
lair
12.01.2017 13:27… почему это невозможно в общем случае?
dim2r
12.01.2017 13:45Иногда количество степеней свободы у управляющей системы меньше, чем у управляемой. Например, управляющий имеет одну степень свободы — выключатель {0,1}. А у управляемой 2 степени свободы — например 2 светодиода {{0,1},{0,1}}. Один выключатель может управлять только одним светодиодом или обоими сразу. Некоторые комбинации светодиодов будут недоступны.
Vlad_fox
12.01.2017 13:59про
Что это за проблемы, которые нельзя заранее обсудить с ключевыми сотрудниками?
часто у владельца бизнеса возникает желание избавиться от тех (разрабов), кто принимал участие в становлении стартапа.
не хочет делиться и о будущем бизнеса не шибко думает — деньги приносит и хорошо, а помрет — так помрет…
для этого нанимает манагеров со стороны, и создает невыносимые условия для недавних сокомпаньенов.
после их ухода наберет на те ж зарплаты (или даже больше) таких же толковых и гениальных, но других, которым кроме зарплаты уже ничего не обязан.
Всем спасибо, все свободны! называется этот принцип а не скрам или аджайл
ApeCoder
13.01.2017 10:28Давайте попробуем сопоставить то, что написано в статье и Scrum guide
"Scrum is:
- Lightweight
- Simple to understand
- Difficult to master"
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками.
Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика,
ведь это просто обновление с одной версии на другую?Была ли эта проблема обсуждена на ретроспективах и что на это сказали?
Я думаю, если бы вы объяснили PO, зачем именно нужен преход между фреймворками и какой business value это принесет, то разумный PO смог бы приоретизировать эту задачу.
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление
со стороны менеджмента и отчет за каждый час рабочего времени.Scrum guide:
"The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development
Team can assess what it can accomplish over the upcoming Sprint."
"The Development Team is responsible for all estimates.
The Product Owner may influence the Development Team by helping
it understand and select trade-offs, but the
people who will perform the work make the final estimate."
Стали выполняться только задачи (User Story), приходящие
от менеджеров,По Scrum guide команда может управлять беклогом при одобрении
product owner.
Задачам стали присваивать приоритеты.
А раньше никаких приоритетов не было и все делалось одновременно?
Или фактически приоритеты были, но их никто не записывал?
Менеджеры начали конфликтовать между собой,
пытаясь присвоить своей userStory высший приоритет,
т.к. у них обязательства перед заказчиками и никого не волнует
занятость разработчиков."The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner."
Методология Скрам, превращающая процесс разработки в конвейер...
Резюме: методология Scrum описана в Scrum guide. То, что описано
в статье частично ей противоречит, частично ее дополняет.
Описанные проблемы, я думаю, именно из-за этих противоречий и дополнений
Автор, как мне кажется, на веру принял то, что ему говорил скрам-мастер и не сопоставил это с тем, что пишут авторы скрама.
VolCh
13.01.2017 13:11Ну, нам, как разработчикам, читать что пишут авторы скрама не нужно. Для того и берут скрам-мастера, чтобы он нас всему научил.
ApeCoder
13.01.2017 15:02Кто-то тогда должен выбирать скрам-мастера и он должен понимать как его выбирают. Еще такие разработчики, по моему, должны говорить типа "Скрам в интерпретации Васи Пупкина"
VolCh
13.01.2017 19:52Мы не должны. К нам пришли и сказали: «делаем скрам». Аналогия: пришёл врач и сказал, что делает прививку. Может он на нас эксперименты ставит, например эффект плацебо изучает, может перепутал и глюкозу колет, но для нас это прививка.
ApeCoder
13.01.2017 23:13С моей точки зрения логично посмотреть отзывы на врача, вызнать что за прививка и какое качество у производителя, второе мнение и т.д.
То есть ответственные люди врача выбирают
s-kozlov
14.01.2017 06:00ответственные люди врача выбирают
Вы что, как можно? У нас люди не знают, что имеют право прикрепиться к любой поликлинике страны без прописки.
VolCh
14.01.2017 10:27+1В подобных ситуациях выбирать не приходится: или увольняйся, или делай то, что врач/менеджер называет прививкой/скрамом.
ApeCoder
14.01.2017 14:01+1Я не знаю, что такое "подобные случаи" но как мне кажется, если это не говноконтора со взаимоотношениями "я — начальник, ты — дурак", то можно, по крайней мере попробовать убедить начальника поменять. Кстати, в скраме встроены ретроспективы для того, чтобы улучшать процесс. Или у вас был скрам без ретроспектив?
VolCh
14.01.2017 16:08Убедить начальника поменять процесс или убедить начальника начальника поменять начальника? )
Были. Я предлагал отказаться от планирования спринтов и вообще спринтов, просто расставить задачи в бэклоге по приоритетам и релизиться по мере их готовности, собственно исключив такое понятие как релиз, просто деплой в продакшен готовой фичи/багфикса. «Это канбан какой-то получится».ApeCoder
14.01.2017 17:59+1Были какие-то аргументы против канбана?
VolCh
14.01.2017 23:51У нас скрам, а не канбан.
ApeCoder
15.01.2017 08:50Это так начальник сказал? Тогда надо спросить чем скрам для конкретных условий лучше канбана.
Вот, кстати, зачем надо разработчику разбираться в предмете — чтобы аргументировать свою точку зрения.
Вот, кстати, видео об изменениях в скраме — что убрали, что добавили и почему?
VolCh
15.01.2017 12:08Да, сказал. Скрам лучше канбана, по его словам, потому что в канбане отсутствует планирование. А заказчикам без планов проект не продать. Без модных слов тоже.
Я свою точку зрения аргументировал, я предлагал конкретные изменения во внедренных процессах, которые бы повысили эффективность. Мне как бы всё равно попадает результат моих изменений под какое-то популярное название или нет. Это как с паттернами — читаешь книжку и понимаешь, что давно их используешь, просто не знаешь, что те решения, которые постоянно применяешь от задачи к задачи и от проекта к проекту носят какие-то названия типа Стратегия или Репозиторий.
Прошу прощения, но смотреть 2 часа видео нет возможности. Вообще видео только развлекательное смотрю, в основном художественные фильмы. Для получения полезной информации предпочитаю текст с редкими схемами.ApeCoder
15.01.2017 15:43В кабан используется статистика для планирования
вот тут разжёвано http://www.dennisstevens.com/2010/06/07/kanban-and-when-will-this-be-done/
Fesor
14.01.2017 19:01+1Канбан замечательно работает в условиях постоянно меняющихся приоритетов. Когда невозможно собрать внятный скоуп задач даже на недельный спринт. А что бы работало лучше — можно поверх канбана натянуть практик из других методологий.
Из моего опыта "попыток" внедрения канбана могу поделиться только таким наблюдением. Если в команде наблюдаются проблемы с коммуникацией тут они будут усугублять дело на порядок больше чем со скрамом. То есть к примеру, есть у нас физический борд с задачами. Первая проблема — разработчики не пользуются возможностью видеть задачи в in progress. Так же как правило не находится человека имеющего роль внятного продукт оунера который бы постоянно подстраивал приоритеты команды. В итоге все это превращается в хаос очень быстро. А ограничения… их не соблюдают и проблемы оказываются смазанными.
VolCh
14.01.2017 23:58Наша ситуация. А человек есть такой. Уже пятая наводка, что нам нужен канбан (одна из них — доска в ютрэке больше понравилась канбановская, почти всё что нужно и почти ничего лишнего :) ). Надо будет почитать про него на досуге что-то большее чем статья на вики.
ViachaslauChurukanau
14.01.2017 00:31+2Согласен с автором статьи
Полтора года усердно пилили командой стартап по скраму.
Вышли в продакшен. Энтузиазм убит. Я уволился.Fesor
14.01.2017 14:27Расскажите что у вас называлось скрамом?
ViachaslauChurukanau
15.01.2017 14:18+2Двухнедельный спринт:
1й день — планирование, в стори поинтах, решал закачик (product owner) какие тикеты делать в очередном спринте
5й день — груминг митинг (обсуждение фич на следующий спринт)
9й день — стабилизация и баг фиксинг
10й день — демо (показывают разработчики), потом ретроспектива
Каждый день стэндап 10 — 15 минут
За полтора года было около 30 спринтов. Из которых в 29 в той или иной степени была новая функциональность, и 1 спринт был по тех долгу.
От нас очень хотели работы только над запланированными в спринт тикетами. Любая инициатива — на выходных. Нет интересного для тебя тикета в текущем спринте — бери неинтересный.
Как-то такs-kozlov
15.01.2017 15:25+3Любая инициатива — на выходных.
Хороший способ полностью избавиться от инициативы.Lofer
15.01.2017 20:51-2Это бизнес! в первую очередь.
Давайте представим, что вместо ПО, это будет хирургия :)
— Я не могу стежки делать шнурками из кожи рыбы, сам вчера нарезал и вымачивал.
— Как-то стерилизацию делать иодом уже не интересно, хочу… серной кислотой попробовать.
— Антибиотки давать по протоколу лечения? Не… давай клистир сделаем из порошка жаб, слышал новое модное на конференции рассказывали по инету.
В конце концов, убили всю инициативу в операционной и я уволился…
Давайте представим, что вам так бухгалтер будет считать и выдавать зарплату «по Scrum что бы было интересно»…s-kozlov
16.01.2017 05:14+2Похоже, вы не понимаете разницы между инициативой и некомпетентной самодеятельностью. Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов. Это когда интересна судьба проекта. А когда начальство неадекватно и хочет неоплачиваемого героизма — по звонку идешь домой и хоть трава не расти.
ApeCoder
16.01.2017 09:34Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
В скрам встроенны ретроспективы как способ выразить идеи и проблемы. Если для бизнеса в данный момент важно ускорять систему в два раза, то PO может одобрить такой айтем в беклоге.
Lofer
16.01.2017 14:32Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
Вы за чей счет провели измерения и рассчитали экономическую целесообразность?
За чей счет будет развертывание у Клиента на серверах и сопровождение новой версии?
Оно вообще надо Клиенту?
Если вы из своего кармана оплатили виртуалки, провели тестирование и измерения — тогда ладно. Приходите и покажите цифры Заказчику или в следующей итерации воткните свой Самый Лучший Код за 5 минут, а до конца спринта занимайтесь чем хотите.
Если вы за счет Клиента прокачаться — тоже, вариант. Но кто платит тот и музыку заказывает.
Но я не думаю, что в процессе разработки у вас за плечом стоит Злой Менеджер, и говорит «Делай хреново! Делай только ректально!!! А если вы сделали Хорошо, я вам потом сломаю пальцы.»
Хотите сделать в два раза лучше и прокачаться за чужой счет? Возьмите Open Source и ваяйте себе на здоровье :)
Никто в здравом уме не будет давить вашу инициативу если будет понятно что «это хорошо», но никто не будет одобрять непонятные бизнес-риски которые Вы, возможно, спровоцируете своими «инициативами»s-kozlov
16.01.2017 14:56Похоже, вы не понимаете разницы между инициативой и некомпетентной самодеятельностью.
Всё еще истинно. В частности, вы не понимаете разницы между «придумал» и «молча внедрил, никого не уведомляя».
Ок, для непонимающих: полное отсутствие инициативы — это когда я делаю только то, что от меня явно просят. Вижу потенциальную проблему — молчу, пока она не выстрелит. Тот, кто «платит и музыку заказывает», должен это понимать, как и то, за чей счет будут оплачиваться последствия.Lofer
16.01.2017 15:27Вас нанимали: делать хорошо
Вас нанимали: не делать, чего не просят
Вас нанимали: понимать разницу между первым и вторым.
Вас нанимали: выслушать ваше професиональное мнение.
Вас НЕ нанимали: ВСЕГДА соглашаться с вашим мнением, после того как вы его высказали.
Вас НЕ нанимали: перед вами что-то объяснять, сверх рамок контракта.
Если вы с этим согласны и подписались в контракте, о чем тогда речь?
Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим. Зато через время или ваше мнение будет подкреплено и его начнут ожидать, или поймете что всем вокруг в принипе пофиг на вас и друг на друга.
А если вы ходите «с фигой в кармане» вы сам себе злой буратино, поскольку вы не узнаете «куда дует ветер»
Свои бизнес риски тот, кто «платит и музыку заказывает» осознает не хуже вас (в основном), потому что на нем кредит в банке для вашей зарплаты, оплатить офис где вы сидите, инвестиции в будущие проекты и т.д.s-kozlov
16.01.2017 17:02Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим.
Высказать свое мнение, когда другим на него плевать, — это, очевидно, проявление инициативы. Отсутствие инициативы — это когда ты молчишь в тряпочку, когда тебе не задают вопросов.
Вижу потенциальную проблему — молчу, пока она не выстрелит.
Если боссы согласны на такое, то они сами себе злобные буратины.Lofer
16.01.2017 21:29Высказать свое мнение, когда другим на него плевать, — это, очевидно, проявление инициативы. Отсутствие инициативы — это когда ты молчишь в тряпочку, когда тебе не задают вопросов.
Я больше рассматриваю как «гарантированое предоставление и доступность сервиса» :)s-kozlov
17.01.2017 06:45Я больше рассматриваю как «гарантированое предоставление и доступность сервиса»
Не нужно семи пядей во лбу, чтобы понимать, что никаких гарантий не будет, если выполнять только таски, которые спустили сверху.Lofer
17.01.2017 14:18А это еще почему?
Я как нанятый спец, в чьи обязанности входит говорить «если… то....» выполняю свою часть контракта.
Свою часть «сделки» я выполнил — предоставил мнение/оценку, и ни одна зараза не сможет сказать «нафига мы его нанимали, если он молчит все время? Табуртка тоже молчит».
Если меня «не слушают», чего мне обижаться? Возможно исходят еще из некоторых долнительных факторов, к которым у меня нет доступа.
Другое дело, если хожу и молчу. Вполне возможно молчание будет трактоваться как «молчит, значит согласен или не видит косяков». Но я свою часть сделки «не выполнил» — не предоставил свою оценку.
Нюанс в том, что донеся свою информацию до собеседника, вы вынуждаете его что-то делать. Ничего не делать — это такое-же тоже решение и тоже «действие».
Понятно, что отсутсвие обратной связи «почему не ценят или не слушают» интересно и может напрягать иногда.s-kozlov
17.01.2017 16:10Речь не о том, чтобы не отвечать на вопросы или врать, а о том, что не все нужные вопросы могут быть заданы.
Lofer
17.01.2017 23:18Для этого есть «управление рисками», для умных и кто может сам себе сделать процессы, понимая что и зачем.
Для тех кому «чего думать, трясти надо» в Scrum сделали «planing poker» и «ретроспективы» с вопросам: где получились косяки и почему? Как сделать так, что бы их было поменьше на следующих итерациях?
Все в этой части все просто: обезьянка видит — обезьянка делает.
В бизнесе применяется принцип «разумной достаточности», а не учитывается движение всех атомов во вселенной.
В итоге: если нету вопросов, значит косяки не возникли и потери были в допустимых границах, следовательно «разумная достаточность» соблюдена.s-kozlov
18.01.2017 07:48где получились косяки и почему?
Ну это бесполезный разговор уже. Если боссы работают по принципу «пока гром не грянет», они сами себе злобные буратины.
Есть косяки, которые лучше предотвращать, а не исправлять.ApeCoder
18.01.2017 08:12Ну это бесполезный разговор уже.
Почему бесполезно анализировать причины косяков?
Есть косяки, которые лучше предотвращать, а не исправлять.
Именно чтобы предотвартить будущие косяки, надо анализировать причины прошлых
s-kozlov
18.01.2017 12:34-1Ну это бесполезный разговор уже.
Почему бесполезно анализировать причины косяков?
Бесполезно не анализировать причины косяков, а объяснять Lofer очевидные вроде бы вещи.Lofer
18.01.2017 13:14+1Речь не о том, чтобы не отвечать на вопросы или врать, а о том, что не все нужные вопросы могут быть заданы.
Увы, это так.
Для этого есть стадия идентификация рисков: методы прецедентов, экспертной оценки и еще более 50 методов, которые можно комбинировать между собой.
Есть косяки, которые лучше предотвращать, а не исправлять.
И есть стратегии обработки рисков:
- принять риск. Согласиться, что ущерб от сработавщего риска допустим и где-то застраховать сумму для компенсации. Или вложиться в предовтращение риска
- отклонить риск: считать, что ущерб от сработавщего риска недопустим. и не делать так, что бы риск возник.
Вы видите только свою часть, и Вы уверены, что можете верно провести хотя бы Business Impact Analysis для своего Работодателя, не говоря уже про Клиента?
Вас уже, наняли что бы снизить уже известные риски
Даже не смотря на все вышеупомянутое, «черного лебедя» никто не отменял :)s-kozlov
19.01.2017 08:26-1Ну до чего же трудно доходит. Ну нельзя оценить риск и выбрать стратегию, если не знать о ситуации, которая грозит.
Вас уже, наняли что бы снизить уже известные риски
В моем случае это не так, т.к. мой работодатель не долбоеб.Lofer
19.01.2017 13:49Ну до чего же трудно доходит. Ну нельзя оценить риск и выбрать стратегию, если не знать о ситуации, которая грозит.
Давайте последуем стратегии «обезьянка видит — обезьнка делает» и изучим доступные материалы по этой теме (хотя бы кратко) :)
Оценка риска позволяет ответить на следующие основные вопросы:
— какие события могут произойти и их причина (идентификация опасных событий);
— каковы последствия этих событий;
— какова вероятность их возникновения;
— какие факторы могут сократить неблагоприятные последствия или уменьшить вероятность возникновения опасных ситуаций. Кроме того, оценка риска помогает ответить на вопрос: является уровень риска приемлемым, или требуется его дальнейшая обработка?
Ответственные за оценку риска должны знать:
— область деятельности и цели организации;
— уровень приемлемого риска и способы обработки неприемлемого риска;
— способы интеграции процессов оценки риска в процессы менеджмента организации;
— методы оценки риска и способы их применения в процессе менеджмента риска;
— систему подотчетности, распределения ответственности и полномочий в области оценки риска;
— требуемые и доступные ресурсы для выполнения оценки риска;
— способы регистрации и анализа оценки риска.
Причинно-следственный анализ
Краткий обзор
Причинно-следственный анализ является структурированным методом идентификации возможных причин нежелательного события или проблемы. Данный метод позволяет скомпоновать возможные причинные
факторы в обобщенные категории так, чтобы можно было исследовать все возможные гипотезы
Контрольные листы
Краткий обзор
Контрольные листы представляют собой перечни опасностей, риска или отказов средств управления, которые обычно разрабатывают на основе полученного ранее опыта, результатов предыдущей оценки риска или
результатов отказов, произошедших в прошлом.
Анализ воздействия на бизнес
Краткий обзор
Метод анализа воздействия на бизнес (BIA1) ), также известный как оценка воздействия на бизнес, позволяет исследовать, как ключевые виды отказов/нарушений/разрушений могут повлиять на ключевые виды деятельности и процессы организации, а также идентифицировать и количественно определить необходимые возможности для управления организацией в этих условиях. Процесс метода BIA обеспечивает согласование и понимание:
— идентификации и критичности ключевых бизнес-процессов, функций, связанных ресурсов и ключевых взаимосвязей, существующих в организации;
— влияния отказов/нарушений/разрушений на возможности организации достигать установленных критических целей бизнеса;
— необходимых возможностей управления воздействием отказов/нарушений/разрушений и восстановлением нормального хода деятельности организации.s-kozlov
19.01.2017 14:03-1Учебники цитировать мы научились, но понимание того, что разработчик не отвертка, не пришло. Живите дальше в своем мире.
Lofer
19.01.2017 14:24А кто мешает «творить» разработчику в его области ответственности?
Разработчик должен понимать, что он предоставляет «сервис разработки» для своего Работодателя и Клиента. Этот «предоставленный сервис» обязан быть выполнен в первую очередь с заранее оговоренным качеством и ценой.
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
Или чем-то отличается?khim
19.01.2017 18:27+1С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
А это — уже бизнесу решать.
Или чем-то отличается?
Тут всё дело в том, что производительность труда разработчика, который «болеет душой за дело» и того, который «предоставляет сервис разработки» — отличаются на порядок. Не двоичный, нет. Разница в производительности в 10 раз — это задокументированный факт.
Если руководству компании подход «это просто сервис разработки» милее и они готовы увеличить ФОТ разика в три, чтобы нанять в 10 раз больше разработчиков (обычные разработчики ещё и дешевле, ко всему прочему — но, разумеется, не в 10 раз) — тогда всё описанное в статье было сделано правильно: это вполне себе действенный способ превратить разработчиков в «винтики» и выжить тех, кто могут что-то действительно крутое сделать.
А если нет — то это большая ошибка. Потому что превратить разработку в рутину и выжить «10x звёзд» — несложно. Проделать обратную процедуру — почти невозможно.Lofer
19.01.2017 19:15-1Что значит «болеть душой за дело»? Это бесплатно работать ночами? Рвать на груди рубашку и с криком «вы все козлы» деплоить самопальный «гениальный» код на сервера клиента?
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
И как Работодатель должен стимулировать «болеть душой за дело»? Взять любимого хомячка в заложники или дать «сахарные губки» и Негра с опахалом?
Условия работы оговорили? Оговорили.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом и «сахарные губки» или что ему еще надо.
Есть условия получше? Пусть перебирается.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Видел людей которые под капельницей полежали, после такой вот «болеть душой за дело»… Нифига они не рады такомуqw1
19.01.2017 20:44+2Условия работы оговорили? Оговорили.
Формально верно. Вам платят, вы работаете.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом
Но в реальности что происходит, когда разработчику не интересно? Он с трудом вымучил 2 функции и сидит тупит. Код будет некачественным, потому что лень кодировать случаи, не указанные в ТЗ (а они в процессе разбора алгоритма так или иначе появляются), лень даже формировать качественные сообщения об ошибках, чтобы пользователь сам разобрался.
Конечно, разработчик будет уверять, что он работает с полной отдачей, только платите побольше. Но мозг не обманешь — когда скучно, он будет искать способы сэкономить энергию.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Это глупость. К примеру, нравится человеку матрёшек вытачивать и раскрашивать, он болеет за них всей душой. Значит ли, что от такого рукоделия появятся седые волосы или поднимется давление?Lofer
19.01.2017 21:05-1Но в реальности что происходит, когда разработчику не интересно? Он с трудом вымучил 2 функции и сидит тупит.
В реальности? Если вышел за «рамки»? Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…khim
19.01.2017 21:29+2Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…
И он его найдёт — не сомневайтесь. Люди, способные командой в 5-10 создать нечто, что их конкуренты не могут повторить, имея коллектив в несколько сотен «винтиков» на рынке вполне востребованы.
Но вопрос «а нужны ли они нашему бизнесу» — это уже совсем другой вопрос. Собственно это и есть главный вопрос, на который в статье не был дан ответ. Чего хотели от внедрения Agile — и получили ли в результате то, чего хотели?
qw1
20.01.2017 12:27Так 2 функции в день — это средний показатель на неинтересном проекте, где разработчики демотивируются. Поэтому объясняться придётся всем, ну или владельцы не допрут, что такая скорость это ненормально и будут думать, что раз все так работают, то так и надо.
khim
19.01.2017 21:23+2Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
А потому что невыгодно.
Давайте я покажу на примере. Просто не так давно этим занимался, потому пример в памяти ещё свеж. Эмуляция ARM, основные инструкции. Их — порядка 100 штук в мануале.
Что можно сделать при использовани скрама и тому подобных вещей? Создать 100 «тасков» на пару часов каждый и начать реализовывать эти инструкции. За месяц с небольшим задача будет решена (40-часовая неделя, всё такое).
Что можно сделать если не считать человека винтиком? Вспомнить о том, что эти инструкции же были как-то реализованы в ARM2, в котором было-то всего 30'000 транзисторов! Как? Если внимательно всмотреться — то можно увидеть что там есть 8 бит, которые влияют на то, какие блоки в процессоре срабатывают и когда. И написать несколько функций, которые будут тесно друг с другом связаны строк на 150-200 — и всё.
Но вот беда: Петя с его 100 «тасками» будет любимцем всех менеджеров, будет иметь отличные показатели и будет всеми уважаем и любим. Вася, который создаст несколько функций, потратит на них дня три, причём в первые пару дней выхода не будет вообще — он будет мануалы читать!
Есть условия получше? Пусть перебирается.
Дык так и происходит. Когда Петя, со своей погоней за «тасками» разнесёт «фен-шуй», который создал Вася, то тот перестанет чувствовать сопричастность или либо уйдёт, либо переключится на стиль работы Пети.Lofer
19.01.2017 21:45Извините, но вопрос внутренней мотивации и психологии разработчика никак не относится к методологии и ее не корректному применению.
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»khim
19.01.2017 22:00+2Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»
Выбор идёт в обратном направлении: Менеджер, стремящийся примерно к этому найдёт такую методологию, которая позволит ему это сделать. А как она формально будет называться — уже не так и важно.
Извините, но вопрос внутренней мотивации и психологии разработчика никак не относится к методологии и ее не корректному применению.
Это очень странно, потому что это, собственно, самое главное, что влияет на количество и качество результатов…Lofer
20.01.2017 02:02Да. В этом и проблема.
Слишком много «человеческих» переменных. А процессы пытаются это влияние и зависимость уменьшить.
Женщину достали, автомат поставили. (с)s-kozlov
20.01.2017 09:04+2Да. В этом и проблема.
Слишком много «человеческих» переменных.
Умные менеджеры рассматривают это не только как проблему, но и как великую возможность. Глупые — пытаются заменить человеческий потенциал инструкциями и методологиями.Lofer
20.01.2017 10:30Глупые — пытаются заменить человеческий потенциал инструкциями и методологиями.
А вот тут я с Вами согласен :)
Корректная трактовка инструкци — это накопленный опыт, как некоторые действия в уже известных ситуация привели к ожидаемому результату (Success stories), что освобождает время на на иные действия.
Например: не суй цальцы в розетку, мойте руки перед едой, не дразните собаку, проверь код что написал, SOLID, Scurm, ISO 27001 и т.д.:)
Так же очевидно, что они не запрещают и дейстовать иначе в аналогичной ситуации и вырабатывать иные «инструкции».s-kozlov
20.01.2017 12:38Ну вот, теперь мы начинаем приходить к общему знаменателю.
Видимо, разногласия у нас только в терминологии.
Например, я не рассматриваю «Делай хорошо свою работу» как инструкцию. Инструкция, на мой взгляд, — это достаточно точное указание, объясняющее, что нужно делать. Например, в крупных сетях ресторанов есть подробные инструкции, позволяющие повару среднего пошиба готовить достаточно сносные блюда. Проблема в том, что так невозможно готовить эксклюзив: тут уже нужен талант — тот самый человеческий фактор, который инструкциями не заменишь.
ApeCoder
20.01.2017 10:42Что можно сделать при использовани скрама и тому подобных вещей? Создать 100 «тасков» на пару часов каждый и начать реализовывать эти инструкции. За месяц с небольшим задача будет решена (40-часовая неделя, всё такое).
Почему вы считаете, что скрам требует такого подхода? В рамках планирования спринта и груминга беклога команда может решить что это все одна User story. Или побить по видам команд. См также "Вертикальная декомпозиция"
qw1
20.01.2017 12:30+1Чтобы это понять, нужно прочитать весь мануал и в уме держать всю архитектуру. Типичный «ленивый» подход — я держу в памяти только свой кусок ТЗ, который есть в спринте — не позволит это сделать.
ApeCoder
20.01.2017 13:57При чем тут Scrum? Он никак не предписывает разбивать спринты по командам процессора и не держать в уме всю архитектуру. Более того, реализация n команд — плохая цель спринта с моей точки зрения. Правильная цель спринта — "Дать пользователю запустить X на эмуляторе" — то есть декомпозиция должна быть вертикальной. Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.
khim
20.01.2017 17:22+1Правильная цель спринта — «Дать пользователю запустить X на эмуляторе»
Это — месяца два работы, как минимум. Вы хотите это одним таском оформить?
Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.
Не будет при таком подходе разбивки по битам. Потому что история про эти биты и их «творческое комбинирование» подробно разбирается только и исключительно в мануале 1987го года на процессор ARM2! В мануале 1996го года на ARM810 — описано как эта схема эволюционировала (но подробного описания уже нет), а в современных мануалах — не осталось даже намёков! Вы думаете кто-то, кому платят за выполнение «тасков» туда полезет разбираться? Зачем? Если есть простой и понятный путь, который будет гарантированно оплачен?ApeCoder
20.01.2017 17:42Это — месяца два работы, как минимум. Вы хотите это одним таском оформить?
Я не в теме. X может быть hello world, например. Или мигнуть виртуальной лампочкой.
Вы думаете кто-то, кому платят за выполнение «тасков» туда полезет разбираться?
В скраме команде платят не только за выполнение тасков. Таски это просто способ координировать работу команды
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
zenkz
20.01.2017 01:31+2Вот наглядный пример:
Есть задача разработать систему расчётов чего-либо.
К этой задаче прилагается техзадание.
Разработчик А (предоставляющий сервис): реализовал задачу в точности по ТЗ.
Разработчик Б (болеющий душой за дело): внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Промежуточный итог 1: «сервис»-разработчик лучше, т.к. всё реализовано быстро и по ТЗ
Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ, на которые разработчик А не обратил внимание, а разработчик Б — обратил и исправил ещё процессе разработки. В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
Итог: разработчик (да и любой специалист), который не просто «работает с 8 до 5 предоставляя сервис», а нацелен на результат и старается сделать проект лучше, будет более востребован и ему будут платить в разы больше (и это будет оправдано экономически).
Притом «болеющий душой» разработчик не обязательно трудоголик. Он может и в 8 часов рабочего дня приносить в разы больше пользы компании, чем «предоставляющий сервис» разработчик за 12 часов.Lofer
20.01.2017 02:21-1Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ,
Привет Agile и иже с ними.
внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Молодец. Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.
В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
В первом случае тоже не будет никаких судебных разборок:
- сделано по ТЗ.
- Клиент провел приемо-сдаточные испытания или получил протоколы тестов от Подрядчика
- подписал акт приемки.
khim
20.01.2017 04:03+2Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
Да потому что это не-вы-год-но!
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.
Как раз наоборот. Обязательно дойдут, выползут и «ударят по почкам». Вы забываете про один фактор, который реально перечёркивает всё: клиенты не знают, что они хотят. Люди, которые приносят вам ТЗ — это совсем не те люди, которые будут пользоваться вашей программой в 99% случаев! И даже если — те, они всё равно понятия не имеют чего вы в принципе можете, а чего не можете!
В первом случае тоже не будет никаких судебных разборок:
Именно! Если ваша задача — сделать не хорошую программу/систему/etc, а что-то, что получит хорошие оценки на «приёмо-сдаточных испытаниях» — то гораздо проще и выгоднее не мучиться, не дёргать аналитиков и менеджеров, а подождать пока всё то дерьмо, которое вы сотворите согласно ТЗ всплывёт в реальной эксплуатации, пользователи начнут орать благим матом — а вы, весь такой в белом, придёте и разрулите ситуацию. Ещё хуже — когда разработчик начнёт работать на то, чтобы реализовать больше UserStory, а не на то, чтобы удовлетворить заказчика.- сделано по ТЗ.
- Клиент провел приемо-сдаточные испытания или получил протоколы тестов от Подрядчика
- подписал акт приемки.
Простой пример: менеджеры будут обсуждать неделю куда всунуть кнопку «пересчитать итог» и каким цветом её лучше выделить, но додуматься до того, что можно сделать так, чтобы эта кнопка была не нужна, так как можно сделать все в фоновом потоке и просто скрывать данные, которые не валидны и показать их, когда они станут валидны — не смогут, так как это не вписывается в их видение мира!
А когда увидят эту фичу в конкурирующем продукте — заставят её внедрить везде и пользователи начнут вас проклинать, когда рассчёты, требующие полчаса, будут происходить в фоне и никто не будет знать — они, вообще, собираются заканчиваться или нужно систему на ночь оставить, чтобы она «прочухалась»…Lofer
20.01.2017 11:03-1Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
Да потому что это не-вы-год-но!
Возможно я уже перерос ходить «с фигой в кармане», но почему невыгодно мне, как разработчику, сказать про косяки заранее?
- Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»
Я смотрю обратную связь Работодателя, Клиента. Если я вижу, что их реакция «неадекватная», я понимаю что ничем хорошим это не кончится и начинаю себе «стелить соломку».
И через время ухожу «подготовленный» - Если я молчу «с фигой в кармане», через время у Компании начинаются проблемы, я не успеваю подстелить соломку и все равно вынужден уходить. только уже не подготовленным.
Где моя выгода в стратегии «молчания, с фигой в кармане»?
Я сам себе сделал хуже, а не только «злым менеджерам».
Люди, которые приносят вам ТЗ — это совсем не те люди, которые будут пользоваться вашей программой в 99% случаев!
Учим мат часть :) Изучаем работу со стейкходелдерами, изучаем приемы BA и т.д.
менеджеры будут обсуждать неделю куда всунуть кнопку «пересчитать итог» и каким цветом её лучше выделить,
Не менеджерское/барское дело «кнопки красить». Пусть займутся своими делами. К примеру сделают RACI матрицу в начале проекта, обеспечат ресурсами и не лезут не в свое дело после.
Нанимают нормальных спецов по UI/UX, дают ресурсы изучать мануалы по дизайну от компаний, обеспечивают софтом для прототипирования и т.д.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим. Потом удивляемтся, почему так? А хто эта сделал ?!
Из бочки варенья и ложки г#вн@, получается бочка г#вн@ + 1 ложка. И не иначеkhim
20.01.2017 17:39+1Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»
… и попадаете в «чёрный список», потому что из-за вас количество UserStory, реализованных за спринт начинает падать, ваш отдел получает славу «скандалистов» и т.д. Оно вам надо?
Если я молчу «с фигой в кармане», через время у Компании начинаются проблемы
И вы их героически разруливаете. Получаете премию.
Где моя выгода в стратегии «молчания, с фигой в кармане»?
Почему же? Вы сохранили свои нервы, считаетесь «надёжным работником», так что когда компания начнёт разваливаться — у вас будет больше времени на то, чтобы найти новую. Вы всем сделали лучше — за исключением конечного пользователя, конечно — но это-то как раз в этой ситуации уже совсем неважно.
Я сам себе сделал хуже, а не только «злым менеджерам».
Не менеджерское/барское дело «кнопки красить».
Если бы менеджеры в обсуждаемой компании тоже так считали — то не было бы этой статьи. А если менеджеры учитывают только свои «таски», то вся работа и вырождается в вопросы покраски кнопок. И менеджеры как раз на них у будут делать упор, так как остального не понимают.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим.
Неа. Прослеживается устойчивая мысль: вы получаете то, за что платите. Хотите хороший продукт? Тогда сделайте так, чтобы тот, кто его делает был в этом заинтересован. Хотите больше UserStory и «галочек»? Получите свои UserStory и галочки. Только хорошего продукта уже не будет.ApeCoder
20.01.2017 17:49… и попадаете в «чёрный список», потому что из-за вас количество UserStory, реализованных за спринт начинает падать, ваш отдел получает славу «скандалистов» и т.д. Оно вам надо?
Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам? Вероятно, у вас какой-то опыт работы в конторах с не очень хорошими отношениями между начальством и подчиненными и вы накладываете это на скрам. Но весь эффект получается от именно этого отношения, а не от скрама
khim
20.01.2017 18:41+1Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам?
Вы сюда как будто из какой-то альтернативной вселенной свалились. Где люди читают инструкции.
Какой-такой скрамгайд в мирное время? Есть цифирьки, их можно сладывать и сравнивать. Кто больше получил — тот и молодец… Всё ж просто! Ах, что так не надо было? А почему? И кто мне, менеджеру, это запретит делать, собственно?ApeCoder
20.01.2017 19:04Да в моей вселенной хорошие отношения на работе и менеджеры не давят на цифирьки и понимают, если им объяснить.
А в вашей вселенной получается вы работаете как-то так, что никаких чисел нельзя вычислить. Например в языке принципиально нельзя подсчитать количество строк кода, а то бы менеджеры их просили и за них дрючили.
khim
20.01.2017 19:22Например в языке принципиально нельзя подсчитать количество строк кода
Посчитать можно, но мы этого не делаем. Потому что если бы делали — да, менеджеры бы начали их складывать и вычитать. В журналах, кстати, платят пословно.
а то бы менеджеры их просили и за них дрючили
Одно дело — запросить какую-то информацию специально (тут ещё можно объяснить, что я не передовик производства только потому что залил в репозиторий автосгенерённый файл на 10'000 строк), другое дело — запретить им использовать данные, которые у них уже есть.
Грубо говоря весь Scrum сводится к тому, что мы в клетку с тиграми заносим тарелку с мясом, а потом начинаем им объяснять, что есть его нельзя. У кого-то получается, у кого-то нет, но сама идея, конечно, совершенно правильна, вы не находите?ApeCoder
20.01.2017 19:39Получается, в вашем мире вам нельзя использовать гитхаб и багтрекеры — все что позволяет считать статистику. Давайте лучше к нам!
ApeCoder
20.01.2017 19:53И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"
Lofer
20.01.2017 18:18-1Прослеживается устойчивая мысль: вы получаете то, за что платите. Хотите хороший продукт? Тогда сделайте так, чтобы тот, кто его делает был в этом заинтересован. Хотите больше UserStory и «галочек»? Получите свои UserStory и галочки. Только хорошего продукта уже не будет.
Что и требовалось выяснить- не корректное применение инструментария безграмотными менеджерами.
Вины инструментария Scum / Agilre- нет. :)khim
20.01.2017 18:37+1Вины инструментария Scum / Agilre- нет. :)
Есть — но косвенная. Если сравнивать Agile/Scrum с языками программирования — то я бы сравнил их даже не с C++, а, скорее, с ассемблером. А из бытовых предметов — с дисковой пилой без ограничителя.
То есть при правильном примении — вы можете добиться фантастических результатов. Однако «отрезать себе руку» — не просто, а черезвычайно просто.
Инструментарий просто-таки напрашивается, чтобы его «эффективные манагеры» засунули к себе в Excel и начали на его основании «любить и жаловать». Для того, чтобы его не стали вдруг использовать «неправильно» (то есть — наиболее очевидным, просто-таки напрашивающимся способом!) нужен специальный человек с весьма специфическими навыками.ApeCoder
20.01.2017 19:45Интересно, какая должна быть методология чтобы зарезать себя использовать неправильно? Даже в том случае, когда можно выполнять не все предписания или не полностью из гацда придумывать свое и все равно называть это ее именем? Есть скрам мастеру и сертификация оных, но все равно недостаточно. Мне кажется это должно быть тайное общество и методология должна называться секретно. То есть ее имя открывается только тому, кому верховный методолог разрешил, убедившись, что он усвоил ее букву и дух. И жестоко карать отступников.
- Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»
VolCh
20.01.2017 07:35+2Конечно, отличается.
1. В случае наемного труда все риски берёт на себя работодатель, в частности работодатель не может не оплатить труд разработчика.
2. Разработчик не предоставляет сервис, разработчик продаёт свой труд, а не результат труда.
Fesor
19.01.2017 08:51Есть косяки, которые лучше предотвращать, а не исправлять.
И намного больше косяков, на которые можно закрыть глаза на данный момент если ущерб от оных в финансовом плане меньше чем попытки предотвращения оных.
https://www.youtube.com/watch?v=GRr4xeMn1uU — тут весьма содержательный пример. Из жизни же примеров можно и других накидать.
s-kozlov
19.01.2017 11:50И намного больше косяков, на которые можно закрыть глаза на данный момент
И что? Чем это поможет при возникновении косяка, который было выгоднее предотвратить?Lofer
19.01.2017 14:32Кто оценивает «выгоду» Клиент или Подрядчик? Как он оценивает?
s-kozlov
20.01.2017 09:08Чтобы оценить, надо сначала узнать. Отвертка и винтик вам об этом не сообщат.
Lofer
20.01.2017 11:22Простые вопросы.
Кто получает «выгоду»?
Кто оценивает «выгоду»?
Как выгодоприобритатель «выгоду» оценивает?s-kozlov
20.01.2017 12:42Понятно, что в конечном счете выгоду оценивает не разработчик. С этим никто не спорит. Вот только инициативный разработчик может подкинуть руководству такую идею, до которой оно само не додумалось.
Lofer
20.01.2017 13:55Подкинул идею.
Мотивация в подкидывании идеи?
- Сожрать или использовать ресурсы компании на ее проверку ?
- Получить похвалу от окружающих ?
- Предотвратить будущую проблему для себя ?
- Финасовая мотивация (получить премию, пакет акций)?
Что дальше?
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту. Переиграй «ничтожных людишек» :)s-kozlov
20.01.2017 14:29+2Мотивация в подкидывании идеи?
Кроме внешней мотивации, примеры которой Вы привели, есть еще внутренняя — чувство удовлетворения от хорошо сделанной работы, самоуважение, которое проистекает из осознания ценности себя как специалиста и человека. Те самые «человеческие переменные», которые плохие менеджеры пытаются «обезвредить». Те самые «человеческие переменные», которые можно использовать как рычаг, улучшая показатели бизнеса в разы или даже на порядки.
Почему бы не сделать на этом «кучу бабла»?
Потому что зачастую реализовать эту идею выгодно только в текущей компании. Ну и не будем забывать, что основать прибыльный стартап — это титанический труд, и не каждая идея этого стоит.
Встречный вопрос: а почему бы работодателю самому не сделать на этом кучу бабла?
VolCh
20.01.2017 14:45+2делай свою Фирму
Это путь менеджера, а не разработчика. Обычный разработчик не сможет нормально управлять фирмой (даже как учредитель с наемным менеджером) и оставаться разработчиком.
khim
20.01.2017 17:45+1Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту.
Этот путь работает, когда в компании 5-10 человек. И такое — регулярно происходит. А если в компании — человек 50-100 и они нужны, чтобы поддерживать продукт соответствующего масштаба… То ваши потуги «переиграть ничтожных людишек», в общем-то, обречены… Ну не сможете вы уйти и разработать за месяц, аналог того, что требовало не один десяток человеко-лет…
Вот уйти и сделать что-то новое, другое — легко. Этим обычно и кончается…
malbaron
15.01.2017 11:50Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.
Когда я впервые столкнулся с Agile, то у меня была подобная же реакция.
Мне понравилось как быстро команда пробует и откидывает кучу интересных технологий.
Но я не вписался.
Я по привычке делал код «на века», с тщательным продумыванием, с вынесением части кода в общеупотребимые библиотеки/пакеты. В результате мне пришлось неоднократно переписывать код с нуля, подстраиваясь под все новые и новые варианты интеграции. И я все никак не мог завершить свой маленький подпроектик и получить соответствующую премию.
В результате я не выдержал и свалил с проекта.
Вот таким было мое первое знакомство с Agile.
Поразмыслив, я считаю сейчас, что методология Agile — это очень круто.
Вот только нужно правильно с ней работать.VolCh
15.01.2017 19:41Agile — как принципы гибкой разработки, как принципы тесного взаимодействия заказчика и исполнителя с доставкой фич на ранних стадиях разработки и минимальным временем реакции на уточненные после неё требования — это круто. Способы его насаждения сверху в виде каких-то жестких методологий, зачастую очень похожих на сектантские ритуалы — это, обычно, путь в, как минимум, уменьшение эффективности команды.
malbaron
15.01.2017 21:02Способы его насаждения сверху в виде каких-то жестких методологий, зачастую очень похожих на сектантские ритуалы — это, обычно, путь в, как минимум, уменьшение эффективности команды.
Конкретные способы насаждения с которыми столкнулись Вы — не знаю.
А в целом и общем готовая методология нужна и полезна.
Чужие грабли это лучше, чем свои.
Да, они хуже усваиваются, но если просто следовать чужому методу обхода граблей — это просто и быстро.
В конце концов мы же не придумываем свои операционные системы и свои СУБД (редко) для нового очередного проекта — пользуемся готовыми. Это — эффективно.
Так же как и использование готовой методологии.
VolCh
15.01.2017 22:56Тут в чём дело — методологии управления разработкой нужны, прежде всего, менеджерам, а не разработчикам. А менеджер, зачастую, не может выбрать оптимальную методологию для имеющихся условий, не зная ни области её применимости, ни даже существующих условий.
Fesor
15.01.2017 23:13а если убрать из команды менеджеров? Ну вот совсем. Нету менеджеров. Выходит и процессы не нужны? Как-то не очень...
Процессы нужны команде в первую очередь чтобы знать что делать.
VolCh
16.01.2017 09:56Процессы всегда есть, вопрос насколько они формализованы, насколько гибки. Разработчикам нужна постановка задач, чтобы знать что делать. В общем и в целом отдельный менеджер команды для этого не нужен. Постановка осуществляется аналитиками (вариант — совместно заказчиком и разработчиками). Ещё неплохо бы приоритезацию, а она может осуществляться совместным решением конкурирующих за ресурсы команды стейкхолдерами, или вообще большим боссом, если они не договорились.
malbaron
15.01.2017 11:56К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.
А вот это вряд ли.
О сути, которой является вот это:
Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.
А вовсе не используемые базы данных — разработчики ни сном не духом.
Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка
А он всегда и был отверткой и молотком.
Деньги в таком проекте приносит то, кто знает кому проект толкнуть.
malbaron
15.01.2017 12:07С их точки зрения всё, конечно, логично: быстрее сделали – а значит, понесли меньше расходов, быстрее выполнили контракт, получили деньги и премии. Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
Сие не имеет к Agile/Scrum ровным счетом никакого отношения.
Это обычное отношение менеджера (заказчика) к программисту (исполнителю).
Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.
Имхо, Agile как раз и позволяет по-крупному творить.
Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понравиться не всем.
Дети-то как раз быстрее взрослых адаптируются
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Сие опять таки описывает только взаимоотношения менеджеров и разработчиков.
Не имеющего никакого отношения к Scrum/Agile.
Почему в производственной компании, делающий уже много лет как единственный как я понял основной продукт, решили подходить к изготовлению ПО как к ПО-однодневке, почему баги считаются менее важным, чем развитие продукта — вопросы к руководству проектом.
Вполне возможно, что пытались угнаться за конкурентами.
То есть проблема, думается, лежит вне области разработчиков.
Учитывая вступление к статье, где говориться о бурном росте и открытие филиалов — компании банально были нужны деньги.
А деньги дают прежде всего новые фичи, сделанные по финансируемым заказчикам просьбам.
Руководство не смогло держать баланс между зарабатыванием на новых фичах и бесплатным исправлениями старых багов.
Но, вопрос возникает снова, — вина ли в этом Agile/Scrum. Почему?
Перестройка на новую методологию (любую — хоть Agile, хоть не Agile) — это разумеется напряжение.
Но почему автор статьи сваливает вину именно на Agile?
А не на менеджеров.
malbaron
15.01.2017 12:25В итоге вся эта система стала приводить к маленькому локальному коллапсу. Разработчики растеряли весь энтузиазм и стали относиться к разработке формально. Есть задача – делаем, нет задачи – не делаем.
Тут описана болезнь роста.
В маленькой фирме все на виду. В большой — более формальный подход, разработчики и не должны ничего делать просто так, без формальной задачи. Кроме особо доверенных.
Такая схема позволяет руководству компании иметь представление, а какими ресурсами оно располагает, какова будет себестоимость на том или ином этапе работ.
А работа без поставленной задачи = не работе вообще.
Вы можете быть добросовестным работником, а можете балду пинать — в большой компании это не видно.
Поэтому формальная задача нужна всегда.
У нас с Agile это решается просто — разработчики могут сами поставить себе задачу (разумеется, с уведомлением и одобрением старшего), если видят что-то «в глубине», что не видно менеджерам снаружи.
Разумеется, всегда сложно объяснить «верхам» что тут обязательно нужен крупный рефакторинг (который, понятно денег не приносет сиюминутно, а напротив).
Технический долг — эта тема отдельной статьи:
https://habrahabr.ru/post/319332/
Но опять таки — это не вина Agile/Scrum.
Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
В итоге вся эта система стала приводить к маленькому локальному коллапсу.
Из чего следует, что некий старший разработчик недостаточно защищал интересы своих людей (и качество их работы).
Менеджеры давили, они всегда давят на скорость и т.п. — это и есть их работа.
Но старший разработчик должен был сопротивляться. Не фикшен критический баг перед выпуском в production — кто об этом скажет руководству? Кто выбьет время на исправление бага? Это и должен быть старший разработчик. Это может быть менеджер проекта(скорее всего), именно его дело — заботиться о качестве, именно он и знает. Ну может еще тех. лид (но маловероятно, что лид пойдет стучать ботинком о стол руководства).
А менеджеры, принимающие у заказчиков новые требования и конвертирующие их в таски разработчиков — разумеется, занитересованы в другом.
malbaron
15.01.2017 12:32+1Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Агрессивный переход на такие потоковые методологии разработки приводит к «формализации» отношений внутри компании. Результатом резких внедрений стало то, что менеджмент теперь лучше видит, что происходит в компании, но ключевых разработчиков в компании уже нет.
Энтузиазм — штука не контролируемая.
Поэтому она хороша или до некого небольшого размера компании, когда все на виду.
Или, когда у тебя полно бабла и жесткий отбор сотрудников — как Google позволяет своим сотрудникам творить в больших объемах.
По мере роста компании без формализации компания развалится (станет неэффективной).
Говорить о том, что эти сотрудники виноваты сами, тем, что не смогли адаптироваться, или поступили высокомерно – как по мне, так это ошибка. Возможно, сам процесс внедрения Agile был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
Ну ну.
Я сам из своего первого Agile вылетел сам и с облегчением вздохнул.
А сейчас его люблю.
bks
15.01.2017 17:27Почти 10 лет управляю разработкой. Сам не программист. У меня работа идет только по задачам, а учет времени даже не почасовой, а поминутный. Мы зачастую себя называем экстримальными Agile разработчиками.
Agile — изначально это возможность заказчика в ходе разработки менять требования, т.е. гибкая разработка. Модели процессов, которые придумывают люди, чтобы обеспечить такой режим разработки нельзя применять «как есть» с закрытыми глазами на текущую в конкретной команде реальность.
Получается, что в описанном результате не виноват ни сам эйджайл, ни скрам.
Если мой разработчик обнаруживает, что есть незапланированная задача, которую следует по его мнению выполнить, то он просто вносит ее. В зависимости от настройки проекта он, либо ждет согласования, либо выполняет сразу и учитывает по ней затраченное время.
На вопрос сколько нужно времени на выполнение задачи, ответ от программиста от 20 минут до 2 недель вполне приемлем! У программистов многопоточное мышление. Если он не знает, как сейчас решать задачу лучше и переключается на другую, то это не значит, что во втором потоке не идет поиски решений по первой. Надо уметь давать вызревать задаче, тогда на ее решение может уйти всего минуты. Это уже практика.
По факту хреновый был у вас менеджмент, видимо хорошего опыта разработки не имел.
Опасайтесь моделей! Модели бизнес процессов, взятые из опыта других — это лишь примеры для ваших размышлений. Принять к сведению и сделать по своему. Приблизительно такая же ситуация произошла, когда один из «наших» купил Mandriva, ввел туда менеджмент и все разработчики разбежались, а разработка была приостановлена.
Менеджмент и разработчики и много других участников процесса разработки — это части одного целого. Нельзя противопоставлять их друг другу. Причем со стороны разработчиков также нужно относится с пониманием, или хотя бы с желанием понять задачи тех, кто управляет разработкой или выполняет другие функции, в купе дающие готовый и рабочий продукт.
Много раз встречал и быстро прощался с разработчиками, которые ставили себя выше других и с пренебрежением относились к другим участникам не столь одаренным, но выполняющим свое дело. Только во взаимопонимании рождаются действительно хорошие продукты, и устанавливается комфортная среда для ведения процессов разработки. А методы должны соответствовать конкретной команде, задаче и другим условиям окружающей среды.
Всех благ.
Blight
16.01.2017 22:42+2Управляю разработкой почти 8 лет как CTO, немного программист, имеют опыт около 5 лет как фронтенд-разработчик.
И именно поэтому проблем, сходных с описываемыми в посте, у меня не возникает — я говорю с менеджерами на их языке, с разработчиками — на их. Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит. Он обещает клиенту золотые горы, и уже завтра, он не понимает, что «добавить галочку» одновременно значит «перелопатить логику в десятке мест и все протестировать», он хочет, чтобы конкретно его клиенту сделали ту фичу, которую этот клиент хочет прямо сейчас, бросив все другие дела.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру» — расставить приоритеты, превратить поток сознания менеджера-продажника в нормальные задачи, решить, кто эти задачи сделает эффективнее и распределить их, оценить сроки (когда самому, а когда и посоветовавшись), проконтролировать исполнение, а также заблокировать неумеренный и неуместный энтузиазм вида «да это буквально 5 минут, давайте сделаем прям щас». Ага, щас, разбежались.
Вообще стараюсь не допускать прямого контакта технарей и менеджеров, если честно. Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды. И это облегчает жизнь всем этим частям.
Думаю, без такого контроля, когда все, что подается на вход в разработку извне, разбирается человеком, понимающим техническую часть, полу-менеджером и полу-технарем, любая методология может фейлиться, как и описано в посте. Скрам, ватерфол — итог один, завал разработчиков «текучкой», раздрай в команде и полное непонимание менеджерами, почему у них все не так, как хочется. И чем больше команда, тем больше будет проблем.malbaron
16.01.2017 22:50Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит.
Существуют огромные корпорации, где на многих уровнях люди не понимают, чем занимаются люди на других уровнях.
Это нормально. Современный уровень познаний настолько велик, что невозможно знать все даже в среднем предприятии.
Совершенно нормально, консультироваться с узким специалистом по конкретному вопросу.
Как-то мне один руководитель (успешный) сказал, что его работа целиком состоит из общения с сотрудниками — они ему рассказывают что да как устроено на его предприятии по конкретному поводу.
В ИТ менеджером (и успешным) может работать кто угодно.
Напротив даже, те менеджеры, кто раньше давно был программистом, а потом отошел далеко от этого — не должны сами делать оценки.
Если менеджер-непрограммист это понимает, как правило, но менеджер-программист такие вещи понимает плохо.
malbaron
16.01.2017 22:56Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды
Ага. Низзя, низзя
У программистов другие приоритеты — программист может на вторичную малонужную фичу, от которой можно было бы отказаться, убить дохрена времени. Запросто.
Далеко не всякий программист умеет понять, когда нужно акцентировать менеджеру — эта фича будет слишком дорогой, она точно нам нужна прямо сейчас?
Далеко не всякий программист способен сказать менеджеру, «если галка будет не голубой, а такой же как основной цвет галок темы, я смогу закончить эту задачу за 2 часа, а если ты хочешь непременно голубую, то — за 2 дня».
Многие просто выполняют задачу, не пытаясь оптимизировать её постановку/формулировку. Ну это не факт что и нужно делать рядовому разработчику. Однако при прямом общении рядового разработчика с продаваном без smart-фильтра между ними — запросто возможны вышеописанные передергивания.
ApeCoder
17.01.2017 09:14Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру»
То, что вы описали задачи скорее продакт овнера и команды разработчиков, а не скрам мастера :)
Klocska
18.01.2017 17:41Моими глазами в описаном кейсе нарушено сразу несколько важных моментов AGILE и SCRUM в частности, то есть, согласно евангелистам получившееся SCRUMом называть негоже.
Самое главное — любая AGILE методология предполагает участие команды в формировании самой методологии, то есть если команду что-то не устраивает команда меняет правила, подстраивая процесс под себя. Собственно главной постулируемой целью появления AGILE методологий была разгрузка команд, вывод их на ровный режим работы без пиковых перегрузок и внезапного заваливания «срочными» никому не нужными задачами.
Ну и в SCRUM трудоёмкость измеряется в сторипоинтах, причем на реальное рабочее время это должно проецироваться только для всей команды в целом, причем производительность команды оценивается по результатам нескольких предыдущих спринтов.
К сожалению часто когда инициатором внедрения AGILE, особенно SCRUM является большое начальство, по сути, внедрение agile рассматривается как внедрение жесткой контролирующей процедуры для маскировки собственной некомпетентности, нежелания вникать в детали и неуверенности в себе.
В итоге в приведённой выше истории получился непонятный уродец, удобный для рисования табличек, но совершенно не ориентированный на удобство разработчиков и, более того, не обладающий возможностью ретроспективной модификации процессов. Развал команды — естественное следствие. Называть это Agile примерно как написать «Боинг» на газовом баллоне с примотанным скотчем крыльями и после рассказывать всем о том, какие плохие они самолеты клепают.
freethetan
18.01.2017 17:41+1Я конечно не про 80лвл с грандиозными проэктами за плечами, но как то работал в одном заграничном стартапе.
Начинали всё с нуля, и по старинке описывали все процессыв тетрадке, на доске.
Не было у нас никаких Agile и утренних Scrum-ов, и делали всё что нужно, «до самого утра» для стабильного выпуска версии, сообща работая с Senior Developer.
Проэкт рос, наняли «Ого-го» специалиста, потом и PM пришол и ввёл Agile.
Руководство требовало добавить «красивых» фич в фронтэнд, «ого-го» специалист захотел перейти с Zend на Wordpress, а PM просто делал свою работу от «а» до «б». Мы по прежнему старались делатьхорошодо самого утра свою работу а PM требовал присутствия на утренних Scrum-ах и дрюкал за дедлайны…
И вроде бы тоже как то там Agile «приплетён»… о чём это я?..
Ах да, " губит людей не пиво — губят людей дебилы, не правильная оценка ситауций и неграмотное управление"
Всем удачи и по меньше «баговых» сотрудников
pashilka
18.01.2017 17:42Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
В шею таких менеджеров, думаю проблема была в них. Видимо, они были со стороны и не пропитались культурой компании в полной мере.s-kozlov
19.01.2017 08:29— Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
— Как мы не можем тебя уволить, ведь это же просто замена одного некомпетентного мальчика с MBA другим.
Vlad_fox
19.01.2017 13:02+1напомнило:
— Василий, как Вам Паваротти?
— да фуфло вообще, как такое вообще слушают ??
— странно, а что из него Вы слушали, где?
— да мне как-то друган Серега по телефону напел что-то из этого Паваротти, ему тоже почему-то понравилось, но мне вообще не пошло.
ivkomn
Т.е. людской ресурс — ошибка
Человеческий потенциал — верно