Комментарии 580
Т.е. людской ресурс — ошибка
Человеческий потенциал — верно
Человеческий потенциал — верно
Типичный Agile по-русски… Почему-то все забывают про то что «Люди и взаимодействие важнее процессов и инструментов». У меня про такой «scrum» целый набор историй и выводов. Я сам являюсь сертифицированным скрам мастером и agile специалистом. Тут еще вопрос к скрам мастеру — он должен не просто «внедрять процесс», но и защищать людей от менеджмента и объективно рисовать текущую картину как команде так и заказчику.
У меня только один вопрос: при чем тут Scrum/Agile? Ровно тот же эффект получается с любой (неправильно примененной методологией) с оценкой времени и внешней постановкой задачи. Какие специфичные для скрама особенности привели к описанному в посте результату?
Кажется, я понял автора. Попробую описать свой опыт до и после прихода скрама.
Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт! Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня, и сделаю revert changes, отложив до следующего раза (а в следующий раз сделаю за 1.5 часа, потому что оно варилось у меня в голове целый месяц и пришло понимание, как это должно быть сделано). Через планирование и приоритеты вся магия пропадает. Может, у меня плохое настроение я бы сегодня поковырял старые баги из трекера. Но нет — наверху висит рефакторинг, который я выпрашивал целый месяц — будь добр, вперёд и с песней, или что я скажу завтра на митинге? Нет, спасибо, я не предложу взять такую фичу в спринт. Остаётся только свободное время (вечера и выходные), что не всем подходит. Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.
Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.
Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт! Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня, и сделаю revert changes, отложив до следующего раза (а в следующий раз сделаю за 1.5 часа, потому что оно варилось у меня в голове целый месяц и пришло понимание, как это должно быть сделано). Через планирование и приоритеты вся магия пропадает. Может, у меня плохое настроение я бы сегодня поковырял старые баги из трекера. Но нет — наверху висит рефакторинг, который я выпрашивал целый месяц — будь добр, вперёд и с песней, или что я скажу завтра на митинге? Нет, спасибо, я не предложу взять такую фичу в спринт. Остаётся только свободное время (вечера и выходные), что не всем подходит. Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.
Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.
Ну так и в вашем случае — при чем тут скрам? Возьмите любую методологию планирования, которая выглядит (грубо) как:
- дай разработчику оценить задачи
- выбери период времени
- накидай задач в этот период в соответствии с приоритетами и оценкой
- в конце периода проверь выполнение
- повторить
Вы получите все те же самые спецэффекты, которые у вас описаны. Их величина будет зависеть от того, как именно выполняется шаг 3, и это определяется тем, кто занимается планированием.
Ну и дальше немного общих рассуждений, никак не связанных со скрамом:
Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Ээээ. Вы это серьезно? А мне казалось, что давать и выполнять собственные обещания — это нормально, а не тяжело. Собственно, это наша работа, нет? (это неплохо описано у Мартина в Clean Coder, кстати)
Второе — нет времени остановиться и посмотреть/подумать.
Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт!
Ну так если вы не знаете, как оно пойдет, то и ваш менеджмент не знает, чего от вас ожидать. А это в бизнесе очень неудобно. Кто-то готов на такие риски, кто-то нет.
Да и после хронического ощущения выжатости от спринтов уже мало хочется заниматься проектом на собственном энтузиазме.
Аналогично, если спринты у вас оставляют ощущение выжатости — вы (или ваш менеджмент) что-то делаете не так.
Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»)
Подобные "разговоры" тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.
Впрочем, это все тоже сильно зависит от того, как именно обсуждаются результаты планирования. Если менеджмент адекватно относится к "я это не успел, потому что ко мне пришли и попросили то-то показать" — можно и не заниматься буквоедством в оценке.
Вы всё правильно написали, но много где называют «скрамом» то, что им не является.
Идеология скрама подавляет спонтанные идеи?
Менеджемент знает обо всех проблемах, но не может пойти против избалованных пользователей. Ведь «мы (IT) — сервис и должны быть клиентоориентированными». Так что скрам у нас — чистая фикция.
>>Второе — нет времени остановиться и посмотреть/подумать.Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Идеология скрама подавляет спонтанные идеи?
вы (или ваш менеджмент) что-то делаете не так.Конечно, всё не так. Каждый спринт меняется состав задач и приоритеты в середине спринта. Часто берём задачи без полного понимания и оценки, потому что это очень важная задача важного человека, надо её в спринт пропихнуть, а там определимся по ходу дела. Часто возвращаемся к срочному мелкому (и крупному) допиливанию фич прошлого спринта, потому что то, что сделано, пользователям не понравилось (ну вот так, они думали, что хотят это а оказалось, что это выглядит не так, как они представляли и уже хотят другое).
Менеджемент знает обо всех проблемах, но не может пойти против избалованных пользователей. Ведь «мы (IT) — сервис и должны быть клиентоориентированными». Так что скрам у нас — чистая фикция.
Вы всё правильно написали, но много где называют «скрамом» то, что им не является.
Если кто-то где-то что-то не так называет, то это проблема того, кто не так называет, а не того, чем называют.
В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
20% свободного времени. Или просто подойти к менеджменту и поговорить.
Идеология скрама подавляет спонтанные идеи?
Идеология предварительного планирования подавляет спонтанные идеи.
Конечно, всё не так.
Ну вот видите. И скрам у вас — чистая фикция, и описанные вами проблемы — не от скрама. Но почему-то претензии все равно к скраму.
Ваш (ну, или не ваш) стартап просто превратился в бизнес.
Из творческой мастерской, где можно в любой момент переключиться на проверку идей, просмотр логов, тестирование новых интересных плюшек — в инструмент по зарабатыванию денег. Программистов переставили от художественного холста к конвейеру.
А по скраму вы работаете или ещё по какой методике — не имеет никакого значения.
Из творческой мастерской, где можно в любой момент переключиться на проверку идей, просмотр логов, тестирование новых интересных плюшек — в инструмент по зарабатыванию денег. Программистов переставили от художественного холста к конвейеру.
А по скраму вы работаете или ещё по какой методике — не имеет никакого значения.
Это убивает творческое начало. В любой момент мне в голову может прийти любая идея. И если её не проверить в ближайшие дни, она уже протухнет.
Идеология скрама подавляет спонтанные идеи?
Если ваша творческая идея требует совсем уж много времени — у нас это прекрасно согласовывается с руководством. Обсуждается на митингах (еще чего коллеги и посоветовать умного могут).
Учитесь общаться с людьми.
Руководство не заинтересовано просто выжать из вас соки.
Руководство заинтересовано получить результат.
Если ваше творческое исследование направлено на развитие коммерческого проекта и у проекта есть небольшая финансовая подушка — то вас поддержат, будьте уверены.
Если будете молчать — то исход очевиден.
По этому поводу анекдот:
— У меня плохие отношения с женой.
Я после операции, мне нужно кашки есть, а она готовит мне котлеты.
Доктор сказал мне что нужно следить за питанием.
У меня развилась изжога.
Жена, гадюка такая, виновата.
— А ты сказал жене, что доктор тебе велел придерживаться строгой диеты?
— Нет.
— И почему тогда жена виновата?
Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.
Ладно, когда это место прижмёт, вот тогда и поставят задачу. Причём разработчику, который не любит оптимизациями заниматься (потому что у него загрузка меньше).
Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.
Ладно, когда это место прижмёт, вот тогда и поставят задачу. Причём разработчику, который не любит оптимизациями заниматься (потому что у него загрузка меньше).
У нас член команды добавляет тикет в таком случае который может быть приоритезирован или отвергнут овнером.
Да ну нафиг, объяснительные давать. Если продакт-оунеру надо, пусть сам ставит задачу.
Простейший пример — немного подтормаживает какая-то операция. Может, кеш какой поставить, может сложность алгоритма уменьшить. Поковыряться надо часа 2-4.
Что значит: «пусть сам ставит задачу, если ему надо»?
Это же только ты, закопавшись в детали, изнутри видишь, где это тормозит и всего 2-4 работы.
Видишь — скажи.
Вы случайно не срам-мастер из вышеописанной конторы?
Есть. Оно должно быть заложено в оценку задач, которые вы выполняете.
Подобные «разговоры» тоже должны закладываться в оценку времени той же задачи. А если у вас и после этого не хватает времени на исследовательские работы, а они объективно нужны — значит, вам нужно не 20%, а 40.
Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?
"Закладывается" столько, сколько нужно, чтобы оценка приближалась к реальности. Если разработчик знает, что после дня собственно разработки ему еще нужен день "походить под отладчиком" и "посмотреть на логи", значит оценка задачи — не день, а два. Если разработчик — или тимлид, или менеджмент — знает, что после завершения задачи еще полдня неизбежно уйдет на объяснения, как тестировать — значит, надо приплюсовать эти полдня к оценке.
(а 20/80 и так далее — это не для задачи, это вообще свободное время, оставляемое в итерации на исследования)
Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.
Гораздо более хороший подход — Due Date. Т.е. «сколько ты успеешь к такому-то времени?». На практике эта методика оценки ведет к менее частым срывам сроков. Не очень понятно зачем скрам-мастерам требуется знать сколько времени уйдет на каждую отдельную задачу. Гораздо важнее знать что и к какому сроку человек успеет сделать. Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты» и во всех книжках одно время талдычили что поинты != время, и вообще оценка сравнительная, чтобы определить что сложнее, а что легче.
Оценивать задачу путем вопроса «сколько это займет времени?» — ущербный подход.
Это вопрос, скажем так, неочевидный. Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется "сколько времени займет эта задача" и "к когда ты сделаешь эту задачу" — одно легко выводимо из другого.
К тому же, на сколько я понмю, в скраме же нет «времени», есть же «поинты»
Так я и не про скрам говорю, а про абстрактную систему планирования в вакууме.
одно легко выводимо из другого.
Теоретически да. Практически — такой подход переворачивает в голове разработчика процесс оценки с попытки определить объем работ по задаче и проанализировать риски на «набрать себе лукошко задач и разгребаться с ними». Вы можете поделить время до дедлайна разделив кол-во дней в часах на кол-во задач и получить нужную вам (а не разработчику) оценку. Разработчик (как и любой человек) не способен к быстрой оценке объемов работы. Однако оценивалка в режиме «успею-не успею» работает у людей куда лучше. Рекомендую попробовать.
Проблема в том, что у меня регулярно бывает ситуация "вот есть десять задач из роадмапа, надо оценить, какая сколько займет, чтобы понять, в каком порядке их выгодно делать, и на какие версии делать анонс". Задачи, очевидно, не одинаковые по сложности (иногда на порядок).
Собственно, это основная причина для чего нужна оценка времени — составить план работ на текущий список задач.
Боюсь, вы путаете приоритеты и оценку по времени.
Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».
Бывает что задача на 15 минут, но сделать её надо вотпрямщас, а бывает что месячный трип по мозгу заказчика задачи может быть в целом несрочным. Равно как и наоборот.
В любом случае оценивать мелочевку смысла не имеет — имеет смысл делать её сразу же пачкой.
А да, еще есть задачи-детонаторы, выполняемые например в режиме «сделать первую версию — а там посмотрим» и/или с пометкой «уточнить требования».
НЛО прилетело и опубликовало эту надпись здесь
Простите, но не верю. Если человек не может приблизительно оценить отдельно задачи А, Б и В, на чем основана его оценка «успею все три сегодня»?
На безудержном оптимизме разработчиков в своих оценках
Читайте Брукс «Мифический человеко-месяц».
НЛО прилетело и опубликовало эту надпись здесь
Везде эти оптимисты… И в скрамовском planning poker оптимисты насчет оценок, и в настоящем покере тоже оптимисты, у которых дырявый стрит из 3 карт обязательно соберется на ривере.
Настоящий покер — не тот пример.
В покере-то как раз в этом весь смысл (ну 50% смысла) игры.
Это же игра!
А если рассматривать покер с финансовой точки зрения — покер без блефа не даст вам превратить его в источник заработка, а навсегда останется всего лишь хобби (к слову, даже неинтересным хобби, ибо без блефа покер не покер).
А название planning poker отражает всего лишь юмор создателей, не стоит тащить в Scrum принципы покера из реальной жизни. Они всего лишь отдаленно похожи, не более того.
Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.
Например, мне надо подготовить 6 бумажек, которые я бы сделал за 3 часа + час запаса. Но так как начало года — это безумие, когда меня разрывают по телефону, а кто не дозванивается приходит лично — то я сделал эти бумажки в тот же день только потому что задержался на работе. Или делал бы их два дня.
То есть в среднем надо 4 часа, но реальность — это не сферический конь в вакууме.
… и как вам поможет оценка "успеешь к такому-то времени"?
(Но вообще, конечно, приведенная вами ситуация — классический пример несовпадения планируемых оценок с реальностью. Ну да, бывает. Не повод не планироваться вообще.)
и как вам поможет оценка «успеешь к такому-то времени»?
Обычно я представляю «внезапную» нагрузку неким средним числом по времени. Также очень помогает ориентироваться сколько человек сейчас в отделе и все ли работают полный день, чтобы делегировать некоторые работы другим.
Но вообще да, лучше взять в два раза больше времени чем требуется и сделать не торопясь, передохнуть и перепроверить, чем ограничить себя во времени заранее.
при этом ориентир «это требуется завтра после обеда», значительно понятнее, чем «данная работа займёт два часа». Причина — я не фрилансер и выполняю более чем одну задачу за день. В моём рабочем дне надо выделить два часа.
В моём рабочем дне надо выделить два часа.
Разве не в этом цель планирования?
Разве не в этом цель планирования?
Цель планирования в контексте обсуждения — это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу. Моя задача выполнять работу из моей должностной инструкции, в которой множество пунктов «следить, чтобы всё работало». Обратите внимание, я работаю по принципу первой части статьи.
Если у нас спор, то хочется узнать суть спора.
это менеджеру, который совсем не шарит в моей работе определится за какое время я выполню конкретную задачу.
Это не конечная цель. Конечная цель все же определиться успевает ли команда сделать скоуп работы, или что именно успевает сделать команда. Оценка от разработчика — это очень примерное число которое дает какое-то представление о временных затратах. Есть еще масса переменных которые влияют на конечный результат но как правило типичный менеджер (да и разработчики) их не учитывает.
А может цель изначально определить когда конкретный скоуп будет закончен?
Поскольку проект в большинстве случаев имеет какой-то фиксированный бюджет, нет гарантии что в этот бюджет уложится весь скоуп работ. Так что в этой ситуации нужно заблаговременно знать что примерно не успеют сделать разработчики. Именно по этой причине приоритезация задач важна, чтобы закидывать неважные задачи на конец разработки.
Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство), то тут уже скрамы не помогут ничем, поскольку будет все хорошо или нет уже зависит только от оценки данной на самом раннем этапе при выборе этого фиксированного скоупа/бюджета.
Если же у нас фиксированный бюджет и фиксированный скоуп (как делает наверное большинство)В момент когда так начинает делать ваше начальство — пора искать другую работу.
Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).
И дальше — уже неважно, какие умные слова вы на это вешаете…
В момент когда так начинает делать ваше начальство — пора искать другую работу.
Разработка тем и отличается от других видов деятельности, что так сделать — не получается. Вернее получается — но за счёт «выдавливания» из разработчиков всех соков (почти все проекты почти во всех областях выходят за рамки изначального бюджета — это просто факт).
Так говорят ленивые или глупые разработчики.
А умные придумывают оптимизации. И потом этими оптимизациями пользуются во всем мире.
RAD-development, фреймворки и т.п.
Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.
На самом деле в словах khim есть немалая доля истины. Я считаю что когда люди хотят скрамы и аджайлы но при этом проекты продаются как фикс прайс, это сразу ломает всю идею гибких методологий. Они просто не будут работать при таком раскладе.
Например фрейморк был придуман именно для того, чтобы поддерживать быструю разработку в крупном СМИ, где постоянные изменения.Там был скрам?
— Ну как продвигается спринт?
— Да никак, отстаньте, я фреймворк пилю. Через 2 месяца будет готов, тогда и полетим…
С фиксированным скоупом и бюджет есть, как минимум, вариант поиграть рейтами.
Это вопрос, скажем так, неочевидный. Я, прямо скажем, вообще не очень не понимаю, почему противопоставляется «сколько времени займет эта задача» и «к когда ты сделаешь эту задачу» — одно легко выводимо из другого.
У меня был один знакомый разработчик, которое сие сильно затрудняло.
Загадка быстро открылась: он делал «левую» работу и ему было проще в голове посчитать «до какого», чем «сколько займет».
Если на вопрос «сколько это займет времени?» я ещё хоть как-то могу прикинуть ответ в человеко-часах, то на вопрос «сколько ты успеешь к такому-то времени?» только один ответ: «не знаю, может я к этой задаче вообще не приступлю к такому-то времени».
Если на то пошло, то от этого и надо плясать, а не выдавливать из разработчиков человеко-часы, играя на их неспособности к адекватной оценке и риск-анализу за 5 минут в голове.
Все равно что пытаться выдавить из токаря на станке оценку того, сколько времени он будет точить одну болванку. Он не может сказать. Зато может сказать сколько болванок он сделает к следующему понедельнику, если вы прямо сейчас от него отлупитесь.
Пример с токорем не корректный.
Он их в день 100 штук точит, потому и не знает сколько уйдет на одну, тут ему больше подумать нужно, разделить арифметически.
А кто, кроме самого разработчика может сказать сколько времени ему нужно на конкретную задачу?
Было бы правильнее, чтобы это время ему сверху спускал CEO, что ли.
Проблема оценки сроков имеется только до уровня middle.
Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.
Ты не senior, если не знаешь, что любой оцененный тобой срок прежде чем озвучать, нужно умножить на 3.
Зависит от последствий этого озвучивания. Иногда лучше разделить на три.
Как говорил один мой знакомый — как раз — CEO — не умножай оценку. Ни на 2, ни на 3 — не спасет. И-таки да, в большинстве случаев не спасает.
Как говорил один мой знакомый — как раз — CEO — не умножай оценку.
С высоты 20 летнего опыта разработки скажу, что то был плохой CEO. Скорее жополиз начальства.
Или он имел ввиду другое: разработчик, сообщай мне исходные оценки, я сам умножу их на 3. То есть во избежание коэффициента 9 в итоге.
Правило об оптимистичности разработчиков в оценках известно уже 50 лет как.
Детально рассказано об этом из опыта разработки операционной системы в IBM.
Книга Брукса «Мифический человеко-месяц» — книга тоненькая, можно легко прочитать.
Что-то у вас слишком много времени «закладывается». Это ваше соотношение 80/20, 40/60, или даже 90/10 всегда будет таким для каждой задачи, или это всё-таки зависит (от погоды, от настроения разработчика, да хоть от магнитных бурь на Солнце)?
Вообще не проблема.
Для проверки какой-то серьезной гипотезы у нас менеджер проекта явным образом выделяет время.
Не только автоматически 10/20/30%, а еще и явным образом — «проверишь? да. когда результат? послезавтра скажу» — и все, человек официально занят делом, проверяет гипотезу.
Просто беседуйте с коллегами, с руководством, говорите, что вам нужно.
Они ваши мысли не читают.
Не все они являются специалистами в вашей сфере — иначе бы вас попросту не наняли бы.
Вас наняли в том числе и потому, чтобы вы, пользуясь вашими профессиональными знаниями (которых нет у других людей, которых нет у руководства), рассказывали что и где и как тут надо сделать.
Большие рефакторинги надо относить на отдельную стадию разработки и согласовывать с управленческим звеном/клиентами. Т.е. «пока нет срочных задач». Исследование фреймворков надо относить на отдельных людей вне команды работы над продуктом, а потом вливать эти знания обратно в команду через тех самых отдельных людей. Но это особая управленческая магия, которая многим не по зубам.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент. Внедряющий должен хорошо понимать границы его применимости для данной конкретной команды разработчиков и для данного проекта. И лично я не раз отмечал в отечественных компаниях отношение к методологии управления как к волшебной таблетке, которая может починить разом все огрехи проекта, превратить разработчиков в добрых паладинов, а заказчиков — в белых котяток, ну а бонусом прекратить войну на ближнем востоке и предотвратить кризисы капитализма. Очевидно, оно так не работает. Любая методология управления в любой компании де-факто гибридна и претерпевает множество поправок на объективную реальность, а то и вообще собрана из кусков разных методологий. Кто не умеет этого признавать — получает по голове в долгосрочной перспективе и обречен ходить по граблям.
А в остальном lair прав. Agile/Scrum тут ни при чем. Как раз процесс — это отвертка и инструмент.
Угу. Если процесс позиционируется как средство решения конкретных проблем, но в подавляющем большинстве случаев их не решает, а только усугубляет, то дело, конечно, в погоде на марсе, а не в процессе! Верующие в скрам, такие верующие…
проблемы автора в том как он следует своим процессам. Например процессы не регламентируют способ оценки или что должно в нее входить, это разработчики должны как-то сами для себя родить и следовать этому. Они же явно не закладывают в оценку кучу активностей и оттого страдают. Причем тут скрам?
В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея. Если бы это было так, никто бы не придумывал XP/FDD/Kanban. Но и говорить что скрам никогда не работает это уже другая крайность.
А что до решения проблем, обычно со всеми этими загонами по скрамам проблемы хорошо прячутся. Для того что бы лучше их выявлять и добавлять практики решающие конкретные проблемы еще до всех этих скрамов и модных линов была придумана теория ограничений.
В целом мыслить категориями "скарам всегда хорош просто вы не умеете его готовить" это тоже так себе идея.
Я понимаю, почему нельзя считать такой постулат догматом, но почему нельзя мыслить этими катерогиями?
Почему хотя бы нельзя задаться вопросом, "А скрам ли это?" "А правильно ли мы его готовим?"?
Если бы это было так, никто бы не придумывал XP/FDD/Kanban.
Может их придумали не потому, что скрам нехорош, а потому что он хорош, но можно лучше :)
Почему хотя бы нельзя задаться вопросом, «А скрам ли это?» «А правильно ли мы его готовим?»?
К нам пришёл ПМ и сказал: «Да будет скрам, а я будут продакт аунером и скрам-мастером.» И увидели мы, что скрам это плохо для нас. Что имеете в виду под скрамом вы — мы не знаем. То, что было у нас — практически совпадает с описанием на вики. Если вы считаете, что там неправильно, то поправьте, чтобы мы не называли скрамом, то, что было у нас.
Поверьте, если вы пытаетесь тапком забивать гвозди, а они не забиваются — то это ваша и только ваша вина.
Если на тапке написано — предназначен для забивания гвоздей, то виноват тапок и те религиозные фанатики, которые веруют и проповедуют, что тапок способен забивать гвозди, а те, у кого не получилось — сами виноваты. Даже несмотря на то, что тапком таки иногда можно забить гвоздь в неслишком замороженное сливочное масло. У вас отличная аналогия — спасибо!
Мне кажется, даже если тапок и вправду предназначен для забивания гвоздей, возможно в том числе и неправильное его применение. Как на кадрах 11 и 12.
Широко известный в узких кругах источнник
Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)
Я не агитирую за скрам, поверьте, нет. Я лишь говорю что скрам — это инструмент, все холивары вокруг которого рождаются от того, что натянуть его пытаются туда, куда он не налазиет. И делают это всегда конкретные люди, которые, видимо, не отличают тапок от молотка.
В то же время, я не исключаю что для некоторых инструментов множество случаев, где их можно успешно применить — пустое ;)
Ну у вас же своя голова на плечах есть? Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
Отчего же? Я — могу. Поэтому и считаю скрам антиаджайлом. А вот верующие не могут. Они считают, что если им удалось забить гвоздь тапком в масло, то им можно забивать и в бетонную стену, а если не получилось — ну, не тапок же виноват, в самом деле — значит у вас был "неправильный" скрам.
Вы же можете визуально отличить тапок от молотка, а масло от бетонной стены, верно?
В бетонную стену и молотком лучше гвозди не забивать…
Самое главное, скрам — это постоянный стресс.
Постоянный стресс свидетельствует о плохом планировании а никак не следствие какой-то методологии.
Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает.
Если разработчик не закладывает время на митинги, попить кофе, подумать… то он сам себе злой буратино. Есть еще риски которые тоже имеет смысл закладывать.
В целом неспроста многие оценивают все это добро в относительных единицах измерения (стори поинты, t-shirt sizes и т.д.) что бы уйти от времени и упростить оценку. Лично мне больше всего нравится t-shirt sizes (small, medium, large, xlarge, etc) на основе которого оценивается сложность. А сколько это займет по времени — это уже менеджер может из джирки посчитать (если задачи нормально дробятся).
Далее, тут отмечают, что большие рефакторинги и исследования новых фреймворков нужно выносить в задачи, обосновывая это погашением технического долга. Но я не знаю, как оно пойдёт!
Закладывайте просто 20% времени на погашение технического долга. Не хватает — 30%. Больше — тогда есть вопрос что вы там устраняете. Возможно те рефакторинги которые вы делаете просто не нужны. Разработчики очень часто болеют подобным.
Вся магия в этом — может, я за 1.5 часа перелопачу 250 файлов, а может завязну на 2 дня
Подобные волшебные рефакторинги допускаются только если у вас система покрыта автотестами на 100% иначе шанс схлопотать регрессию заоблочный. Вы не сможете руками все проверить. И опять же очень большой вопрос почему у вас возникает необходимость в таких рефакторингах. Есть задачи которые затрагивают все 250 файлов? Сильно в этом сомневаюсь. Чаще всего разработчику просто хочется пострадать перфекционизмом.
Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками
Разговоры/митинги закладываются в оценку. И все становится чуть проще.
p.s. Есть еще очень крутая штука для оптимизации процессов — теория ограничений называется.
Самое главное, скрам — это постоянный стресс. Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Второе — нет времени остановиться и посмотреть/подумать. Мне нравится исследовать логи, находить в них закономерности, проходить под отладчиком сложные места и убеждаться, что всё идёт правильно и ничего не сломалось, даже если никто не жалуется. Это даёт понимание, куда развивать проект, где были применены сильные и слабые решения. А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Читайте классику: Брукс «Мифический человеко-месяц».
И просто оценивайте проект с коэффициентом 3.
Тогда у Вас будет время на логи.
;)
А если вдруг машина призадумывается, то это повод рассмотреть этот момент поближе. Но такой перерывчик может затянуться часа на 2-4, а что я завтра на утреннем митинге скажу, что ворон считал?
Вы не «Вася вышел в поле погулять да ворон посчитать», а "инженер по разработке программного обеспечения".
И ваша задача — все это учитывать, вас для этого и наняли. Потому оклады разработчикам нынче и существенно выше средних зарплат в других профессиях.
Тут ещё упоминали, что нужно 20% времени оставлять свободным, не загружать людей на 100%. Скажу, что этот мизер легко съедается разговорами с теми же бизнес-аналитиками («ты в прошлом спринте сделал доработку, что-то я не могу её проверить, покажи, как её пользоваться»), помощью коллегам и прочей текучкой.
Когда хотят 20% рабочего времени в танчики играть да в контактике шариться, то забывают упомянуть, что это взято по примеру Google:
1. А у них изначально высококвалифицированнейшие специалисты работают.
2. У Google есть финансовая подушка.
Мы проводили этот эксперимент.
Львинная доля сотрудников восприняла 20% как возможность заниматься совсем уж не относящимися к делу вещами. Да, да, да — танчики и вконтактик.
Только самые высококвалифицированные и высокооплачиваемые у нас поняли все правильно. И развивали себя и наш проект и родственное ПО.
Разработчик сам оценил задачи (допустим, он это делает честно), и сам пообещал, что к концу спринта он их все сделает. Это давление собственного обещания можно выдержать неделю, месяц, но жить под ним годами тяжело.
Вы путаете, в SCRUM'е нет понятия commitment, в нем есть понятие прогноз. Т.е. возможно задача будет сделана, возможно и нет. При этом это не проблема если какая-то задача не войдёт в спринт или «вывалится» из него.
Основная проблема в данном топике, а точнее их две:
1. Это куча stakeholder'ов, которые переросли в Product Owner'ов, коих как раз должен быть один и только один(!).
2. Итальянская забастовка, устроенная разработчиками.
при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача. Возможно в данном вопросе я и не прав, но походу скрам мастера у них не было или работал он через ректум, бо подобные вопросы с менеджментом должен утрясать именно он.
Особенности… э, ну, никакие, Кроме того, что какая-то методология все-таки была изначально, пусть и не была нигде формализована, но работала, и ее изменение (без какого-то реального обоснования) на «перспективную», а прямо сказать — на «модную» и вызвало то что вызвало.
Т.е. буквально — да, Agile тут не при чем. А фактически — очень даже.
Т.е. буквально — да, Agile тут не при чем. А фактически — очень даже.
А теперь представьте, что старую методологию заменили не на Agile, а просто на строгое формальное планирование (я как раз комментарием выше его описал). Что-то изменится в посте? Думаю, нет.
Так что "при чем" тут не Agile, а (неумело сделанное) планирование.
Ну в общем да. Фактически тоже самое наверное было бы при попытке внедрить любую другую методологию.
Я собственно с этим и не спорил — наоборот. Проблема как правило не в методологиях, а в том, что внедряют их управленцы, которые а) сами давно забыли (если вообще умели) разрабатывать б) хотят в конечном счете обычно понятно чего — выжать из разработчиков побольше, заплатить поменьше.
И очень редко, если вообще когда-либо понимают, что эффективнее работают довольные работой люди.
Я собственно с этим и не спорил — наоборот. Проблема как правило не в методологиях, а в том, что внедряют их управленцы, которые а) сами давно забыли (если вообще умели) разрабатывать б) хотят в конечном счете обычно понятно чего — выжать из разработчиков побольше, заплатить поменьше.
И очень редко, если вообще когда-либо понимают, что эффективнее работают довольные работой люди.
Впрочем, я видел примеры когда пытаются внедрить Agile разработчики. В этом случае — в 100% потому что «модно» (даже если на самом деле уже и не так). Результаты в этом случае почему-то тоже плачевные.
… вот и выходит — что Agile/Scrum тут ни при чем. И пост не про "обратную сторону Agile", а про (обратную ли?) сторону плохого руководства.
Agile при том, что в данной реальной истории внедряли именно его. И автор, на мой взгляд отлично проанализировал последствия этого «внедрения».
Вы считаете, что если бы те же люди внедряли другой процесс (скажем, CMMI), ситуация была бы радикально другой?
В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?
На мой взгляд, проблема в другом — не в конкретной методологии, а с переходом компании из состояния «джентльмен джентльмену верит на слово» и «мы тут кучка энтузиастов, работающих на одно большое дело» к состоянию «мы — солидная компания, народу много, кто чем занимается — с кондачка не ухватишь, уровней управления много — надо больше правил и отчетности».
Это вполне обычный шаг в развитии компании от небольшой к крупной.
И многим людям, кто вполне нормально и радостно жил в обычной среде «Серега, надо срочно впендюрить вот такую загогулину» — и Серега хватал загогулину без постановки задачи в трекере и начинал ее впендюривать, в бюрократизированной среде стало тоскливо — пространства для маневра нет, героизм твой никто не оценит, менеджеры бодаются, а у программистов чубы трещат. Потому и двинули.
Не конкретная методология виновата, а стадия развития компании.
На мой взгляд, проблема в другом — не в конкретной методологии, а с переходом компании из состояния «джентльмен джентльмену верит на слово» и «мы тут кучка энтузиастов, работающих на одно большое дело» к состоянию «мы — солидная компания, народу много, кто чем занимается — с кондачка не ухватишь, уровней управления много — надо больше правил и отчетности».
Это вполне обычный шаг в развитии компании от небольшой к крупной.
И многим людям, кто вполне нормально и радостно жил в обычной среде «Серега, надо срочно впендюрить вот такую загогулину» — и Серега хватал загогулину без постановки задачи в трекере и начинал ее впендюривать, в бюрократизированной среде стало тоскливо — пространства для маневра нет, героизм твой никто не оценит, менеджеры бодаются, а у программистов чубы трещат. Потому и двинули.
Не конкретная методология виновата, а стадия развития компании.
В то же самое время там упомянут и переход с Symfony 2.6 на Symfony 3.0. Может, если бы не переходили, ничего подобного не случилось бы? Может, это — причина бед?
Переход в целом мягче чем переход между Ubuntu 14.04 и 16.04 на которых Symfony крутится. Проблемы с BC конечно были и есть, но в принципе ничего такого, чтобы сорвать работу целого отдела надолго.
После прочтения та же мысль. Проблема не в фреймворка, а в менеджменте в целом. Не просчитали риски изменений. Ну и логирование времени совершенно обычная практика для аутсерса. Странно что это вызвало такой коллапс в отделе. А в серами вообще нет времени, есть только SP, которые про сложность задач. Оценка в часах и привязка к 40 часам в рабочей неделе от бизнеса.
Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.
И можно возобновить дискуссию о том, что управленец обязан разбираться в том, чем управляет и при необходимости заменить того, кем управляет.
Перефразирую, сегодня в фаворе не безкорыстные творческие созидающие личности, а подхалимы, показушники и вот грустно… каков итог этого процесса?
Перефразирую, сегодня в фаворе не безкорыстные творческие созидающие личности, а подхалимы, показушники и вот грустно… каков итог этого процесса?
Сказано же: «Задачам стали присваивать приоритеты»
Если менеджер сам не знает и при этом не консультируется у разработчика как надо разрабатывать, то какого качества от него приоритеты будут приходить?
Конечно будут ставить наименьший приоритет всем задачам сопровождения — обновлению библиотек и фреймворков, рефакторинг, исследование киллер-фичи и т.д.
Вменяемые разработчики или будут отстаивать свою позицию (но недолго) или уйдут.
Останутся те, которые уйти не могут/не хотят и те, которым наплевать на задачи сопровождения.
И да, никакого отношения к Agile это не имеет.
Если менеджер сам не знает и при этом не консультируется у разработчика как надо разрабатывать, то какого качества от него приоритеты будут приходить?
Конечно будут ставить наименьший приоритет всем задачам сопровождения — обновлению библиотек и фреймворков, рефакторинг, исследование киллер-фичи и т.д.
Вменяемые разработчики или будут отстаивать свою позицию (но недолго) или уйдут.
Останутся те, которые уйти не могут/не хотят и те, которым наплевать на задачи сопровождения.
И да, никакого отношения к Agile это не имеет.
Ну, понимаете, отношения-то не имеет, и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они. При этом как резонно отмечено уже я нескольких комментах — ничего не понимая в том, чем управляют.
и менеджеров в Agile вроде как не предусмотрено — но вся беда в том, что внедряют-то зачастую именно они
Есть Product Owner, с ОБЯЗАННОСТЬЮ сформировать backlog спринта.
Этого более чем достаточно. Если он не в состоянии этого сделать, то утопить такого менеджера, что бы не мучался…
Команда, в данном случае, выступает как инструмент оценки для product owner-а
Соглашусь, что я вижу в данном случае больше проблему со стороны внедренцев и менеждеров, от себя добавлю, что устроив срач они полностью убили внутреннюю атмосферу, хотя изначально надо было приходить, смотреть как оно работает и по чуть-чуть что-либо менять и за каждым изменением наблюдать, какое оно дает результат.
Скорее беда в тех кто этих менеджеров набирал. Обычная, в общем то история. Нанимается некий специалист из числа узнанных на конференции с жаром рассказывающий как он внедрял и какую выгоду получила компания. Тот не имея представления о истории и сложившейся внутренней культуре компании начинает «роботизировать» рабочий процесс.
В этой истории смущает одно. Если компания формировалась с уровня стартапа, то почему внедрение системы шло без участия разработчиков. Откуда взялся такой упёртый и оторванный топ-менеджмент.
В этой истории смущает одно. Если компания формировалась с уровня стартапа, то почему внедрение системы шло без участия разработчиков. Откуда взялся такой упёртый и оторванный топ-менеджмент.
Вот блин на все 100% согласен, особенно при том, что Scrum подразумевает то, что в процесс разработки менеджмент вообще не должен лезть к разработчикам, для этого есть скраммастер, а это вообще специфическая должность, поскольку он должен с одно стороны пинать разработчиков с другой зад им подтирать, и это только малая доля идеологии Scrum. А получается так, что повесили доску со стикирами и стали каждый день пинать программистов и обозвали это все модным словом.
Проблема не нова и типична. Беда не в скраме, а в набранных с улицы менеджерах. Которые, естественно, стали выяснять отношения кто тут главный методом запрягания разработчиков. Ведь оценка менеджера в глазах начальства — это именно количество выполенных с подачи данного менеджера «фич». Больше фич — выше менеджер в иерархии, и побоку на их срочность/важность.
Вот не нужно считать все подряд начальство полными идиотами. Не, наемный менеджер, руководящий другим наемным менеджером может быть и таким запросто.
Но реально заинтересованное лицо (владелец-управлящий) или просто компетентный менеджер прекрасно понимает что «все в этом мире что-то стоит».
Давайте я вам пример попроще продемонстрирую:
Менеджеры-продажники должны продавать.
Им разрешается продавать в кредит.
Круче тот, кто больше продал? Да. Но факт продажи проверяется не про отданным покупателям без денег в кредит товарам, а по реально полученным от покупателей деньгам.
Так же и здесь:
Зачем, думаете, все эти часы считаются? Только чтобы разработчиков в зарплатах урезать?
Нет, в том числе и чтобы оценивать себестоимость.
Чтобы было видно и в том числе такую вещь как: менеджер протолкнул 100500 фич принесших 1 млн. долларов, но стоивших в разработке при этом 2 млн. долларов. А другой менеджер протолкнул фич на 500 000 при себестоимости разработки фич в 300 000.
Кто из этих менеджеров полезнее для фирмы?
Менеджеров с дурной инициативой — прекрасно и быстро увольняют/понижают. Видел неоднократно.
Скрам даже слова такого не знает «менеджер».
Заголовок про скрам и аджайл, в тексте про:
Понимаю, обидненько. Только процессы тут не при чем.
Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.
Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
А это напрямую противоречит вашему утверждению.
Так может быть, проблема не в аджайле, а во внедренцах?
P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка.
Понимаю, обидненько. Только процессы тут не при чем.
почасовой отчет по времени оставлял привкус того, что за твоей спиной непрерывно кто-то стоит и наблюдает, как ты нажимаешь кнопки.
Вообще никакого отношения к agile не имеет. Аджайл учит менеджеров очень трепетно и бережно относиться к эстимейтам разработчиков и ни в коем случае не считать их последним дедлайном.
Единственный срок который есть — конец спринта, который должен закончиться поставкой работающего функционала. И то, это только значит, что к концу спринта продукт должен получить позитивные изменения. Это не значит, что все задачи обязаны быть в Done.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Во первых, нет вещей и задач, которые не могут быть завернуты в UserStory. Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
Во вторых, если вы откроете agilemanifesto.org вы во втором же абзаце увидите, что
Individuals and interactions over processes and tools
А это напрямую противоречит вашему утверждению.
Так может быть, проблема не в аджайле, а во внедренцах?
P.S. Наконец-то хоть кто-то упомянул TargetProccess, который лично мной нежно любим и почитаем, как один из наиболее удобных таск-менеджмент систем.
Просто источником этих юзерстори может быть не только стейкхолдер, но и сама команда.
То есть обновить фреймоворк это считается за юзер-стори?
нет вещей и задач, которые не могут быть завернуты в UserStory
А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.
«То есть обновить фреймоворк это считается за юзер-стори?»
Я, как эксплуататор/разработчик, делаю *pm outdated в корне и вижу всё зеленое :)
Я, как эксплуататор/разработчик, делаю *pm outdated в корне и вижу всё зеленое :)
А я наблюдаю, как PO считают за юзер-стори только видимый пользователю функционал. Если таска не начинается с слов «Я как пользователь хочу ...», то это не юзер-стори. Добавить поле ввода и кнопку, которые затрагивают всё, от БД до UI становится юзер-стори только из-за UI, а все слои ниже, это вам технические задачи, которые как бы не совсем юзер-стори.
Есть такая штука, как «декомпозиция задач». И есть рекомендация «делать задачи короткими». Из практики 8...24 часа, иначе просто теряется контроль.
Если команда разработки нарежет/декомпозирует UserStory «Все Хорошо» на перечень измеримых и вменяемых задач — значит так надо. Согласен менеджер с этим подходом или нет — это только проблема менеджера.
Согласен менеджер с этим подходом или нет — это только проблема менеджера.Объясните менеджеру что происходит на понятном ему языке — и проблема станет проще.
Пример. Приходите вы в автосалон, приносите лампочу фиолетового цвета и говорите «хочу чтобы фары так светили».
Не проблема — получаете счёт на $100500. Датализация примерно такая:
1. Демонтаж двигателя.
2. Сьём бампера.
3. Замена лампочики ($0.05).
4. Установка бампера на место.
5. Монтаж двигателя.
6. Юстировка колёс.
Дальше — можно обсуждать почему так получилось, что вместо одного пункта «3», который хотел увидеть заказчик у нас появилось вот это вот всё и почему лампочку можно сменить только сняв бампер, а снять его можно только демонтировав двигатель… Но главный-то вопрос: делать будем или нет?
И также можно показать «на пальцах» что такое «рефакторинг» и зачем он нужен: ну дырки мы в бампере в других местах просверлим и вот тогда замена лампочки будет $0.05. Но для этого нам нужно этот бампер снять, то есть демонтировать двигатель и т.п.
Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы.
Ваша задача — правдиво оценить «масштаб бедствия».
P.S. Кстати предложение «дяди Васи» сделать всё за пять минут и один доллар также можно вписать в эту модель: он просто фару отвёрткой расковырять предлагает и вытащить из ниши. То, что потом фары могут вывалиться в момент остановки — его не волнует. Мы так тоже можем — но… под вашу ответственность.
Так что любая UserStory «уходит корнями» в то, что видит пользователь. Любая. А вот размер у них может быть совсем не таким, как того хотят менеджеры, но вот это вот — уже таки их проблемы
Это навык менджера «считать косты». Если они игнорирует этот этап, или ему не нравится «счет» — уволить его нафиг.
Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5. А тут… Ну и начинается вышеописанное.
После нескольких подходов «дяди Васи» (который ведь ещё и премии получит) желание работать дальше над этой системой того… улетучивается.
После нескольких подходов «дяди Васи» (который ведь ещё и премии получит) желание работать дальше над этой системой того… улетучивается.
Менеджеры ведь тоже не идиоты. Они же уже подписались на замену лампочки за $5.
Это как раз и есть «идиоты за 5$». За чей счет банкет, если ценник 50$? За счет разработчика? Компании?
Подписался за 5, а стоит 50? Ну так выплати из своего кармана остальные 45 :)
А что бы такого не было, и прописали процессы типа «мойте руки после туалета....», что бы не было "… а то
Единственный срок который есть — конец спринта
Конец спринта не должен восприниматься как дедлайн. Это метка в календаре и не более. Если вы завалили очередной спринт, просто берете меньше работы. Первые пару спринтов полюбому завалятся пока мы команду формируем. Причем даже если команда уже сработанная для каждого проекта все по новому может быть.
Не совсем. В качестве результатов каждого спринта ожидается положительный прирост функциональности приложения. Это, в общем-то, довольно прямым текстом задекларировано.
Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).
Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).
Поправка: не в продакшене, а в продакшене и готовое к нему.
Увольте скрам-мастера, в скраме нет времени на выполнение задач, там оно заменено на story points.
В конечном-то итоге в спринт можно набрать Х story-points, положить длину спринта в Y дней и получить размер:
1 story point = Y / X.
Но в описании методологии времени нет, это да, и story point — сложность элементарной задачи. Однако, кому какое дело :)
1 story point = Y / X.
Но в описании методологии времени нет, это да, и story point — сложность элементарной задачи. Однако, кому какое дело :)
Такое, во первых, можно использовать, когда есть только один разработчик. Потому, как время выполнения задачи у разных разработчиков будет разным. В пределе в десятки раз. Во вторых, мы рассчитаем понятие средней продолжительности SP команды, которая будет плавать из спринта в спринт с отклонением в пару-тройку размеров средней продолжительности SP ))). Т.е. сказать что мы запланировали на спринт 21 SP со средней продолжительностью 3 часов каждая, итого 63 часа, а по сути от 40 до 180 часов.
По сути SP является нефизическим вознаграждением команды. Т.е. на ретроспективе можно поздравить команду и сказать, что по SP мы повысили производительность по сравнению с прошлым спринтом, в 2 раза. Ну или наоборот.
По сути SP является нефизическим вознаграждением команды. Т.е. на ретроспективе можно поздравить команду и сказать, что по SP мы повысили производительность по сравнению с прошлым спринтом, в 2 раза. Ну или наоборот.
Нет, теоретический коэффициент 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
Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
Это важная и нужная метрика, позволяющая более-менее нормально планировать работу в команде.
Другое дело, что этот коэффициент всегда динамичен и меняется от спринта к спринту.
Цель команды — выдать максимум SP в продакшен к концу спринта без овертаймов, стресса и баттхёртов. Цель «менеджмента» и процессов — создать условия для этого роста производительности.
Например, если выполнение 1 SP у команды занимает с каждым спринтом всё больше времени, то тут есть ряд возможных причин:
1) Калибруется оценка задач в SP и «элементарная задача», являющаяся одним сторипоинтом, разрастается.
2) Мотивация команды падает и работают медленнее.
3) Накапливается легаси и костыли и внесение даже простых правок начинает занимать больше времени.
4-999) ещё много возможных причин.
Для анализа этих причин есть ретроспектива, как и для анализа того, что в текущем спринте позволило нам сделать больше SP, чем в предыдущем.
Есть ещё более сложные сценарии, типа SP/day у команды растёт, а у конкретного человека падает. Это может быть потому, что он задолбался, а остальные фигачат за него. А может быть потому, что он стал больше времени тратить на саппорт коллегам, ревью и прочие не функциональные задачи.
Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
Но, прежде чем внедрять трекинг времени, нужно чётко и ясно донести до команды зачем это делается. Что бы все (включая «менеджеров») понимали, что это делается не для того, что бы посмотреть что ты делал 8 часов рабочего дня (не дай бог читал хабр), и не для того, что бы потом кого-нибудь уволить «потому что слишком мало сторипоинтов делаешь». А для того, что бы более комфортно _для команды_ планировать объем спринтов.
При этом для этих целей:
1) Вполне допустима определенная «погрешность» в оценке затраченного времени. Точность до часов тут нафиг не сдалась. Т.е. шкала оценок «1 час — 4 часа — 1 день — 3 дня — неделя» вполне ясно дает понять ситуацию.
2) Ни в коем случае не намекает нерадивым менеджерам, что разработчик обязательно должен натрекать 40 часов в неделю на задачи, и не дай бог он там хабр читал. Это простое самодурство и синдром вахтёра, аджайл тут ни при чём.
TLDR
Временные «оценки» в аджайле всё равно есть, просто используются они совсем по другому, нежели в случае автора.
Подсчёт SP\day, безусловно, требует от разработчиков как-то трекать время (а мы с вами знаем, что никто не любит трекать время).
Зачем? Есть спринт 2 недели, команда из 4 человек сделала за спринт задач на 90 СП, лид — 20, синьйор — 30, мидл — 25, джун — 15.
SP\day = 9 у команды, синьйор не очень убежал от мидла из-за того, что делает значительно качественнее, а лид загружен коммуникацией и обучением джуна.
Где тут трекинг времени?)
Затем, что это так работает только если предположить, что команда делает только запланированные задачи.
Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
2) То, что я описывал выше.
Не отвлекаясь на багфиксы продакшена, сторонние задачи, вопросы поступающие из вне и прочие неспринтовые таски. Да банальным «релиз не раскатывался».
А такие задачи почти всегда есть, их количество неконстантно, а время на них потраченное может варьироваться очень сильно и непрогнозируемо. Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Таким образом проще потрекать грубые трудозатраты на спринтовые задачи и получить примерное понимание сразу двух вещей:
1) Сколько времени в спринте (и какой объем) отжирается незапланированными задачами (а это тоже история, над которой надо работать).
2) То, что я описывал выше.
Вообще это и есть задача ретроспективы. За спринт сделали 60, а не 90, как обычно? Почему? Было много багфиксов? Как можно уменьшить количество багфиксов? Трекать стоит только незапланированные задачи и то — достаточно на доверии к программисту:
— Как думаешь, почему твоя эффективность в СП в этом спринте вдвое меньше?
— Всунули 5 багофиксов, один из которых съел 2 дня, было 3 двухчасовых митинга и ещё полдня котенка для дочки директора рисовал.
Но обычно количество таких задач стабильно и отражается соответствующе на стори-поинтах. Повысили качество кода, ввели код-ревью, лучше протестировали, как результат — меньше багофиксов в след спринте и +10 сп производительности.
— Как думаешь, почему твоя эффективность в СП в этом спринте вдвое меньше?
— Всунули 5 багофиксов, один из которых съел 2 дня, было 3 двухчасовых митинга и ещё полдня котенка для дочки директора рисовал.
Но обычно количество таких задач стабильно и отражается соответствующе на стори-поинтах. Повысили качество кода, ввели код-ревью, лучше протестировали, как результат — меньше багофиксов в след спринте и +10 сп производительности.
По-хорошему должно закладываться сколько-то процентов времени под то, что обязательно впихнут какой-нить багофикс или еще чего.
Т.е. если у вас в неделе условно 10sp, то задач планируется на 8sp, с учетом того что обязательно что-то пойдет не так. Во время ретроспективы эти проценты если надо корректируются.
Т.е. если у вас в неделе условно 10sp, то задач планируется на 8sp, с учетом того что обязательно что-то пойдет не так. Во время ретроспективы эти проценты если надо корректируются.
Вы предлагаете постфактум разбирать, почему успели меньше, чем запланировали.
Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.
Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.
Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.
Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.
Т.е. включать их в «сделано за спринт» — малополезно и ломает всю картину.
Как по мне, то наоборот их надо включать в спринт по мере возникновения, чтобы как раз получать реальную картину: «сделано за спринт 90 SP из запланированных 100SP, из них 50 SP запланированных в начале спринта задач, 20 SP — внезапно вытащенных из бэклога новых, 20 SP — технических задач типа багфиксов»
Есть разные мнения на этот счёт.
По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
Это значительно упрощает всем жизнь, на мой взгляд.
В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
Это значительно упрощает всем жизнь, на мой взгляд.
В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
Я по скраму работал мало, но когда 9-10 лет назад его вводили там где я работал, то объясняли, что story points не прямо пропорционально времени. У нас использовались, кажется, первые 7 простых чисел. Хотя могу ошибаться, давно было.
Как считать трудозатраты в элементарных задачах? Что вообще считать элементарной задачей? Как сравнить две задачи на элементарность?
О, интересную тему подняли.
Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.
Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
Когда я столкнулся с такой задачей — то набросал на WPF дивный инструмент для разбиения проекта на подзадачи (Work Breakdown Structure это называется в некоторых источниках), которым бил целые проекты на задачи вплоть до «добавить такой-то файл» (попутно я собирал потихоньку собственную «библиотеку элементарных задач» с хорошо известными оценками), которые оценивались PERT-ом с точностью до 10 минут.
В итоге получался excel-файл на потеху заказчику, в котором содержалось 400-600 мелких задач, складывающихся в недели и месяцы разработки. С таковым заказчику очень трудно аргументированно спорить, но оценка на сферическую в вакууме разработку получается дюже точной (в рамках оценок точности PERT-а), да и детальный план что делать — вот он вот. Хоть в JIRA выливай. Бонусом идет проектирование на ранних этапах.
Как водится, у подобного подхода есть одна сложность — это ж надо сидеть и работать. Оценка делается напряженным умственным трудом группы людей на протяжении 2-3 дней. А менеджер работать не любит. Менеджер, как правило, поговорить любит.
Себя увольте. Нет в скраме никаких стори поинтс, потому как в скраме вообще элементы бэклога/спринтлога могут быть вовсе не в формате User Story описаны.
В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
В скрам гайде написано, что должна быть оценка, а в чём — как обычно на усмотрение команды, будь то юзер стори, человеко-часы или попугаи. Другое дело, что на каждом углу все скрам-евангелисты всячески рекомендуют не прибегать к использованию человеко-часов, но нигде жёстких правил что конкретно должно использовать нет, если это конечно не внутренние правила скрам-команды.
Если вы запутались в трех ролях Scrum, страшно даже подумать, что бы было, если бы вы попытались примерить что-нибудь типа RUP, с его тремя десятками ролей. Там-то действительно предписывается с десяток менеджеров.
Рефлектируйте дальше, это полезно :)
Рефлектируйте дальше, это полезно :)
Проблема в менеджерах, а не аджайле, как собственно и сказали практически в каждом комментарии. Оценивать работу нужно в стори поинтах, всячески избегая их привязки к реальному времени. Т.е. они нужны только для относительной оценки юзер стори — «А сложнее/проще Б» — не более. Другими словами, А (2 стори поинта) не в десять раз сложнее Б (20 стори поинтов), а просто сложнее. Если руководство упорно привязывается к цифрам, можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды. Очень опасны сравнительные графики производительности команд в стори поинтах, так как одни могут оценивать задачи как 1-2-3-.., а другие 100-1000-10000, но это совсем не значит, что задачи второй команды серьезнее — просто им так комфортнее и нагляднее… Без подготовленного менеджемта, аджайл неминуемо превращается в цирк.
На пару комментов выше уже ответил на эту тему, не совсем с вами согласен.
Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.
Стори поинты, в итоге, всё равно привязываются к реальному времени, потому что так или иначе производительность мерить придётся. Любая система оценок, будь это часы, поинты, майки или попугаи всё равно придет к этому, потому что есть такая потребность.
Другое дело, что итоговое сведение поинтов в часы весьма приблизительное, несет характер «прогноза», а не клятвы на крови младенцев, и должно использоваться только как внутренний инструмент планирования в команде, а не как инструмент для давления на команду или охоты на медленно программирующих ведьм.
Ну фраза «производительность мерить придется» звучит, конечно красиво… Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе. Любое давление (а этом может быть просто табличка «Команда-количество стори поинтов» на кухне) приведет к удушению всех возможных бонусов в зародыше. Например, если изначально производительность команды привязывается к стори поинтам, разработчики просто начнут завышать оценки («Раскидаем по ходу дела»), чтобы сдержать это, придется ограничить максимальное количество поинтов на спринт, но тогда можно просто брать этот максимум и делить на количество юзер стори, а тогда зачем вообще тратить время на планирование…
Производительность команды — это то, сколько изменений в системе команда успевает делать за спринт.
Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
Эти вещи по умолчанию связаны. Их нельзя «развязать».
Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.
По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.
2) Он считает, что продукт овнер ему враг и опасается, что если назовет реальную оценку — его потом вздрючат в случае чего. Аджайл так не работает, да и вообще работать в коллективах с такими настроениями вредно для психического здоровья.
Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
Количество стори поинтов в задаче — абстрактная оценка объема изменений в системе, необходимых для реализации задачи.
Эти вещи по умолчанию связаны. Их нельзя «развязать».
Как мерить — вполне понятно. Есть коэффициент команды — N поинтов за спринт. Он меняется от спринта к спринту. Может меняться по естественным причинам, может по искусственным. Отфильтровать одно от другого довольно просто и это, в том числе, отлично делается на ретро.
Цели сделать так, что бы 1 стори поинт был равент 1 человекочасу нет и не должно быть. Цель — понимать, какой (примерный) объем изменений в систему может быть внесен командой за время спринта.
И для того, что бы это сделать — совсем не нужно отказываться ни от оценок, ни от приведения чего-то к чему-то.
Нужно, что бы все участники процесса (разработчики, продукт овнер, стейкхолдеры) хорошо понимали, зачем и почему оценка дается и зачем эта производительность мерить. Нужно понимать, что оценка это не инструмент для того, что бы потом потыкать человека носом «атата, ты не успел».
Это инструмент для того, что бы взять команда могла сказать «вот это мы успеем сделать за спринт, а вот это уже вряд ли — слишком большой объем изменений, больше — не получится, сорян».
Давление — не результат перевода поинтов в часы и не вина таблички на кухне. Давление — результат атмосферы в компании и напряженности отношений.
По поводу «разработчики начнут завышать оценки». Есть два сценария, когда это имеет смысл для разработчика.
1) Он видит большое количество потенциальных рисков и закладывает «буффер». Это имеет смысл, хотя следует объяснить разработчикам что это лучше делать в рамках всего спринта, а не в рамках конкретных задач. Типа «Ребята, мы вот в прошлом спринте успели сделать 120 сторипоинтов. Поэтому в этом спринте берем продуктовых задач на 70, ещё 30 на технический долг, а 20 — буффер на всякие риски».
Команда говорит «не, рисков дофига, давай 40 на риски заложим потому что интеграции много и вообще ад». На этом сошлись и всем хорошо.
2) Он считает, что продукт овнер ему враг и опасается, что если назовет реальную оценку — его потом вздрючат в случае чего. Аджайл так не работает, да и вообще работать в коллективах с такими настроениями вредно для психического здоровья.
Ну, и в обоих случаях завышение оценок повредит оценки производительности только если разработчики будут с каждым спринтом оценивать одинаковые по сложности задачи всё более объемно. Т.е. типовой CRUD в первом спринте был 3 поинта, во втором — 6, в третьем — 12.
В итоге коэффициент «производительности» будет постоянно расти (т.к. команда успевает делать всё больше поинтов из-за того, что задачи «переоценены») и это отлично разбирается на ретроспективе с объяснением «почему так делать ненадо».
Собственно аджайл — это еще способ переложить заботу о пересчете стори пойнтов в календарные дни из голов разработчиков в голову product owner. И он же должен изолировать команду от внешнего давления. За то ему и деньги платят (причем обычно больше, чем разработчикам). В описанном случае product owner толи отсутствовал вообще, толи провалил свою работу целиком и полностью. И да, скрам мастера тоже не надо по объявлению набирать. Если он видит, что такой трэш происходит и ничего не делает — ему не грош цена, а меньше. В описанном случае у него отрицательная стоимость.
Так что в описанном случае аджайла как такового вообще не было. Был довольно стандарный провал в управлении компанией в фазе превращения из стартапа во взрослый бизнес. Не они первые, ни они последние с такими проблемами.
Следующий вопрос к менеджменту компании — смогут ли они переломить ситуацию, так или иначе наладить работу по-новой и спасти бизнес, либо бизнес скатится в обычное УГ, покоптит небо еще какое-то время и развалится.
Так что в описанном случае аджайла как такового вообще не было. Был довольно стандарный провал в управлении компанией в фазе превращения из стартапа во взрослый бизнес. Не они первые, ни они последние с такими проблемами.
Следующий вопрос к менеджменту компании — смогут ли они переломить ситуацию, так или иначе наладить работу по-новой и спасти бизнес, либо бизнес скатится в обычное УГ, покоптит небо еще какое-то время и развалится.
Да только как мерить — непонятно. В идеале со временем аджайл позволяет приблизить стори поинты к реальным человекочасам. Но для этого нужен полный отказ от подобной привязки на начальном этапе
Ну так если начали вводить методологию — для этого были предпосылки, например отсутствие возможности планирования. А если такая возможность отсутствует, то нету никакого шанса родить её за две недели. Хоть вы заставите программиста в минутах все оценить и подписать кровью — это из разряда написать себе в штаны чтобы согреться.
можно от них вовсе отказаться, перейдя к чему-то более абстрактному типа размеров одежды
когда команде было сложно перейти от оценки времени к новой системе мы использовали такие стори-поинты:
— задача элементарная
— задача легкая
— задача средняя
— задача тяжелая
— задача очень тяжелая
А менеджер уже приводил эти к значениям 2-3-5-8-13 или как там ему необходимо для своих менеджерских дел.
Боюсь у нас та же проблема, ввели недавно agile и много ключевых людей поуходило, хорошо что не все, а то бы конец. Правда у нас не так всё печально, отчёты надо писать только раз в день и немного больше свободы дают по времени, но т.к. мы работаем с железом то тут всё не просто, потому что железо по умолчанию непредсказуемо.
Проблемы внедрения Скрама хорошо разобраны в книге Майкла Кона "Succeeding with Agile: Software Development Using Scrum"
В том числе и трансфер ролей там разобран.
Уважаемый Keks650, боюсь проблема компании не в самом Скрам, а в идиотизме управленцев (то что вы описали, кроме как идиотизмом назвать нельзя). В Скраме есть стори поинты описывающие сложность задачи — при чем тут вообще «время»?.. Во-вторых половину задач в нашем беклоге генерируем мы сами, не ожидая ничего от бизнеса. И в конце концов в Agile (да и не только) есть такое прекрасное слово «Нет, мы не будем это делать».
Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».
Но боль вашу прекрасно понимаю, у нас тоже так «удачно» внедрили «Девопс».
у нас тоже так «удачно» внедрили «Девопс»
это как? (правда интересно)
Сидели мы, бед не знали, как нашего начальника (директор по инфраструктуре) убрали, и наняли «директора по девопсу». Дядя пришел, раздал всем опросники с вопросами про культуру и вот это вот все, поставил задачу изучать модные тулзы по автоматизации и так далее… и ничего из этого не вышло, т.к. менеджменту удобнее было держать огороженные друг от друга отделы инфраструктуры, тестировщиков и разработки. Никаких объединений над общей задачей, никакой blameless культуры (когда случался факап, вместо решения проблемы искали крайних, которых поставить проблему решить, а потом всенародно отчитывали. Про «проблема не на нашей стороне» вообще молчу — классика.
Закончил девопс дядя тем, что когда из хэд офиса уволили единственного хелпдеска, сидел и людям почту настраивал.
А затем и его уволили и наняли «директора по инфраструктуре».
Закончил девопс дядя тем, что когда из хэд офиса уволили единственного хелпдеска, сидел и людям почту настраивал.
А затем и его уволили и наняли «директора по инфраструктуре».
НЛО прилетело и опубликовало эту надпись здесь
Уволили очень просто — предложили несколько окладов и сказали, что в услугах более не нуждаются.
По оф версии директор по инфраструктуре мыслил классическим подходом со всеми этими чейндж реквестами, многоуровневой валидацией и тд, и якобы не мог переобуться в супергибкий девопс. Потому его убрали и нашли дядю, который знает все модные подходы и технологии.
Проблема в том, что девопс подразумевает тесное взаимодействие. Можно сколько угодно совать тулзы по автоматизации, деплоить код по нажатии кнопки в джире, но blameless culture в мозгах некомпетентных (мягко говоря) управленцев не ложилась никак.
А по неоф данным, старый (изначальный) директор по инфре был слишком упертый и слишком яростно защищал свою команду (т.е. меня и моих коллег), вот его и турнули, но это уже условности.
А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
По оф версии директор по инфраструктуре мыслил классическим подходом со всеми этими чейндж реквестами, многоуровневой валидацией и тд, и якобы не мог переобуться в супергибкий девопс. Потому его убрали и нашли дядю, который знает все модные подходы и технологии.
Проблема в том, что девопс подразумевает тесное взаимодействие. Можно сколько угодно совать тулзы по автоматизации, деплоить код по нажатии кнопки в джире, но blameless culture в мозгах некомпетентных (мягко говоря) управленцев не ложилась никак.
А по неоф данным, старый (изначальный) директор по инфре был слишком упертый и слишком яростно защищал свою команду (т.е. меня и моих коллег), вот его и турнули, но это уже условности.
А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
НЛО прилетело и опубликовало эту надпись здесь
А новый директор по инфраструктуре сидит и так же хелпдеском в хэд офисе занимается, насколько мне известно от несчастных, кто до сих пор в конторе работает. Меня убрали задолго до нынешних времен (как и 90% штата в центре разработки), заменив аутсорсерами из одной «богатой» «крутыми» и «дешевыми» «инженерами». В головах нерадивых менеджеров «передать все в аутсорс и в облако» решает проблемы культурные и расходов.
И?
Сталкивался — как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес. Она за ради денег, а не за ради «поразрабатывать бы что нибудь крутое задорого, не взирая на себестоимость».
как закачивается период активной разработки/развертывания, так меняется организационная структура, убираются куча ставшими не нужными работников, а потом опять активизируется, нанимают заново — это целесообразно, это бизнес.
Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.
Чаще всё иначе. Программисты стоящие за воротами лучше бы за ними и оставались. Новый программист не может править чужой код и начинает его переписывать (топчется на месте). Вы не только полгода не платили зарплату, но и не имели возможности заработать на опытном программисте.
Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
Может проще сразу эффектного менеджера увольнять?
Вы считаете, что если уволить специалиста, например, программиста работающего с основания компании, а затем через полгода нанять программиста на то же место — то это выгодно. Так как вы полгода зарплату не платили, а за воротами программистов немеряно.
Смотрите шире — разработчик сам закиснет на работе по поддержке.
Новый программист не может править чужой код и начинает его переписывать (топчется на месте).
Это отдельная проблема.
Но.
Но неужели вы думаете, что огромные коллективы разработчиков, создающие большие системы, сумели каким-то чудесным образом избежать текучки в коллективе?
Чем больше народу работает, — тем больше «потоки свежей крови», это естественный факт.
Так что, смею утверждать, что вы просто не видели нормального кода, если считаете, что это непреодолимая проблема.
Как итог сокращаете фонд заработной платы, через год — два закрываете компанию или на место одного программиста нанимаете 20 (условно).
Может проще сразу эффектного менеджера увольнять?
Конкретный пример приведу:
Была разработана платежная система.
3 человека разработчиков. Очень высокая квалификация.
Под конец разработки был нанят один попроще квалификацией.
Разработка была завершена.
Оставалось следить за системой, баги редкие фиксить — этим и занялся тот последний принятый на работу «квалификацией попроще».
Кроме разборов с багами в его задачи входило изредка писать очередные платежные шлюзы для новых поставщиков услуг и дружественных платежных систем (что делалось на раз-два, так как API были уже созданы и проработаны в мелочах как надо).
Иногда им писались отчеты.
Зачем там 3 высококвалифицированных спеца на этом этапе?
Прошло не полгода, а 2 года…
Фирма вышла на рынок другой страны — нужно было адаптировать платежную систему.
В частности локализация оказалась не предусмотрена штатно — и потребовала глубоких доработок, неподъемных для программиста, сидящего на поддержке.
Снова наняли высококвалифицированных разработчиков — других, естественно, а не тех, что систему изначально создали.
Это конкретный пример из жизни.
Новых трёх высококвалифицированных специалистов уже уволили?
Новых трёх высококвалифицированных специалистов уже уволили?
Для локализации и пр. задач нанимали всего двух высококвалифицированных.
Задача выполнена.
Да, давно уволены.
Они бы и сами ушли — им же не интересно работать по мелким текущим задачкам.
Тем более коих мало на такую толпу народа.
Я с подобным встречался только в не сложных web проектах. Значит я ошибался.
По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.
По сути, это и есть несложный веб-проект. У большого проекта нескончаемый список нереализованных хотелок.
Хотелок у всех нескончаемо.
Все дело в бабле. Никто вечно не будет спонсировать хотелки на полную катушку.
Разделение жизненного цикла продукта на более и менее интенсивную разработку — совершенно естественно.
Аналогия с домом:
Дом построен — каменщики ушли.
Пришли маляры.
Прошли годы.
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Прошли годы
Еще раз пришли маляры.
Но каменщики не вернуться уже никогда.
Но каменщики не вернуться уже никогда.
В моём городе каменщиков возвращали через суд. Эксперименты с зарплатой строителям во время бума строек привели к тому, что работяги много воровали, например, цемента. В результате новый дом и внешняя стена лопнула. Мужик подал в суд и выиграл, вернулись краны, каменщики и блок стены поменяли. Но аналогия совсем не к месту!
У программистов своя работа. Пишет, например, программист ХХ тысяч строк кода. И вы можете как Ванга нагадать, что в этом коде есть ошибки, при чём много критических. Далее, посмотрев на результат большая часть заказчиков осознаёт, что делать надо было совсем иначе. Плюс много хотелок.
Для многих сайтов программисты после создания сайта не нужны совсем. Логика простая (обработать запрос юзера и сформировать ему хтмл страницу с БД), самописы без внешних непредсказуемых библиотек и всё… Нужны модераторы, корректоры, юристы, рекламщики. Но не программисты.
Но мой опыт показывать, что если после написания программ начинают увольнять программистов — то это всё. Ваш опыт другой.
Но аналогия совсем не к месту!
У программистов своя работа.
Есть этапы создания ПО и этапы его эксплуатации.
Я вас уверяю, какое-нибудь торговое предприятие, вложившееся в внедрение и адаптацию под себя 1С, совсем не мечтает заниматься этим ежемесячно годами.
Делают просто:
1. Нельзя работать, ПО не позволяет.
2. Делаем ПО.
3. Запускаем ПО в эксплуатацию
4. Пользуемся ПО.
5. Фиксим баги
Пункты 2 и 3 несообразно дороги.
Но их терпят ради пункта 4.
Пункт 5 должен быть копеечным, иначе это плохое ПО.
Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.
Это все же не типичные заказчики. Их бизнес и есть ПО.
А все что существует в нашем виде материального — сделано предприятиями традиционного типа.
Для них экономически лучше будет купить новый крутой станок, чем очередной раз переписывать программу управления производством.
Но каменщики не вернуться уже никогда.
Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.
Когда разработку ПО сравнивают со страительством есть одна простая ошибка восприятия, которая ломает все дальнейшие аналогии. Как правило в инженерном деле можно выделить две стадии — проектирование и собственно постройка (design + build) причем фаза строительства не очень то дешевая и исправлять ошибки проектирования на этой фазе очень дорого.
В разработке ПО же "сборка" процесс незатратный. По сути это время работы компилятора/деплоймент. То есть с точки зрения трудозатрат разработка ПО это только процесс "проектирования", что сильно меняет подход к этому делу в плане процессов и разработки. Мы в любой момент можем вызвать "каменщиков" и изменить проект.
Пока не придет чейнджреквест от владельцев здания, например достроить еще одно крыло или связать два рядом стоящих здания переходом.
Если это не ИТ-фирма, а ИТ только обслуживающая служба, то реквест придет ой как не скоро.
Годами держать ненужный штат предлагаете?
Годами держать ненужный штат предлагаете?
Аутсорс не зря придумывали. Если изменения происходят раз два в год, то держать штат смысла нет. Но если риски от того, что изменения не будут сделаны вовремя высоки (каждый день задержки будет приносить убытков компании больше чем посадить человека в штат) то имеет смысл держать в штате человека.
Аутсорс не зря придумывали. Если изменения происходят раз два в год, то держать штат смысла нет. Но если риски от того, что изменения не будут сделаны вовремя высоки (каждый день задержки будет приносить убытков компании больше чем посадить человека в штат) то имеет смысл держать в штате человека.
Абсолютно бессмысленно это обсуждать в отрыве от конкретного проекта.
Я привел вполне конкретный пример выше — с него обсуждение и идет:
Крупные переделки в платежной системе, которые делаются раз в 2 года.
Но длина каждой переделки опять таки по паре лет.
Что до аутсорса:
Занимаюсь аутсорсом — ровно та же ситуация. Доработки идут волнами. Большими волнами.
Нередко во время крупных доработок заказчики просят отдать программиста им в штат. Или сажают аутсорс-программиста себе в офис на постоянку.
Иногда, после месяцев поддержки по аутсорсу, предпочитают нанимать программиста (другого, не переманивают, все честно). Потом отдел. Потом сокращают. Опять возвращаются на аутсорс.
Это жизнь. Это бизнес. Потребности меняются. Штат меняется в зависимости от ситуации.
Зависит от проекта. И его конкурентов. Грубо, Гуглу и Яндексу надо постоянно развиваться.
Не методология виновата. Виноваты манагеры. Ради достижения своих целей одна группа, не очень нужных в компании лиц, решила поставить раком людей, действительно в компании нужных. Так уж повелось у «эффективных менеджеров», считать людей «отвёртками», забывая, что как только разработчик начинает чувствовать себя отвёрткой, к проекту он начинается относиться соответственно. Пока у них есть уверенность, что любого можно заменить, это будет продолжаться до бесконечности.
Творчество и формализация плохо совместимые понятия.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде
Люблю SCRUM как раз за то что УЧИТЫВАЕТ взаимоотношения в команде, знаю что напишу банальщину, но есть подозрение что у вас не правильно приготовили SCRUM.
получается везде scrum готовят неправильно? Может быть проблема в нем самом?
Возможно Вам просто не везло, у нас вся компания(порядка 27 команд) работают по SCRUM и таких проблем нет.
В ПО есть баги, получается везде ПО пишут неправильно?
Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.
Идеальных процессов не бывает. Есть команды, которые больше преуспели на пути к «идеальному», есть команды, у которых не получилось.
К сожалению, факторов по которым «что-то может пойти не так» слишком много, поэтому ребят проваливающих этот путь значительно больше, чем успешно его прошедших.
В ПО есть баги, получается везде ПО пишут неправильно?
Именно так. Иначе не существовало бы такого разнообразия серебряных пуль методологий разработки и индустрии впариветелей этих методологий.
Нет, это не так. Потому что термин «неправильно» подразумевает существование термина «правильно».
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
Важна их частота и степень их влияния.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
Важна их частота и степень их влияния.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок
Бездоказательное утверждение.
Даже если у вас будет неограниченное время и бюджет.
Прро формальное доказательство правильности программ слыхали? Иногда оно бывает даже автоматическим.
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы
Можно использовать инструмент с которым скорее всего будут проблемы. А можно его не использовать и этих проблем избежать
Да, и формальное доказательство предполагает либо слабую логическую сложность программы, либо доказательство в рамках одной тестовой модели.
Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.
Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.
Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.
Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.
Проблема в том, что:
а) у каждой методологии есть области применимости, но обычно явно они не описаны
б) список решаемых проблем тоже часто явно не обозначен
в) а уж цена, которую придётся платить, тем более не обозначена
Ну или, может, всё это есть в толстых книжках, но внедрятели их не читают. Или читают, но плохо. И внедряет, обычно, не команда, а руководство. Команд — это объект внедрения, а не субъект.
а) у каждой методологии есть области применимости, но обычно явно они не описаны
б) список решаемых проблем тоже часто явно не обозначен
в) а уж цена, которую придётся платить, тем более не обозначена
Ну или, может, всё это есть в толстых книжках, но внедрятели их не читают. Или читают, но плохо. И внедряет, обычно, не команда, а руководство. Команд — это объект внедрения, а не субъект.
Прро формальное доказательство правильности программ слыхали?
Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:
— формальное описание корректное
— формальное описание полное
Обычно баги получаются не из-за механической ошибки, а из-за неправильной или неполной обработки данных. А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя.
Формальное доказательство только про соответсвие формальному описанию, но никто не говорил, что:
Угу. Вы ещё скажите, что наше восприятие мира не соответствует действительности и поэтому не бывает по без ошибок. Отделяйте мух от котлет. Написать правильную программу (полностью соответствующую формальному описанию) можно. В исходной формулировке ничего не было про правильность постановке задачи.
А тут часто вступает в дело комбинаторная сложность из-за это все ветви проверить нельзя
(пожимая плечами) в вашей постановке были бесконечные ресурсы. (И при чём здесь проверка всех ветвей? Как и теоремы, программы доказываются не брутфорсом, как правило) Но раз вы меняете правила и формулировки по ходу дела, то конкретно вам ничего доказать нельзя. Продолжение беседы на таких условиях не кажется мне осмысленным.
В исходной формулировке ничего не было про правильность постановке задачи.Но и про наличие готового формального описания тоже ничего не было. Чтобы этим способом написать правильную программу, нужно правильное формальное описание, а получить его (гарантированно правильное) неизвестно как.
Правильная программа — программа, соответствующая формальному описанию. Даже если оно неправильное, то программа ему соответствующая всё равно правильная. Может бесполезная, может даже вредоносная в каких-то кейсах, но правильная.
НЛО прилетело и опубликовало эту надпись здесь
То есть, правильное ПО не относится к
ПО, которое будет работать без ошибок
Оно работает без ошибок — полностью согласно формальному описанию.
Предположим, что ваше трактова термина «ошибка» верная. Тогда почти всё современное ПО не содержит ошибок, потому что не составлено формальное описание. Однако, множество существует множество дефектов, которые признаны ошибками. Противоречие. Исходное предположение неверно.
Раз не составлено формального описания, значит ПО не может ему соответствовать, а значит не может считаться безошибочным.
Ошибка — несоответствие формальному описанию.
Если нет формального описания, то ошибок тоже нет?
Если нет формального описания, то ошибок тоже нет?
Значит есть несоответствие. Вся программа — формально большая ошибка, если что-то принимает на вход и что-то отдаёт, хотя формальное описание пустое.
С таким убеждением можно подходить к любой команде разработчиков и заявлять: «вся ваша программа — большая ошибка».
— А в чём ошибка?
— Не скажу, сначала сделайте формальное описание.
Интересно, куда вас пошлют после такого диалога…
— А в чём ошибка?
— Не скажу, сначала сделайте формальное описание.
Интересно, куда вас пошлют после такого диалога…
Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
Хм, а кто-то всерьёз начнёт доказывать, что их программа безошибочна? Отсутствие формального описания означает наличие N неизвестных ошибок в программе, где N нелинейно растёт вслед за ростом сложности, объёма кода и т.д. Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.
Мы (комментирующие тут) что — все до единого в космической индустрии служим?
Откуда такие вопросы вообще в голову пришли?
Учитывая невозможность обнаружения всех N ошибок без формального описания, действительно можно сказать, что вся программа ошибочна.А если для программы составлено формальное описание, и проведено доказательство корректности, но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?
«У меня нет оснований считать, что программа безошибочна».
но вам об этом не сообщили, вы всё равно с порога будете утверждать, что наверняка программа ошибочная?
Вы меняете условия на ходу. Обсуждался случай, когда достоверно известно об отсутствии формального описания, цитата: "Если нет формального описания, то ошибок тоже нет?"
Даже если оно неправильное, то программа ему соответствующая всё равно правильная
То есть ответственность за корректное с точки зрения бизнес-логики поведение мы перекладываем с программы на формальное описание? Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?
Теперь вопрос — можем ли мы (как вид) создать безбажное формальное описание нетривиального продукта?
Да можем конечно… С математикой же мы как вид как-то справляемся. Так же и программа может быть представлена в декларативном виде. Есть особо сложные случаи, но подавляющее большинство программ реально формализовать… Другой вопрос, что это кучу времени займёт при текущем состоянии IT-индустрии (что не говори, а она ещё только на начальном уровне развития).
НЛО прилетело и опубликовало эту надпись здесь
Вообще говоря, в описании реального мира математика продвинулась куда дальше, чем программирование (см. математическая физика). Но по сути и то и то работает с упрощенными моделями реальности. Формальное описание — это и есть модель.
Справиться с математикой гораздо проще, т.к. она, вообще говоря, не описывает реальный мир.
Точно, точно.
То-то мы строим высоченные здания и уверены (из расчетов), что они не рухнут.
Или на каждом шагу в быту, даже без перепроверок, суммируем и умножаем и не пересчитываем соответствие на деле сумм и произведений нашим расчетам.
Точно точно — математические расчеты не относятся к реальному миру.
И 2*пи*р никакого отношения к кругу не имеет — нужно линейкой перемерять.
Вы путаете:
Математика априори абстрактна. Но это не означает, что она не имеет отношения к реальному миру.
Тут все дело в модели, а не в математике как таковой.
Именно модель и связывает реальный мир и математику.
Бизнес-процессы в больших масштабах ложаться на математику (на статистику, если быть точным).
НЛО прилетело и опубликовало эту надпись здесь
Физика тоже абстрактна (вспомните хотя бы «материальную точку»), и тем не менее она описывает реальный мир, хоть и неточно.
Очевидно ж — почему.
Ведь физика — это именно что моделирование реальности.
А модели — это как раз то, что связывает математику с реальностью.
Не забываем что математические модели это все же больше теория. Не зря же помимо нее обычно делают настоящую модель и проводят симуляции на ней. Не зря после моделирования каркрэша на комьютере по итогу всеравно проводят реальные испытания. Это позволяет существенно снизить издержки на производство и тестирование, но это не гарантия успеха.
На эту тему есть неплохой докладик: https://youtu.be/9IPn5Gk_OiM?t=11m29s
там как раз про устранение человеческого фактора в разработке ПО за счет использования формальных методов.
Да, разделение ответственностей. Описание отвечает за описание :) бизнес-логики, а программа за реализацию описанного.
Полноценного продукта с UI, взаимодействием с ОС и т.п. — только в теории, наверное. Конкретно бизнес-логики — думаю, вполне возможно. Вернее, возможно создать полностью верифицируемое формальное описание проходящее тесты на полноту и не противоречивость. Естественно, если эксперты или аналитики что-то напутают, то такое описание будет с ошибками.
Полноценного продукта с UI, взаимодействием с ОС и т.п. — только в теории, наверное. Конкретно бизнес-логики — думаю, вполне возможно. Вернее, возможно создать полностью верифицируемое формальное описание проходящее тесты на полноту и не противоречивость. Естественно, если эксперты или аналитики что-то напутают, то такое описание будет с ошибками.
а получить его (гарантированно правильное) неизвестно как.
Тут в дело вступает психология. Люди плохо описывают необходимые детали из головы. С другой стороны, когда человеку показывают не то, что он хотел, он уже выдаст намного более полезный список отличий из которых это формальное описание можно будет сформировать.
То есть если у вас нет четкого формального описания программы, его можно составить путем получение обратной связи от клиентов (пользователей системы по хорошему). А из этого мы можем сделать логическое заключение — нам нужно выстраивать работу таким образом, чтобы цикл обратной связи был меньше. И есть целая масса способов собирать фидбэк не вкладывая безумные усилия в разработку. Начиная прототипами и мокапами и заканчивая gherkin сценариями с описанием поведения системы (specification by example, bdd).
из которых это формальное описание можно будет сформировать.Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).
То есть, если у нас конвертор из doc в png (для простоты — первая страница), то имеем входной предикат D(x,y) — утверждение, что x-й байт входного документа есть y, и с помощью правил формального описания можно доказать набор P(x,y) — утверждений, что x-й байт выходного документа есть y. Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?
И это ещё пакетное преобразование. С интерактивными программами вообще ужас.
Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение
Нет конечно. Вообще пожалуй мой комментарий лишь говорил о том что можно получить вменяемые требования по которым можно делать работу. Некое "абстрактное в вакууме" описание будет оставаться все таким же абстрактным.
Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов?
То что вы описали никому не нужно. Вообще на эту тему есть неплохой доклад Грэга Янга. Там как раз про "миллионы формул" и "все возможные word документы" найдутся тезисы.
В целом же я не вижу никакого смысла в "формальном описании" которое сложнее реализации. Реализация задачи может считаться формальным описанием?
я не вижу никакого смысла в «формальном описании» которое сложнее реализацииМы в этой ветке обсуждаем доказательство правильности программ системами логического вывода.
А что есть «формальное описание» в ваших терминах?
Реализация задачи может считаться формальным описанием?Да. Но чтобы сделать правильную реализацию нужна другая правильная реализация?
Прототипы, мокапы, модели и т.д. могут восприниматься как "другая" возможно правильная реализация. Эта реализация должна быть на порядки дешевле "настоящей" и должна служить источником фидбэка для уточнения требований дабы со временем сформировать уже итоговый продукт или отдельные его фичи.
Прототип, как правило, не учитывает всякие сложные случаи, на тяп-ляп относится к безопасности (отсутствует супер-тщательная валидация входных данных), на него равняться нельзя.
и тут в дело вступает управление рисками. Лучше делать систему так, чтобы быстро реагировать на риски а не пытаться их все предотвратить. Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?
НЛО прилетело и опубликовало эту надпись здесь
Зачем тратить человекомесяцы на кейс, который будет возникать один раз на миллион?
Чтобы этот один раз не нанес гораздо больший ущерб, чем стоимость нескольких человекомесяцев
Давно известно, что если оставить право оценивать важности таких вещей разработчикам — то они расставят приоритеты совсем не так, как финансово целесообразно предприятию. Что в конечном итоге может привести к потери финансовой устойчивости предприятия.
Это вопросы менеджеров и выходит за тему данной статьи.
В целом же я не вижу никакого смысла в «формальном описании» которое сложнее реализации. Реализация задачи может считаться формальным описанием?
Извиняюсь, что сломаю ваше мнение о «невозможно» и "… дороже чем..".
Логика тут немного другая. Есть бюджет проекта, скажем 100 денег.
Есть два варианта решения:
- 10 денег — аналитика «тяп-ляп»
- 20 денег — срач/менеджемент по ходу проекта
- 60 денег — ваять-кодить решение (пару-тройку раз переделав)
- 10 денег — тестить
или
- 40 денег — аналитика «формально корректная»
- 10 денег — срач/менеджемент по ходу проекта
- 30 денег — ваять-кодить решение (сделано сразу верно)
- 20 денег — тестить
Так получилость, что у меня было штук 6 похожих проектов сделанные этими двумя разными подходами и мог сравнить метрики проектов.
Фактически получалась «перемена мест слагаемых» :)
Выбор решения состоит в балансе между знанием предметной области и предоставлением MVP.
В большинстве случаев этот выбор — проблема психологии. Клиенту все равно «куда говорить» — в draft проекта или «формальную бумажку», главное что бы его слушали и записывали. А в код или UML- ему пофиг. Главое что бы к моменту Х все было готово.
НЛО прилетело и опубликовало эту надпись здесь
Ладно, поправлюсь
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?
Ладно, поправлюсь
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать гарантированно правильное формальное описание?
Программы пишутся не просто так, не только ради удовольствия.
Посему всегда нужно ставить вопрос: а это надо, это кому надо, это действительно надо?
Описания (вполне себе нормальные) существуют в мире ПО.
Вот только до абсурда их доводить не надо никому.
Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».
Довольно забавно, что который раз вы без знания предмета появляетесь в этой ветке и отвешиваете комментарии. Вроде как если бы беседовали PHP-шники, а к ним всё время лез си-шник и поправлял: «а чего это у вас доллары перед переменными, это же не будет компилироваться».
Я просто много лет как не джун. И знаю, что рулит практическая польза. И только она.
Это только джунов и студентов может всерьез интересовать «правота абсолютно формального описания».
Кто поопытнее — могут это обсуждать только в качестве стёба или троллинга.
И так будет до тех пор, пока компьютерные программы не начали писать сами себя в индустриальных масштабах.
Программистам абсолютно формальное описание нужно только для того, чтобы прикрыть свою задницу (программа написана согласно описанию — отвалите с вашими претензиями, лучше дайте денег за выполненную работу).
Но ведь никто не будет применять для вашего наказания абсолютного оружия. Так что абсолютно формальное описания — явный перебор и напрасная трата времени.
Согласитесь, что даже в внутри вашего предприятия никто не будет всерьез на официальных совещаниях тратить на это время. Разве что в курилках. Единственная возможность обсосать эту тематику — на формах типа этого.
Программируем мы для удовольствия или для денег.
В коллективе программирующих ради удовольствия вас также далеко пошлют с этим формальным описанием — вы все удовольствие коллегам испортите.
В коммерческом проекте бизнес сначала посмотрит на абсолютно формальное описание с интересом и спросит — а как оно себя окупает. После получения ответа (никак) бизнес также потеряет всякий интерес к абсолютно формальному описанию.
Вы серьёзно считаете, что к более-менее нетривиальной программе можно сформировать формальное описание?
Даже более того…
Вы никогда не слышали слово «бриф»? Эта штука используется, чтобы формализовать требования к чисто творческим вещам: фотография, графика, дизайн, видео.
На бриф потом напирают дизайнеры, требующие от заказчика оплаты — соответствует брифу, давайте деньги.
Пример брифа.
Вы в курсе как планируется сериал «Игра престолов»? Да, да, да там бесстыдно написано в плане серии «показать голую женщину в полный рост спереди». Что в результате реализуется в виде исполнения наемником с сидящей на коленях проституткой песни Rains of Castamere (S05E09)
Так что формализовать можно даже такие не формализуемые, казалось бы вещи.
А вы про какие-то программы.
Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания. Но это никому и не нужно. Программы реализуются ради того, чтобы они пользу приносили, а не ради формального соответствия.
Индустрия ПО существует. Еще ой как существует.
И бизнес требует определенности, поэтому формальные описания вполне себе существуют.
Если вы о них не знаете, — это просто объясняется тем, что вы еще не senior, а то может и не крепкий middle.
Все к вам придет в свое время, не нужно бежать впереди паровоза.
Разумеется, не будет 100% взаимооднозначного соответствия программы и её формального описания.
Кхм, в этой ветке речь идёт о формальном доказательстве отсутствия ошибок в программах. А Вы говорите об обычной спецификации, это совсем другая тема.
Кхм, в этой ветке речь идёт о формальном доказательстве отсутствия ошибок в программах. А Вы говорите об обычной спецификации, это совсем другая тема.
Это уже придумано до нас.
Просто посмотрите как это реализовано в космической индустрии (стоимость ошибки страшно высока, бюджеты же на реализацию достаточно хороши). Почти 50 лет как.
;)
Здесь же пытаются притянуть за уши изначально бессмысленную задачу.
Никому не нужно это формальное доказательство, когда бизнес сравнит стоимость его и фактически принесенную пользу.
Вы умеете внимательно читать? Перечитайте, пожалуйста, эту ветку с начала и поймите, что тут обсуждают теоретическую возможность формального доказательства при условии неограниченного времени и бюджета, а не его практическую целесообразность.
Вы умеете внимательно читать? Перечитайте, пожалуйста, эту ветку с начала и поймите, что тут обсуждают теоретическую возможность формального доказательства при условии неограниченного времени и бюджета, а не его практическую целесообразность.
Что тут обсуждать-то?
Невозможно.
Ибо:
1. Программа получает числа на входе.
2. На выходе отдает квадраты входных чисел.
3. С вероятность 0,00000000000000001 выдает в ответ всегда 0, вне зависимости от входного числа.
Пункты 1,2 соответствуют формальному описанию.
Пункт 3 — специально вложенная ошибка, боящимся не получить свои деньги программистом (ну делают так некоторые козлы).
Финиш.
Верификация выявит третий пункт.
Верификация выявит третий пункт.
Если бы верификация все выявляла, то не требовалось бы «формальное описание программы».
Формальное описание для того и нужно, чтобы верифицировать программу на соответствие ему.
Ну не выявит, не выявит 100%. Пример выше.
Выявит только формальное описание равнозначное самой программе. Что лишает его всяческого смысла.
Выявит только формальное описание равнозначное самой программе. Что лишает его всяческого смысла.
Пример выше легко решается символьным вычислением.
Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.
Верификация выявит ваш третий пункт. Не путайте верификацию с тестированием.
Если верификация реальна и она проще программного кода (а иначе какой в ней практический смысл) и при этом 100% гарантировано все режимы работы программы проверяет — давайте писать верификационный код. А ПО и будет переводить его в программный уже.
;)
Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.
Верификация — процесс, код — объект этого процесса. Сравнивать, что сложнее — это как сравнивать тёплое и длинное.
Формальное описание, на основании которого, как вы писали, будет делаться верификация — это совсем не процесс. А тоже объект.
Вот вы хотите верифицировать.
И у вас для этого есть формальное описание.
Верификация 100%.
Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно. Ее из 100% формального описания выведет автоматика за вас.
То есть куда не погляди — практического смысла это лишено.
Потренироваться тут в комментариях в слепом десятипальцевом методе набора текста на клавиатуре только?
«Вывод: если вы можете верифицировать программу, то вам ее и писать не нужно.»
Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.
Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.
Ложный вывод. Одно дело проверить конкретное решение на соответствие описанию, а совсем другое — найти. Да ещё и выбрать из практически бесчисленного множества. Это как уравнение — проверить является ли число его корнем просто по сравнению с поиском всех корней.
Проверка корней уравнения — это подобно всего лишь тестированию программы, так же проверяется частный случай.
Здесь же в комментариях замахиваются на общую проверку со 100% гарантией. Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.
Вот я и спрашиваю, если программы пока еще пишут люди, а не другие программы — то какой в этом смысл? Ну кроме как языком побалякать.
Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.
Общая проверка со 100% гарантией, что программа соответствует описанию. Число программ ему соответствующих бесконечно множество в теории. Нам же надо проверить одну конкретную.
Это если бы вы под проверкой подразумевали простое тестирование частных случаев — было бы просто.
Если же мы рассматриваем, как тут, «доказательство» — это другой коленкор.
Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.
По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.
По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.
Доказательство соответствия программы формальному описанию — это то же самое, что доказательство верности уравнения при каком-то одном из множества корней.
По одному формальному описанию можно написать бесконечное множество корректных программ. У нас не стоит задача найти всё это множество, у нас задача проверки, что данная конкретная программа ему принадлежит. Сама программа — это частный случай. Это как проверка продуктов на сантребования — требования одни, продуктов много, какие-то соответствуют, какие-то нет. Нас, как производителя продукта, интересует только чтобы наш продукт требованиям соответствовал.
Прошло уж 20 лет как Пролог умер, а человечество еще не продвинулось в индустриальных масштабах к таким проверкам даже для консольных утилит, не говоря уж про GUI.
Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.
Другое дело, он в тырпрайзах не применяется. Но он и раньше не применялся, когда был якобы жив.
Другое дело, он в тырпрайзах не применяется. Но он и раньше не применялся, когда был якобы жив.
Пролог не умер. Логику предикатов обязательно преподают на математических факультетах, а Пролог — вполне нормальный язык её моделирования.
Преподают.
Но это не имеет к Прологу отношения.
Учился на математическом.
Ничего мы на Прологе не моделировали.
Даже более древний Фортран где-то там ограниченно применялся (в математической физике, вроде), но уж не как не Пролог.
Я его так, для себя почитал.
Это сродни найти доказательство теоремы, что ничуть не проще нахождения конкретного решения, а даже — наоборот, сложнее.
Естественно написать корректную (с гарантированным отсутствием багов) программу сложнее, чем некорректную. И, разумеется, писать корректные программы экономически невыгодно, по крайней мере на текущем этапе развития индустрии. Какой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.
акой смысл в ваших капитанских вопросах не по теме?
А практический смысл формальной верификации — то самое ПО без багов, пусть пока в теории. Но если не развивать теорию, то оно никогда в реальности и не появится.
Еще раз:
В комментариях никто даже не вышел на верную постановку задачи.
О каком развитии теории по решению задачи тут может идти речь?
А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Когда Вы уже ветку с начала перечитаете и осознаете, что тут никто и не собирался никаких задач ставить.
Сформулируйте лучше цель вашего активного оффтопика… Вы хотите привести доказательство, что формальная верификация невозможна никогда и ни при каких условиях или тупо покапитанить что это долго, дорого и не во всех случаях возможно?
А Вы ждали развития теории формального доказательства в комментариях на Хабре?.. смешной Вы однако.
Разумеется, не ожидал.
Если бы вы начали (если бы вы могли) обсуждать всерьез — 99% ваших собеседников бы скисло и вышло из беседы.
Интересно ведь просто языком побалякать, а не думать.
А тут думать пришлось серьезно, хотя бы чтоб прочитать и понять комментарий.
Я другого ожидал (ожидаю)
На Хабре частенько можно почитать упоминания об интересных вещах.
А дальше уже самому пойти копать.
Здесь же даже направление не смогли задать за несколько дней не то чтобы формулировки/постановки проблемы — хотя бы к ним приблизиться или упомянуть, а кто уже где подобные вещи решал/решать пытается.
Да и не старались.
Вот я и говорю — пустопорожняя беседа. В которой по сути проблемы никто ничего сказать и не может. Ни фразы.
Вам не кажется забавным, что эта "пустопорожняя беседа" по большей части состоит из Ваших собственных комментариев, на которые Вам изредка отвечают разные люди?
А по поводу ссылок, я Вам дал ссылки на Agda, на символьное выполнение программ и т.п. Уже успели ознакомиться?
В качестве практического применения символьное выполнение используется для автоматической генерации юнит-тестов.
Что касается Agda, то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.
то на основе его идей пилят язык общего назначения Idris, в феврале версию 1.0 собираются зарелизить.
Ну вот наконец-то, единственное золотое зерно.
Все остальное — тлен и плевелы (плевела? плевел? )
И почему мне нужно было ваш шпинять два дня, чтобы его получить?
Отчего бы вам сразу не выставить такой (легчайший, что вполне достаточно) акцент на Idris?
Ну, Вы ворвались в ветку с заявлениями типа формальное описание — это бриф, а формальное доказательство — то же самое, что тестирование. Исходя из этого сложно сделать вывод, что тема Вам хоть капельку интересна, т.к. все заявления мимо кассы.
На самом деле тема очень обширная. Хоть пока и не мейнстримная. И то, что Eiffel, Coq и Prolog не используются широко в повседневной разработке вовсе не значит, что они умерли, идеи их живут и развиваются. Рано или поздно это всё придёт и в мейнстрим, т.к. цена ошибок в ПО с каждым годом только растёт.
НЛО прилетело и опубликовало эту надпись здесь
Слышали о проблеме P и NP? Полагаю, нет.
Ага. Имею не техническое программистское, а математическое ВУЗовское образование. Так что напрасно умничайте терминами.
Обсуждаемая тематика в комментариях являет собой не более чем способ поважничать, так ни один автор из комментариев не то, что не подошел к решению проблемы (да это и не возможно в таком формате беседы), а даже никто и сформулировать-то грамотно задачу не сподобился.
Ибо понимает — есть пределы его ума. P и NP — а дальше сказать нечего.
Но этих букв достаточно, чтобы зрители благововели?
Господа, вы тут уже не первый день из пустого в порожнее переливаете.
Ни в практическом смысле пользы нет ни в математическо-теоретическом вы даже к правильным словам так подойти и не можете.
Что-то Вы опять какую-то несуразицу написали… Понятно что Вам лень изучать Agda, Prolog и т.д. Но какой смысл оффтопить, когда Вы совсем не в теме?
Напомню, формальное описание это машинночитаемый документ, из которого логическими правилами можно вывести требуемое поведение (output) при заданном входе (input).
И такое существует и активно применяется
Скажем, http://swagger.io/ мы используем.
Только зачем вам машиночитаемое формальное описание?
Вам же с ним жить, кому это нужно в реальной практики постановки задач, кроме таких вещей как API
Как думаете, сколько миллионов страниц логических формул потребуется, чтобы вывести P(x,y) из D(x,y) для всех возможных ворд-документов? Кто напишет эти формулы и где гарантии, что в них не будет ошибок?
Ничего этого не нужно.
OCR существует. Делаем обратное преобразование и проверяем (даже тестами можно, автоматически).
Отчего же неизвестно? В очень многих случаях очень даже известно. Почти вся автоматика от микроволновок до "вояджеров" так работает.
На мой взгляд дело не в методологии а в цели ее внедрения. Если стали внедрять — значит недовольны текущим положением. Предположу, что хотели сократить расходы на разработку. Видимо цели добились — самые старые и наверное самые высокооплачиваемые ушли. Экономия налицо.
Далее вероятно будет как в этом сценарии.
Не, обычно внедряют не потому, что не довольны, а потому что *модно*. Смотрите-ка, а у %условныйгугл% СКРАМ и нас на курсах MBA ему учили — это круто! надо внедрять! А! И, ни коем случае не забыть теперь считать человекочасы!
Ну, а дальше по накатанной — найм эффективного манагера(главное умеющего красиво ссать в уши и петь диферамбы) и спуск в тартарары
Ну, а дальше по накатанной — найм эффективного манагера(главное умеющего красиво ссать в уши и петь диферамбы) и спуск в тартарары
Рискну сказать, что если методологию внедряют повсеместно плохо, может быть все-таки что-то не так с методологией? Постоянно слышу про «вы неправильно используете Agile/Scrum/...» — покажите мне, где они используются правильно?
P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
НЛО прилетело и опубликовало эту надпись здесь
Вы действительно считаете, что определение подхода исследовательской задачи (даже без реализации) может быть оценено? Если да — скажите область, интересно. В моей области это нереально, к сожалению.
НЛО прилетело и опубликовало эту надпись здесь
>> программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны.
Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.
Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.
Да нет же, никаких «готовых» ответов нету — есть бизнес задачи, а разработчиков просят оценить их «примерно»
Поэтому поинты обычно идут в геометрической прогрессии: 2, 4, 8, 16 (ну или там размеры футболок), чтобы не было соблазна пытаться давать точные оценки трудозатрат. Просто чтобы у бизнеса складывалось понимание что вот эта задача вроде как простая, займет максимум день, а вот эта посложнее, дня на 2-3 и т.д.
Чтобы у менеджеров было примерное представление о сложности заданий. Ну и заодно насколько трезво члены команды оценивают свои силы.
Поэтому поинты обычно идут в геометрической прогрессии: 2, 4, 8, 16 (ну или там размеры футболок), чтобы не было соблазна пытаться давать точные оценки трудозатрат. Просто чтобы у бизнеса складывалось понимание что вот эта задача вроде как простая, займет максимум день, а вот эта посложнее, дня на 2-3 и т.д.
Чтобы у менеджеров было примерное представление о сложности заданий. Ну и заодно насколько трезво члены команды оценивают свои силы.
НЛО прилетело и опубликовало эту надпись здесь
---На agile-доску программистам
а что если в команде не software devеlopers, а principal software engineers и они сами себе ставят задачи? И таких компаний немало.
У меня были задачи что я и через месяцы не знал можно ли ее довести до конца и когда закончу.
А reverse engineering? Там можно месяцами ковырятся и в любой момент — сказать все, писец, дальше хода нет.
а что если в команде не software devеlopers, а principal software engineers и они сами себе ставят задачи? И таких компаний немало.
У меня были задачи что я и через месяцы не знал можно ли ее довести до конца и когда закончу.
А reverse engineering? Там можно месяцами ковырятся и в любой момент — сказать все, писец, дальше хода нет.
У меня были задачи что я и через месяцы не знал можно ли ее довести до конца и когда закончу.Что за атомарная и неделимая задача такая. Есть пример?
Да легко. Нужно разобраться почему важная игра одного из наших партнёров на устройстве падает при установке аппа от Facebook'а или Skype, но отлично работает без.
Расследование, занявшее месяц, показало что в старых версиях Android'а sem_wait работает не по POSIX'у, а новые версии это воспроизводят только если апликуха собрана под старую версию, эта ошибка «стреляет» если вложить старую версию Unity в новый апп и обеспечить достаточную нагрузку на систему, после чего GC в mono с некоторой вероятностью вынесет живые обьекты.
И? Сколько у вас будет «поинтов» это задачу? Оно ведь отлично вопроизводится — ну сколько может потребоваться времени, на то, чтобы с этой плёвой ошибкой разобраться?
Расследование, занявшее месяц, показало что в старых версиях Android'а sem_wait работает не по POSIX'у, а новые версии это воспроизводят только если апликуха собрана под старую версию, эта ошибка «стреляет» если вложить старую версию Unity в новый апп и обеспечить достаточную нагрузку на систему, после чего GC в mono с некоторой вероятностью вынесет живые обьекты.
И? Сколько у вас будет «поинтов» это задачу? Оно ведь отлично вопроизводится — ну сколько может потребоваться времени, на то, чтобы с этой плёвой ошибкой разобраться?
Если у вас все задачи такие, то вероятно именно вашему процессу agile подходит.
Если же задача разовая. Начнём с того, что у вас нет постановки, как она к вам пришла. Но допустим это стабильные, но рандомные креши при высокой нагрузке. Лично я бы никогда не назвал данную задачу плевой, потому что это явный признак проблем с памятью. Кто вам сказал, что она плёвая?
После того как мы сразу определились, что задача не плевая, то сразу можно предположить, что для ее решения понадобится как минимум спринт. Вот вам и оценка: максимум строипойнтов, которые вы можете вместить, на предварительное исследование и попытку решения. Причем лучше тоже разбить на два этапа: стредняя по сложности задача на предварительное исследование и сложная задача на исправление.
После исследования можно уточнить оценку. И сразу же через день-два (а не через месяц) осознать что проблема серьёзнее. После этого у команды есть возможность оперативно подключить дополнительные ресурсы.
Если же задача разовая. Начнём с того, что у вас нет постановки, как она к вам пришла. Но допустим это стабильные, но рандомные креши при высокой нагрузке. Лично я бы никогда не назвал данную задачу плевой, потому что это явный признак проблем с памятью. Кто вам сказал, что она плёвая?
После того как мы сразу определились, что задача не плевая, то сразу можно предположить, что для ее решения понадобится как минимум спринт. Вот вам и оценка: максимум строипойнтов, которые вы можете вместить, на предварительное исследование и попытку решения. Причем лучше тоже разбить на два этапа: стредняя по сложности задача на предварительное исследование и сложная задача на исправление.
После исследования можно уточнить оценку. И сразу же через день-два (а не через месяц) осознать что проблема серьёзнее. После этого у команды есть возможность оперативно подключить дополнительные ресурсы.
НЛО прилетело и опубликовало эту надпись здесь
Алгоритмы все известны
Какое смелое утверждение :)
НЛО прилетело и опубликовало эту надпись здесь
Во первых, сильно зависит от исследовательских задач. Для большинства из них можно дать вполне конкретные сроки сколько ресурсов съест, например, знакомство с возможными технологиями для использования и их comparison.
Во вторых, для исследовательских задач эстимейт — не значит, что «через N часов у меня будет алгоритм».
Это значит что в этом спринте вы потратите N часов на исследование этого вопроса, а оставшиеся M будете заниматься другими задачами.
При этом по истечении этого эстимейта вполне нормальным (и ожидаемым) результатов будет являться «Попробовал следующие варианты, ни один из них не подходит для наших целей потому-то, потому-то. Есть ещё такие варианты, но на их исследование нужно ещё X времени».
Во вторых, для исследовательских задач эстимейт — не значит, что «через N часов у меня будет алгоритм».
Это значит что в этом спринте вы потратите N часов на исследование этого вопроса, а оставшиеся M будете заниматься другими задачами.
При этом по истечении этого эстимейта вполне нормальным (и ожидаемым) результатов будет являться «Попробовал следующие варианты, ни один из них не подходит для наших целей потому-то, потому-то. Есть ещё такие варианты, но на их исследование нужно ещё X времени».
Для этого существует тайм-бокс. Отводится столько-то времени, что успел, то успел.
Пример задача разработать интеграцию API Печкина, с которой ещё никто никогда не работал. Берется тайм-бокс, и 3 дня играется с этой API. По истечении трёх дней опытный разработчик сможет оценить конкретную задачу точнее, как минимум разбить её на маленькие UserStories.
Пример задача разработать интеграцию API Печкина, с которой ещё никто никогда не работал. Берется тайм-бокс, и 3 дня играется с этой API. По истечении трёх дней опытный разработчик сможет оценить конкретную задачу точнее, как минимум разбить её на маленькие UserStories.
НЛО прилетело и опубликовало эту надпись здесь
Системное программирование/компиляторы/производительность. Замена инструкции А на Б приводит к регрессии на 20% по производительности. Инструкции делают одно и то же, с очень похожими таймингами. Оказалось прицина в code alignment'е. Т.е. скедулинг другой инструкции триггерил проблему совершенно в другом месте. Да и многие проблемы с производительностью из этой корзины.
Или другое: не работает раскрутка стека из обработчика сигналов. Оказалось, что причина в некорректной работе dl'я (dynamic linker). И такие задачи всплывают регулярно.
P.S. А что за коллега? Есть предыдущие публично доступные публикации на эту тему?
Или другое: не работает раскрутка стека из обработчика сигналов. Оказалось, что причина в некорректной работе dl'я (dynamic linker). И такие задачи всплывают регулярно.
P.S. А что за коллега? Есть предыдущие публично доступные публикации на эту тему?
Конкретно Scrum очень плохо себя показал в ситуациях, когда на одной команде несколько проектов в активной фазе разработки. И ещё несколько в активной поддержке.
А по какой причине одна и та же задача может занять 1 день, а может неделю?
Не сарказм, правда интересно. Я могу понять разброс в два раза, может даже в три. Ошибка в оценке в 7 раз по понятным и не меняющимся требованиям?
Я вот вижу три возможные причины:
1) Неполные и меняющиеся требования. Т.е. хотели одно (и делать это 1 день), потом захотели другое (и делать это неделю).
На этот случай скоуп спринта фиксируется и меняется толькоценой жизни менеджеров по средством выкидывания других задач из спринта, и то только в случае, если работы можно распараллеливать.
2) Неясность реализации. Т.е. задача выглядит простой (на 1 день), но в процессе реализации всплывает много побочных факторов, требующих доработки.
И тут два пути: если есть подозрение, что такие проблемы могут возникнуть — сначала берется задача на исследование, что бы точно понимать объем работы, и только потом берется задача на реализацию.
Если с точки зрения разработчика проблем возникнуть не должно, понятно как это укладывается в текущую архитектуру и никаких рисков нет, а потом они появляются — значит есть высокая связанность и слабая прозрачность архитектуры приложения. Такие случаи пост-фактум разбираются на ретро, заводятся задачи на рефакторинг и редизайн кода.
3) Проблема оценки. Человек, оценивавший задачу не компетентен и\или страдает завышенным ЧСВ «я сделаю это с трёх нот».
С обоими случаями надо работать внутри команды — учить людей оценивать нормально, обеспечивать знакомство людей с кодом, оценивать задачи командой. Вариантов довольно много.
Не сарказм, правда интересно. Я могу понять разброс в два раза, может даже в три. Ошибка в оценке в 7 раз по понятным и не меняющимся требованиям?
Я вот вижу три возможные причины:
1) Неполные и меняющиеся требования. Т.е. хотели одно (и делать это 1 день), потом захотели другое (и делать это неделю).
На этот случай скоуп спринта фиксируется и меняется только
2) Неясность реализации. Т.е. задача выглядит простой (на 1 день), но в процессе реализации всплывает много побочных факторов, требующих доработки.
И тут два пути: если есть подозрение, что такие проблемы могут возникнуть — сначала берется задача на исследование, что бы точно понимать объем работы, и только потом берется задача на реализацию.
Если с точки зрения разработчика проблем возникнуть не должно, понятно как это укладывается в текущую архитектуру и никаких рисков нет, а потом они появляются — значит есть высокая связанность и слабая прозрачность архитектуры приложения. Такие случаи пост-фактум разбираются на ретро, заводятся задачи на рефакторинг и редизайн кода.
3) Проблема оценки. Человек, оценивавший задачу не компетентен и\или страдает завышенным ЧСВ «я сделаю это с трёх нот».
С обоими случаями надо работать внутри команды — учить людей оценивать нормально, обеспечивать знакомство людей с кодом, оценивать задачи командой. Вариантов довольно много.
Баги в используемых инструментах. Время решения задачи включает время обнаружения, локализации и фикса бага.
Баги в используемых инструментах — это нормальная история, но это риски.
Профачил сроки в 10 раз, собрались на ретро — обсудили, что на задачи, требующие использования сторонних инструментов нужно закладывать больше буффер, потому что грустненько.
Если такие истории случаются каждый раз — искать более подходящие инструменты.
Профачил сроки в 10 раз, собрались на ретро — обсудили, что на задачи, требующие использования сторонних инструментов нужно закладывать больше буффер, потому что грустненько.
Если такие истории случаются каждый раз — искать более подходящие инструменты.
Даже без учёта требований и оценок одну и ту же задачу можно сделать быстро, а можно сделать продуманно и качественно. Один разработчик держит в голове кратчайший путь и даёт оценку к примеру 3, а другой знает подводные камни или связанные области и даёт оценку 15. И тот и другой дали правильную оценку. Поэтому так важно обсуждать оценки, поднимать вопросы и подчёркивать возможные проблемы, а не просто брать минимальную оценку.
Такое обсуждение в скраме реализуется т.н. «scrum poker».
А кто-то призывал брать минимальную оценку?
Я нет. Более того, я склоняюсь к тому, что при планировании стоит брать максимальную из незавышенных искусственно оценок.
Я нет. Более того, я склоняюсь к тому, что при планировании стоит брать максимальную из незавышенных искусственно оценок.
Бесполезно, менеджер в *типо скраме* объявит клиенту — через 2ч будет готово
Это уже проблема менеджера в «типо скраме».
Эстимейты устанавливает команда. Thats all, folks.
Если кто-то не может сказать менеджеру «Сорян, друг, но нет» — это уже его проблемы.
Эстимейты устанавливает команда. Thats all, folks.
Если кто-то не может сказать менеджеру «Сорян, друг, но нет» — это уже его проблемы.
Нет времени на полный анализ, срок нужно назвать в течении 5 мин. обычно.
Если «берется задача на исследование» — а сколько времени займёт исследовние? Нужно брать задачу «исследование для оценка сроков исследования»?
Т.е. перфразировав — оценка сложности задачи может занять от 1 до 7 дней — после этого будет точно известно сколько времени займёт её выполнение =)
Если «берется задача на исследование» — а сколько времени займёт исследовние? Нужно брать задачу «исследование для оценка сроков исследования»?
Т.е. перфразировав — оценка сложности задачи может занять от 1 до 7 дней — после этого будет точно известно сколько времени займёт её выполнение =)
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
Если вы достаточно точно оценивает задачи на спринт в среднем, то что вы достаточно сильно промахнулись с оценкой отдельных задач не так страшно. Где то больше, где то меньше, — если в сумме за спринт вы добились результата не так важно что одну задачу вы переоценили а другую недооценили. Точные оценки требуют времени, а время можно потратить с большей пользой. Но и вообще игнорировать оценки нельзя, это бардак.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
Это и есть ошибка человека, который привык эстимировать в часах и воспринимает СториПоинты как их аналог и именно потому мы использовали систему без цифр. Задача сложная или средняя? Если б в этой задаче не было рисков вы б назвали ее средней? То риски делают ее сложной. А время уже менеджер выводит, есть средние задачи, которые делаются день, а есть такие, которые делаются три дня, в среднем за счет объема оценка усредняется. А хорошему менеджеру не очень важно, что в силу технических причин именно эта задача заняла на два дня больше, чем любая другая с такой же оценкой в СП. Уже в среднесрочной перспективе эти два дня не играют никакой роли.
Разбивать на более мелкие задачи не пробовали?
Я понимаю, если руки чешутся взять и все нахерачить, скучно сидеть час-другой, расписывать большую задачу на десяток-другой элементарных.
Но мы же вводя скрам хотим предсказуемости, правильно? Другим способом предсказуемости не добиться.
Я понимаю, если руки чешутся взять и все нахерачить, скучно сидеть час-другой, расписывать большую задачу на десяток-другой элементарных.
Но мы же вводя скрам хотим предсказуемости, правильно? Другим способом предсказуемости не добиться.
НЛО прилетело и опубликовало эту надпись здесь
Так, судя по всему, ваши разработчики недовольны элементами тайм менеджмента, а не собственно scrum. Учет рабочего времени всегда вызывает недовольство, так как его никто не умеет правильно внедрять. Например, есть такое понятие как утилизация рабочего времени. Обычно, оно равно, примерно, 80%. Если все 100% времени распределять на задачи у вас вообще весь коллектив сбежит. Потом, на исправление багов нужно планировать определенный объем времени. Потом, есть задачи вне проектов (обучение, технологические задачи и т.д.). На них тоже планируют время.
Интересно было бы почитать мнение менеджеров этой же компании. Думаю не всё там так, как описывает автор.
Согласен с автором. Недавно внедрял Скрам и чуть не наступил на эти грабли излишнего закручивания гаек. Вовремя осознал и остановился. Надо уметь балансировать и иметь подход к разрабам. Тоже слышал такое от Бобука.
Одно из самых сильных что может убить компанию это оторванность менеджмента от земли и незнание, что происходит в цеху. К сожалению, это очень часто в наших компаниях. Западные компании с самого начала внедряют механизмы позволяющие владеть ситуацией.
Одно из самых сильных что может убить компанию это оторванность менеджмента от земли и незнание, что происходит в цеху. К сожалению, это очень часто в наших компаниях. Западные компании с самого начала внедряют механизмы позволяющие владеть ситуацией.
К разработчикам не нужно «иметь подход» и «закручивать гайки». Разработчики не подчинённые, а члены команды. Если менеджеры не разбираются в кухне разработки, то пусть лучше идут на завод управлять, где конвеер выдаёт определённое число деталей в сутки и их задача будет в том, чтобы заставлять работяг это требование выполнять.
Keks650, подскажите, а какой процесс использовался до перехода? он как-то был описан, сформулирован, осознан? или люди просто интуитивно правильно работали?
Любой бизнес всегда хочет знать «через сколько» он получит свою фичу. Если вся бизнес-задача уместилась в спринт, то все просто — это значит 1 фича в 2 неделя-спринта. Это бизнесу понятно. Но есть бизнес-задачи, которые могут длиться несколько спринтов, и любой менеджер захочет сразу знать сколько спринтов ему ждать результата. Значит в часы придется перевести, чтобы успокоить менеджера.
Например, во всем известной jira по дефолту оценка scrum'овских задач делается в часах.
Например, во всем известной jira по дефолту оценка scrum'овских задач делается в часах.
К сожалению, настоящее понимание Scrum'а втречается не часто. По сути — это как раз полная изоляция манагеров от команды разработчиков. Scrum'а master должен играть роль сторожевой собаки и пресекать любые поползновения любителей подогнать и надавить. Остальное все — детали, которые каждая команда подгоняет под себя и проект.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало.
Ну вот это как бы не то чтобы и хорошо, не то чтобы и плохо. Не все йогурты одинаково полезны, и не любая инициатива останется безнаказанной. В рамках SCRUM всё множество задач (backLog) изолируется спринтом(неделя например), и это очень удобно в первую очередь девелоперам, потому что никто тебе во время спринта никто не сможет поменять консистенцию спринта, поставить сверх срочную задачу (если не считать аварий и дичайших форсмажоров). И если у вас было не так, то у вас возможно это и было проблемой.
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени.
Можно у вас уточнить, это происходило только до внедрения SCRUM или так-же и после внедрения? Просто если в недельном спринте в команде из 4-5 человек каждый работает над 3-5 проектами сразу, то это игра в SCRUM. Только при этом создаются документальные прецеденты, вроде: «Если я сделал задачу А за 4 часа, значит я и впредь и всегда буду делать её за 4 часа и все другие девелоперы будут делать не меньше чем за 4 часа, иначе ситуация подлежит разбору и нервотрёпке.»
Я тоже соглашусь с asirazhi. Тут скорее всего не столько скрам виноват, как закрученные гайки таймменеджмента.
Вот еще вещь, которая режет глаз.
Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Ну то что, менеджеры конфликтуют в этом ничего страшного. А вот касались ли эти конфликты разработчиков? Между разработчиками и менеджерами должен быть один стейкхолдер, который оставит эти конфликты за скобками и создаст и донесёт внятный план на 1 спринт, на 4, и на 16 вперёд(на скрам грумингах это делается), чтобы разработчики могли правильно распланировать скорость внедрения новых фич и реализацию багов (технического долга).
И последнее:
А у вас точно все по канону было:
Ежеспринтовые пленинги, ежедневные стендапы, срединедельный груминг, демо и ретроспектива в конце спринта?
Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Это очень странно, поскольку по-хорошему надо бы делить разработчиков на команды с областью ответственности за определённые проекты/проект/части проекта, да и у «менеджеров», как вы их тут назвали, должно быть то же самое – каждый должен быть ответственен за какую-то часть и должен работать с определённой командой, привязанной к этой части.
у них обязательства перед заказчиками и никого не волнует занятость разработчиков
Разработчики сами по себе заняты? Или их опять-таки занимают все менеджеры подряд? Почему менеджеры не ставят перед заказчиками реальные сроки, исходящие от разработчиков?
Судя по всему, вся проблема всё-таки в гнилых эффективных говноменеджерах, которых понабрали хрен знает откуда, а не в методологии. Не нужно винить молоток в том, что строитель разбил им ваше стекло.
в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики.
Кто-то сильно «солгал» когда запускал этот проект :) С таким же успехом могли менять коврики у мышей с синих на фиолетовые. Менеджеры — безграмотные дауны… увы.
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
Мы начинаем ценить работу других людей, только когда начинаем делать ее сами :)
Знаешь как сделать быстрее — давай знания. Если не знаешь — заткнись и не мешай. Менеджеры — идиоты… увы.
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами.
А какие претензии к разработке? заказал задачи — получите задачи.
Удивляет, что есть технологические задачи?
Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
См начало: Кто-то сильно «солгал» когда запускал этот проект, поскольку хотел «уделать» своих конкурентов :)
Что и требовалось доказать: мы менеджеры безграмотные-дауны-имибицилы перегрыземся, между собой потому что не можем поуправлять между собой. А так как мы менеджеры-идиоты «все в белом», то мы еще и г#вн@ в вентилятор накидаем, что бы всем было не скучно…
Скрам, к тому что вы описали не имеет ровным счетом никакого отношения. Это просто безграмотная команда менеджеров, и с любым инструментом управления, получился бы точно такой-же п… ц.
То, что разработчики делают оттуда ноги — это самое разумное что они могут сделать, после того как доедят свой попкорн. увы.
Можно, было бы, сделать аудит процессов и привести систему в порядок, но это из разряда фантастики.
К сожалению, в данном конкретном случае Скрам не является главной проблемой. Хотя он и отстой, но описание событий больше похоже на что-то вроде: "Всё началось с того, что я сломал ноготь. Затем мне всадили нож под ребро. Затем ещё один нож в спину. Далее разрядили обойму в живот. А затем полоснули опасной бритвой по горлу. После чего я умер. Вот такие дела, котаны. Оказывается, сломанный ноготь — это верная смерть."
Притом, что исходный поинт абсолютно верный — Скрам действительно формализует процесс разработки. Т.е. перераспределяет приоритеты между формой процесса разработки и его содержанием в пользу формы и в ущерб содержанию. Закономерным образом это не нравится тем разработчикам, которые предпочитают "быть разработчиками", но зато очень нравится тем, кто предпочитает "работать разработчиком". Тем не менее, с этим всё равно можно работать. Нужно просто одновременно с внедрением Скрама массово набирать тех, кому нравится "работать разработчиками". А разработчиков-основателей постепенно переводить на некритичные участки работы или же вообще на тренерскую работу. И даже если исходить из того, что зайцы могут как-то стать ежиками, то это в любом случае отдельная задача, которую нужно как-то решать. Недостаточно просто внедрить систему, удобную для ежиков, там, где работают зайцы. Само по себе такое внедрение зайцев в ежиков не превратит.
Притом, что исходный поинт абсолютно верный — Скрам действительно формализует процесс разработки.
Любой SDLC формализует и пытается его сделать предсказуемым для бизнеса. От этого никуда.
Нужно просто одновременно с внедрением Скрама массово набирать тех, кому нравится «работать разработчиками»
Это не так, поскольку не запрещает делать ПО вам удобным (экономически обоснованным) способом.
Если карго-культ, то да… «это не нравится… постепенно переводить на....»
Если методология-костяк, описываемая несколькими принципами, превращается в священную корову с каноничным писанием на много-много страниц, объясняющих как же на самом деле надо правильно понимать и трактовать, чтобы не пополнить представительный набор примеров успешного развала коллективов, то что-то все же в методологии не так божественно, как кажется на первый или второй взгляд.
Проблема, конечно, чаще всего связана с насильственным внедрением; наличием ADD практик в компании; неверным выбором скрама в качестве методологии, которая сделает всем хорошо; упованием на волшебный авось и ту самую кривую, что путем коротких итераций и рестроспектив выведет на устойчивую орбиту эффективного зарабатывания бабла. Скрам зачастую не подходит. Компании, их клиенты/стейкхолдеры и область деятельности, требования к доставке — разные. Это стоит признать, а не продолжать насаждать карго-культ и поедать кактус на скорость.
Имел возможность наблюдать исход людей, подвергнутых испытанию скрамом. Видел утрату технической компетенции в команде. Отношусь к этой методологии скептически.
Проблема, конечно, чаще всего связана с насильственным внедрением; наличием ADD практик в компании; неверным выбором скрама в качестве методологии, которая сделает всем хорошо; упованием на волшебный авось и ту самую кривую, что путем коротких итераций и рестроспектив выведет на устойчивую орбиту эффективного зарабатывания бабла. Скрам зачастую не подходит. Компании, их клиенты/стейкхолдеры и область деятельности, требования к доставке — разные. Это стоит признать, а не продолжать насаждать карго-культ и поедать кактус на скорость.
Имел возможность наблюдать исход людей, подвергнутых испытанию скрамом. Видел утрату технической компетенции в команде. Отношусь к этой методологии скептически.
Честно говоря весь описанный негатив не имеет к Скраму никакого отношения.
Скажу больше — правильное внедрение Скрама предполагает, что разработчики кроме технических задач глубже погружаются в проблемы бизнеса, их видение проблем проекта становится шире и выходит за рамки чисто технических задач.
Конечно, многим нравится замыкаться на решении чисто технических задач и такие люди не любят думать о проблемах бизнеса. Для интровертов, а их в ИТ немало, это естественно. Но говорить, что из-за Скрама люди перестали чувствовать себя частью компании — значит противоречить духу Скрама.
Скажу больше — правильное внедрение Скрама предполагает, что разработчики кроме технических задач глубже погружаются в проблемы бизнеса, их видение проблем проекта становится шире и выходит за рамки чисто технических задач.
Конечно, многим нравится замыкаться на решении чисто технических задач и такие люди не любят думать о проблемах бизнеса. Для интровертов, а их в ИТ немало, это естественно. Но говорить, что из-за Скрама люди перестали чувствовать себя частью компании — значит противоречить духу Скрама.
Необязательно. У компаний могут меняться ценности, например главной ценностью объявляют удовлетворенности заказчика. Или банальную прибыль.
Получение прибыли является главной ценностью любого коммерческого предприятия по определению. А удовлетворенность заказчика — хороший инструмент достижения главной цели.
Но все же ни удовлетворенность заказчика, ни гонка за прибылью не противоречат ни вовлеченности разработчиков в проект, ни их личной творческой реализации. Все перечисленное вполне совместимо.
В описанной же ситуации мы видим пример карго-культа, то есть скопировали некоторые внешние атрибуты скрама при полном непонимании их сути.
Но все же ни удовлетворенность заказчика, ни гонка за прибылью не противоречат ни вовлеченности разработчиков в проект, ни их личной творческой реализации. Все перечисленное вполне совместимо.
В описанной же ситуации мы видим пример карго-культа, то есть скопировали некоторые внешние атрибуты скрама при полном непонимании их сути.
Получение — да, максимизация любой ценой — нет. Изначально компания могла создаваться по принципу: «есть функциональная ниша на рынке, в которых другие продукты в этой сфере или вообще не представлены, или эта функциональность реализована в „комбайнах“ для галочки. Мы можем сделать продукт, который будет делать только эту вещь и будет делать её отлично, плюс интеграция с комбайнами. Коммерческая цель — прибыль достаточная для неспешного развития и выплаты нам (стартовой команде) зарплаты и дивидендов процентов на 50 в сумме большей чем средняя по рынку зарплата для разработчиков, менеджеров и т. д. — нам миллионы не нужны, просто хороший для наших позиций доход при занятии любимым делом в команде единомышленников».
Под эти принципы находится главный инвестор (или им становится один из менеджеров, заложивший квартиру, напрмиер), всё хорошо несколько лет, но всё чаще поступают от клиентов просьбы (подкрепленные готовностью платить больше обычного) добавить ту или иную функциональность из того или иного комбайна, вместо интеграции с ним, поскольку комбайн брали для двух фич, одна из которых работает хорошо, другая для галочки и заменена нашим продуктом и, по сути, из комбайна используется только одна фича. В такой ситуации у менеджмента/инвестора возникает большой соблазн не просто реализовать эту фичу отдельным продуктом, который её делает тоже отлично, собрать под него отдельную команду и обеспечить глубокую интеграцию двух продуктов, а начать делать в отличном продукте одной фичи вторую фичу для галочки, в лучшем случае нормально, силами той же команды, максимум добавив несколько человек к ней, чтобы не срывать график релизов основной фичи. Сработало, пускай без энтузиазма, но сделали, а зарплата плюс дивиденды на 100% больше средней зарплаты по рынку мотивировали технарей-соучредителей довести работу по второй фичи для конца — кто-то ипотеку закрыл досрочно, кто-то смог позволить себе ребёнка.
Думали на этом успокоиться и вернуться к основной фиче продукта. Но главному инвестору понравилась увеличившаяся прибыль, возможно кому-то из технарей (или их женам) тоже и они продавливают решение «делаем новый комбайн, прогибаясь под хотелки клиентов — смотрите как удачно получилось по деньгам». Набирается народ по принципу «ты начальник — я дурак, я начальник — ты дурак», возможно новый главный инвестор ищется, которому первоначальный дух до лампочки, его лишь возврат инвестиций интересует, и хорошо если из дивидендов, а не изначально планирует продажу компании. Всё, первоначального духа в компании нет, это не компания одной фичи и дохода немного большего чем средняя зарплата, это компания одного комбайна с целью максимизации прибыли для инвестора. Всё. Ядро (прежде всего технари) начинают относиться просто как к работе за деньги, дивиденды (если они есть, а инвестор вполне может продавить решение полной реинвестиции прибыли) рассматривая как часть зарплаты, они уже не могут влиять на бизнес-решения, хорошо если технические принимают в духе «мы посовещались и я решил».
Под эти принципы находится главный инвестор (или им становится один из менеджеров, заложивший квартиру, напрмиер), всё хорошо несколько лет, но всё чаще поступают от клиентов просьбы (подкрепленные готовностью платить больше обычного) добавить ту или иную функциональность из того или иного комбайна, вместо интеграции с ним, поскольку комбайн брали для двух фич, одна из которых работает хорошо, другая для галочки и заменена нашим продуктом и, по сути, из комбайна используется только одна фича. В такой ситуации у менеджмента/инвестора возникает большой соблазн не просто реализовать эту фичу отдельным продуктом, который её делает тоже отлично, собрать под него отдельную команду и обеспечить глубокую интеграцию двух продуктов, а начать делать в отличном продукте одной фичи вторую фичу для галочки, в лучшем случае нормально, силами той же команды, максимум добавив несколько человек к ней, чтобы не срывать график релизов основной фичи. Сработало, пускай без энтузиазма, но сделали, а зарплата плюс дивиденды на 100% больше средней зарплаты по рынку мотивировали технарей-соучредителей довести работу по второй фичи для конца — кто-то ипотеку закрыл досрочно, кто-то смог позволить себе ребёнка.
Думали на этом успокоиться и вернуться к основной фиче продукта. Но главному инвестору понравилась увеличившаяся прибыль, возможно кому-то из технарей (или их женам) тоже и они продавливают решение «делаем новый комбайн, прогибаясь под хотелки клиентов — смотрите как удачно получилось по деньгам». Набирается народ по принципу «ты начальник — я дурак, я начальник — ты дурак», возможно новый главный инвестор ищется, которому первоначальный дух до лампочки, его лишь возврат инвестиций интересует, и хорошо если из дивидендов, а не изначально планирует продажу компании. Всё, первоначального духа в компании нет, это не компания одной фичи и дохода немного большего чем средняя зарплата, это компания одного комбайна с целью максимизации прибыли для инвестора. Всё. Ядро (прежде всего технари) начинают относиться просто как к работе за деньги, дивиденды (если они есть, а инвестор вполне может продавить решение полной реинвестиции прибыли) рассматривая как часть зарплаты, они уже не могут влиять на бизнес-решения, хорошо если технические принимают в духе «мы посовещались и я решил».
Исяходя из кейса, я бы сказал, что команда отлично работала по 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, не понимая того, что у них он был, а потом они его зачем-то сломали в пользу измерения часов и усиления контроля (что — полностью противоположно принципам). Такие дела.
Важно понимать, что 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, не понимая того, что у них он был, а потом они его зачем-то сломали в пользу измерения часов и усиления контроля (что — полностью противоположно принципам). Такие дела.
Вообще я пришел к выводу, что скрам это аджаил для мэнеджмента. Все эти оценивания примеривания, надзор, таим трекинг и вечное желание сделать больше поинтов противоречат самой сути манифеста.
Во-первых, это постоянная вражда из-за стори поинтов, кто больше сделал, кто главнее и тд.
Во-вторых, в угоду поинтам пишется говнокод.
В-третьих, зацикленность на маленьких задачах пораждает проблемы при рефакторинге легаси.
В-четвертых, уж не знаю почему, но каждый мэнэджер хочет больше поинтов каждый спринт, но при этом не учитывается инфляция этих поинтов. Например на создание первой кнопки уходит 4 поинта. Но при повторном таске кнопка оценивается в 1 или 0 поинтов. Автоматизировать что-либо по сути не выгодно — у хорошего разработчика затрачивается больше поинтов, чем у джуна. В глазах менеджмента он тормоз.
Можно сказать что мы не правильно готовим, но я уже столкнулся с похожей проблемой в 3 разных организациях. И если это так тяжело готовить, то стоит ли оно того? Где гарантия, что при идеальном скраме не придет новый оунер и не устроит вышеописанный хаос. И не дорого ли средней организации увольнять всех пмов, чтобы набрать скрам мастеров?
Про то что разработчики не в Северной Корее можно не читать — большинство людей не хотят спорить, бегать, прыгать — они хотят приходить на работу, спокойно её делать и уходить домой на час раньше с улыбкой на лице.
Во-первых, это постоянная вражда из-за стори поинтов, кто больше сделал, кто главнее и тд.
Во-вторых, в угоду поинтам пишется говнокод.
В-третьих, зацикленность на маленьких задачах пораждает проблемы при рефакторинге легаси.
В-четвертых, уж не знаю почему, но каждый мэнэджер хочет больше поинтов каждый спринт, но при этом не учитывается инфляция этих поинтов. Например на создание первой кнопки уходит 4 поинта. Но при повторном таске кнопка оценивается в 1 или 0 поинтов. Автоматизировать что-либо по сути не выгодно — у хорошего разработчика затрачивается больше поинтов, чем у джуна. В глазах менеджмента он тормоз.
Можно сказать что мы не правильно готовим, но я уже столкнулся с похожей проблемой в 3 разных организациях. И если это так тяжело готовить, то стоит ли оно того? Где гарантия, что при идеальном скраме не придет новый оунер и не устроит вышеописанный хаос. И не дорого ли средней организации увольнять всех пмов, чтобы набрать скрам мастеров?
Про то что разработчики не в Северной Корее можно не читать — большинство людей не хотят спорить, бегать, прыгать — они хотят приходить на работу, спокойно её делать и уходить домой на час раньше с улыбкой на лице.
Мне кажется, тут проблема не в процессе, а в его непонимании (во-первых) и отсутствии эффективной коммуникации между разработчиками и менеджерами во-вторых.
Те же проблемы миграции между версиями фреймворков легко объясняются понятием Technical Debt, и тыканьем в статьи о том, как он управляется через призму Скрама. Также до менеджмента надо доносить, что есть технические стори — которые дают выигрыш в производительности в будущем.
Ну и строго говоря, скрам как процесс рассчитан как раз на гармоничное сосуществование менеджеров и разработчиков, когда одни могут эффективно доносить до других те проблемы, которые надо решить для жизнедеятельности проекта и со стороны разработки, и со стороны управления. А то, что описываете вы это попытка бездумно навязать только одну точку зрения в экстремальном виде, прикрываясь переходом на новый процесс.
При этом с одной стороны, менеджеры явно зарвались, а с другой стороны, во всей команде разработки не нашлось людей, которые смогли бы эффективно донести свою позицию до руководства. Что тоже странно.
Те же проблемы миграции между версиями фреймворков легко объясняются понятием Technical Debt, и тыканьем в статьи о том, как он управляется через призму Скрама. Также до менеджмента надо доносить, что есть технические стори — которые дают выигрыш в производительности в будущем.
Ну и строго говоря, скрам как процесс рассчитан как раз на гармоничное сосуществование менеджеров и разработчиков, когда одни могут эффективно доносить до других те проблемы, которые надо решить для жизнедеятельности проекта и со стороны разработки, и со стороны управления. А то, что описываете вы это попытка бездумно навязать только одну точку зрения в экстремальном виде, прикрываясь переходом на новый процесс.
При этом с одной стороны, менеджеры явно зарвались, а с другой стороны, во всей команде разработки не нашлось людей, которые смогли бы эффективно донести свою позицию до руководства. Что тоже странно.
То есть вместо статей о подводных камнях апгрейда фреймворка читать статьи о подводных камнях методологии управления, внедренной сверху.
Это не подводные камни методологии, а следствия особенностей разработки ПО, не понятных менеджерам, особенно привлеченным со стороны. Истина про «скупой платит дважды» зачастую очень сложна, поэтому часто прослеживается «а чего это вы время тратите на непонятную фигню — давайте лучше вот эту фичу прикрутим». При чём, чем дальше человек от разработки, тем чаще такая логика встречается.
И такая проблема встречается всегда, когда начинают трекать время и задавать вопросы.
При этом есть обратная сторона — если время совсем не трекать, и дать разработчикам делать всё, что их душе угодно — можно на выходе получить очень красивое с технологической стороны решение, которым никто не будет пользоваться. Обратная сторона не всегда случается, конечно же, потому что некоторые разработчики достаточно опытны, чтоб понимать потребности бизнеса. Но это та же история, что и с крутым менеджментом — всё просто и без проблем работает.
И такая проблема встречается всегда, когда начинают трекать время и задавать вопросы.
При этом есть обратная сторона — если время совсем не трекать, и дать разработчикам делать всё, что их душе угодно — можно на выходе получить очень красивое с технологической стороны решение, которым никто не будет пользоваться. Обратная сторона не всегда случается, конечно же, потому что некоторые разработчики достаточно опытны, чтоб понимать потребности бизнеса. Но это та же история, что и с крутым менеджментом — всё просто и без проблем работает.
Скрам удобен для манагеров. Скрам неудобен для разработчиков. Поэтому он внедряется не разработчиками (которым он только добавляет головняка и поэтому он им нафиг не нужен), а менеджерами (которые, таким образом сваливают свои обязанности на разработчиков).
Поэтому манагеры описывают скрам с восторгом, а недовольных разработчиков, сбежавших от нечеловеческой методологии обвиняют в том, что у них был "неправильный" скрам. Причём, отчего-то почти у всех получается именно "неправильный" скрам. По-моему, скрам — это анти-эджайл.
Отдельные случаи успешного внедрения "снизу", насколько я понимаю, редки и являются лишь статистическими выбросами.
А чем вам, как разработчику, не удобен скрам?
Ну, если можно, то развернуто и по пунктам. При этом постарайтесь, пожалуйста, абстрагироваться от сферического вотерфолл в вакууме, когда «мне просто дали идеально проработанное тз на 500 страниц, а я написал код, который идеально работает», а всё таки придти к жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Ну, и я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще.
Ну, если можно, то развернуто и по пунктам. При этом постарайтесь, пожалуйста, абстрагироваться от сферического вотерфолл в вакууме, когда «мне просто дали идеально проработанное тз на 500 страниц, а я написал код, который идеально работает», а всё таки придти к жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Ну, и я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще.
А кто-нибудь видел настоящий скрам, а не СкрамНО? Только не по мнению скрам-мастера, Owner-a или ещё кого-то, а именно по мнению разработчика.
Я видел scrumban, один раз в российских реалиях, пару раз в международных.
Плюс, пара знакомых которые так же вполне успешно и счастливо работают по довольно каноничному scrum, без всего перечисленного в вашей статье.
Плюс, пара знакомых которые так же вполне успешно и счастливо работают по довольно каноничному scrum, без всего перечисленного в вашей статье.
Я видел скрам на 2 долгих проектах. Отличный процесс, в котором когда надо ужимался скоуп для того, чтоб впихнуть технические стори, постоянно закрывался технический долг и даже сроки когда надо двигались.
Проблема не в процессе, а в очень небольшом количестве грамотных менеджеров. Да и разработчиков, которые постоянно думают не только о красивом решении проблемы, но и о потребностях бизнеса — очень немного.
Проблема не в процессе, а в очень небольшом количестве грамотных менеджеров. Да и разработчиков, которые постоянно думают не только о красивом решении проблемы, но и о потребностях бизнеса — очень немного.
Я видел работающий скрам. Внедрение было не очень приятное, но в итоге получилось достаточно удобно, и проект в итоге вытянули(внедрять начали, когда осознали, что со сроками немножко печаль). Но там скрам-мастером поставили технического специалиста, и задачи в беклог шли в том числе от разработчиков. В наш админский беклог они шли вообще практически только от самих админов и от смежных отделов.
Как минимум, потерей времени на организацию процессов. Было: есть разработчики, есть «девелоперс аунер», ставятся задачи, дается оценка в часах, выставляется очередность, диаграммы Ганта или что-то вроде них показывают дедлайны. Часто очередность меняется (особенно при изменении оценки в ходе) и вообще появляются новые первоочередные задачи, но все менеджеры Ганту видят сдвиги своих задач и, если что-то не так, разбираются сами между собой. Разработчик если и тратит время на процессы, то только чтобы внести в треккер первоочередную задачу, поставленную большим боссом устно. Премии платятся за внедренные по плану «эпики», очень важные для бизнеса.
Внедряется скрам, обычно сверху и «по учебнику», разработчики становятся участниками планирования, тратя на это время, которое могли бы потратить на задачи. И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то. До этого обязательств не было, была оценка. Как минимум, меняет моральный настрой, если внезапная первоочередная задача не позволила выполнить все задачи спринта, не позволила выполнить обязательства. Особенно, если задачи можно было бы успеть решить вместе с первоочередной, не тратя время на скрам-ритуалы. И да, премии, перестают платиться — зачем платить за исполнение обязательств? Максимум платятся как оплата за сверхурочные, чтобы всё закончить спринт по плану, если продакт аунер решил и смог пробить.
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Менеджер подает руководству красивые планы, но перестает нести персональную ответственность за их выполнение — это же решение команды.
Внедряется скрам, обычно сверху и «по учебнику», разработчики становятся участниками планирования, тратя на это время, которое могли бы потратить на задачи. И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то. До этого обязательств не было, была оценка. Как минимум, меняет моральный настрой, если внезапная первоочередная задача не позволила выполнить все задачи спринта, не позволила выполнить обязательства. Особенно, если задачи можно было бы успеть решить вместе с первоочередной, не тратя время на скрам-ритуалы. И да, премии, перестают платиться — зачем платить за исполнение обязательств? Максимум платятся как оплата за сверхурочные, чтобы всё закончить спринт по плану, если продакт аунер решил и смог пробить.
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Менеджер подает руководству красивые планы, но перестает нести персональную ответственность за их выполнение — это же решение команды.
И берут на себя, как основная часть скрам-команды, обязательства сделать за неделю-две то-то и то-то.
В современном скраме этого нет. Даже нет оценки того, что можно сделать за спринт. Есть предсказание
"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."
Ситуация усугубляется, если несколько проектов на одну команду, каждая со своим продакт аунером, в разборки между ними вовлекаются разработчики на планировании спринтов, времени на планирование тратится ещё больше.
Не могу с ходу привести цитату, но мне кжется, это вообще антипаттерн.
Пока у нас не внедряли скрам, к нашим оценкам относились именно как к предсказаниям, прогнозам. Как начали внедрять, все стали воспринимать как обязательство. Собственно митинги ближе к концу спринта начинались с фразы «ребята, уже понятно, что свои обязательства выполнить не сможем, давайте посмотрим что сможем доделать».
Во, кстати, с целью спринта. У нас было: «реализовать фичу А в системе 1, фичу Б в системе 2 и пофикстить баг в системе 3№.
Во, кстати, с целью спринта. У нас было: «реализовать фичу А в системе 1, фичу Б в системе 2 и пофикстить баг в системе 3№.
А какой был размер спринта? Планирование осуществлялось с учетом накопленной статистики о скорости команды или разработчики оценивали в календарных днях?
Кстати, Интересный доклад о том, что оценка имеет вероятностный характер и про NoEstimates
А чем вам, как разработчику, не удобен скрам?
Ну, если можно, то развернуто и по пунктам
1 "митингами"
2 "митингами"
3 "митингами"
4 выполнением за менеджеров (части) их обязанностей
5 работой в режиме постоянного стресса
жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Вообще-то аджайл не про это придумали. А вот скрам — про это. И поэтому он — антиаджайл.
я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще
Менеджерам неудобен аджайл. Менеджерам удобен скрам. Он позволяет скинуть часть их работы на бедолаг разработчиков.
Не уверен, специально вы передергиваете, или по незнанию.
Во первых, аджайл придумали именно про это. Что бы не отсылать вас в глубины умных книжек, просто оставлю вам статью на википедию.
Если вы прочитаете хотя бы её, то там подробно изложено что и зачем. Короткие итерации — из-за постоянно меняющихся требований. Беспрерывная доставка — из-за необходимости развивать продукт динамично. И т.д.
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
По поводу претензий, я специально попросил развернуто, потому что ваши пункты не звучат конструктивно.
Окей, целых три пункта про митинги. Какие митинги в скрам делают вашу работу столь невыносимой?
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса? Я не видел более удачных способов синхронизировать между собой, это или полный хаос и «каждый в своём углу херачит неизвестно что» или бредовые письменные репорты и прочий ад.
В любом случае, даже если предположить что вам глубоко положить на то, чем занимаются ваши коллеги по команде — вполне можно потратить 10 минут в день, что бы _они_ знали, чем занимается команда.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два? Опять же, мне не кажется, что это безумное количество времени, которое нельзя потратить, что бы попытаться вместе с коллегами улучшить процесс работы.
Самый муторный из оных — планирование спринта, с разбором и оценкой задач и вот этим всем. Эта штука может сожрать дохрена времени. Но, надо понимать, что единственная его цель — что бы команда понимала, что нужно сделать. Если вам приходят уже понятные и проработанные требования, то разбор задач на 3 недели для 15 человек занимает… от двух до трех часов. С декомпозицией, оценкой и вот этим всем.
Неприятно, но 2-3 часа в неделю на три недели работы — как-то немного маловато, что бы при этом со слюной у рта кричать «ДОСТАЛЕ МИТИНГИ!!11».
Если планирование, оценка и декомпозиция занимает больше времени — значит на ней объясняются и выясняются требования. Чем более неясны требования — тем дольше будет разбор задач. Но, нужно понимать, что все эти вопросы в любом случае всплыли бы, просто скорее всего позже — когда код (или по крайней мере его часть) уже написана и внесение изменений будет дороже.
Т.е. вы тратите время на митинг сейчас, что бы не перепиливать задачи в последний момент. На мой взгляд — вполне оправданное вложение времени.
В целом, на трехнедельный спринт вы потратите от 5 до 8 часов. Больше никаких обязательных митингов, затрагивающих типичного разработчика, в скраме нет.
8 часов из 120 — это дофига? Я вот так не думаю.
P.S. Все это, конечно, работает только при одном важном условии. Должен выполняться один из важнейших принципов Agile Manifesto:
Причем, выполнять его должны не только менеджеры и «заказчики», выполнять его должны в первую очередь разработчики.
Во первых, аджайл придумали именно про это. Что бы не отсылать вас в глубины умных книжек, просто оставлю вам статью на википедию.
Если вы прочитаете хотя бы её, то там подробно изложено что и зачем. Короткие итерации — из-за постоянно меняющихся требований. Беспрерывная доставка — из-за необходимости развивать продукт динамично. И т.д.
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от 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
Причем, выполнять его должны не только менеджеры и «заказчики», выполнять его должны в первую очередь разработчики.
Но, нужно понимать, что все эти вопросы в любом случае всплыли бы
Уточнить требования нужно одному человеку у другого, а вся команда сидит и слушает…
Угу, и при подходе «одному надо уточнить» очень часто потом вся команда работает в оверхедах, потому что зачем их мнение спрашивать — ониж работать должны.
Плюс к тому люди, которые непосредственно выполняющие какую-то работу вполне могут дать очень дельные комментарии. В итоге, исходя из личного опыта ситуация «один уточняет — другие делают» работает в разы хуже, и для команды, и для клиента.
Возможно, мне просто не везло с уточняющими — поэтому у нас очень разное восприятие того, как лучше.
Плюс к тому люди, которые непосредственно выполняющие какую-то работу вполне могут дать очень дельные комментарии. В итоге, исходя из личного опыта ситуация «один уточняет — другие делают» работает в разы хуже, и для команды, и для клиента.
Возможно, мне просто не везло с уточняющими — поэтому у нас очень разное восприятие того, как лучше.
Во первых, аджайл придумали именно про это.
Нет, не про это. Его придумали для того, чтобы снизить уровень стресса у разработчиков. В принципе, именно это делает норманый менеджер. Но, видимо, нормальных мало :).
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Да, верующие в него так и говорят. Но это не обязательно так и есть. Он напрямую противоречит аджайл манифесту. Пункту первому и немного последнему.
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
Скрам сосредоточен на процессах. Вы сосредоточены на процессах. А первый, но же главный принцип манифеста какой? Напомнить? Individuals and interactions over processes and tools. В скраме определённо processes and tools over individuals and interactions. Поэтому скрам — антиаджайл.
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса?
Да. Это процесс превыше людей. Еженедельный "митинг" — куда ни шло. Ежедневный — бежать.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два?
И это тоже. И далее также. Это всё формальный process over individuals. Антиаджайл.
Скорее, мало кто понимает, что такое скрам. И все выхватывают то, что привлекает их.
А поскольку некоторые менеджеры изначально считают, что они главные — получается палочная система под лозунгом аджайла, на которую навешивают тайм трекинд с загрузкой 8/8.
На моём первом скрам-проекте был нанят внешний скрам-мастер. И первые полгода она чуть ли не палкой била менеджера (PO) во время каждого митинга, пока тот не отучился от привычки раздавать команды в стиле «шоб завтро булО!».
А поскольку некоторые менеджеры изначально считают, что они главные — получается палочная система под лозунгом аджайла, на которую навешивают тайм трекинд с загрузкой 8/8.
На моём первом скрам-проекте был нанят внешний скрам-мастер. И первые полгода она чуть ли не палкой била менеджера (PO) во время каждого митинга, пока тот не отучился от привычки раздавать команды в стиле «шоб завтро булО!».
Отличный рецепт как не надо готовить Agile.
Вот список ошибок и советов:
1. Нет равенства в команде. Менеджер — это такой же член команды как и все остальные и с ним можно не соглашаться (обоснованно).
2. Никто в команде не должен продавливать свои решения. Оценка сложности задач делается совместно. Приоритеты выставляются тоже совместно.
3. Увольте менеджеров-прапоршиков. В идеале менеджерами должны становиться те, кто пришёл из разработчиков или аналитиков. Ваши менеджеры не заинтересованы в результате, а заинтересованы сделать больше/заплатить меньше. Пересмотрите KPI или систему премирования менеджеров. В идеале пусть работают за зарплату + премия на всю комаду по прохождению релиза / важной вехи.
4.Ставьте во главу угла не сроки и даже не деньги, а удовлетворённость клиента и удобство продукта
5. Оставляйте простор для творчества. Вносите в беклог предложения и улучшения. Выделяйте 2-4 недели на R&D после каждого большого релиза. (или хотя бы месяц в году).
Конечно у скрама тоже есть проблемы, например:
— Проект часто плывёт по-течению «беклога» и важные архитектурные проблемы не решаются. Из-за этого проект скатывается в разномастный набор фич вместо цельного продукта.
— Как уже было сказано выше — мало времени выделяется на улучшение продукта, которые не будут видны заказчику, но позволят в будущем сократить время разработки и сэкономить на поддержке
Но все эти проблемы решаемы. Не зря же это Agile, т.е. гибкий подход…
Вот список ошибок и советов:
1. Нет равенства в команде. Менеджер — это такой же член команды как и все остальные и с ним можно не соглашаться (обоснованно).
2. Никто в команде не должен продавливать свои решения. Оценка сложности задач делается совместно. Приоритеты выставляются тоже совместно.
3. Увольте менеджеров-прапоршиков. В идеале менеджерами должны становиться те, кто пришёл из разработчиков или аналитиков. Ваши менеджеры не заинтересованы в результате, а заинтересованы сделать больше/заплатить меньше. Пересмотрите KPI или систему премирования менеджеров. В идеале пусть работают за зарплату + премия на всю комаду по прохождению релиза / важной вехи.
4.Ставьте во главу угла не сроки и даже не деньги, а удовлетворённость клиента и удобство продукта
5. Оставляйте простор для творчества. Вносите в беклог предложения и улучшения. Выделяйте 2-4 недели на R&D после каждого большого релиза. (или хотя бы месяц в году).
Конечно у скрама тоже есть проблемы, например:
— Проект часто плывёт по-течению «беклога» и важные архитектурные проблемы не решаются. Из-за этого проект скатывается в разномастный набор фич вместо цельного продукта.
— Как уже было сказано выше — мало времени выделяется на улучшение продукта, которые не будут видны заказчику, но позволят в будущем сократить время разработки и сэкономить на поддержке
Но все эти проблемы решаемы. Не зря же это Agile, т.е. гибкий подход…
1. Никогда не будет абсолютного равенства в любом обществе, особенно в формальном. Менеджер на то и менеджер. Если не он, то кто-нибудь другой.
2. Я продавливаю идею хорошего кода, тестов и ревью. Если собираемся вместе — начинается балаган и война. Лучшие проекты это часто диктатура адекватного разработчика. + сборы стоят денег
С остальными пунктами согласен. Но их нет в тех материалах которые читают манагеры. На деле скрам похож на систему гос. законов, в случае которых тебя сажают в яму и обвиняют что ты не умеешь готовить.
2. Я продавливаю идею хорошего кода, тестов и ревью. Если собираемся вместе — начинается балаган и война. Лучшие проекты это часто диктатура адекватного разработчика. + сборы стоят денег
С остальными пунктами согласен. Но их нет в тех материалах которые читают манагеры. На деле скрам похож на систему гос. законов, в случае которых тебя сажают в яму и обвиняют что ты не умеешь готовить.
НЛО прилетело и опубликовало эту надпись здесь
Зарплату платит бухгалтерия. Премию тоже. Индивидуальные подвиги - зло.
В вопросах изменения ставки зарплаты (и увольнения) должны участвовать ключевые сотрудники команды. Один лишь менеджер не может полноценно оценить работу разработчика.
В вопросах изменения ставки зарплаты (и увольнения) должны участвовать ключевые сотрудники команды. Один лишь менеджер не может полноценно оценить работу разработчика.
А при чём тут зарплата и премии? Эти вопросы к конкретному проекту отношения не имеют. В хороших компаниях зарплата и премия считается на основании Performance Review (или вклада сотрудника в развитие компании).
Тут вопрос в том, что менеджер не должен единолично принимать решения не ставя в известность команду, т.к. реализовывать не только ему. Другое дело что после обсуждения с командой именно менеджер примет финальное решение — это и есть его роль.
Тут вопрос в том, что менеджер не должен единолично принимать решения не ставя в известность команду, т.к. реализовывать не только ему. Другое дело что после обсуждения с командой именно менеджер примет финальное решение — это и есть его роль.
"<...>ведь у любой монеты, как оказалось <...>" срыв покровов уровня /b или показалось?
Г. является именно скрум, он отнимает по крайней мере 80% времени, там где его применяют со всей тщательностью.
Плюс добавляются люди, которые в большом количестве сильно мешают разработке. У нас было на одного девелопера примерно 20 BA, начальников над кем-то, скрум мастеров, огромного числа людей, который были очень плохими разработчиками, то есть совсем не умели кодировать, а теперь командуют старшими разработчиками.
Скрум приживатеся в компаниях, доход которых не зависит от разработки.
Плюс добавляются люди, которые в большом количестве сильно мешают разработке. У нас было на одного девелопера примерно 20 BA, начальников над кем-то, скрум мастеров, огромного числа людей, который были очень плохими разработчиками, то есть совсем не умели кодировать, а теперь командуют старшими разработчиками.
Скрум приживатеся в компаниях, доход которых не зависит от разработки.
Скрам как раз-таки лучше всего приживается в чисто ИТ компаниях (особенно конслатинговых). Потому что если это ИТ департамент какой-то большой фирмы, то в лучшем случае получится какое-то подобие скрама из-за неприятия формата со стороны подразделения-заказчика и важности бумажек и прочей бюрократии.
Судя по описанию — вы работали(те) в весьма странной компании. Какой IT бизнес может выдержать такую нагрузку левыми людьми, представить мягко говоря сложно.
Забавно смотреть на ИТ-отрасль, особенно из-за того, что в ней много творческих, увлеченных людей. «К разработчикам надо относиться как к детям» — к сожалению, этим пользуются ушлые менеджеры.
Каждая новая методика или технология воспринимается как панацея.
Но, кроме творчества и влеченности, отличетельной чертой ИТ-отрасли являлется очень узкий гругозор.
Я хочу сказать, что большинство «новых» методик и технологий имеют возраст в несколько десятков лет и 2-3 итерации забвения.
Приведу примеры «килер-фич» из смежной области, управленческого менеджента:
— «ABC-costing». 10-15 лет назад: методика управления накладными расхода. Куча книг, десятки семинаров, много проектов по внедрению. Результат — она забыта. Причина — ни одго успешного проекта внедрения.
— KPI — медодика управления предприятием с использованием «ключевых показателей». Изначально выглядела как некий dush-board предприятия — по 4-5 показателя на производство, финансы, маркетинг и персонал. За посление 15 лет доведена до абсурда — по сути превратилась во внедрение «сдельщины» по всех профессиях. Много компаний превратились в «террариум единомышленников» благодаря этому.
— «описание бизнес-процессов» — здравая в начале идея доведена до бюрократического формализма — к моменту завершания описания всех процессов и создания по ним инструкций компании может уже и не быть. Реально работает в узких отраслях и подсистемах — СМК ISO9000 и низовые процессы по исполнителям при разработке ПО.
— «бюджетирование» — старая как мир идея в очередной раз полюбилась публике 15 лет назад, когда новын бизнесмены прочитали такое в газетах (о том, что оно десятилетиями работало — они ещё не знали). Запустилось множество проектов во многих странах и компаниях. В текущий момент идея жива в кулуарах — реальные работающие системы бюджетирования не выходят дальше Экселя и конкретных людей, знающих специфику именно этой компании и её продукцтов. Ни одной общепринятой технологической платформы все ещё нет.
— «20% времени на личные проекты» — можная фишка для модной компании. Став корпорацией, Гугел как-то незаметно прикрыл лавочку.
В общем, ко всем этим «модным» технлогиям надо выждать время — года 2-3, а лучше 5. В большинстве случаев они перестаю быть модными и исчезают.
Пока ещё не опровергнута классика управления: стратегические цели — план их достижения пошагово — цели и задачи на каждом шаге — тактика по достижению локальных целей и задач.
Имеено по этому шаблону надо оценивать метолики и теории и определять их место.
Отсюда же связка Проектант — инженер — прораб — строитель, ой, CTO — продакт менеджер — проджект менеджер — разработчик.
Почти все таории, описанные выше, пытались покрыть эту цепочку частично или целиком.
Кратко по скруму — это так называемый «простой неправильный ответ на сложный вопрос».
Состоит он из смеси атомарных бизнесс-процессов, обещания счастья для неспециалистов и KPI в творческих профессиях. Уже сам набор компонентов вызывает скепсис по жизнепособности: про стратегию нет вообще ни слова, голая тактика на 2 недели с отжимом продуктивности по KPI — сомнительная на марафонской дистанции аврально-потогоная система.
Каждая новая методика или технология воспринимается как панацея.
Но, кроме творчества и влеченности, отличетельной чертой ИТ-отрасли являлется очень узкий гругозор.
Я хочу сказать, что большинство «новых» методик и технологий имеют возраст в несколько десятков лет и 2-3 итерации забвения.
Приведу примеры «килер-фич» из смежной области, управленческого менеджента:
— «ABC-costing». 10-15 лет назад: методика управления накладными расхода. Куча книг, десятки семинаров, много проектов по внедрению. Результат — она забыта. Причина — ни одго успешного проекта внедрения.
— KPI — медодика управления предприятием с использованием «ключевых показателей». Изначально выглядела как некий dush-board предприятия — по 4-5 показателя на производство, финансы, маркетинг и персонал. За посление 15 лет доведена до абсурда — по сути превратилась во внедрение «сдельщины» по всех профессиях. Много компаний превратились в «террариум единомышленников» благодаря этому.
— «описание бизнес-процессов» — здравая в начале идея доведена до бюрократического формализма — к моменту завершания описания всех процессов и создания по ним инструкций компании может уже и не быть. Реально работает в узких отраслях и подсистемах — СМК ISO9000 и низовые процессы по исполнителям при разработке ПО.
— «бюджетирование» — старая как мир идея в очередной раз полюбилась публике 15 лет назад, когда новын бизнесмены прочитали такое в газетах (о том, что оно десятилетиями работало — они ещё не знали). Запустилось множество проектов во многих странах и компаниях. В текущий момент идея жива в кулуарах — реальные работающие системы бюджетирования не выходят дальше Экселя и конкретных людей, знающих специфику именно этой компании и её продукцтов. Ни одной общепринятой технологической платформы все ещё нет.
— «20% времени на личные проекты» — можная фишка для модной компании. Став корпорацией, Гугел как-то незаметно прикрыл лавочку.
В общем, ко всем этим «модным» технлогиям надо выждать время — года 2-3, а лучше 5. В большинстве случаев они перестаю быть модными и исчезают.
Пока ещё не опровергнута классика управления: стратегические цели — план их достижения пошагово — цели и задачи на каждом шаге — тактика по достижению локальных целей и задач.
Имеено по этому шаблону надо оценивать метолики и теории и определять их место.
Отсюда же связка Проектант — инженер — прораб — строитель, ой, CTO — продакт менеджер — проджект менеджер — разработчик.
Почти все таории, описанные выше, пытались покрыть эту цепочку частично или целиком.
Кратко по скруму — это так называемый «простой неправильный ответ на сложный вопрос».
Состоит он из смеси атомарных бизнесс-процессов, обещания счастья для неспециалистов и KPI в творческих профессиях. Уже сам набор компонентов вызывает скепсис по жизнепособности: про стратегию нет вообще ни слова, голая тактика на 2 недели с отжимом продуктивности по KPI — сомнительная на марафонской дистанции аврально-потогоная система.
Скрам появился, потому что клиент часто не понимает, что ему надо. И в результате получает не то, что ему было надо/закрывал проект. Появился он не от хорошей жизни, и не как киллер фича, а как попытка дать ответ на вопрос «как максимально быстро дать клиенту посмотреть, что у нас получается, получить фитбек и внести коррективы». Плюс возможность частых релизов (раз в 1-2 недели).
Это не серебренная пуля, и она далеко не всегда подходит. К примеру, его сомнительно использовать для разработки ПО для ракеты или атомной станции, потому что там требования четко определены на старте и не будут меняться — в этом случае процесс будет скорее мешать. Точно также, в случае мейнтенанс команды скрам подходит плохо, потому что постоянно появляются высокоприоритетные таски, которые должны решаться ASAP. Скрам с его итерациями в этом случае подходит плохо.
Да, Скрам зарождаться начал в 1986 году, а манифест был написан в 2001. «Модная технология» выждала где-то в 3-8 раз больше времени — и исходя из наблюдений количество проектов на нём (и других гибких) только растёт, а вот классика управления (RUP) используется всё реже.
Это не серебренная пуля, и она далеко не всегда подходит. К примеру, его сомнительно использовать для разработки ПО для ракеты или атомной станции, потому что там требования четко определены на старте и не будут меняться — в этом случае процесс будет скорее мешать. Точно также, в случае мейнтенанс команды скрам подходит плохо, потому что постоянно появляются высокоприоритетные таски, которые должны решаться ASAP. Скрам с его итерациями в этом случае подходит плохо.
Да, Скрам зарождаться начал в 1986 году, а манифест был написан в 2001. «Модная технология» выждала где-то в 3-8 раз больше времени — и исходя из наблюдений количество проектов на нём (и других гибких) только растёт, а вот классика управления (RUP) используется всё реже.
Как тут некоторые написали — scrum это реально постоянный стресс. Более того, постоянно изменяющимся пожелания менеджера по одной задаче ( поправь тут, слушай давай передедаем по-быстрому, тут ведь не долго), необходимость на часовом митинге более менее реально оценить объем работы, практически постоянная работа ( нужно ж и балду погонять, чтоб с мыслями собраться или зачитнуть какую-нибудь статью по твоей теме, чтобы расширить кругозор) — все это истощает. У нас ушло несколько людей по этим причинам
И что, все эти менеджеры/мастера не заметили падения индекса счастья? Значит, это был не скрам, ибо контроль за счастьем по методике прямо в базе прописан.
А можно ссылку на индекс счастья? Нет, серьёзно не слышал просто. Интересно как мерить предлагают.
Количественная сторона счастья
Как мы можем сделать счастливыми себя, своих подчиненных, своих коллег по команде? Как преобразовать счастье в продуктивный труд, приносящий прибыль?
Чтобы ответить на все вопросы, обратимся снова к Toyota и крестовому походу Тайити Оно, объявленному им против потерь. Ликвидация потерь – высокая цель, приведшая Оно к идее непрерывного совершенствования. Недостаточно достичь определенного уровня производительности и успокоиться на этом. Следует постоянно анализировать рабочие процессы и неустанно улучшать их. Увы, совершенство недостижимо, но любой шаг в его сторону будет оправдан.
Точно так же, как мы распределяем работу на легко управляемые короткие циклы, а рабочее время разбиваем на небольшие промежутки, так и усовершенствование необходимо делить на фазы, чтобы на каждый отрезок времени приходилось по одной фазе улучшения. Понятие «непрерывное совершенствование» в японском языке передается словом кайдзен. Какие помехи можно устранить за один раз и таким образом добиться небольшого улучшения – и так, шаг за шагом, осуществлять идею непрерывного совершенствования?
В методологии Scrum этот вопрос рассматривают в конце каждого спринта во время ретроспективных собраний. Члены группы рассказывают о заданиях, выполненных за прошедший спринт, перемещают рассмотренные задачи в колонку «Сделано» – теперь эти части программы можно продемонстрировать заказчику и выслушать его мнение, а потом приступают к обсуждению того, что получилось хорошо и что можно было бы сделать лучше в этом спринте. Далее они идентифицируют наиболее серьезную помеху и анализируют задачу по ее немедленному устранению в следующем спринте. Так решается проблема непрерывного совершенствования.
Чтобы собрание было действенным, потребуется создать атмосферу доверия и проявить необходимую эмоциональную зрелость. Главное, о чем нужно помнить, – вы никого не обличаете, а рассматриваете рабочий процесс. Почему что-то получилось так, а не иначе? Почему мы это упустили? Что помогло бы нам ускорить темпы? Очень важно, что люди ощущают себя командой, поэтому они сообща как команда берут на себя ответственность за все: и отличные результаты, и ошибки. И они сообща как команда ищут решения. Участники группы должны обладать определенной психологической выдержкой, чтобы их обсуждения были направлены на решение злободневной проблемы, а не на поиски виноватых. Абсолютно недопустимо, чтобы даже один член команды вынужден был занимать оборонительную позицию, – все в группе должны слышать и понимать друг друга.
Если вспомнить цикл Деминга «Планировать, действовать, проверять, корректировать», то очевидно, что ретроспективные собрания несут функцию проверки. Нам нужно подойти к этапу «действовать», то есть кайдзен, и выполнить функции, которые усовершенствуют рабочий процесс. Недостаточно лишь делиться мнениями, нужно приступать к непосредственной работе.
Самый лучший способ добиться непрерывного совершенствования, который мне удалось найти, я назвал индексом счастья. Это простой и весьма эффективный способ понять не только каким должен быть кайдзен, но и какой кайдзен сделает людей самыми счастливыми. Когда я использовал его, он дал впечатляющие результаты.
Вот как функционирует этот способ: в конце спринта каждый участник группы должен ответить на несколько вопросов.
1. Оцените свою роль в компании по шкале от одного до пяти.
2. Оцените компанию в целом по той же шкале.
3. Почему вы так считаете.
4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.
Всего четыре вопроса, решаемых буквально за несколько минут. Участники группы по очереди высказывают свои мнения, любое из которых может послужить причиной активных и глубоких обсуждений. Сообща взявшись за дело, команда довольно быстро предлагает свой кайдзен. Предложенный мной способ позволяет выявить одновременно несколько обстоятельств: что на текущий момент является самым важным и для каждого члена группы, и для всей группы, что они считают наиболее важным для своей компании.
Мы подходим к решающему этапу. Команда, идентифицировав главное препятствие на этот момент, определяет соответствующую фазу улучшения и делает ее основной задачей следующего спринта, каждая такая задача проходит обязательное приемочное тестирование. Как мы можем подтвердить, что улучшение было достигнуто? Для этого следует выработать формулировку успеха, однозначную и отвечающую реальной ситуации. Таким образом, на следующем ретроспективном собрании можно будет с легкостью увидеть, был ли достигнут кайдзен или нет.
Несколько лет назад я захотел расширить свою компанию Scrum. и сделать ее консультационным агентством, предоставляющим полный цикл обслуживания по методологии Scrum. Мы проанализировали динамику своей производительности и выяснили, что за недельный спринт у нас получается сорок очков осуществленных историй. Когда я ввел индекс счастья, первое, что мы обнаружили, – наши пользовательские истории выглядели недостаточно правильными. Они были слишком расплывчатыми, а значит не готовыми перейти в колонку «Сделано». Мы их еще раз проработали и получили вроде бы качественные истории. Но во время следующего спринта они все-таки оказались недостаточно хорошими. Этот недостаток отражался на нашем индексе счастья. В третьем спринте появилась другая проблема. Мы решили ее. И так далее. За считаные недели мы улучшили показатели динамики с 40 баллов за спринт до 120. Всего лишь поинтересовавшись, что делает людей более счастливыми, мы умудрились втрое улучшить свою производительность. В результате счастливее стали не только мы, но и наши клиенты, а прибыль компании просто взлетела до небес. Еще раз повторю: чтобы достичь таких результатов, нужно было только задать вопрос коллективу: «Что сделает вас счастливее?» – и всем вместе выполнить это.
Мы создали диаграммы с нашими показателями и кривыми их изменений за длительное время и обнаружили невероятно удивительные вещи. Как генеральный директор компании я уделяю большое внимание вопросам прибыли, роста и производительности. И я сделал поразительное открытие: в отличие от финансовых показателей, индекс счастья был более прогностическим. Финансовые показатели отражают результаты деятельности, происходившей в прошлом, но когда вы спрашиваете человека, насколько он счастлив, ответ обычно проецируется на будущее. Люди задумываются над тем, довольны ли они своей компанией, будет ли польза от эффекта их деятельности, как в принципе у компании идут дела. В результате, посмотрев на ситуацию их глазами, вы увидите симптомы проблемы, прежде чем она возникнет в реальной жизни. Если вы будете уделять достаточное внимание оценкам своих работников, у вас появится возможность начать действовать немедленно и исправить любой недочет до того, как он превратится в настоящую проблему. На следующей диаграмме видно, что падение уровня счастья происходит на несколько недель раньше падения динамики производительности. Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее.
Джефф Сазерленд.Scrum. Революционный метод управления проектами
Чтобы ответить на все вопросы, обратимся снова к Toyota и крестовому походу Тайити Оно, объявленному им против потерь. Ликвидация потерь – высокая цель, приведшая Оно к идее непрерывного совершенствования. Недостаточно достичь определенного уровня производительности и успокоиться на этом. Следует постоянно анализировать рабочие процессы и неустанно улучшать их. Увы, совершенство недостижимо, но любой шаг в его сторону будет оправдан.
Точно так же, как мы распределяем работу на легко управляемые короткие циклы, а рабочее время разбиваем на небольшие промежутки, так и усовершенствование необходимо делить на фазы, чтобы на каждый отрезок времени приходилось по одной фазе улучшения. Понятие «непрерывное совершенствование» в японском языке передается словом кайдзен. Какие помехи можно устранить за один раз и таким образом добиться небольшого улучшения – и так, шаг за шагом, осуществлять идею непрерывного совершенствования?
В методологии Scrum этот вопрос рассматривают в конце каждого спринта во время ретроспективных собраний. Члены группы рассказывают о заданиях, выполненных за прошедший спринт, перемещают рассмотренные задачи в колонку «Сделано» – теперь эти части программы можно продемонстрировать заказчику и выслушать его мнение, а потом приступают к обсуждению того, что получилось хорошо и что можно было бы сделать лучше в этом спринте. Далее они идентифицируют наиболее серьезную помеху и анализируют задачу по ее немедленному устранению в следующем спринте. Так решается проблема непрерывного совершенствования.
Чтобы собрание было действенным, потребуется создать атмосферу доверия и проявить необходимую эмоциональную зрелость. Главное, о чем нужно помнить, – вы никого не обличаете, а рассматриваете рабочий процесс. Почему что-то получилось так, а не иначе? Почему мы это упустили? Что помогло бы нам ускорить темпы? Очень важно, что люди ощущают себя командой, поэтому они сообща как команда берут на себя ответственность за все: и отличные результаты, и ошибки. И они сообща как команда ищут решения. Участники группы должны обладать определенной психологической выдержкой, чтобы их обсуждения были направлены на решение злободневной проблемы, а не на поиски виноватых. Абсолютно недопустимо, чтобы даже один член команды вынужден был занимать оборонительную позицию, – все в группе должны слышать и понимать друг друга.
Если вспомнить цикл Деминга «Планировать, действовать, проверять, корректировать», то очевидно, что ретроспективные собрания несут функцию проверки. Нам нужно подойти к этапу «действовать», то есть кайдзен, и выполнить функции, которые усовершенствуют рабочий процесс. Недостаточно лишь делиться мнениями, нужно приступать к непосредственной работе.
Самый лучший способ добиться непрерывного совершенствования, который мне удалось найти, я назвал индексом счастья. Это простой и весьма эффективный способ понять не только каким должен быть кайдзен, но и какой кайдзен сделает людей самыми счастливыми. Когда я использовал его, он дал впечатляющие результаты.
Вот как функционирует этот способ: в конце спринта каждый участник группы должен ответить на несколько вопросов.
1. Оцените свою роль в компании по шкале от одного до пяти.
2. Оцените компанию в целом по той же шкале.
3. Почему вы так считаете.
4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.
Всего четыре вопроса, решаемых буквально за несколько минут. Участники группы по очереди высказывают свои мнения, любое из которых может послужить причиной активных и глубоких обсуждений. Сообща взявшись за дело, команда довольно быстро предлагает свой кайдзен. Предложенный мной способ позволяет выявить одновременно несколько обстоятельств: что на текущий момент является самым важным и для каждого члена группы, и для всей группы, что они считают наиболее важным для своей компании.
Мы подходим к решающему этапу. Команда, идентифицировав главное препятствие на этот момент, определяет соответствующую фазу улучшения и делает ее основной задачей следующего спринта, каждая такая задача проходит обязательное приемочное тестирование. Как мы можем подтвердить, что улучшение было достигнуто? Для этого следует выработать формулировку успеха, однозначную и отвечающую реальной ситуации. Таким образом, на следующем ретроспективном собрании можно будет с легкостью увидеть, был ли достигнут кайдзен или нет.
Несколько лет назад я захотел расширить свою компанию Scrum. и сделать ее консультационным агентством, предоставляющим полный цикл обслуживания по методологии Scrum. Мы проанализировали динамику своей производительности и выяснили, что за недельный спринт у нас получается сорок очков осуществленных историй. Когда я ввел индекс счастья, первое, что мы обнаружили, – наши пользовательские истории выглядели недостаточно правильными. Они были слишком расплывчатыми, а значит не готовыми перейти в колонку «Сделано». Мы их еще раз проработали и получили вроде бы качественные истории. Но во время следующего спринта они все-таки оказались недостаточно хорошими. Этот недостаток отражался на нашем индексе счастья. В третьем спринте появилась другая проблема. Мы решили ее. И так далее. За считаные недели мы улучшили показатели динамики с 40 баллов за спринт до 120. Всего лишь поинтересовавшись, что делает людей более счастливыми, мы умудрились втрое улучшить свою производительность. В результате счастливее стали не только мы, но и наши клиенты, а прибыль компании просто взлетела до небес. Еще раз повторю: чтобы достичь таких результатов, нужно было только задать вопрос коллективу: «Что сделает вас счастливее?» – и всем вместе выполнить это.
Мы создали диаграммы с нашими показателями и кривыми их изменений за длительное время и обнаружили невероятно удивительные вещи. Как генеральный директор компании я уделяю большое внимание вопросам прибыли, роста и производительности. И я сделал поразительное открытие: в отличие от финансовых показателей, индекс счастья был более прогностическим. Финансовые показатели отражают результаты деятельности, происходившей в прошлом, но когда вы спрашиваете человека, насколько он счастлив, ответ обычно проецируется на будущее. Люди задумываются над тем, довольны ли они своей компанией, будет ли польза от эффекта их деятельности, как в принципе у компании идут дела. В результате, посмотрев на ситуацию их глазами, вы увидите симптомы проблемы, прежде чем она возникнет в реальной жизни. Если вы будете уделять достаточное внимание оценкам своих работников, у вас появится возможность начать действовать немедленно и исправить любой недочет до того, как он превратится в настоящую проблему. На следующей диаграмме видно, что падение уровня счастья происходит на несколько недель раньше падения динамики производительности. Анализируя только показатели производительности, вы никогда не узнаете о будущем снижении темпа, пока ситуация не выйдет из-под контроля. Но если вы внимательно следите за индексом счастья и замечаете его падение в коллективе, то сразу отмечаете будущую угрозу, даже при условии, что производительность продолжает расти. Вы предупреждены о проблеме и собираетесь с нею разобраться как можно быстрее.
Джефф Сазерленд.Scrum. Революционный метод управления проектами
Отличная статья, очень наглядная, но я не согласен с названием поскольку 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 конечно легче, он же не может ответить.
Прошу прощения за резкий тон комментария, я старался быть конструктивным.
Коротко: в компании произошла локальная оптимизация расходов на разработку,
никакого отношения к принципам 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 конечно легче, он же не может ответить.
Прошу прощения за резкий тон комментария, я старался быть конструктивным.
Поддержу общий тренд, внедрение новой методологии разработки не при чём. Вчера у Вас разработчики были главными. Например, время. Им дают реализовать новый набор фич, они говорят — сделаем за неделю. Решают задачу за 3 дня или 3 недели и ни одна собака им тявкнуть не может про время, так как они разработчики! Сегодня власть и ответственность отдали менеджерам. Менеджер не может сказать на пятиминутке «разработчики обещали сделать за неделю, но я к ним через неделю пришёл, а меня на фиг отправили, типа ждите». Как итог менеджер делит задачи, требует соблюдения сроков и так далее. Так и по остальным пунктам, дело не в algine, дело во власти и отвественности.
Что надо делать? Как и все. Продолжайте делить программный код (ооп Вам в помощь). Вместо одного ключевого разработчика нанимайте 20 обычных, снижайте нагрузку на ключевых сотрудников, требуйте, чтобы все кодеры были взаимозаменяемыми. Разработка станет значительно дороже, проект из игрушки превратится в ресурсоёмкого монстра, но зато власть останется в руках у менеджеров.
Вариант вернуть как было, вы явно не рассматриваете.
ps
Сам я негативно отношусь к власти менеджеров, но ситуация такая, какая она есть.
Что надо делать? Как и все. Продолжайте делить программный код (ооп Вам в помощь). Вместо одного ключевого разработчика нанимайте 20 обычных, снижайте нагрузку на ключевых сотрудников, требуйте, чтобы все кодеры были взаимозаменяемыми. Разработка станет значительно дороже, проект из игрушки превратится в ресурсоёмкого монстра, но зато власть останется в руках у менеджеров.
Вариант вернуть как было, вы явно не рассматриваете.
ps
Сам я негативно отношусь к власти менеджеров, но ситуация такая, какая она есть.
Читая некоторых, делаю вывод: Scrum — это хорошо, если вы что-то внедряете, и у вас всё плохо — это не Scrum ;)
Статья хорошая, а вот вывод автор делает неверный.
На мой взгляд — причина неудачного внедрения в том, что новые цепочки процесса управления во-первых убили напрочь обратную связь между командой разработки и менеджментом (или даже клиентом), во-вторых, само желание «высокого начальства» внедрить Scrum — сиречь, проконтролировать то, что контролировать не нужно (время на разработку) — было ущербным.
Если честно, я вообще не понимаю трекинг времени внутри команды в штате компании. К'мон, ребята, как будто вы заплатите сотруднику меньше денег, узнав что он решил задачу за X времени, когда по вашему скромному мнению она должна занимать Y времени. Вы или выкупаете команду оптом, без вопросов выплачивая фиксированную сумму в месяц и берете на себя все риски неправильной постановки задач, рабочей среды, коммуникаций и оборудования, или, если вам хочется контролировать время — отправляете сотрудников на UpWork с почасовой оплатой (правда, она будет выше в силу накладных расходов разработчиков).
А организовывать грибной менеджмент на сотрудниках на зарплате с допросами почему эта кнопочка заняла столько времени попахивает излишней укомплектованностью управленческого звена кадрами (читай: менеджеров пора выпинывать с работы, или придумывать чем занять).
Хотя с другой стороны — если менеджеру хочется поговорить вместо работы, то рыночно-ориентированный программист никогда не откажет ему в такой возможности. Любой каприз, как говорится, за ваши деньги. Менеджер имеет полное право получить услуги психотерапии усилиями программиста и по его рейту.
На мой взгляд — причина неудачного внедрения в том, что новые цепочки процесса управления во-первых убили напрочь обратную связь между командой разработки и менеджментом (или даже клиентом), во-вторых, само желание «высокого начальства» внедрить Scrum — сиречь, проконтролировать то, что контролировать не нужно (время на разработку) — было ущербным.
Если честно, я вообще не понимаю трекинг времени внутри команды в штате компании. К'мон, ребята, как будто вы заплатите сотруднику меньше денег, узнав что он решил задачу за X времени, когда по вашему скромному мнению она должна занимать Y времени. Вы или выкупаете команду оптом, без вопросов выплачивая фиксированную сумму в месяц и берете на себя все риски неправильной постановки задач, рабочей среды, коммуникаций и оборудования, или, если вам хочется контролировать время — отправляете сотрудников на UpWork с почасовой оплатой (правда, она будет выше в силу накладных расходов разработчиков).
А организовывать грибной менеджмент на сотрудниках на зарплате с допросами почему эта кнопочка заняла столько времени попахивает излишней укомплектованностью управленческого звена кадрами (читай: менеджеров пора выпинывать с работы, или придумывать чем занять).
Хотя с другой стороны — если менеджеру хочется поговорить вместо работы, то рыночно-ориентированный программист никогда не откажет ему в такой возможности. Любой каприз, как говорится, за ваши деньги. Менеджер имеет полное право получить услуги психотерапии усилиями программиста и по его рейту.
Трекинг времени полезен, чтобы понимать, на что уходят ресурсы — т.е., он может показать, что на багфикс уходит в два раза больше времени, чем на разработку. Еще он полезен, чтобы корректировать планирующие оценки — т.е. сравнение плановых оценок с реально потраченным временем может иметь стабильную зависимость, которая позволит давать "наружу" более точные оценки.
Важно понимать, однако, что чтобы это работало, трекинг времени не должен использоваться для "а почему это заняло столько времени" со смыслом "что-то ты медленно работаешь".
Поминутный трекер, поверьте, слабо поможет в этом. Достаточно просто отмечать сколько задачи висят в определенных статусах. И на определенных людях.
А я и не говорил о поминутном трекинге. Вопрос только в том, как именно организовать измерение "сколько задача висит в определенном статусе".
Ну вот есть грамотный способ — через статусы в JIRA например. И неграмотный — устанавливая людям на компьютеры тайм-трекер или (о боги, в 2017м-то году!) заставляя репортить время вручную.
Ну вот есть грамотный способ — через статусы в JIRA например.
Я перевел задачу в Active. Потом ко мне прилетела более важная задача, и я на нее переключился. Потом я вернулся к этой задаче, доделал ее, и перевел в Resolved. Как посчитать реально затраченное на нее время?
Понятно, что правильный ответ — это "при переключении вернуть задачу из Active в предыдущий статус", но в результате то, что мы получим — это и будет таймтрекер, только кнопки у него в других местах расположены и иначе называются. И тут уже вопрос, какой "трекер" команде удобнее — тот, где надо задачи каждый раз между статусами пинать, или тот, где надо каждый вечер указать часы на задачу.
Клиент говорит: «покрасьте зебру в белый!».
Покрасили.
Клиент говорит: «не, белая зебра не смотрится, покрасьте зебру в черный!».
Покрасили.
Клиент говорит: «не, верните все как было!».
Отмыли зебру.
Пришла пора говорить с клиентом о деньгах.
И тут фиксация, куда сколько времени потрачено, может крайне помочь. Потому как клиент искренне не понимает, с чего бы эти перекраски стоят СТОЛЬКО.
Покрасили.
Клиент говорит: «не, белая зебра не смотрится, покрасьте зебру в черный!».
Покрасили.
Клиент говорит: «не, верните все как было!».
Отмыли зебру.
Пришла пора говорить с клиентом о деньгах.
И тут фиксация, куда сколько времени потрачено, может крайне помочь. Потому как клиент искренне не понимает, с чего бы эти перекраски стоят СТОЛЬКО.
Именно об этом я и сказал когда упомянул UpWork. Подойдет так же Paymo, TimeManiac, или ваш любимый тайм-трекер. Просто прелесть UpWork-подхода в том, что он устанавливает прямую (прямее некуда) взаимосвязь между потраченным временем и деньгами. Это порой сильно меняет отношения.
В ряде случаев клиент не хочет в T&M.
Клиент хочет фикспрайс.
Клиент договаривается с продавцом на фикспрайс и выдает ТЗ.
На промежуточном показе клиент понимает, что ТЗ он написал неправильно, и вместо деритриниации ему нужна тирьямпампация.
В этот момент и начинается очень интересный этап — обоснование изменения стоимости договора, включаемой в допсоглашение об изменении параметров проекта. Клиенту надо пояснить, почему делать А стоит так дорого — и тут разблюдовка по задачам с указанием фактически понесенных трудозатрат может помочь очень сильно.
Клиент хочет фикспрайс.
Клиент договаривается с продавцом на фикспрайс и выдает ТЗ.
На промежуточном показе клиент понимает, что ТЗ он написал неправильно, и вместо деритриниации ему нужна тирьямпампация.
В этот момент и начинается очень интересный этап — обоснование изменения стоимости договора, включаемой в допсоглашение об изменении параметров проекта. Клиенту надо пояснить, почему делать А стоит так дорого — и тут разблюдовка по задачам с указанием фактически понесенных трудозатрат может помочь очень сильно.
Полагаю это взгляд со стороны разработки? Хотелось бы услышать взгляд со стороны менеджмента. Какие причины заставили играть с огнём и ломать устоявшуюся систему?
Я сам был в подобной истории, в разработке. Действительно костяк заслуженных-перезаслуженных людей создали кучку продуктов, приносивших компании основные деньги. Но год от года темп падал, задачи висели годами(!), сроки постоянно срывались и разработчики сами ничего не могли и не хотели с этим поделать.
Серия изменений в управлении конечно здорово выкосила ряды и привела в первое время к еще большим просадкам. Компанию постепенно наполняли новые люди, для которых жесткий контроль был изначально привычен. И в конце концов процесс выровнялся.
Я сам был в подобной истории, в разработке. Действительно костяк заслуженных-перезаслуженных людей создали кучку продуктов, приносивших компании основные деньги. Но год от года темп падал, задачи висели годами(!), сроки постоянно срывались и разработчики сами ничего не могли и не хотели с этим поделать.
Серия изменений в управлении конечно здорово выкосила ряды и привела в первое время к еще большим просадкам. Компанию постепенно наполняли новые люди, для которых жесткий контроль был изначально привычен. И в конце концов процесс выровнялся.
НЛО прилетело и опубликовало эту надпись здесь
Актуальность внедрения любого новшества в процесс должно быть обсуждено. Факт. И кстати… Есть такое понятие как «риски»… Вообщем в России как и прежде две беды… Дураки и дороги.
Отличный анти-кейс. Отставив в стороне «это НЕ-Скрам», получается, что среди разработчиков или менеджеров никто не встал и не сказал, что получается фигня. И, видимо, у менеджеров яйца оказались более железными, раз выжили из компании ключевых разработчиков. Грустно, конечно.
получается, что среди разработчиков или менеджеров никто не встал и не сказал, что получается фигня
ну да, яиц/ума нет у менеджеров/разрабов, а виноват, конечно же, Agile
Если менеджер признает, что это все ерунда, то кто-то получит по ушам за потраченные деньги и/или лишиться повышения, своего авторитета в фирме. Разработчик сразу же становится персоной нон грата для всех управленцев.
Программисты последнее время чем-то похожи на художников, чью работу мерят по затраченным краскам. Больше затратил краски — больше стоит картина. Меньше затратил краски — картина дешевая.
Понятно, что все высказались уже в подобном ключе, но не удержусь:
Обозвали задачи юзер сторями, срок на их выполнение — спринтами, проджект-менджеров — продакт «овнерами» и потом решили, что все, это у них теперь scrum
Как обычно, scrum превратили в срам, не понимая сути agile/scrum.
Как в известном изречении «они сидели и день, и ночь, и день, и ночь и все думали, как сделать убыточное предприятие прибыльным, ничего в оном не меняя». Здесь да, поменяли. Обозвали одно и то же другими словами — и вперед.
И обвинять в этом Agile/Scrum — это уподобляться тем, кто Интернет считает рассадником порнухи и источником отупления человечества, а Телеграм — пособником террористов. Что, настала пора запрещать и Scrum?
Обозвали задачи юзер сторями, срок на их выполнение — спринтами, проджект-менджеров — продакт «овнерами» и потом решили, что все, это у них теперь scrum
Как обычно, scrum превратили в срам, не понимая сути agile/scrum.
Как в известном изречении «они сидели и день, и ночь, и день, и ночь и все думали, как сделать убыточное предприятие прибыльным, ничего в оном не меняя». Здесь да, поменяли. Обозвали одно и то же другими словами — и вперед.
И обвинять в этом Agile/Scrum — это уподобляться тем, кто Интернет считает рассадником порнухи и источником отупления человечества, а Телеграм — пособником террористов. Что, настала пора запрещать и Scrum?
В скрам и агиле вообще менеджеры (в скраме кстати нет такой роли), скрам мастер, продукт овнер не могут диктовать или влиять на то как девелоперы оценивают стори. Они могут помогать советом, если попросили, но и все — команда по сути автономна, это один из основных принципов агиле.
Это внутреннее дело команды как оценивать и что делать долго а что медленно. Максимум менеджеры могут попросить распилить стори на более маленькие, и если совсем все плохо реарганизовывать/тусовать команды (если совсем не получаетсо).
И уже тут получается что внедряли не Скрам, а под видом Скрама пытались закрутить гайки. Тайм трекинг как таковой не является частью агиле и Скрама в частности.
Вообше имхо любой инструмент/процесс можно ввести так что мало не покажется. Нужен человек который понимает принципы агиле и в состоянии анализировать текущее состояние процессов, находить конфликты и разрешать их. Если же скрам мастер "не приходя в сознание" начинает пихать формальную часть процесса, не блокируя микроменеджмент от менеджеров (который противоречит принципам процесса) то быть беде.
Для того, что бы оченить сложность чей то задачи, обычно мне надо по крайней мере в течении 15 мин посмотреть на код, а мне это надо? Продакт оуны или скрум мастера обычно в сотстоянии оценить сложность задачи с порядком ошибки «две трамвайные остановки». То есть все эти обсуждения — чистой воды потеря времени, политика и профанация.
В целом скрам — это микроменеджмет, который по определению является наиболее непродуктивной методикой.
Как сейчас хорошо жить в компании без скрума, наконец то можно работать.
В целом скрам — это микроменеджмет, который по определению является наиболее непродуктивной методикой.
Как сейчас хорошо жить в компании без скрума, наконец то можно работать.
Так самое забавное что в Скраме ненадо напрягать мозг и ванговать размер каждой стори в часах или днях. Я часто использую 4ре градации — легко, средне, сложно и эпик. Если команда затрудняется ответить как сложно делать такую стори — значит у команды нет необходимых знаний и/или стори надо заресерчить и распилить, т.е. брать в спринт не на выполнение а на ремерч и бэклог груминг.
Но когда микроменеджмент умников снаруди не блокируется, то мало того что эстимейты стори пытаются пропихнуть с точностью в часах, так еще и начинают грузить команду мнениями что "много" или "мало".
А это стресс и отбитие органов принятия решений команды, что приводит к меньшей эффективности всей разработки. Имхо.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Сдаётся мне, что либо «внедрятели» скрама в компании не интересовались в чём суть скрама, либо автор статьи, либо и те и другой.
Скрам, как он описан в одноимённой книге от его основателя, ставит именно людей (команду) на первое место.
Менеджер не может приоретизировать UserStory. Менеджер не может давить сокращением сроков, требовать отчёта о потерянном времени, и заниматься прочими псевдоуправленческими глупостями.
По сути, scrum/agile — продолжение старых добрых идей Листера и Демарко о кристаллизации команд.
То что у нас внедряется под видом agile — старое доброе линейное гуано в новой обёртке и с новыми терминами.
В немалой степени потому что мало кто имеет интерес к чтению матчасти, всех тянет сразу внедрять в продакшен.
Внедряющие может и читают что-то. Но вот абстрактно, приходит ко мне менеджер и говорит «Завтра внедряем скрам». Я «ОК. А что это? Ах, методология управления разработкой. Давай, изложи, что мне делать можно, что нельзя. Лучше в письменном виде на почту. А то приказом по фирме об изменении должностных обязанностей.»
Ну и кто в данном случае будет ответственен за результат? Agile-методология?
Ответственен за результат внедрения тот, кто руководит процессом. В данном случае — менеджер. Не смог толком донести суть и детали процесса, не смог мотивировать (причём пряником) поддерживать внедрение, а не изображать его из под палки — его ошибки.
Но вообще слабо представляю, чем менеджер может замотивировать разработчика помочь внедрить скрам. Единственная «плюшка», которая есть для меня в скраме — обещание, что в течение спринта меня никто из бизнеса не дергает. ради этого можно и потерпеть митинги и прочие ритуалы. Но по факту, не знаю ни одной фирмы из первого-второго круга, где вроде бы скрам есть, чтобы это обещание выполнялось.
Но вообще слабо представляю, чем менеджер может замотивировать разработчика помочь внедрить скрам. Единственная «плюшка», которая есть для меня в скраме — обещание, что в течение спринта меня никто из бизнеса не дергает. ради этого можно и потерпеть митинги и прочие ритуалы. Но по факту, не знаю ни одной фирмы из первого-второго круга, где вроде бы скрам есть, чтобы это обещание выполнялось.
Ээээ написали страшилок — ну наверно попался вам не очень толковый Скрам Мастер и сам процесс Скрама у вас похоже перерос в «ритуальность» (ака «карго-культ»). У вас до Скрама всё ведь было идеально, правда? :-)))
Судя по симптомам у вас НЕТ «Product Owner» — раз всякие «мэнеджеры» до бесконечности приоретезируют User Stories — на самом деле должен быть лишь один «мэнеджер» тот самый Product Owner.
И вообще в толковом Скраме разработчикам живётся замечательно — потому как в реальном Скраме нет зоопарка PMов, Мэнеджеров и тд
Судя по симптомам у вас НЕТ «Product Owner» — раз всякие «мэнеджеры» до бесконечности приоретезируют User Stories — на самом деле должен быть лишь один «мэнеджер» тот самый Product Owner.
И вообще в толковом Скраме разработчикам живётся замечательно — потому как в реальном Скраме нет зоопарка PMов, Мэнеджеров и тд
НЛО прилетело и опубликовало эту надпись здесь
Правильно ли я понял, что в вашей компании не выделили человека из команды программистов, который бы фильтровал задачи от менеджеров, общался бы с ними на совещаниях, распределял задачи внутри команды программистов, устанавливал бы внутренние приоритеты и т.д.? (Человек должен был быть уважаемым специалистом из команды программистов, иногда называется TeamLead или как-то ещё, но суть от этого не сильно меняется, так как для отдельных подкоманд стоит так же выделять TeamLead-ов).
Просто сложилось впечатление, что у вас в компании была классическая проблема большого количества прямых начальников над одним сотрудником.
Программисты вообще не должны были что-то знать о том, что какому-то менеджеру не хватает их времени.
А момент о том, что «старые» программисты перестали чувствовать себя частью компании вообще никак не связан с методологией. Это была проблема найма людей с улицы (поясню, людей, которые не строили компанию) на руководящие должности. Возможно, у программистов были куда более большие планы на работу в компании и управление. Они просто ощутили некоторую обиду, что человек с улицы получает большую власть, чем они, над продуктом, который они знают лучше. Это проблема любой компании, которая не выращивает управленческий персонал внутри.
В общем, у меня сложилось впечатление, что не в Scrum дело.
Просто сложилось впечатление, что у вас в компании была классическая проблема большого количества прямых начальников над одним сотрудником.
Программисты вообще не должны были что-то знать о том, что какому-то менеджеру не хватает их времени.
А момент о том, что «старые» программисты перестали чувствовать себя частью компании вообще никак не связан с методологией. Это была проблема найма людей с улицы (поясню, людей, которые не строили компанию) на руководящие должности. Возможно, у программистов были куда более большие планы на работу в компании и управление. Они просто ощутили некоторую обиду, что человек с улицы получает большую власть, чем они, над продуктом, который они знают лучше. Это проблема любой компании, которая не выращивает управленческий персонал внутри.
В общем, у меня сложилось впечатление, что не в Scrum дело.
Я работал в похожей компании, где-то через год работы в компании, пришел новый эффективный менеджер, и жизнь в отделе круто изменилась, правда там такой подход scrum-ом не пытались называть. Каждую пятницу проходили по списку задач с руководителем. И если время не билось (40 часовая неделя) до минут, то говорил, что бездельники, а если чуть завышаешь (чтобы было проще жить), говорил что выдохлись и если не соберемся лишит премии. Меня хватило на месяц. Хотя, сейчас я работаю в компании, где тоже нет честного scrum, но, вроде, всех все устаревает.
А почему вдруг все решили что менджерье и владельцы не понимают что делают?
Проект запущен, нужно срубить бабла здесь и сейчас, посему запускаем кадровую оптимизацию и добровольно выдавливаем дорогих разрабов и заменяем дешевыми кодерами. Профит.
Локальный профит для манагеров и/или руководства на лицо. Переживания пехоты никого не волнует.
Скрам, Ажайл бабло правит этим миром а не аббревиатурки IT-шников.
Проект запущен, нужно срубить бабла здесь и сейчас, посему запускаем кадровую оптимизацию и добровольно выдавливаем дорогих разрабов и заменяем дешевыми кодерами. Профит.
Локальный профит для манагеров и/или руководства на лицо. Переживания пехоты никого не волнует.
Скрам, Ажайл бабло правит этим миром а не аббревиатурки IT-шников.
Я один чувствую некий диссонанс между принципами agile, в которых я готов подписаться под каждым словом, и кучей «методологий», «правильное» и одновременно жизнеспособное внедрение которых по слухам где-то существует но никто не видел?
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
Внедрение agile почему-то начинают именно с методологий, тулов для их поддержки и таймтрекинга.
А начинать надо бы наверное с консенсуса в компании на всех уровнях по поводу принципов.
И пока эти принципы не осознаны и не приняты всеми, внедрение каких-то методологий и тулов бессмысленно и вредно, IMHO.
Хочу свою ложку дегтя как менеджер внести. Вина менеджеров безусловно есть, но у меня остались вопросы:
1) На одну команду разработки несколько менеджеров? зачем? почему нет одного ответственного за все что происходит? Одного менеджера вполне хватает чтобы справиться с командой в 7-8 человек без потери фокуса. все остальные — стейкхолдеры и его задача «подружить» все хотелки.
2) За разработку (люди, процессы и тд) должен отвечать руководитель (например технический директор). Почему он не разнес такую систему в пух и прах? Если в компанию может прийти новый сейл и сказать разработчикам как они теперь должны работать, то это как-то неправильно. Повторюсь, за процессы разработки отвечает руководитель разработки. Если профессионалы начали увольняться, то это в первую очередь его ответственность. Должен был навести порядок в головах остального менеджмента.
3) Сложилось впечатление, что до провального внедрения agile, разработчики сами решали что они будут делать и когда. В результате, как по волшебству, продукт начал развиваться, компания расширяться и все были счастливы. У вас не было планирования, оценки, приоритезации? Не верю. Waterfall, agile, любая другая методология не может игнорировать планирование и оценку результата. Иначе у вас не коммерческая организация, а кружок по интересам. Лучшие решения должны быть результатом процесса разработки, а не случайного стечения обстоятельств. Для этого есть тимлиды, руководители разработки и т.д.
Не про Agile статья. «Разруха не в клозетах, а в головах».
1) На одну команду разработки несколько менеджеров? зачем? почему нет одного ответственного за все что происходит? Одного менеджера вполне хватает чтобы справиться с командой в 7-8 человек без потери фокуса. все остальные — стейкхолдеры и его задача «подружить» все хотелки.
2) За разработку (люди, процессы и тд) должен отвечать руководитель (например технический директор). Почему он не разнес такую систему в пух и прах? Если в компанию может прийти новый сейл и сказать разработчикам как они теперь должны работать, то это как-то неправильно. Повторюсь, за процессы разработки отвечает руководитель разработки. Если профессионалы начали увольняться, то это в первую очередь его ответственность. Должен был навести порядок в головах остального менеджмента.
3) Сложилось впечатление, что до провального внедрения agile, разработчики сами решали что они будут делать и когда. В результате, как по волшебству, продукт начал развиваться, компания расширяться и все были счастливы. У вас не было планирования, оценки, приоритезации? Не верю. Waterfall, agile, любая другая методология не может игнорировать планирование и оценку результата. Иначе у вас не коммерческая организация, а кружок по интересам. Лучшие решения должны быть результатом процесса разработки, а не случайного стечения обстоятельств. Для этого есть тимлиды, руководители разработки и т.д.
Не про Agile статья. «Разруха не в клозетах, а в головах».
Интересно было бы посмотреть, что бы случилось с фирмой, не введя скрам, но так же наберая менеджеров всех мастей. Очень может быть, что ситуация была бы еще хуже, так как под давлением менеджеров творился бы полный хаос. Так вы хоть были «защищены» спринтами. Я ни в коем случае не защищаю скрам, так как сам не являюсь сильным его фанатом(планировать время — задача не из простых, таймтрекинг тоже создает ощущение, что за тобой следят), но мне кажется в вашем частном случае проблема далеко не в скраме.
Наверно поэтому, по крайней време в Европе, стало модным так называемая «плоская иерархия» в компаниях + скрам — когда что попадет в спринт, и как будет продукт дальше развиваться, решают разработчики, но при этом свою работу четко структурируют.
Наверно поэтому, по крайней време в Европе, стало модным так называемая «плоская иерархия» в компаниях + скрам — когда что попадет в спринт, и как будет продукт дальше развиваться, решают разработчики, но при этом свою работу четко структурируют.
За последние три года как после внедрения Agile сгнили так же два успешных стартапа
Новый менеджемент прикрываясь модной в этом сезоне методологией находит способ сожрать все ресурсы компании.
Всё по классике.
Новый менеджемент прикрываясь модной в этом сезоне методологией находит способ сожрать все ресурсы компании.
Всё по классике.
Как же приятно чувствовать себя значимым разработикам, который неудачлив только потому, что ему не дают развернуться тупые менеджеры, всё губящие.
Вот бы всех менеджеров и к стенке?
После чего, поди, Вы сразу станете таким же крутым как Линус? Ну признайтесь? Понадобится всего год-два — и вы в дамках?
Как правило, все иначе:
Человеку нужно придумывать виноватых. А устрани все названные ему «мешающие» факторы — такой человек таки все равно ничего и не добьется.
Ну разве что усовершенствуется в придумывании причин почему у него не получается работать, что ему опять кто-то мешает.
Ведь в том, что ты не особо успешен как разработчик и во всех твоих неудачах кто угодно виноват, только не ты сам.
Вот бы всех менеджеров и к стенке?
После чего, поди, Вы сразу станете таким же крутым как Линус? Ну признайтесь? Понадобится всего год-два — и вы в дамках?
Как правило, все иначе:
Человеку нужно придумывать виноватых. А устрани все названные ему «мешающие» факторы — такой человек таки все равно ничего и не добьется.
Ну разве что усовершенствуется в придумывании причин почему у него не получается работать, что ему опять кто-то мешает.
Ведь в том, что ты не особо успешен как разработчик и во всех твоих неудачах кто угодно виноват, только не ты сам.
А если вполне успешным себя считаешь, но понимаешь, что если бы менеджеры помогали, то эффективность была бы ещё выше?
А если вполне успешным себя считаешь, но понимаешь, что если бы менеджеры помогали, то эффективность была бы ещё выше?
Эффективность чего?
Тут не эффективность, а невозможность без менеджеров.
Если маленькая группка разработчиков, то она не нуждается в «надсмотрщике». Но нужен менеджер-сейлер (продавец) — он занимается вещами, которыми я не хочу заниматься.
Если это большая группа — то менеджер нужен для организации всех людей в единое целое.
И т.д.
Каждый занимается своим делом (плохо или хорошо, лишние там менеджеры имеются в компании или лишние разработчики, которые балду пинают — другой вопрос).
Если я буду это делать за менеджера — то я и превращусь в менеджера.
Законы человеческого социума неумолимы.
Не совсем ясна цель этой статьи. Пожурить плохих менеджеров? Так компаний много, работы тоже. Выбирай где тебе по вкусу. Изменить систему все равно не получится, только сменить её.
Можно еще погуглить карго культ и улыбнуться :)
Можно еще погуглить карго культ и улыбнуться :)
Из-за этой методологии, и вообще из-за всякого тайм-контроллинга и прочего давления, я, не выдержав постоянно нарастающего стресса, ощущения что из тебя пытаются сделать автомат, которому на вход подали задачу, на выход ожидают получить точный и безошибочный временной прогноз, а затем решение, периодически подзаряжая аккумуляторы (деньги), бросил профессию наёмного программиста. С пол года живу на остатки накоплений и до сих пор, как вспоминаю это, никакого желания возвращаться в профессию нет, для себя сидеть кодить что хочу и на чём хочу — сколько угодно, но наёмничать желания никакого не возникает, за любые деньги. Этот скрам/аджайл пришёл повсюду со своими спринтами, тайм-трекингом и каждодневными отчётами, и везде где я его видел, — он всё портил, я в конечном итоге, без того измученный этой парашей, понимал что совершенно недоволен результатом, это полное дно, куча недоделок, незаконченная работа, кругом ошибки и грязь, зато в спринт уложились и отчитались какой-то очередной цепочке по иерархии «выше». Для меня слова аджайл/скрам/канбан/тайм-трекинг прочно ассоциируются с угнетением и паршиво сделанной работой.
Зря вы бросили работу, есть огромное количесво компаний, где скрам просто формальность.
Плюс надо адекватно оценивать задачу, или баг: 1 час для репродукции бага, один час тестирование после того как баг пофиксили, один час обнавлять несколько раз время в jira и писать дескрипшин, сам бак фиксить 15 мин — округляем до часа, то есть получается 4 часа по крайне мере.
Раньше, если по ходу выполнения задачу видил баг, который пофиксит 15 мин, то просто это делал без всяких менеджеров, в компаниях со скрумом это категарическ запрещено. То есть эффективность в данном случае падает в 16 раз, в среднем эффективность работы со скрумом падает в 5 раз.
Плюс надо адекватно оценивать задачу, или баг: 1 час для репродукции бага, один час тестирование после того как баг пофиксили, один час обнавлять несколько раз время в jira и писать дескрипшин, сам бак фиксить 15 мин — округляем до часа, то есть получается 4 часа по крайне мере.
Раньше, если по ходу выполнения задачу видил баг, который пофиксит 15 мин, то просто это делал без всяких менеджеров, в компаниях со скрумом это категарическ запрещено. То есть эффективность в данном случае падает в 16 раз, в среднем эффективность работы со скрумом падает в 5 раз.
Как раз проблема в том, что такой 15-минутный баг вам не дадут оценить в 4 часа. Или по их истечении начнется, как кто-то тут выразился, «охота на медленно программирующих ведьм.»
И вообще, «такой баг делать не 15, а 5 минут».
Те же пропорции для более крупных задач.
И вообще, «такой баг делать не 15, а 5 минут».
Те же пропорции для более крупных задач.
Тогда это уже не Scrum.
Насколько я помню, в книге «Scrum» специально много раз обращается внимание, что не может быть никакой охоты на ведьм.
«Чем ты занимался?», «Чем ты планируешь заниматься» и «Что тебе мешает в твоей деятельности»?
Никаких «Почему так медленно?»
Задача менеджера — устранять помехи, а не третировать команду.
Насколько я помню, в книге «Scrum» специально много раз обращается внимание, что не может быть никакой охоты на ведьм.
«Чем ты занимался?», «Чем ты планируешь заниматься» и «Что тебе мешает в твоей деятельности»?
Никаких «Почему так медленно?»
Задача менеджера — устранять помехи, а не третировать команду.
Здесь уже отметили, что есть скрам в теории, а есть на практике.
У меня вообще ощущение, что если внедрять скрам и/или аджайл по теоретическим канонам, то получится некая в целом нормальная разработка, которая будет сходиться в одной точке с тем же waterfall, только осовремененным и «с человеческим лицом».
У меня вообще ощущение, что если внедрять скрам и/или аджайл по теоретическим канонам, то получится некая в целом нормальная разработка, которая будет сходиться в одной точке с тем же waterfall, только осовремененным и «с человеческим лицом».
Наймитесь поработать в кол-центр банка. Не на долго: на недельку. Думаю, что вы измените свое отношение к стрессу и снова полюбите профессию:)
Я Вас понимаю. Сам почти год «забил» на все и отдыхал мозгом.
Посмотрите на это следующим образом: На двигателе Ролс Ройса в графе мощность двигателя написан «Достаточная» :)
Ваша «мощность» — Достаточная :) А если от Вас ожидают «минута в минуту» точность оценки, то просто выдайте «достаточную», Если хотят — больше, то возьмите попкорн, откиньтесь на спинку и пусть Вам предоставят технологию, как оценить «минута в минуту» :)
Идиоты не истребимы :)
выдержав постоянно нарастающего стресса, ощущения что из тебя пытаются сделать автомат, которому на вход подали задачу, на выход ожидают получить точный и безошибочный временной прогноз
Посмотрите на это следующим образом: На двигателе Ролс Ройса в графе мощность двигателя написан «Достаточная» :)
Ваша «мощность» — Достаточная :) А если от Вас ожидают «минута в минуту» точность оценки, то просто выдайте «достаточную», Если хотят — больше, то возьмите попкорн, откиньтесь на спинку и пусть Вам предоставят технологию, как оценить «минута в минуту» :)
Идиоты не истребимы :)
Для меня слова аджайл/скрам/канбан/тайм-трекинг прочно ассоциируются с угнетением и паршиво сделанной работой.
Эти методологии не учитывают психологический профиль. Среди программистов есть много индивидуалов — интеллектуалов, которые не хотят что бы их беспокоили.
Так же не учитывается, что мозг у мужчин лучше работает когда погружается в одно дело. Когда дел много и надо переключаться, то на это тратится куча сил, иногда больше чем на просто работу.
Выступаю в роли змея-искусителя: попробуйте фриланс с почасовой оплатой.
В канбане нет таим трекинга насколько я знаю
разработчика нет, задачи есть. погуглите метрики канбана.
погуглите метрики канбана.
В канбане по дефолту нет вообще никаких метрик кроме "сколько тасок одновременно находятся в in progress". За счет ограничения на количество этих тасок проблемы будут находиться вне зависимости от того следите вы за временем или нет. Главное за ограничениями следить, их бывает часто игнорят и пытаются обойти.
Работаю в телекоме, долгое время работал в одном средней руки интеграторе, а сейчас стремлюсь в разработку.
Проблема типична. Может просто стартап вырос? Может ли большая компания жить на энтузиазме? Нет, ну только честно. Я, увы, не верю.
Приведу пример из телекома.
Сережа работает в крупной федеральной конторе, а Миша — в маленьких Мухосранских сетях.
Мишина компания все тот-же стартап середины нулевых выросший от пары тупарей до сети на половину города, но душа у сети все таже. Ее хотят купить за копье, Мишиного начальника хотят посадить или штрафануть. А ведь есть за что.
Сережина компания — что-то среднее или крупное.
Миша получает может и не особо меньше Сережи, но не так стабильно. Миша, скорее всего и админ и немного сварщик, и щепотку аварийщик. Ибо постоянно кто-то в офисе заболевает. Сережа половину дня жмет на 2 кнопки, обрабатывая инциденты, и делает то, что вроде никак на работу сети не влияет. Миша понимает же, что каждый клиент — часть его зарплаты, и он в 12 ночи поедет писать конфиг коммутатору, который почему-то решил сгореть, а конфиг был только в голове Миши и его начальника. У Сережи есть четкие нормативы. Что случается после его смены — ему мало интересно, главное — что бы в том не было косяка. Потоп, ли пожар, есть нормативы, и тут главное Сереже вовремя нажать на ту из двух кнопок, которую нажать нужно, что бы не лишиться премии. Конфиги сохраняет специально обученный для этого скрипт.
Технари в крупном провайдере на уровне обслуги. Менежджеры, вообще не понимают, зачем нужны технари. Проводочик ведь воткнул, и лампочки сами заморгали. ARPу технари не повышают. Можно ведь сократить половину и чуть-чуть увеличть нормативы по авариям. Кто заметит разницу по процентам простоя? Наймем девочек на телефон, и напечатаем много красивой рекламы. Пипл схавает. Все сводится в статистический маразм надоя с одного сферического абонента в вакууме и отфутболивание разного рода вопросов между отделами.
Ну ведь караван идет, менеджеры сдают дебильные отчеты в красивых папках главным главнюкам. Те в ответ дают более дебильные задания. Подсчитать количество абонентов пьющих ряженку по утрам. Нет, стойте, лучше проведите сравнение между цветом глаз собак абонентов и наработкой в ночные часы. И главное что бы рекламы было больше. Голустяна там еще не забрали? Вот, давайте с ним!
Плохо это или хорошо? Наверное, скажете вы, лучше быть Мишей. Там интересно. Только вот беда, все меняется, когда у Миши и Сережи появляются дети, жена, которой надо в Тайланд и ипотека. Вот тогда уж проще нажимать 2 кнопки и молчать о своей доли, строя в голове замки из песка, где ты, да ты, подкопишь сотню-другую тысяч мильенов рублей и что-нить свое замутишь. Ну там провайдера VoIP или ОТТ TV. Лет через 15-20, ибо за квартиру половину зарплаты еще отдавать и отдавать.
О чем это я. Простите, не верю в крупные и эффективные фирмы, где балом правят технари, или хотя бы толковые менеджеры. Не, может, они и есть, но я их не видел. Единорогов, к слову, не видел тоже.
Проблема типична. Может просто стартап вырос? Может ли большая компания жить на энтузиазме? Нет, ну только честно. Я, увы, не верю.
Приведу пример из телекома.
Сережа работает в крупной федеральной конторе, а Миша — в маленьких Мухосранских сетях.
Мишина компания все тот-же стартап середины нулевых выросший от пары тупарей до сети на половину города, но душа у сети все таже. Ее хотят купить за копье, Мишиного начальника хотят посадить или штрафануть. А ведь есть за что.
Сережина компания — что-то среднее или крупное.
Миша получает может и не особо меньше Сережи, но не так стабильно. Миша, скорее всего и админ и немного сварщик, и щепотку аварийщик. Ибо постоянно кто-то в офисе заболевает. Сережа половину дня жмет на 2 кнопки, обрабатывая инциденты, и делает то, что вроде никак на работу сети не влияет. Миша понимает же, что каждый клиент — часть его зарплаты, и он в 12 ночи поедет писать конфиг коммутатору, который почему-то решил сгореть, а конфиг был только в голове Миши и его начальника. У Сережи есть четкие нормативы. Что случается после его смены — ему мало интересно, главное — что бы в том не было косяка. Потоп, ли пожар, есть нормативы, и тут главное Сереже вовремя нажать на ту из двух кнопок, которую нажать нужно, что бы не лишиться премии. Конфиги сохраняет специально обученный для этого скрипт.
Технари в крупном провайдере на уровне обслуги. Менежджеры, вообще не понимают, зачем нужны технари. Проводочик ведь воткнул, и лампочки сами заморгали. ARPу технари не повышают. Можно ведь сократить половину и чуть-чуть увеличть нормативы по авариям. Кто заметит разницу по процентам простоя? Наймем девочек на телефон, и напечатаем много красивой рекламы. Пипл схавает. Все сводится в статистический маразм надоя с одного сферического абонента в вакууме и отфутболивание разного рода вопросов между отделами.
Ну ведь караван идет, менеджеры сдают дебильные отчеты в красивых папках главным главнюкам. Те в ответ дают более дебильные задания. Подсчитать количество абонентов пьющих ряженку по утрам. Нет, стойте, лучше проведите сравнение между цветом глаз собак абонентов и наработкой в ночные часы. И главное что бы рекламы было больше. Голустяна там еще не забрали? Вот, давайте с ним!
Плохо это или хорошо? Наверное, скажете вы, лучше быть Мишей. Там интересно. Только вот беда, все меняется, когда у Миши и Сережи появляются дети, жена, которой надо в Тайланд и ипотека. Вот тогда уж проще нажимать 2 кнопки и молчать о своей доли, строя в голове замки из песка, где ты, да ты, подкопишь сотню-другую тысяч мильенов рублей и что-нить свое замутишь. Ну там провайдера VoIP или ОТТ TV. Лет через 15-20, ибо за квартиру половину зарплаты еще отдавать и отдавать.
О чем это я. Простите, не верю в крупные и эффективные фирмы, где балом правят технари, или хотя бы толковые менеджеры. Не, может, они и есть, но я их не видел. Единорогов, к слову, не видел тоже.
Есть математическая теорема об управляющей и управляемой системах, в которой говорится:
Управляемая система должная в каком смысле быть умнее управляемой или по крайней мере на уровне. То есть менеждер должен быть в каком-то смысле умнее программиста. Но это невозможно, если не понизить интеллект программиста. Вот и получается, что умным остается либо тупеть, либо бежать, либо брать власть в свои руки.
Управляемая система должная в каком смысле быть умнее управляемой или по крайней мере на уровне. То есть менеждер должен быть в каком-то смысле умнее программиста. Но это невозможно, если не понизить интеллект программиста. Вот и получается, что умным остается либо тупеть, либо бежать, либо брать власть в свои руки.
То есть менеждер должен быть в каком-то смысле умнее программиста. Но это невозможно, если не понизить интеллект программиста.
Это, простите, почему? Особенно учитывая вашу же оговорку про "в каком-то смысле".
Использую «в каком-то смысле», так как это аналогия. Точное определение можно дать для формальных систем. А человек и социум — система неформализируемая до конца, поэтому можно только обозначить тенденцию
Ну и откуда вы берете тенденцию, что менеджер не может быть "в каком-то смысле умнее" программиста?
Понятно же, что мы не говорим об общем интеллекте, мы говорим о приспособленности к конкретным задачам — иными словами, о специализации. Менеджер умеет управлять, программист умеет программировать. Что в этом такого?
Менеджер умеет управлять, программист умеет программировать. Что в этом такого?
тогда все в порядке.
… а вы говорили, что это невозможно.
иногда возможно, иногда невозможно.
… почему это невозможно в общем случае?
Иногда количество степеней свободы у управляющей системы меньше, чем у управляемой. Например, управляющий имеет одну степень свободы — выключатель {0,1}. А у управляемой 2 степени свободы — например 2 светодиода {{0,1},{0,1}}. Один выключатель может управлять только одним светодиодом или обоими сразу. Некоторые комбинации светодиодов будут недоступны.
про
часто у владельца бизнеса возникает желание избавиться от тех (разрабов), кто принимал участие в становлении стартапа.
не хочет делиться и о будущем бизнеса не шибко думает — деньги приносит и хорошо, а помрет — так помрет…
для этого нанимает манагеров со стороны, и создает невыносимые условия для недавних сокомпаньенов.
после их ухода наберет на те ж зарплаты (или даже больше) таких же толковых и гениальных, но других, которым кроме зарплаты уже ничего не обязан.
Всем спасибо, все свободны! называется этот принцип а не скрам или аджайл
Что это за проблемы, которые нельзя заранее обсудить с ключевыми сотрудниками?
часто у владельца бизнеса возникает желание избавиться от тех (разрабов), кто принимал участие в становлении стартапа.
не хочет делиться и о будущем бизнеса не шибко думает — деньги приносит и хорошо, а помрет — так помрет…
для этого нанимает манагеров со стороны, и создает невыносимые условия для недавних сокомпаньенов.
после их ухода наберет на те ж зарплаты (или даже больше) таких же толковых и гениальных, но других, которым кроме зарплаты уже ничего не обязан.
Всем спасибо, все свободны! называется этот принцип а не скрам или аджайл
Давайте попробуем сопоставить то, что написано в статье и 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. То, что описано
в статье частично ей противоречит, частично ее дополняет.
Описанные проблемы, я думаю, именно из-за этих противоречий и дополнений
Автор, как мне кажется, на веру принял то, что ему говорил скрам-мастер и не сопоставил это с тем, что пишут авторы скрама.
Ну, нам, как разработчикам, читать что пишут авторы скрама не нужно. Для того и берут скрам-мастера, чтобы он нас всему научил.
Кто-то тогда должен выбирать скрам-мастера и он должен понимать как его выбирают. Еще такие разработчики, по моему, должны говорить типа "Скрам в интерпретации Васи Пупкина"
Мы не должны. К нам пришли и сказали: «делаем скрам». Аналогия: пришёл врач и сказал, что делает прививку. Может он на нас эксперименты ставит, например эффект плацебо изучает, может перепутал и глюкозу колет, но для нас это прививка.
С моей точки зрения логично посмотреть отзывы на врача, вызнать что за прививка и какое качество у производителя, второе мнение и т.д.
То есть ответственные люди врача выбирают
НЛО прилетело и опубликовало эту надпись здесь
В подобных ситуациях выбирать не приходится: или увольняйся, или делай то, что врач/менеджер называет прививкой/скрамом.
Я не знаю, что такое "подобные случаи" но как мне кажется, если это не говноконтора со взаимоотношениями "я — начальник, ты — дурак", то можно, по крайней мере попробовать убедить начальника поменять. Кстати, в скраме встроены ретроспективы для того, чтобы улучшать процесс. Или у вас был скрам без ретроспектив?
Убедить начальника поменять процесс или убедить начальника начальника поменять начальника? )
Были. Я предлагал отказаться от планирования спринтов и вообще спринтов, просто расставить задачи в бэклоге по приоритетам и релизиться по мере их готовности, собственно исключив такое понятие как релиз, просто деплой в продакшен готовой фичи/багфикса. «Это канбан какой-то получится».
Были. Я предлагал отказаться от планирования спринтов и вообще спринтов, просто расставить задачи в бэклоге по приоритетам и релизиться по мере их готовности, собственно исключив такое понятие как релиз, просто деплой в продакшен готовой фичи/багфикса. «Это канбан какой-то получится».
Были какие-то аргументы против канбана?
У нас скрам, а не канбан.
Это так начальник сказал? Тогда надо спросить чем скрам для конкретных условий лучше канбана.
Вот, кстати, зачем надо разработчику разбираться в предмете — чтобы аргументировать свою точку зрения.
Вот, кстати, видео об изменениях в скраме — что убрали, что добавили и почему?
Да, сказал. Скрам лучше канбана, по его словам, потому что в канбане отсутствует планирование. А заказчикам без планов проект не продать. Без модных слов тоже.
Я свою точку зрения аргументировал, я предлагал конкретные изменения во внедренных процессах, которые бы повысили эффективность. Мне как бы всё равно попадает результат моих изменений под какое-то популярное название или нет. Это как с паттернами — читаешь книжку и понимаешь, что давно их используешь, просто не знаешь, что те решения, которые постоянно применяешь от задачи к задачи и от проекта к проекту носят какие-то названия типа Стратегия или Репозиторий.
Прошу прощения, но смотреть 2 часа видео нет возможности. Вообще видео только развлекательное смотрю, в основном художественные фильмы. Для получения полезной информации предпочитаю текст с редкими схемами.
Я свою точку зрения аргументировал, я предлагал конкретные изменения во внедренных процессах, которые бы повысили эффективность. Мне как бы всё равно попадает результат моих изменений под какое-то популярное название или нет. Это как с паттернами — читаешь книжку и понимаешь, что давно их используешь, просто не знаешь, что те решения, которые постоянно применяешь от задачи к задачи и от проекта к проекту носят какие-то названия типа Стратегия или Репозиторий.
Прошу прощения, но смотреть 2 часа видео нет возможности. Вообще видео только развлекательное смотрю, в основном художественные фильмы. Для получения полезной информации предпочитаю текст с редкими схемами.
В кабан используется статистика для планирования
вот тут разжёвано http://www.dennisstevens.com/2010/06/07/kanban-and-when-will-this-be-done/
Канбан замечательно работает в условиях постоянно меняющихся приоритетов. Когда невозможно собрать внятный скоуп задач даже на недельный спринт. А что бы работало лучше — можно поверх канбана натянуть практик из других методологий.
Из моего опыта "попыток" внедрения канбана могу поделиться только таким наблюдением. Если в команде наблюдаются проблемы с коммуникацией тут они будут усугублять дело на порядок больше чем со скрамом. То есть к примеру, есть у нас физический борд с задачами. Первая проблема — разработчики не пользуются возможностью видеть задачи в in progress. Так же как правило не находится человека имеющего роль внятного продукт оунера который бы постоянно подстраивал приоритеты команды. В итоге все это превращается в хаос очень быстро. А ограничения… их не соблюдают и проблемы оказываются смазанными.
Скрам?
НЛО прилетело и опубликовало эту надпись здесь
Расскажите что у вас называлось скрамом?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это бизнес! в первую очередь.
Давайте представим, что вместо ПО, это будет хирургия :)
— Я не могу стежки делать шнурками из кожи рыбы, сам вчера нарезал и вымачивал.
— Как-то стерилизацию делать иодом уже не интересно, хочу… серной кислотой попробовать.
— Антибиотки давать по протоколу лечения? Не… давай клистир сделаем из порошка жаб, слышал новое модное на конференции рассказывали по инету.
В конце концов, убили всю инициативу в операционной и я уволился…
Давайте представим, что вам так бухгалтер будет считать и выдавать зарплату «по Scrum что бы было интересно»…
Давайте представим, что вместо ПО, это будет хирургия :)
— Я не могу стежки делать шнурками из кожи рыбы, сам вчера нарезал и вымачивал.
— Как-то стерилизацию делать иодом уже не интересно, хочу… серной кислотой попробовать.
— Антибиотки давать по протоколу лечения? Не… давай клистир сделаем из порошка жаб, слышал новое модное на конференции рассказывали по инету.
В конце концов, убили всю инициативу в операционной и я уволился…
Давайте представим, что вам так бухгалтер будет считать и выдавать зарплату «по Scrum что бы было интересно»…
НЛО прилетело и опубликовало эту надпись здесь
Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
В скрам встроенны ретроспективы как способ выразить идеи и проблемы. Если для бизнеса в данный момент важно ускорять систему в два раза, то PO может одобрить такой айтем в беклоге.
Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
Вы за чей счет провели измерения и рассчитали экономическую целесообразность?
За чей счет будет развертывание у Клиента на серверах и сопровождение новой версии?
Оно вообще надо Клиенту?
Если вы из своего кармана оплатили виртуалки, провели тестирование и измерения — тогда ладно. Приходите и покажите цифры Заказчику или в следующей итерации воткните свой Самый Лучший Код за 5 минут, а до конца спринта занимайтесь чем хотите.
Если вы за счет Клиента прокачаться — тоже, вариант. Но кто платит тот и музыку заказывает.
Но я не думаю, что в процессе разработки у вас за плечом стоит Злой Менеджер, и говорит «Делай хреново! Делай только ректально!!! А если вы сделали Хорошо, я вам потом сломаю пальцы.»
Хотите сделать в два раза лучше и прокачаться за чужой счет? Возьмите Open Source и ваяйте себе на здоровье :)
Никто в здравом уме не будет давить вашу инициативу если будет понятно что «это хорошо», но никто не будет одобрять непонятные бизнес-риски которые Вы, возможно, спровоцируете своими «инициативами»
НЛО прилетело и опубликовало эту надпись здесь
Вас нанимали: делать хорошо
Вас нанимали: не делать, чего не просят
Вас нанимали: понимать разницу между первым и вторым.
Вас нанимали: выслушать ваше професиональное мнение.
Вас НЕ нанимали: ВСЕГДА соглашаться с вашим мнением, после того как вы его высказали.
Вас НЕ нанимали: перед вами что-то объяснять, сверх рамок контракта.
Если вы с этим согласны и подписались в контракте, о чем тогда речь?
Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим. Зато через время или ваше мнение будет подкреплено и его начнут ожидать, или поймете что всем вокруг в принипе пофиг на вас и друг на друга.
А если вы ходите «с фигой в кармане» вы сам себе злой буратино, поскольку вы не узнаете «куда дует ветер»
Свои бизнес риски тот, кто «платит и музыку заказывает» осознает не хуже вас (в основном), потому что на нем кредит в банке для вашей зарплаты, оплатить офис где вы сидите, инвестиции в будущие проекты и т.д.
Вас нанимали: не делать, чего не просят
Вас нанимали: понимать разницу между первым и вторым.
Вас нанимали: выслушать ваше професиональное мнение.
Вас НЕ нанимали: ВСЕГДА соглашаться с вашим мнением, после того как вы его высказали.
Вас НЕ нанимали: перед вами что-то объяснять, сверх рамок контракта.
Если вы с этим согласны и подписались в контракте, о чем тогда речь?
Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим. Зато через время или ваше мнение будет подкреплено и его начнут ожидать, или поймете что всем вокруг в принипе пофиг на вас и друг на друга.
А если вы ходите «с фигой в кармане» вы сам себе злой буратино, поскольку вы не узнаете «куда дует ветер»
Свои бизнес риски тот, кто «платит и музыку заказывает» осознает не хуже вас (в основном), потому что на нем кредит в банке для вашей зарплаты, оплатить офис где вы сидите, инвестиции в будущие проекты и т.д.
НЛО прилетело и опубликовало эту надпись здесь
Высказать свое мнение, когда другим на него плевать, — это, очевидно, проявление инициативы. Отсутствие инициативы — это когда ты молчишь в тряпочку, когда тебе не задают вопросов.
Я больше рассматриваю как «гарантированое предоставление и доступность сервиса» :)
НЛО прилетело и опубликовало эту надпись здесь
А это еще почему?
Я как нанятый спец, в чьи обязанности входит говорить «если… то....» выполняю свою часть контракта.
Свою часть «сделки» я выполнил — предоставил мнение/оценку, и ни одна зараза не сможет сказать «нафига мы его нанимали, если он молчит все время? Табуртка тоже молчит».
Если меня «не слушают», чего мне обижаться? Возможно исходят еще из некоторых долнительных факторов, к которым у меня нет доступа.
Другое дело, если хожу и молчу. Вполне возможно молчание будет трактоваться как «молчит, значит согласен или не видит косяков». Но я свою часть сделки «не выполнил» — не предоставил свою оценку.
Нюанс в том, что донеся свою информацию до собеседника, вы вынуждаете его что-то делать. Ничего не делать — это такое-же тоже решение и тоже «действие».
Понятно, что отсутсвие обратной связи «почему не ценят или не слушают» интересно и может напрягать иногда.
Я как нанятый спец, в чьи обязанности входит говорить «если… то....» выполняю свою часть контракта.
Свою часть «сделки» я выполнил — предоставил мнение/оценку, и ни одна зараза не сможет сказать «нафига мы его нанимали, если он молчит все время? Табуртка тоже молчит».
Если меня «не слушают», чего мне обижаться? Возможно исходят еще из некоторых долнительных факторов, к которым у меня нет доступа.
Другое дело, если хожу и молчу. Вполне возможно молчание будет трактоваться как «молчит, значит согласен или не видит косяков». Но я свою часть сделки «не выполнил» — не предоставил свою оценку.
Нюанс в том, что донеся свою информацию до собеседника, вы вынуждаете его что-то делать. Ничего не делать — это такое-же тоже решение и тоже «действие».
Понятно, что отсутсвие обратной связи «почему не ценят или не слушают» интересно и может напрягать иногда.
НЛО прилетело и опубликовало эту надпись здесь
Для этого есть «управление рисками», для умных и кто может сам себе сделать процессы, понимая что и зачем.
Для тех кому «чего думать, трясти надо» в Scrum сделали «planing poker» и «ретроспективы» с вопросам: где получились косяки и почему? Как сделать так, что бы их было поменьше на следующих итерациях?
Все в этой части все просто: обезьянка видит — обезьянка делает.
В бизнесе применяется принцип «разумной достаточности», а не учитывается движение всех атомов во вселенной.
В итоге: если нету вопросов, значит косяки не возникли и потери были в допустимых границах, следовательно «разумная достаточность» соблюдена.
Для тех кому «чего думать, трясти надо» в Scrum сделали «planing poker» и «ретроспективы» с вопросам: где получились косяки и почему? Как сделать так, что бы их было поменьше на следующих итерациях?
Все в этой части все просто: обезьянка видит — обезьянка делает.
В бизнесе применяется принцип «разумной достаточности», а не учитывается движение всех атомов во вселенной.
В итоге: если нету вопросов, значит косяки не возникли и потери были в допустимых границах, следовательно «разумная достаточность» соблюдена.
НЛО прилетело и опубликовало эту надпись здесь
Ну это бесполезный разговор уже.
Почему бесполезно анализировать причины косяков?
Есть косяки, которые лучше предотвращать, а не исправлять.
Именно чтобы предотвартить будущие косяки, надо анализировать причины прошлых
НЛО прилетело и опубликовало эту надпись здесь
Речь не о том, чтобы не отвечать на вопросы или врать, а о том, что не все нужные вопросы могут быть заданы.
Увы, это так.
Для этого есть стадия идентификация рисков: методы прецедентов, экспертной оценки и еще более 50 методов, которые можно комбинировать между собой.
Есть косяки, которые лучше предотвращать, а не исправлять.
И есть стратегии обработки рисков:
- принять риск. Согласиться, что ущерб от сработавщего риска допустим и где-то застраховать сумму для компенсации. Или вложиться в предовтращение риска
- отклонить риск: считать, что ущерб от сработавщего риска недопустим. и не делать так, что бы риск возник.
Вы видите только свою часть, и Вы уверены, что можете верно провести хотя бы Business Impact Analysis для своего Работодателя, не говоря уже про Клиента?
Вас уже, наняли что бы снизить уже известные риски
Даже не смотря на все вышеупомянутое, «черного лебедя» никто не отменял :)
НЛО прилетело и опубликовало эту надпись здесь
Ну до чего же трудно доходит. Ну нельзя оценить риск и выбрать стратегию, если не знать о ситуации, которая грозит.
Давайте последуем стратегии «обезьянка видит — обезьнка делает» и изучим доступные материалы по этой теме (хотя бы кратко) :)
Оценка риска позволяет ответить на следующие основные вопросы:
— какие события могут произойти и их причина (идентификация опасных событий);
— каковы последствия этих событий;
— какова вероятность их возникновения;
— какие факторы могут сократить неблагоприятные последствия или уменьшить вероятность возникновения опасных ситуаций. Кроме того, оценка риска помогает ответить на вопрос: является уровень риска приемлемым, или требуется его дальнейшая обработка?
Ответственные за оценку риска должны знать:
— область деятельности и цели организации;
— уровень приемлемого риска и способы обработки неприемлемого риска;
— способы интеграции процессов оценки риска в процессы менеджмента организации;
— методы оценки риска и способы их применения в процессе менеджмента риска;
— систему подотчетности, распределения ответственности и полномочий в области оценки риска;
— требуемые и доступные ресурсы для выполнения оценки риска;
— способы регистрации и анализа оценки риска.
Причинно-следственный анализ
Краткий обзор
Причинно-следственный анализ является структурированным методом идентификации возможных причин нежелательного события или проблемы. Данный метод позволяет скомпоновать возможные причинные
факторы в обобщенные категории так, чтобы можно было исследовать все возможные гипотезы
Контрольные листы
Краткий обзор
Контрольные листы представляют собой перечни опасностей, риска или отказов средств управления, которые обычно разрабатывают на основе полученного ранее опыта, результатов предыдущей оценки риска или
результатов отказов, произошедших в прошлом.
Анализ воздействия на бизнес
Краткий обзор
Метод анализа воздействия на бизнес (BIA1) ), также известный как оценка воздействия на бизнес, позволяет исследовать, как ключевые виды отказов/нарушений/разрушений могут повлиять на ключевые виды деятельности и процессы организации, а также идентифицировать и количественно определить необходимые возможности для управления организацией в этих условиях. Процесс метода BIA обеспечивает согласование и понимание:
— идентификации и критичности ключевых бизнес-процессов, функций, связанных ресурсов и ключевых взаимосвязей, существующих в организации;
— влияния отказов/нарушений/разрушений на возможности организации достигать установленных критических целей бизнеса;
— необходимых возможностей управления воздействием отказов/нарушений/разрушений и восстановлением нормального хода деятельности организации.
НЛО прилетело и опубликовало эту надпись здесь
А кто мешает «творить» разработчику в его области ответственности?
Разработчик должен понимать, что он предоставляет «сервис разработки» для своего Работодателя и Клиента. Этот «предоставленный сервис» обязан быть выполнен в первую очередь с заранее оговоренным качеством и ценой.
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
Или чем-то отличается?
Разработчик должен понимать, что он предоставляет «сервис разработки» для своего Работодателя и Клиента. Этот «предоставленный сервис» обязан быть выполнен в первую очередь с заранее оговоренным качеством и ценой.
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
Или чем-то отличается?
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.А это — уже бизнесу решать.
Или чем-то отличается?
Тут всё дело в том, что производительность труда разработчика, который «болеет душой за дело» и того, который «предоставляет сервис разработки» — отличаются на порядок. Не двоичный, нет. Разница в производительности в 10 раз — это задокументированный факт.
Если руководству компании подход «это просто сервис разработки» милее и они готовы увеличить ФОТ разика в три, чтобы нанять в 10 раз больше разработчиков (обычные разработчики ещё и дешевле, ко всему прочему — но, разумеется, не в 10 раз) — тогда всё описанное в статье было сделано правильно: это вполне себе действенный способ превратить разработчиков в «винтики» и выжить тех, кто могут что-то действительно крутое сделать.
А если нет — то это большая ошибка. Потому что превратить разработку в рутину и выжить «10x звёзд» — несложно. Проделать обратную процедуру — почти невозможно.
Что значит «болеть душой за дело»? Это бесплатно работать ночами? Рвать на груди рубашку и с криком «вы все козлы» деплоить самопальный «гениальный» код на сервера клиента?
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
И как Работодатель должен стимулировать «болеть душой за дело»? Взять любимого хомячка в заложники или дать «сахарные губки» и Негра с опахалом?
Условия работы оговорили? Оговорили.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом и «сахарные губки» или что ему еще надо.
Есть условия получше? Пусть перебирается.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Видел людей которые под капельницей полежали, после такой вот «болеть душой за дело»… Нифига они не рады такому
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
И как Работодатель должен стимулировать «болеть душой за дело»? Взять любимого хомячка в заложники или дать «сахарные губки» и Негра с опахалом?
Условия работы оговорили? Оговорили.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом и «сахарные губки» или что ему еще надо.
Есть условия получше? Пусть перебирается.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Видел людей которые под капельницей полежали, после такой вот «болеть душой за дело»… Нифига они не рады такому
Условия работы оговорили? Оговорили.Формально верно. Вам платят, вы работаете.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом
Но в реальности что происходит, когда разработчику не интересно? Он с трудом вымучил 2 функции и сидит тупит. Код будет некачественным, потому что лень кодировать случаи, не указанные в ТЗ (а они в процессе разбора алгоритма так или иначе появляются), лень даже формировать качественные сообщения об ошибках, чтобы пользователь сам разобрался.
Конечно, разработчик будет уверять, что он работает с полной отдачей, только платите побольше. Но мозг не обманешь — когда скучно, он будет искать способы сэкономить энергию.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…Это глупость. К примеру, нравится человеку матрёшек вытачивать и раскрашивать, он болеет за них всей душой. Значит ли, что от такого рукоделия появятся седые волосы или поднимется давление?
Но в реальности что происходит, когда разработчику не интересно? Он с трудом вымучил 2 функции и сидит тупит.
В реальности? Если вышел за «рамки»? Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…
Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…И он его найдёт — не сомневайтесь. Люди, способные командой в 5-10 создать нечто, что их конкуренты не могут повторить, имея коллектив в несколько сотен «винтиков» на рынке вполне востребованы.
Но вопрос «а нужны ли они нашему бизнесу» — это уже совсем другой вопрос. Собственно это и есть главный вопрос, на который в статье не был дан ответ. Чего хотели от внедрения Agile — и получили ли в результате то, чего хотели?
Так 2 функции в день — это средний показатель на неинтересном проекте, где разработчики демотивируются. Поэтому объясняться придётся всем, ну или владельцы не допрут, что такая скорость это ненормально и будут думать, что раз все так работают, то так и надо.
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?А потому что невыгодно.
Давайте я покажу на примере. Просто не так давно этим занимался, потому пример в памяти ещё свеж. Эмуляция ARM, основные инструкции. Их — порядка 100 штук в мануале.
Что можно сделать при использовани скрама и тому подобных вещей? Создать 100 «тасков» на пару часов каждый и начать реализовывать эти инструкции. За месяц с небольшим задача будет решена (40-часовая неделя, всё такое).
Что можно сделать если не считать человека винтиком? Вспомнить о том, что эти инструкции же были как-то реализованы в ARM2, в котором было-то всего 30'000 транзисторов! Как? Если внимательно всмотреться — то можно увидеть что там есть 8 бит, которые влияют на то, какие блоки в процессоре срабатывают и когда. И написать несколько функций, которые будут тесно друг с другом связаны строк на 150-200 — и всё.
Но вот беда: Петя с его 100 «тасками» будет любимцем всех менеджеров, будет иметь отличные показатели и будет всеми уважаем и любим. Вася, который создаст несколько функций, потратит на них дня три, причём в первые пару дней выхода не будет вообще — он будет мануалы читать!
Есть условия получше? Пусть перебирается.Дык так и происходит. Когда Петя, со своей погоней за «тасками» разнесёт «фен-шуй», который создал Вася, то тот перестанет чувствовать сопричастность или либо уйдёт, либо переключится на стиль работы Пети.
Извините, но вопрос внутренней мотивации и психологии разработчика никак не относится к методологии и ее не корректному применению.
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»Выбор идёт в обратном направлении: Менеджер, стремящийся примерно к этому найдёт такую методологию, которая позволит ему это сделать. А как она формально будет называться — уже не так и важно.
Извините, но вопрос внутренней мотивации и психологии разработчика никак не относится к методологии и ее не корректному применению.Это очень странно, потому что это, собственно, самое главное, что влияет на количество и качество результатов…
Да. В этом и проблема.
Слишком много «человеческих» переменных. А процессы пытаются это влияние и зависимость уменьшить.
Женщину достали, автомат поставили. (с)
Слишком много «человеческих» переменных. А процессы пытаются это влияние и зависимость уменьшить.
Женщину достали, автомат поставили. (с)
НЛО прилетело и опубликовало эту надпись здесь
Глупые — пытаются заменить человеческий потенциал инструкциями и методологиями.
А вот тут я с Вами согласен :)
Корректная трактовка инструкци — это накопленный опыт, как некоторые действия в уже известных ситуация привели к ожидаемому результату (Success stories), что освобождает время на на иные действия.
Например: не суй цальцы в розетку, мойте руки перед едой, не дразните собаку, проверь код что написал, SOLID, Scurm, ISO 27001 и т.д.:)
Так же очевидно, что они не запрещают и дейстовать иначе в аналогичной ситуации и вырабатывать иные «инструкции».
Что можно сделать при использовани скрама и тому подобных вещей? Создать 100 «тасков» на пару часов каждый и начать реализовывать эти инструкции. За месяц с небольшим задача будет решена (40-часовая неделя, всё такое).
Почему вы считаете, что скрам требует такого подхода? В рамках планирования спринта и груминга беклога команда может решить что это все одна User story. Или побить по видам команд. См также "Вертикальная декомпозиция"
Чтобы это понять, нужно прочитать весь мануал и в уме держать всю архитектуру. Типичный «ленивый» подход — я держу в памяти только свой кусок ТЗ, который есть в спринте — не позволит это сделать.
При чем тут Scrum? Он никак не предписывает разбивать спринты по командам процессора и не держать в уме всю архитектуру. Более того, реализация n команд — плохая цель спринта с моей точки зрения. Правильная цель спринта — "Дать пользователю запустить X на эмуляторе" — то есть декомпозиция должна быть вертикальной. Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.
Правильная цель спринта — «Дать пользователю запустить X на эмуляторе»Это — месяца два работы, как минимум. Вы хотите это одним таском оформить?
Дальше команда может разбить инкремент спринта технически, если это надо — хотите по командам, хотите по группам битов внутри команд.Не будет при таком подходе разбивки по битам. Потому что история про эти биты и их «творческое комбинирование» подробно разбирается только и исключительно в мануале 1987го года на процессор ARM2! В мануале 1996го года на ARM810 — описано как эта схема эволюционировала (но подробного описания уже нет), а в современных мануалах — не осталось даже намёков! Вы думаете кто-то, кому платят за выполнение «тасков» туда полезет разбираться? Зачем? Если есть простой и понятный путь, который будет гарантированно оплачен?
Это — месяца два работы, как минимум. Вы хотите это одним таском оформить?
Я не в теме. 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.
Вот наглядный пример:
Есть задача разработать систему расчётов чего-либо.
К этой задаче прилагается техзадание.
Разработчик А (предоставляющий сервис): реализовал задачу в точности по ТЗ.
Разработчик Б (болеющий душой за дело): внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Промежуточный итог 1: «сервис»-разработчик лучше, т.к. всё реализовано быстро и по ТЗ
Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ, на которые разработчик А не обратил внимание, а разработчик Б — обратил и исправил ещё процессе разработки. В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
Итог: разработчик (да и любой специалист), который не просто «работает с 8 до 5 предоставляя сервис», а нацелен на результат и старается сделать проект лучше, будет более востребован и ему будут платить в разы больше (и это будет оправдано экономически).
Притом «болеющий душой» разработчик не обязательно трудоголик. Он может и в 8 часов рабочего дня приносить в разы больше пользы компании, чем «предоставляющий сервис» разработчик за 12 часов.
Есть задача разработать систему расчётов чего-либо.
К этой задаче прилагается техзадание.
Разработчик А (предоставляющий сервис): реализовал задачу в точности по ТЗ.
Разработчик Б (болеющий душой за дело): внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Промежуточный итог 1: «сервис»-разработчик лучше, т.к. всё реализовано быстро и по ТЗ
Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ, на которые разработчик А не обратил внимание, а разработчик Б — обратил и исправил ещё процессе разработки. В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
Итог: разработчик (да и любой специалист), который не просто «работает с 8 до 5 предоставляя сервис», а нацелен на результат и старается сделать проект лучше, будет более востребован и ему будут платить в разы больше (и это будет оправдано экономически).
Притом «болеющий душой» разработчик не обязательно трудоголик. Он может и в 8 часов рабочего дня приносить в разы больше пользы компании, чем «предоставляющий сервис» разработчик за 12 часов.
Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ,
Привет Agile и иже с ними.
внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Молодец. Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.
В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
В первом случае тоже не будет никаких судебных разборок:
- сделано по ТЗ.
- Клиент провел приемо-сдаточные испытания или получил протоколы тестов от Подрядчика
- подписал акт приемки.
Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?Да потому что это не-вы-год-но!
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.Как раз наоборот. Обязательно дойдут, выползут и «ударят по почкам». Вы забываете про один фактор, который реально перечёркивает всё: клиенты не знают, что они хотят. Люди, которые приносят вам ТЗ — это совсем не те люди, которые будут пользоваться вашей программой в 99% случаев! И даже если — те, они всё равно понятия не имеют чего вы в принципе можете, а чего не можете!
В первом случае тоже не будет никаких судебных разборок:Именно! Если ваша задача — сделать не хорошую программу/систему/etc, а что-то, что получит хорошие оценки на «приёмо-сдаточных испытаниях» — то гораздо проще и выгоднее не мучиться, не дёргать аналитиков и менеджеров, а подождать пока всё то дерьмо, которое вы сотворите согласно ТЗ всплывёт в реальной эксплуатации, пользователи начнут орать благим матом — а вы, весь такой в белом, придёте и разрулите ситуацию. Ещё хуже — когда разработчик начнёт работать на то, чтобы реализовать больше UserStory, а не на то, чтобы удовлетворить заказчика.
- сделано по ТЗ.
- Клиент провел приемо-сдаточные испытания или получил протоколы тестов от Подрядчика
- подписал акт приемки.
Простой пример: менеджеры будут обсуждать неделю куда всунуть кнопку «пересчитать итог» и каким цветом её лучше выделить, но додуматься до того, что можно сделать так, чтобы эта кнопка была не нужна, так как можно сделать все в фоновом потоке и просто скрывать данные, которые не валидны и показать их, когда они станут валидны — не смогут, так как это не вписывается в их видение мира!
А когда увидят эту фичу в конкурирующем продукте — заставят её внедрить везде и пользователи начнут вас проклинать, когда рассчёты, требующие полчаса, будут происходить в фоне и никто не будет знать — они, вообще, собираются заканчиваться или нужно систему на ночь оставить, чтобы она «прочухалась»…
Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
Да потому что это не-вы-год-но!
Возможно я уже перерос ходить «с фигой в кармане», но почему невыгодно мне, как разработчику, сказать про косяки заранее?
- Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»
Я смотрю обратную связь Работодателя, Клиента. Если я вижу, что их реакция «неадекватная», я понимаю что ничем хорошим это не кончится и начинаю себе «стелить соломку».
И через время ухожу «подготовленный» - Если я молчу «с фигой в кармане», через время у Компании начинаются проблемы, я не успеваю подстелить соломку и все равно вынужден уходить. только уже не подготовленным.
Где моя выгода в стратегии «молчания, с фигой в кармане»?
Я сам себе сделал хуже, а не только «злым менеджерам».
Люди, которые приносят вам ТЗ — это совсем не те люди, которые будут пользоваться вашей программой в 99% случаев!
Учим мат часть :) Изучаем работу со стейкходелдерами, изучаем приемы BA и т.д.
менеджеры будут обсуждать неделю куда всунуть кнопку «пересчитать итог» и каким цветом её лучше выделить,
Не менеджерское/барское дело «кнопки красить». Пусть займутся своими делами. К примеру сделают RACI матрицу в начале проекта, обеспечат ресурсами и не лезут не в свое дело после.
Нанимают нормальных спецов по UI/UX, дают ресурсы изучать мануалы по дизайну от компаний, обеспечивают софтом для прототипирования и т.д.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим. Потом удивляемтся, почему так? А хто эта сделал ?!
Из бочки варенья и ложки г#вн@, получается бочка г#вн@ + 1 ложка. И не иначе
Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»… и попадаете в «чёрный список», потому что из-за вас количество UserStory, реализованных за спринт начинает падать, ваш отдел получает славу «скандалистов» и т.д. Оно вам надо?
Если я молчу «с фигой в кармане», через время у Компании начинаются проблемыИ вы их героически разруливаете. Получаете премию.
Где моя выгода в стратегии «молчания, с фигой в кармане»?Почему же? Вы сохранили свои нервы, считаетесь «надёжным работником», так что когда компания начнёт разваливаться — у вас будет больше времени на то, чтобы найти новую. Вы всем сделали лучше — за исключением конечного пользователя, конечно — но это-то как раз в этой ситуации уже совсем неважно.
Я сам себе сделал хуже, а не только «злым менеджерам».
Не менеджерское/барское дело «кнопки красить».Если бы менеджеры в обсуждаемой компании тоже так считали — то не было бы этой статьи. А если менеджеры учитывают только свои «таски», то вся работа и вырождается в вопросы покраски кнопок. И менеджеры как раз на них у будут делать упор, так как остального не понимают.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим.Неа. Прослеживается устойчивая мысль: вы получаете то, за что платите. Хотите хороший продукт? Тогда сделайте так, чтобы тот, кто его делает был в этом заинтересован. Хотите больше UserStory и «галочек»? Получите свои UserStory и галочки. Только хорошего продукта уже не будет.
… и попадаете в «чёрный список», потому что из-за вас количество UserStory, реализованных за спринт начинает падать, ваш отдел получает славу «скандалистов» и т.д. Оно вам надо?
Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам? Вероятно, у вас какой-то опыт работы в конторах с не очень хорошими отношениями между начальством и подчиненными и вы накладываете это на скрам. Но весь эффект получается от именно этого отношения, а не от скрама
Не могли бы вы процитировать кусок скрамгайда, относящийся к черным спискам?Вы сюда как будто из какой-то альтернативной вселенной свалились. Где люди читают инструкции.
Какой-такой скрамгайд в мирное время? Есть цифирьки, их можно сладывать и сравнивать. Кто больше получил — тот и молодец… Всё ж просто! Ах, что так не надо было? А почему? И кто мне, менеджеру, это запретит делать, собственно?
Да в моей вселенной хорошие отношения на работе и менеджеры не давят на цифирьки и понимают, если им объяснить.
А в вашей вселенной получается вы работаете как-то так, что никаких чисел нельзя вычислить. Например в языке принципиально нельзя подсчитать количество строк кода, а то бы менеджеры их просили и за них дрючили.
Например в языке принципиально нельзя подсчитать количество строк кодаПосчитать можно, но мы этого не делаем. Потому что если бы делали — да, менеджеры бы начали их складывать и вычитать. В журналах, кстати, платят пословно.
а то бы менеджеры их просили и за них дрючилиОдно дело — запросить какую-то информацию специально (тут ещё можно объяснить, что я не передовик производства только потому что залил в репозиторий автосгенерённый файл на 10'000 строк), другое дело — запретить им использовать данные, которые у них уже есть.
Грубо говоря весь Scrum сводится к тому, что мы в клетку с тиграми заносим тарелку с мясом, а потом начинаем им объяснять, что есть его нельзя. У кого-то получается, у кого-то нет, но сама идея, конечно, совершенно правильна, вы не находите?
И еще. Для искажённого скрама есть отдельное название "scrumbut" ("скрамно") https://www.scrum.org/scrumbut так, что наверное стоит использовать его. "у нас внедрили скрамно, в результате все уводились"
НЛО прилетело и опубликовало эту надпись здесь
Я этот термин уже видел, да и искать его проще https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%D1%81%D0%BA%D1%80%D0%B0%D0%BC%D0%BD%D0%BE
НЛО прилетело и опубликовало эту надпись здесь
Прослеживается устойчивая мысль: вы получаете то, за что платите. Хотите хороший продукт? Тогда сделайте так, чтобы тот, кто его делает был в этом заинтересован. Хотите больше UserStory и «галочек»? Получите свои UserStory и галочки. Только хорошего продукта уже не будет.
Что и требовалось выяснить- не корректное применение инструментария безграмотными менеджерами.
Вины инструментария Scum / Agilre- нет. :)
Вины инструментария Scum / Agilre- нет. :)Есть — но косвенная. Если сравнивать Agile/Scrum с языками программирования — то я бы сравнил их даже не с C++, а, скорее, с ассемблером. А из бытовых предметов — с дисковой пилой без ограничителя.
То есть при правильном примении — вы можете добиться фантастических результатов. Однако «отрезать себе руку» — не просто, а черезвычайно просто.
Инструментарий просто-таки напрашивается, чтобы его «эффективные манагеры» засунули к себе в Excel и начали на его основании «любить и жаловать». Для того, чтобы его не стали вдруг использовать «неправильно» (то есть — наиболее очевидным, просто-таки напрашивающимся способом!) нужен специальный человек с весьма специфическими навыками.
Интересно, какая должна быть методология чтобы зарезать себя использовать неправильно? Даже в том случае, когда можно выполнять не все предписания или не полностью из гацда придумывать свое и все равно называть это ее именем? Есть скрам мастеру и сертификация оных, но все равно недостаточно. Мне кажется это должно быть тайное общество и методология должна называться секретно. То есть ее имя открывается только тому, кому верховный методолог разрешил, убедившись, что он усвоил ее букву и дух. И жестоко карать отступников.
Мне кажется это должно быть тайное общество и методология должна называться секретно. То есть ее имя открывается только тому, кому верховный методолог разрешил, убедившись, что он усвоил ее букву и дух. И жестоко карать отступников.В каждой шутке…
Главное, чего в ней быть не должно — это чисел, которые можно пытаться «улучшить». То она должна раз навсегда постулировать, скажем, что UserStory — должно быть 5 штук в неделю. Или 7. Или 3. Неважно даже сколько — важно, что это число должно быть фиксированным.
Поймите вы: это естественное побуждение любого менеджера — увеличивать «эффективность». Единственный способ не дать им этого делать — это предоставить им информацию в таком виде, чтобы она не позволяла этого делать. Вот и всё. Scrum пытается вместо этого использвовать сертификацию и «гацды». Иногда это работает, но чаще — нет. Потому что идёт вразрез с привычками побуждениями менеджеров.
НЛО прилетело и опубликовало эту надпись здесь
User stories бывают разные: на одну нужен час, на другую — 8.Значит ту, которая займёт час нужно объединить с ещё парочкой других и назвать как-нибудь типа «пакет мелких улучшений от заказчиков X и Y».
Даже их сложение не имеет смысла.Объяснить это типичному менеджеру — невозможно. Потому что ему нужны числа, которые можно складывать и сравнивать. И он будет их выискивать во всех данных, которые будут от вас поступать! Ваши числа «даже сложение которых не имеет смысла» — первейший кандидат. Какие нафиг рубашки разных размеров? Хоть бананы! Менеджеры ведь не идиоты. Достаточно посмотреть на результаты работы нескольких недель, чтобы понять сколько «помидор размера XXL» занимает в часах.
НЛО прилетело и опубликовало эту надпись здесь
https://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes
T-shirt sizes are an OK approach to getting started with relative estimating, but they suffer from two severe weaknesses:
- They aren't additive. You cannot tell a boss you'll be done in 3 mediums, 4 larges, and 2 petites.
- Your view of an XL may not match mine. You may think it's 50% bigger than an L; I may think 25% bigger.
Ни один вменяемый человек не будет прибавлять десятку к даме и ждать осмысленного результата.Почему нет? Нужно только пересчитать «десятки» и «дамы» в часы — и дело в шляпе. Несколько недель наблюдений и «ретроспектив» — и всё.
НЛО прилетело и опубликовало эту надпись здесь
А как же классическое «на этот спринт у нас запланировано 100 SP, а сделали 80 — премии не будет!»?
НЛО прилетело и опубликовало эту надпись здесь
Так или иначе в спринт включается конечный список задач, который планируется сделать в его течение. Весь бэклог не включают.
Я вполне готов допустить, что где-то Scrum может быть и другой.
Но тут как бы посылки были изначально даны в статье:
Любая методология будет «подтягиваться» под решение поставленных задач.
Но тут как бы посылки были изначально даны в статье:
С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики.Так вот вторая часть — во многом противоречит первой. Из неё прямо следует необходимость учёта, в том или ином виде, времени — а дальше уже не так важно: Scrum или Хрум.
Любая методология будет «подтягиваться» под решение поставленных задач.
как в Scrum что-то организовано
Я уже достаточно много сталкивался со Scrum, чтобы понимать, что единого Scrum нет, что есть понимание каждого, как минимум Scrum-мастера, о том, что такое правильный скрам, что и как должно быть организовано.
Эффект воздействия описан здесь извините, это видео :), но зато ссылка воспроизведет нужный кусочек
Я думаю, никакая методология не даст хорошего результата на ваших "типичных менеджерах". Надо им развиваться в нетипичных.
Вы просто привыкли к таким менеджерам и вам кажется, что других не бывает :)
Ну да…
Сдать на Scrum мастера, PM- сертифиакцию и т.д.- это же недостижимо для обычных людей…
Сдать на Scrum мастера, PM- сертифиакцию и т.д.- это же недостижимо для обычных людей…
Конечно, отличается.
1. В случае наемного труда все риски берёт на себя работодатель, в частности работодатель не может не оплатить труд разработчика.
2. Разработчик не предоставляет сервис, разработчик продаёт свой труд, а не результат труда.
1. В случае наемного труда все риски берёт на себя работодатель, в частности работодатель не может не оплатить труд разработчика.
2. Разработчик не предоставляет сервис, разработчик продаёт свой труд, а не результат труда.
Есть косяки, которые лучше предотвращать, а не исправлять.
И намного больше косяков, на которые можно закрыть глаза на данный момент если ущерб от оных в финансовом плане меньше чем попытки предотвращения оных.
https://www.youtube.com/watch?v=GRr4xeMn1uU — тут весьма содержательный пример. Из жизни же примеров можно и других накидать.
НЛО прилетело и опубликовало эту надпись здесь
Кто оценивает «выгоду» Клиент или Подрядчик? Как он оценивает?
НЛО прилетело и опубликовало эту надпись здесь
Простые вопросы.
Кто получает «выгоду»?
Кто оценивает «выгоду»?
Как выгодоприобритатель «выгоду» оценивает?
Кто получает «выгоду»?
Кто оценивает «выгоду»?
Как выгодоприобритатель «выгоду» оценивает?
НЛО прилетело и опубликовало эту надпись здесь
Подкинул идею.
Мотивация в подкидывании идеи?
Что дальше?
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту. Переиграй «ничтожных людишек» :)
Мотивация в подкидывании идеи?
- Сожрать или использовать ресурсы компании на ее проверку ?
- Получить похвалу от окружающих ?
- Предотвратить будущую проблему для себя ?
- Финасовая мотивация (получить премию, пакет акций)?
Что дальше?
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту. Переиграй «ничтожных людишек» :)
НЛО прилетело и опубликовало эту надпись здесь
делай свою Фирму
Это путь менеджера, а не разработчика. Обычный разработчик не сможет нормально управлять фирмой (даже как учредитель с наемным менеджером) и оставаться разработчиком.
Я остаюсь основным разработчиком (с основания фирмы 15 лет назад), при том, что являюсь совладельцем компании (50%) и руководителем. Всё возможно, было бы желание.
Я несколько раз пробовал подобный путь (даже с 51% решающих голосов и наемным генеральным директором) и прекрасно понимаю, чем это грозит мне как разработчику. Вот положа руку на сердце, сколько процентов реального рабочего времени вы тратите на собственно разработку (пускай даже включая задачи системного администрирования) и сколько на управление, на менеджмент? Сколько процентов личного времени вы тратите на повышение квалификации как разработчика и сколько как руководителя?
У меня не получалось хотя бы 50/50 распределить, как только появлялся второй разработчик. Как ведущему разработчику мне приходилось постоянно решать практически все вопросы с техническим персоналом, с «техническими» подрядчиками и заказчиками. Как топ-менеджеру и соучредителю — участвовать в принятии многих нетехнических решений, в том числе как соучредителю в аудите деятельности генерального директора и главного бухгалтера, особенно когда 51% был. Когда мой голос ничего не решал, то просто ставил «воздержался», а когда он и только он решал, то не поставляю же я «за» или «против» хотя бы не попытавшись разобраться сам в вопросе?
У меня не получалось хотя бы 50/50 распределить, как только появлялся второй разработчик. Как ведущему разработчику мне приходилось постоянно решать практически все вопросы с техническим персоналом, с «техническими» подрядчиками и заказчиками. Как топ-менеджеру и соучредителю — участвовать в принятии многих нетехнических решений, в том числе как соучредителю в аудите деятельности генерального директора и главного бухгалтера, особенно когда 51% был. Когда мой голос ничего не решал, то просто ставил «воздержался», а когда он и только он решал, то не поставляю же я «за» или «против» хотя бы не попытавшись разобраться сам в вопросе?
Я остаюсь основным разработчиком (с основания фирмы 15 лет назад), при том, что являюсь совладельцем компании (50%) и руководителем. Всё возможно, было бы желание.
Это не бизнес, строго говоря. Это такой разросшийся фриланс.
Это не плохо — качество продукта, когда его столь лично контролирует совладелец-разработчик, довольно высоко.
Но возможности роста фирмы серьезно ограничены.
Пока вы не делегируете, пока не можете уехать на пару лет на Канары жить (не по финансовым соображениям, а по управленческим) — это не классический бизнес.
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту.Этот путь работает, когда в компании 5-10 человек. И такое — регулярно происходит. А если в компании — человек 50-100 и они нужны, чтобы поддерживать продукт соответствующего масштаба… То ваши потуги «переиграть ничтожных людишек», в общем-то, обречены… Ну не сможете вы уйти и разработать за месяц, аналог того, что требовало не один десяток человеко-лет…
Вот уйти и сделать что-то новое, другое — легко. Этим обычно и кончается…
Этот путь работает, когда в компании 5-10 человек. И такое — регулярно происходит. А если в компании — человек 50-100 и они нужны, чтобы поддерживать продукт соответствующего масштаба…
Отличие в том, что для этого вам нужно иметь репутацию и хорошо подвешенный язык — чтобы убедить инвесторов.
И управленческие навыки, чтобы не профукать инвестиции.
Посмотрите хоть историю Интела.
Компанию основали Роберт Нойс и Гордон Мур 18 июля 1968 года[4] после того, как ушли из компании Fairchild Semiconductor. Вскоре к ним присоединился Энди Гроув, разработавший и внедривший метод корпоративного управления OKR, эффективно используемый в менеджменте. Бизнес-план компании, распечатанный Робертом Нойсом на печатной машинке, занимал одну страницу. Представив его финансисту (ранее помогавшему создать Fairchild) Intel получила стартовый кредит в $2,5 млн.
Вполне себе разработчики:
Роберт Нортон Нойс (англ. Robert Norton Noyce; 12 декабря 1927 — 3 июня 1990) — американский инженер, один из изобретателей интегральной схемы (1959), один из основателей Fairchild Semiconductor (1957), основатель, совместно с Гордоном Муром, корпорации Intel (1968).
А Мур проделал это на одну фирму раньше:
С 1953 года работал в лаборатории прикладной физики в университете Джона Хопкинса. С 1956 года работал в Shockley Semiconductor Laboratory в Пало Альто, Калифорния, под руководством Уильяма Шокли (William Shockley).
В сентябре 1957 года Мур и ещё семь талантливых инженеров (Вероломная восьмёрка) уходят из Shockley Semiconductor Laboratory из-за разногласий с Шокли и основывают собственную компанию Fairchild Semiconductor для работы с кремниевыми транзисторами в Mountain View, Калифорния. С 1957 работал в Fairchild Semiconductors начальником инженерного отдела, а с 1959 Мур становится директором R&D и руководит группой по разработке n-p-n транзистора.
Смотрю на историю Intel'а. Не вижу ничего из того, что выпускал Fairchild в момент ухода «отцов-основателей». Все люди, ушедшие оттуда начали делать что-то другое. Успешно, да. Но никто из них даже не пытался выпускать что-то, что покупал бы «готовый Клиент», о котором шла речь.
Единственный известный человек, которому удавалось нечто подобное — небеизизвестный Сеймур, но даже у него это со временем стало получаться всё хуже и хуже…
Единственный известный человек, которому удавалось нечто подобное — небеизизвестный Сеймур, но даже у него это со временем стало получаться всё хуже и хуже…
Но никто из них даже не пытался выпускать что-то, что покупал бы «готовый Клиент», о котором шла речь.
Производи что покупают.
В данном случае ребята вышли на рынок к ожидающим клиентам :)
В данном случае ребята вышли на рынок к ожидающим клиентам :)В том-то и дело, что нет. Они выпускали вещи, которые «готовые Клиенты» Fairchild не покупали и искали других клиентов.
Те клиенты, которые покупали продукцию Fairchid с Fairchild и остались. По крайней мере поначалу. Иначе бы Fairchild бы до 1987го года не дотянул бы.
Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.
Когда я впервые столкнулся с Agile, то у меня была подобная же реакция.
Мне понравилось как быстро команда пробует и откидывает кучу интересных технологий.
Но я не вписался.
Я по привычке делал код «на века», с тщательным продумыванием, с вынесением части кода в общеупотребимые библиотеки/пакеты. В результате мне пришлось неоднократно переписывать код с нуля, подстраиваясь под все новые и новые варианты интеграции. И я все никак не мог завершить свой маленький подпроектик и получить соответствующую премию.
В результате я не выдержал и свалил с проекта.
Вот таким было мое первое знакомство с Agile.
Поразмыслив, я считаю сейчас, что методология Agile — это очень круто.
Вот только нужно правильно с ней работать.
Agile — как принципы гибкой разработки, как принципы тесного взаимодействия заказчика и исполнителя с доставкой фич на ранних стадиях разработки и минимальным временем реакции на уточненные после неё требования — это круто. Способы его насаждения сверху в виде каких-то жестких методологий, зачастую очень похожих на сектантские ритуалы — это, обычно, путь в, как минимум, уменьшение эффективности команды.
Способы его насаждения сверху в виде каких-то жестких методологий, зачастую очень похожих на сектантские ритуалы — это, обычно, путь в, как минимум, уменьшение эффективности команды.
Конкретные способы насаждения с которыми столкнулись Вы — не знаю.
А в целом и общем готовая методология нужна и полезна.
Чужие грабли это лучше, чем свои.
Да, они хуже усваиваются, но если просто следовать чужому методу обхода граблей — это просто и быстро.
В конце концов мы же не придумываем свои операционные системы и свои СУБД (редко) для нового очередного проекта — пользуемся готовыми. Это — эффективно.
Так же как и использование готовой методологии.
Тут в чём дело — методологии управления разработкой нужны, прежде всего, менеджерам, а не разработчикам. А менеджер, зачастую, не может выбрать оптимальную методологию для имеющихся условий, не зная ни области её применимости, ни даже существующих условий.
а если убрать из команды менеджеров? Ну вот совсем. Нету менеджеров. Выходит и процессы не нужны? Как-то не очень...
Процессы нужны команде в первую очередь чтобы знать что делать.
Процессы всегда есть, вопрос насколько они формализованы, насколько гибки. Разработчикам нужна постановка задач, чтобы знать что делать. В общем и в целом отдельный менеджер команды для этого не нужен. Постановка осуществляется аналитиками (вариант — совместно заказчиком и разработчиками). Ещё неплохо бы приоритезацию, а она может осуществляться совместным решением конкурирующих за ресурсы команды стейкхолдерами, или вообще большим боссом, если они не договорились.
К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.
А вот это вряд ли.
О сути, которой является вот это:
Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.
А вовсе не используемые базы данных — разработчики ни сном не духом.
Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка
А он всегда и был отверткой и молотком.
Деньги в таком проекте приносит то, кто знает кому проект толкнуть.
С их точки зрения всё, конечно, логично: быстрее сделали – а значит, понесли меньше расходов, быстрее выполнили контракт, получили деньги и премии. Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
Сие не имеет к Agile/Scrum ровным счетом никакого отношения.
Это обычное отношение менеджера (заказчика) к программисту (исполнителю).
Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.
Имхо, Agile как раз и позволяет по-крупному творить.
Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понравиться не всем.
Дети-то как раз быстрее взрослых адаптируются
Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Сие опять таки описывает только взаимоотношения менеджеров и разработчиков.
Не имеющего никакого отношения к Scrum/Agile.
Почему в производственной компании, делающий уже много лет как единственный как я понял основной продукт, решили подходить к изготовлению ПО как к ПО-однодневке, почему баги считаются менее важным, чем развитие продукта — вопросы к руководству проектом.
Вполне возможно, что пытались угнаться за конкурентами.
То есть проблема, думается, лежит вне области разработчиков.
Учитывая вступление к статье, где говориться о бурном росте и открытие филиалов — компании банально были нужны деньги.
А деньги дают прежде всего новые фичи, сделанные по финансируемым заказчикам просьбам.
Руководство не смогло держать баланс между зарабатыванием на новых фичах и бесплатным исправлениями старых багов.
Но, вопрос возникает снова, — вина ли в этом Agile/Scrum. Почему?
Перестройка на новую методологию (любую — хоть Agile, хоть не Agile) — это разумеется напряжение.
Но почему автор статьи сваливает вину именно на Agile?
А не на менеджеров.
В итоге вся эта система стала приводить к маленькому локальному коллапсу. Разработчики растеряли весь энтузиазм и стали относиться к разработке формально. Есть задача – делаем, нет задачи – не делаем.
Тут описана болезнь роста.
В маленькой фирме все на виду. В большой — более формальный подход, разработчики и не должны ничего делать просто так, без формальной задачи. Кроме особо доверенных.
Такая схема позволяет руководству компании иметь представление, а какими ресурсами оно располагает, какова будет себестоимость на том или ином этапе работ.
А работа без поставленной задачи = не работе вообще.
Вы можете быть добросовестным работником, а можете балду пинать — в большой компании это не видно.
Поэтому формальная задача нужна всегда.
У нас с Agile это решается просто — разработчики могут сами поставить себе задачу (разумеется, с уведомлением и одобрением старшего), если видят что-то «в глубине», что не видно менеджерам снаружи.
Разумеется, всегда сложно объяснить «верхам» что тут обязательно нужен крупный рефакторинг (который, понятно денег не приносет сиюминутно, а напротив).
Технический долг — эта тема отдельной статьи:
https://habrahabr.ru/post/319332/
Но опять таки — это не вина Agile/Scrum.
Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
В итоге вся эта система стала приводить к маленькому локальному коллапсу.
Из чего следует, что некий старший разработчик недостаточно защищал интересы своих людей (и качество их работы).
Менеджеры давили, они всегда давят на скорость и т.п. — это и есть их работа.
Но старший разработчик должен был сопротивляться. Не фикшен критический баг перед выпуском в production — кто об этом скажет руководству? Кто выбьет время на исправление бага? Это и должен быть старший разработчик. Это может быть менеджер проекта(скорее всего), именно его дело — заботиться о качестве, именно он и знает. Ну может еще тех. лид (но маловероятно, что лид пойдет стучать ботинком о стол руководства).
А менеджеры, принимающие у заказчиков новые требования и конвертирующие их в таски разработчиков — разумеется, занитересованы в другом.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
Агрессивный переход на такие потоковые методологии разработки приводит к «формализации» отношений внутри компании. Результатом резких внедрений стало то, что менеджмент теперь лучше видит, что происходит в компании, но ключевых разработчиков в компании уже нет.
Энтузиазм — штука не контролируемая.
Поэтому она хороша или до некого небольшого размера компании, когда все на виду.
Или, когда у тебя полно бабла и жесткий отбор сотрудников — как Google позволяет своим сотрудникам творить в больших объемах.
По мере роста компании без формализации компания развалится (станет неэффективной).
Говорить о том, что эти сотрудники виноваты сами, тем, что не смогли адаптироваться, или поступили высокомерно – как по мне, так это ошибка. Возможно, сам процесс внедрения Agile был организован неверно, но, так или иначе, свою черную сторону этот процесс имел.
Ну ну.
Я сам из своего первого Agile вылетел сам и с облегчением вздохнул.
А сейчас его люблю.
Почти 10 лет управляю разработкой. Сам не программист. У меня работа идет только по задачам, а учет времени даже не почасовой, а поминутный. Мы зачастую себя называем экстримальными Agile разработчиками.
Agile — изначально это возможность заказчика в ходе разработки менять требования, т.е. гибкая разработка. Модели процессов, которые придумывают люди, чтобы обеспечить такой режим разработки нельзя применять «как есть» с закрытыми глазами на текущую в конкретной команде реальность.
Получается, что в описанном результате не виноват ни сам эйджайл, ни скрам.
Если мой разработчик обнаруживает, что есть незапланированная задача, которую следует по его мнению выполнить, то он просто вносит ее. В зависимости от настройки проекта он, либо ждет согласования, либо выполняет сразу и учитывает по ней затраченное время.
На вопрос сколько нужно времени на выполнение задачи, ответ от программиста от 20 минут до 2 недель вполне приемлем! У программистов многопоточное мышление. Если он не знает, как сейчас решать задачу лучше и переключается на другую, то это не значит, что во втором потоке не идет поиски решений по первой. Надо уметь давать вызревать задаче, тогда на ее решение может уйти всего минуты. Это уже практика.
По факту хреновый был у вас менеджмент, видимо хорошего опыта разработки не имел.
Опасайтесь моделей! Модели бизнес процессов, взятые из опыта других — это лишь примеры для ваших размышлений. Принять к сведению и сделать по своему. Приблизительно такая же ситуация произошла, когда один из «наших» купил Mandriva, ввел туда менеджмент и все разработчики разбежались, а разработка была приостановлена.
Менеджмент и разработчики и много других участников процесса разработки — это части одного целого. Нельзя противопоставлять их друг другу. Причем со стороны разработчиков также нужно относится с пониманием, или хотя бы с желанием понять задачи тех, кто управляет разработкой или выполняет другие функции, в купе дающие готовый и рабочий продукт.
Много раз встречал и быстро прощался с разработчиками, которые ставили себя выше других и с пренебрежением относились к другим участникам не столь одаренным, но выполняющим свое дело. Только во взаимопонимании рождаются действительно хорошие продукты, и устанавливается комфортная среда для ведения процессов разработки. А методы должны соответствовать конкретной команде, задаче и другим условиям окружающей среды.
Всех благ.
Agile — изначально это возможность заказчика в ходе разработки менять требования, т.е. гибкая разработка. Модели процессов, которые придумывают люди, чтобы обеспечить такой режим разработки нельзя применять «как есть» с закрытыми глазами на текущую в конкретной команде реальность.
Получается, что в описанном результате не виноват ни сам эйджайл, ни скрам.
Если мой разработчик обнаруживает, что есть незапланированная задача, которую следует по его мнению выполнить, то он просто вносит ее. В зависимости от настройки проекта он, либо ждет согласования, либо выполняет сразу и учитывает по ней затраченное время.
На вопрос сколько нужно времени на выполнение задачи, ответ от программиста от 20 минут до 2 недель вполне приемлем! У программистов многопоточное мышление. Если он не знает, как сейчас решать задачу лучше и переключается на другую, то это не значит, что во втором потоке не идет поиски решений по первой. Надо уметь давать вызревать задаче, тогда на ее решение может уйти всего минуты. Это уже практика.
По факту хреновый был у вас менеджмент, видимо хорошего опыта разработки не имел.
Опасайтесь моделей! Модели бизнес процессов, взятые из опыта других — это лишь примеры для ваших размышлений. Принять к сведению и сделать по своему. Приблизительно такая же ситуация произошла, когда один из «наших» купил Mandriva, ввел туда менеджмент и все разработчики разбежались, а разработка была приостановлена.
Менеджмент и разработчики и много других участников процесса разработки — это части одного целого. Нельзя противопоставлять их друг другу. Причем со стороны разработчиков также нужно относится с пониманием, или хотя бы с желанием понять задачи тех, кто управляет разработкой или выполняет другие функции, в купе дающие готовый и рабочий продукт.
Много раз встречал и быстро прощался с разработчиками, которые ставили себя выше других и с пренебрежением относились к другим участникам не столь одаренным, но выполняющим свое дело. Только во взаимопонимании рождаются действительно хорошие продукты, и устанавливается комфортная среда для ведения процессов разработки. А методы должны соответствовать конкретной команде, задаче и другим условиям окружающей среды.
Всех благ.
Управляю разработкой почти 8 лет как CTO, немного программист, имеют опыт около 5 лет как фронтенд-разработчик.
И именно поэтому проблем, сходных с описываемыми в посте, у меня не возникает — я говорю с менеджерами на их языке, с разработчиками — на их. Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит. Он обещает клиенту золотые горы, и уже завтра, он не понимает, что «добавить галочку» одновременно значит «перелопатить логику в десятке мест и все протестировать», он хочет, чтобы конкретно его клиенту сделали ту фичу, которую этот клиент хочет прямо сейчас, бросив все другие дела.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру» — расставить приоритеты, превратить поток сознания менеджера-продажника в нормальные задачи, решить, кто эти задачи сделает эффективнее и распределить их, оценить сроки (когда самому, а когда и посоветовавшись), проконтролировать исполнение, а также заблокировать неумеренный и неуместный энтузиазм вида «да это буквально 5 минут, давайте сделаем прям щас». Ага, щас, разбежались.
Вообще стараюсь не допускать прямого контакта технарей и менеджеров, если честно. Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды. И это облегчает жизнь всем этим частям.
Думаю, без такого контроля, когда все, что подается на вход в разработку извне, разбирается человеком, понимающим техническую часть, полу-менеджером и полу-технарем, любая методология может фейлиться, как и описано в посте. Скрам, ватерфол — итог один, завал разработчиков «текучкой», раздрай в команде и полное непонимание менеджерами, почему у них все не так, как хочется. И чем больше команда, тем больше будет проблем.
И именно поэтому проблем, сходных с описываемыми в посте, у меня не возникает — я говорю с менеджерами на их языке, с разработчиками — на их. Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит. Он обещает клиенту золотые горы, и уже завтра, он не понимает, что «добавить галочку» одновременно значит «перелопатить логику в десятке мест и все протестировать», он хочет, чтобы конкретно его клиенту сделали ту фичу, которую этот клиент хочет прямо сейчас, бросив все другие дела.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру» — расставить приоритеты, превратить поток сознания менеджера-продажника в нормальные задачи, решить, кто эти задачи сделает эффективнее и распределить их, оценить сроки (когда самому, а когда и посоветовавшись), проконтролировать исполнение, а также заблокировать неумеренный и неуместный энтузиазм вида «да это буквально 5 минут, давайте сделаем прям щас». Ага, щас, разбежались.
Вообще стараюсь не допускать прямого контакта технарей и менеджеров, если честно. Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды. И это облегчает жизнь всем этим частям.
Думаю, без такого контроля, когда все, что подается на вход в разработку извне, разбирается человеком, понимающим техническую часть, полу-менеджером и полу-технарем, любая методология может фейлиться, как и описано в посте. Скрам, ватерфол — итог один, завал разработчиков «текучкой», раздрай в команде и полное непонимание менеджерами, почему у них все не так, как хочется. И чем больше команда, тем больше будет проблем.
Менеджер, который только общается с клиентами и не понимает разработчиков, не должен принимать участие в их деятельности, ничего хорошего из этого не выходит.
Существуют огромные корпорации, где на многих уровнях люди не понимают, чем занимаются люди на других уровнях.
Это нормально. Современный уровень познаний настолько велик, что невозможно знать все даже в среднем предприятии.
Совершенно нормально, консультироваться с узким специалистом по конкретному вопросу.
Как-то мне один руководитель (успешный) сказал, что его работа целиком состоит из общения с сотрудниками — они ему рассказывают что да как устроено на его предприятии по конкретному поводу.
В ИТ менеджером (и успешным) может работать кто угодно.
Напротив даже, те менеджеры, кто раньше давно был программистом, а потом отошел далеко от этого — не должны сами делать оценки.
Если менеджер-непрограммист это понимает, как правило, но менеджер-программист такие вещи понимает плохо.
Иногда это не страшно, когда решается условно-типовая задача, но чаще всего приходится выступать связующим звеном между независимыми частями команды
Ага. Низзя, низзя
У программистов другие приоритеты — программист может на вторичную малонужную фичу, от которой можно было бы отказаться, убить дохрена времени. Запросто.
Далеко не всякий программист умеет понять, когда нужно акцентировать менеджеру — эта фича будет слишком дорогой, она точно нам нужна прямо сейчас?
Далеко не всякий программист способен сказать менеджеру, «если галка будет не голубой, а такой же как основной цвет галок темы, я смогу закончить эту задачу за 2 часа, а если ты хочешь непременно голубую, то — за 2 дня».
Многие просто выполняют задачу, не пытаясь оптимизировать её постановку/формулировку. Ну это не факт что и нужно делать рядовому разработчику. Однако при прямом общении рядового разработчика с продаваном без smart-фильтра между ними — запросто возможны вышеописанные передергивания.
Как раз моя задача — и в данном случае я выступаю альтернативой «скрам-мастеру»
То, что вы описали задачи скорее продакт овнера и команды разработчиков, а не скрам мастера :)
Моими глазами в описаном кейсе нарушено сразу несколько важных моментов AGILE и SCRUM в частности, то есть, согласно евангелистам получившееся SCRUMом называть негоже.
Самое главное — любая AGILE методология предполагает участие команды в формировании самой методологии, то есть если команду что-то не устраивает команда меняет правила, подстраивая процесс под себя. Собственно главной постулируемой целью появления AGILE методологий была разгрузка команд, вывод их на ровный режим работы без пиковых перегрузок и внезапного заваливания «срочными» никому не нужными задачами.
Ну и в SCRUM трудоёмкость измеряется в сторипоинтах, причем на реальное рабочее время это должно проецироваться только для всей команды в целом, причем производительность команды оценивается по результатам нескольких предыдущих спринтов.
К сожалению часто когда инициатором внедрения AGILE, особенно SCRUM является большое начальство, по сути, внедрение agile рассматривается как внедрение жесткой контролирующей процедуры для маскировки собственной некомпетентности, нежелания вникать в детали и неуверенности в себе.
В итоге в приведённой выше истории получился непонятный уродец, удобный для рисования табличек, но совершенно не ориентированный на удобство разработчиков и, более того, не обладающий возможностью ретроспективной модификации процессов. Развал команды — естественное следствие. Называть это Agile примерно как написать «Боинг» на газовом баллоне с примотанным скотчем крыльями и после рассказывать всем о том, какие плохие они самолеты клепают.
Самое главное — любая AGILE методология предполагает участие команды в формировании самой методологии, то есть если команду что-то не устраивает команда меняет правила, подстраивая процесс под себя. Собственно главной постулируемой целью появления AGILE методологий была разгрузка команд, вывод их на ровный режим работы без пиковых перегрузок и внезапного заваливания «срочными» никому не нужными задачами.
Ну и в SCRUM трудоёмкость измеряется в сторипоинтах, причем на реальное рабочее время это должно проецироваться только для всей команды в целом, причем производительность команды оценивается по результатам нескольких предыдущих спринтов.
К сожалению часто когда инициатором внедрения AGILE, особенно SCRUM является большое начальство, по сути, внедрение agile рассматривается как внедрение жесткой контролирующей процедуры для маскировки собственной некомпетентности, нежелания вникать в детали и неуверенности в себе.
В итоге в приведённой выше истории получился непонятный уродец, удобный для рисования табличек, но совершенно не ориентированный на удобство разработчиков и, более того, не обладающий возможностью ретроспективной модификации процессов. Развал команды — естественное следствие. Называть это Agile примерно как написать «Боинг» на газовом баллоне с примотанным скотчем крыльями и после рассказывать всем о том, какие плохие они самолеты клепают.
Я конечно не про 80лвл с грандиозными проэктами за плечами, но как то работал в одном заграничном стартапе.
Начинали всё с нуля, и по старинке описывали все процессыв тетрадке, на доске.
Не было у нас никаких Agile и утренних Scrum-ов, и делали всё что нужно, «до самого утра» для стабильного выпуска версии, сообща работая с Senior Developer.
Проэкт рос, наняли «Ого-го» специалиста, потом и PM пришол и ввёл Agile.
Руководство требовало добавить «красивых» фич в фронтэнд, «ого-го» специалист захотел перейти с Zend на Wordpress, а PM просто делал свою работу от «а» до «б». Мы по прежнему старались делатьхорошо до самого утра свою работу а PM требовал присутствия на утренних Scrum-ах и дрюкал за дедлайны…
И вроде бы тоже как то там Agile «приплетён»… о чём это я?..
Ах да, " губит людей не пиво — губят людей дебилы, не правильная оценка ситауций и неграмотное управление"
Всем удачи и по меньше «баговых» сотрудников
Начинали всё с нуля, и по старинке описывали все процессы
Не было у нас никаких Agile и утренних Scrum-ов, и делали всё что нужно, «до самого утра» для стабильного выпуска версии, сообща работая с Senior Developer.
Проэкт рос, наняли «Ого-го» специалиста, потом и PM пришол и ввёл Agile.
Руководство требовало добавить «красивых» фич в фронтэнд, «ого-го» специалист захотел перейти с Zend на Wordpress, а PM просто делал свою работу от «а» до «б». Мы по прежнему старались делать
И вроде бы тоже как то там Agile «приплетён»… о чём это я?..
Ах да, " губит людей не пиво — губят людей дебилы, не правильная оценка ситауций и неграмотное управление"
Всем удачи и по меньше «баговых» сотрудников
Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую?
В шею таких менеджеров, думаю проблема была в них. Видимо, они были со стороны и не пропитались культурой компании в полной мере.
напомнило:
— Василий, как Вам Паваротти?
— да фуфло вообще, как такое вообще слушают ??
— странно, а что из него Вы слушали, где?
— да мне как-то друган Серега по телефону напел что-то из этого Паваротти, ему тоже почему-то понравилось, но мне вообще не пошло.
— Василий, как Вам Паваротти?
— да фуфло вообще, как такое вообще слушают ??
— странно, а что из него Вы слушали, где?
— да мне как-то друган Серега по телефону напел что-то из этого Паваротти, ему тоже почему-то понравилось, но мне вообще не пошло.
Сколько бы не было придумано новых религий и методологий с самыми лучшими пожеланиями.
Придут новые священники или манагеры чтобы использовать модный в этом сезоне срам-скрам для самоудовлетворения.
Придут новые священники или манагеры чтобы использовать модный в этом сезоне срам-скрам для самоудовлетворения.
Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, всё равно найдется человек, который поймет вас неправильно.
Если вы уверены, что ваш поступок встретит всеобщее одобрение, кому-то он обязательно не понравится. — Третий закон Чизхолма
Придут новые священники или манагеры чтобы использовать модный в этом сезоне срам-скрам для самоудовлетворения.
Неужто не для зарабатывания денег?
Прочитал пост, и при чем тут методология SCRUM не понял…
На мой взгляд описанная проблема лежит совсем в другой плоскости:
На старте компании и в фазе ее стабильности — нужны совсем разные люди.
Просто руководство в какой-то момент почувствовало, что гениальные талантливые разработчики ядра «пинают балду». Соответственно усилило свой контроль чтобы попробовать извлекать из них максимальную прибыль. Но гениальные талантливые разработчики на то и гениальные, что им вся эта рутина и «муть голубая» по улучшениям и мелкой штриховке — не интересна. Им хочется ТВОРИТЬ НОВОЕ, а не модернизировать и бесконечно улучшать старое. На крайний случай они будут «пинать балду», если ЗП достаточна высока чтобы усыпить совесть.
Гайки им закрутили и они ушли. Но от этого же все только выигрыше!
Компания — сократила свои издержки. Ведь, поддерживать, модернизировать и обновлять ядро смогут и программисты уровнем попроще. Доделывать это не изобретать.
Программисты же перестали просиживать штаны на тёплом месте и наконец пошли расти и реализовывать свой талант в новых компаниях, писать новое ядро.
Всем хорошо!
Как можно было их удержать?
Либо не давить и не задрачивать, а позволить пинать балду. Переплата за страхи руководства. Но, кому от этого хорошо?..
Либо обеспечить новыми амбициозными проектами и новыми дерзкими вызовами внутри компании! Занять людей в соответствии с их высокой квалификацией!
На мой взгляд описанная проблема лежит совсем в другой плоскости:
На старте компании и в фазе ее стабильности — нужны совсем разные люди.
Просто руководство в какой-то момент почувствовало, что гениальные талантливые разработчики ядра «пинают балду». Соответственно усилило свой контроль чтобы попробовать извлекать из них максимальную прибыль. Но гениальные талантливые разработчики на то и гениальные, что им вся эта рутина и «муть голубая» по улучшениям и мелкой штриховке — не интересна. Им хочется ТВОРИТЬ НОВОЕ, а не модернизировать и бесконечно улучшать старое. На крайний случай они будут «пинать балду», если ЗП достаточна высока чтобы усыпить совесть.
Гайки им закрутили и они ушли. Но от этого же все только выигрыше!
Компания — сократила свои издержки. Ведь, поддерживать, модернизировать и обновлять ядро смогут и программисты уровнем попроще. Доделывать это не изобретать.
Программисты же перестали просиживать штаны на тёплом месте и наконец пошли расти и реализовывать свой талант в новых компаниях, писать новое ядро.
Всем хорошо!
Как можно было их удержать?
Либо не давить и не задрачивать, а позволить пинать балду. Переплата за страхи руководства. Но, кому от этого хорошо?..
Либо обеспечить новыми амбициозными проектами и новыми дерзкими вызовами внутри компании! Занять людей в соответствии с их высокой квалификацией!
Обратная сторона Agile