Комментарии 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 неделю?
Это и есть ошиб
Обратная сторона Agile