Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
гражданин в Wargaming
  • Почему ДОУ уже не тот...

    Технические сайты никому не нужны. Еще раз повторю, технические сайты никому не нужны.

    Ерунда. Правильные технические сайты нужны. 12 тыс. уникальных хостов в сутки тому подтверждением.

    Підтримав: anonymous
  • To Be Agile Or Not To Be Agile?

    Однако! Главная фишка рупа, которая так и не далась многим, — «кастомизация».

    При «кастомизации» из рупа можно получить и XP, и Scrum, и какой еще захочешь Agile :-) :-) :-) :-)

    Підтримав: Zakhar Khrystych
  • To Be Agile Or Not To Be Agile?

    Да, я сталкивался с такой проблемой. Причем, как раз в области обсуждаемых типов проектов, а не стартапах.

    Достаточно подробно один из таких случаев описывал в этой теме, сразу под Вашим постом от 1 марта ;-). Фундаментальные ошибки в проектировании (причем, как видно из описания, обнаруженные и озвученные вовремя) привели в итоге к краху очень крупного проекта. И, кстати говоря, там я не упомянул: до начала проекта я проводил занятие по ознакомлению команды разработки с существующими продуктами конкурентов и указывал на особенности принятой архитектуры, обратил особое внимание на один из продуктов — «так делать не надо» и объяснил почему. Спроектировали именно так, как я сказал не надо, только на другой «элементной базе».

    Я думаю, что если человек хочет ошибиться, он это сделает независимо от типа проекта. Если руководство компании хочет ошибаться, даже не смотря на раннее выявление ошибки снизу, оно будет ошибаться.

    Цена ошибки проектирования высока (выше только цена ошибок анализа) в любом типе проектов. Другое дело, что в «BDUF» такая ошибка лучше документирована, ее можно раньше выявить и понятнее, что с ней делать (когда, наконец, до принимающих решение дошло, что ошибка есть) :-)

    Підтримав: Zakhar Khrystych
  • To Be Agile Or Not To Be Agile?

    Да, но конкретно в этой ветке мы говорим про «fixed cost fixed scope».

    Ваше замечание хорошо подходит для случаев разработки нового коробочного продукта или онлайнового сервиса, где потенциальных покупателей и юзеров много разных. Условно говоря, когда один стартап вступает в гонку с другим стартапом на том же поле.

    Здесь же отношения «конкретный заказчик — конкретный исполнитель». Да, конкуренты могут влезть, но это реально клоуны, если они «побыренькому», пока я пишу ТЗ, сумели склепать продукт, нужный одному заказчику.

    А если заказчик не повелся на их продукт? Максимум, что я теряю — месяц работы одного аналитика на ТЗ, максимум, что теряет такой конкурент — месяц и больше работы команды.

    Согласитесь, такой конкурент рискует на порядок большей суммой затрат при значительно большей вероятности реализации риска :-)

    Підтримав: Zakhar Khrystych
  • To Be Agile Or Not To Be Agile?

    Если Вы не против, поделюсь своим еще военным опытом. Тогда эту практику я воспринимал как дуристику, но уже потом понял ее глубинный положительный смысл.

    До начала нового рабочего года формировались планы отделов, в которые включались сроки и трудоемкость новых и текущих (которые не завершаются в текущем году) проектов. Планы начинали формироваться с августа месяца и окончательно утверждались в середине декабря.

    Откуда брались трудоемкость и сроки для новых проектов? На эти проекты до их начала разрабатывались технические задания. Проект не мог быть включен в план части и отдела без ТЗ на него. Причем, разработка ТЗ считалась частью проекта и по трудоемкости включалась в него. Т.е. получалось, что ТЗ вписано в план на январь-февраль, а реально готово до начала проекта — к концу предыдущего года.

    Собственно такой подход к планированию я и считал тогда дуристикой — фактически проектом мы начинаем заниматься до его начала, что не согласовывалось с формальной стороной.

    Только потом я понял такую простую вещь: когда ТЗ готово, проект можно спланировать достаточно точно даже на год вперед (и без двухнедельных спринтов). А поскольку в следующем году мы все равно будем делать ТЗ на другие проекты, то время, которое мы запланировали на уже готовое ТЗ, будет израсходовано уже на них. Т.е. в январе-феврале мы фактически не ТЗ пишем, а делаем следующую за ним по плану работу, с тем прицелом, что в этом году писать другие ТЗ, на которые формально времени нет, а фактически есть :)

    Ну и отчитаться же за потраченное на ТЗ время надо все-равно, а включать его в план до начала проекта мы не можем.

    Такая, на первый взгляд, дуристика позволяла резко сужать конус планирования :)

    Підтримав: Zakhar Khrystych
  • To Be Agile Or Not To Be Agile?

    Мной выведен очень простой, но эффективный закон: чем меньше времени на разработку, тем большую его часть надо выделить на «подумать».

    Чтобы не писать заново, позволю себе ещё раз обратиться к собственным заметкам:

    Аналитик, сразу наваявший по заданию руководства ТЗ на 60 страниц, формально задачу выполнил вовремя. Но фактически он впустую потерял неделю, так как не разобрался в предметной области. Более того, руководство со своими сжатыми сроками получило совершенно непригодный к использованию документ, пойдет с ним к заказчику и начнётся многомесячный геморрой по внесению правок, взаимным упрёкам в некомпетентности и глупости, обидам и т. п. В результате реальные потери времени составят человеко-месяцы!

    Что делать в такой ситуации? Работать правильно! Любая работа должна начинаться с мыслительного процесса головой и погружения в предметную область. На это в любом случае необходимо время независимо от искусственно установленных сроков. Если сроки слишком жёсткие, то лучше сразу сделать правильное ТЗ и не уложиться в сроки на одну-две-три недели. Но это будет осмысленный документ и «лишнее» время, затраченное на его обдумывание, в дальнейшем сэкономит месяцы!

    Підтримав: Denys Kostin
  • To Be Agile Or Not To Be Agile?

    А, Вы в смысле «редактор ВП». Уже очень давно нет :)

    Мне тоже фиолетово когда придуман термин, я имел ввиду, что как давно придуманный он уже имеет вариант перевода «покер планирования».

    Про «иллюзию контроля» вижу тренерскую хватку внедренца Скрама. Здесь Вы не правы. В начале своей карьеры я пять лет служил в конструкторско-технологическом центре, в котором выполнялись сложные проектные, конструкторские, технологические и программные проекты с десятками исполнителей, отделами соисполнителями и смежниками. Никакой иллюзии и контроль не был целью, целью был результат и управление процессом для его достижения. Можете не верить, но уверяю Вас, нигде и никогда я больше не видел более точного планирования.

    По нормочасам. Это полный аналог «сторипоинтов». Полный в том смысле, что оба являются абстрактной единицей измерения трудоемкости, что я и показал примером в предыдущем посте. Да, они дают возможность контроля вплоть до каждого исполнителя, но только если это тебе нужно. Не нужно, и ладно, всё равно оценка дается точно так же, позадачно, проект оценивается суммой нормочасов всех задач, а текущее состояние проекта — суммой нормочасов закрытых задач. Фактически те же самые сторипоинты.

    Нормочасы ничего не усложняют, это Ваш привычный скрамный маркетинг :) Усложняют люди.

    Даже при учете с учетом исполнителей большая трудоемкость для руководителя — миф (да, низкосортному манагеру сложно и трудоемко). Смотрите. В скраме задачи оцениваются сторипоинтами, та же самая оценка в нормочасах ничем организационно не отличается, просто другие единицы измерения. Далее. Задача закрыта — закрыты строипоинты/нормочасы, тоже разницы никакой.

    На этом можно остановиться и у нас полная аналогия.

    Дополнительно. Нужен персональный учет? Неужели это составляет великую организационную проблему знать КТО закрыл задачу? По-моему это необходимо знать. Неужели это составляет такую большую проблему знать когда человек взял на себя задачу и когда ее закрыл (а отсюда видны фактические часы)? И неужели регистрацию этих событий так сложно автоматизировать, что для манагеров новой формации это такое великое усложнение и увеличение затрат их драгоценного времени? На самом деле управленческие затраты на ведение этой информации близки к нулю. Анализ ее занимает не более часа раз в месяц-квартал.

    Скрам — великое гониво и обман. Это я Вам говорю, как ярый противник производства тех артефактов, которые не ведут к выпуску готового продукта (что Вы, кстати, так же декларируете).

  • To Be Agile Or Not To Be Agile?

    Чтобы удачно пошутить по теме, надо на достаточном уровне ей владеть ;-)

    Пятилетка — перспективное планирование.

    Спринт, как и итерация, относится к оперативному/текущему (недельному, месячному) планированию.

  • To Be Agile Or Not To Be Agile?

    Насчет автора Википедии Вы, конечно, загнули :-)

    Вы немного смешали мои претензии. У меня есть претензии по терминологии к Скраму в целом — в нем многие термины подменяют существующие, как пример тот же спринт, который на самом деле итерация. Здесь к переводу претензий быть не может, вы сделали все правильно — в Скраме спринт, значит спринт.

    Претензия к переводу связана с введением. Независимо от последующего содержания введение должно содержать информацию полностью понятную неподготовленному читателю. Здесь неподготовленный не третьеклассник, а человек, на момент начала прочтения незнакомый с предметом. Т.е. это может быть подготовленный отраслевой специалист, который с этой ее частью (в данном случае — Скрамом) еще не сталкивался. Если во введении используются специфические термины их следует тут же объяснять. Нет возможности объяснить во введении — переписать и не использовать, по тексту книги оно и так есть.

    Когда это действительно необходимо, не вижу проблем использования терминов на исходном языке, но оставлять тот же «Code review» из-за его якобы лаконичности по-моему уже перебор. Наиболее известные/подходящие варианты: «ревизия кода», «рецензия кода», «пересмотр кода».

    Planning Poker — придуман еще до Скрама. Уже существует русскоязычный термин «покер планирования». По сути то же самое, что «игра в планирование». По-моему подходят оба варианта.

    Sprint Backlog — здесь ну прямо напрашивается «план итерации» (мы же знаем, что план может иметь совершенно разные внешние представления). Если более буквально: «план спринта», «журнал спринта».

    Scrum — оставим эту хрень без перевода :)

    Story Point — а здесь есть большая идеологическая сложность.

    Дело в том, что «Story Point», как условная единица измерения объема и скорости работ, призваны решить проблему часов, которые для одной и той же задачи у разных разработчиков разные. Вводится как инновация, тренеры тренируют, манагеры писяют кипятком, переходят на планирование в «сторипоинтах». Это не плохо, плохо другое: все это давно изобретено десятки лет назад и прекрасно работало. Этого сейчас никто не знает и «сторипоинты» становятся почему-то неким открытием, серебрянной пулей...

    В правильном, еще советском планировании проектов, в отличие от Проджектов и пр., в которых есть «план» и «факт», время учитывалось тремя показателями: план, факт и табель.

    Так вот, при трех показателях план и факт учитывались не в часах, а в условных «нормочасах», что фактически и есть полный аналог «сторипоинтов». В «табель» вписывались реальные рабочие часы, затраченные на работу.

    Простейший пример: если на стандартную модальну форму с тремя полями ввода по нормам положено 16 нормочасов, значит в план вписывается 16 н/ч. Если эта задача не менялась (форма та же, что первоначально задумано, число полей то же), значит независимо от реально затраченного времени вписываем факт 16 н/ч, а в табель 2 ч, если управились за два рабочих часа или 40 ч, если управились за неделю. Сравнение факта и табеля дает нам понимание производительности отдельных разработчиков и команды в целом.

    Но это так, слишком поверхностно, если будет желание, то по этой теме я могу много и подробно :)

    Кое-что, опять же поверхностно, я отразил здесь: armor.kiev.ua/...дство_проектами

  • To Be Agile Or Not To Be Agile?

    Относительно Вашей жалобы «с какой стати человек, которому не понравился перевод, говнoм мажет 10 человек и называет фигней их работу для сообщества?»

    Перевод меня устраивает. Заметны отличия в стиле разделов и используемых терминов, видно, что не было редактора и рецензента но в целом на приемлемом уровне.

    За работу по переводу искреннее Вам спасибо, прочел с интересом, вполне познавательно и полезно. Претензия не к переводу, а к введению, его же Вы от себя писали. И, не обижайтесь, написали фигню.

    Підтримав: Zakhar Khrystych
  • To Be Agile Or Not To Be Agile?

    Артем, держите себя в руках. Я вполне адекватен, чтобы не быть апологетом никакой из методологий, как Вы мне это сгоряча приписали. Апологеты, вроде Вас, апологета Скрама, ущербны, как тот узкий специалист Козьмы Пруткова, который подобен флюсу :-)

    Апологет по определению не гибок, поэтому лично я строю процесс разработки в зависимости от конкретного проекта — где-то это будет XP, где-то Скрам (может быть), где-то даже RUP; итерационный (как правило), а, может быть, и водопад; как полностью формализованный, так и без каких-либо формальных ограничений. Повторяю, все зависит от конкретного проекта: его сложности, сроков, заказчика, технологий и пр. и пр. И ни в коем случае «только Скрам», «только XP», «му-му», «баржа, а на барже ж»...

    В обиде и праведном гневе Вы сами таки ничего не поняли. Я понял все идеи книги, о чем ранее и указал. Понял, и увидел, что кроме новых терминов, которые подменяют уже существующие, в этих идеях ничего нового нет. Я (и многие другие) их использовал на практике и пять, и десять, и пятнадцать лет назад. Вот только не знал, что это так мудрено кто-то обзовет.

    Не обижайтесь. Попробуйте понять и простить :-) Перевод вполне нормальный, понятный и читабельный. Для полугодовой работы нескольких человек слабоват, но, повторюсь, вполне приемлемый. Претензия к Вам и Вашим со-переводчикам относительно введения. Вы же переводили книгу в том числе для тех людей, которые об этом долбаном Скраме читают впервые.

    Я когда пишу, всегда думаю о той аудитории, для которой предназначен текст. Вы хоть раз задумались?; Уверен, что нет. Адекватный писатель во введении никогда не напишет «Основная ценность книги Хенрика состоит в том, что если вы будете следовать его советам, то у вас будет и product backlog, и оценки для product backlog’а, и burndown-диаграмма.» — это бред для любого читателя кроме апологета скрама, а апологету скрама эта книга уже не нужна.

    Вам действительно так трудно было изложить введение на понятном любому читателю языке? Вы не можете излагать свои мысли по-русски? Не уважаете родной язык? Почему же тогда беретесь за перевод?

    Тогда не обижайтесь и не соскакивайте с темы, что якобы кто-то неадекватен, только потому, что он критикует Ваш бред.

  • «Два года разработки» x «$1,7млн» = иск в суд на бесполезное ПО

    Я говорил о бюрократических законах в свете начатой Вами же темы Паркинсона. Или Вы сами не читали его книги или, может быть, не поняли?

    А цитаты не противоречат друг-другу, т.к. не имеют никакой взаимосвязи.

  • «Два года разработки» x «$1,7млн» = иск в суд на бесполезное ПО

    Я — редкий случай работника, который в силу своей подготовки, опыта и знаний может занимать руководящие должности любого уровня, но не имеет никакого желания заниматься карьерой. По двум причинам: в качестве руководителя реализовал себя давно и достаточно успешно, и это уже не интересно; имею достаточно личных ресурсов, позволяющих в качестве наемного специалиста чувствовать себя абсолютно независимо от сиюминутных прихотей начальства.

    Что это дает? Хоть кто-то в ответ на указание шефа должен иметь возможность вместо того, чтобы «работать работу» (выполнять бесполезную работу), обоснованно сказать «мы не будем это делать» или «мы это сделаем по-другому». Это иногда может быть много полезнее для результата, чем несколько десятков исполнителей, которые тупо роют тут, потому что сказали рыть тут.

    Поэтому бюрократические законы и правила дрес-кода на меня не распространяются.

  • Креш-тест резюме, выпуск № 1: Советы Инны Скочко

    А я кроме резюме составил документ с перечислением собственных преумещств и недостатков. При случае предлагаю его как опциональное дополнение.

    Такое ощущение, что сейчас все уже работают «по процессу» и такое отклонение как правило не догоняют. А ведь из него явно видно, на какие позиции кандидат подходит, а на какие ставить не следует. В результате как буд-то специально предлагаются именно те должности, на которые ставить не следует.

  • Креш-тест резюме, выпуск № 1: Советы Инны Скочко

    Меня, например, охранники в банках не оскорбляют. Но если вдруг... тогда не знаю, я просто к такому повороту не готов :)

  • «Два года разработки» x «$1,7млн» = иск в суд на бесполезное ПО

    еще один человек, который знает, что другой не знает :)

    Представьте себе, читал, что подтверждается моей заметкой о маразматическом планировании.

  • «Два года разработки» x «$1,7млн» = иск в суд на бесполезное ПО

    Я в подобном проекте участвовал на стороне заказчика. Длился он на пару лет дольше, а по деньгам где-то на порядок дороже.

    У заказчика было:
    1) нормально работающее, развивающееся с 99 года ПО;
    2) мой отдел, в котором IT-специалисты совместно с предметными специалистами занимались глубоким изучением, анализом и обобщением предметной области;

    3) возможность выдавать разработчику не только требования, но и рабочие макеты (прототипы) тех или иных подсистем программы (не более 2-3 дней на каждый прототип), разработку которых разработчик объявлял малореальной по времени/затратам.

    Разработчик — одна из ведущих украинских компаний разработчиков ПО. Использовали .NET, интерфейс пользователя — WPF.

    Необходимость разработки нового ПО новой компанией была чисто «политическая».

    О стороне заказчика красноречиво говорит тот факт, что пока у руководителя проекта от разработчика не было политической установки руководства «свалить проблемы на заказчика», после очередного рабочего прототипа он сказал, что с таким уникальным (в хорошем смысле) заказчиком ему ещё не приходилось работать.

    Через пару месяцев после начала проекта, оценив принятую разработчиками архитектуру, я пришел к выводу, что выбран неверный путь — система или вообще не получится, или будет ужасающе неповоротливой и дорогой.

    По этому поводу мной был поднят шум, дошел до высшего руководства у нас и у разработчика. Шум привлек даже интерес владельцев компании-разработчика. Собрали совещание на высшем уровне по обсуждению вопроса. Поскольку система пока только на уровне архитектуры, то с моей стороны только эмпирические оценки, интуиция и опыт — померять и выдать в цифирном виде нечего...

    У разработчика клоунада: директор поднимает поочередно специалиста по СУБД, архитектора, тимлида, руководителя проекта. Каждый торжественно клянется, что архитектура классная, через 2 года всё будет ок. По результатам совещания представитель владельца компании посмотрел на меня как на клоуна, поднявшего истерику на пустом месте...

    Пришлось подчиниться коллегиальному решению и работать в имеющихся политических рамках.

    В итоге в пилотную эксплуатацию внедрять начали систему, которая на момент начала внедрения не имела и 20% функционала старой, а требования к железу на порядок выше (для заказчика с десятками тыс. компов по всей Украине это весьма критично).

    Тут тоже было много интересных событий, но опустим их, как лишние детали. В общем, загнулась система, не пошла.

    Я уходил оттуда, когда еще трепыхались в попытках доделать и довести.

    Директор компании-разработчика на прощанье заявил:
    — Это ты виноват, что у нас не получилось.
    — Ну нихера себе! Когда все еще начиналось, при всеобщем одобрямсе, я единственный здесь, кто бегал, уговаривал, кричал, орал, что делается херня. Меня же тогда выставили клоуном и не послушали. И это я виноват?!

    — Да ты. Надо было громче кричать, чтобы мы услышали...

    Занавес. После этого полгода я просто отдыхал и не имел желания искать новую работу.

  • Увлечение Agile может быть вредно для вашего стартапа

    Все, кто умер, дышали воздухом и пили воду...

  • Некоторые правила улучшения временнóй оценки задачи

    Скажем так, заказчик в некотором смысле был «идеальным». Люди знали и понимали предметную область, понимали что и зачем они хотят от статистики и работали еще по стройной гостированной системе отчетности, налаженной еще в советское время. А еще они понимали к каким последствиям приводит внесение изменений в первичные формы отчетности и итоговые отчеты. Поэтому они изначально смогли достаточно четко построить свою работу, а после автоматизации на любые поползновения «а давайте в форму отчетности добавим...» задавали простой вопрос «зачем?» — вразумительных ответов не было и необходимости изменений в ПО не возникало :)

    По судебной статистике пример прямо обратный. Там была и продолжается по наши дни перманентная задница — изменения чуть ли не каждый квартал. Причем, вплоть до таких. Добавляется в отчет новая колонка. Мой диалог с ответственной за форму отчета:
    — Вы понимаете, что эта колонка та же самая, что через одну слева, но с другим заголовком в шапке?
    — Да.
    — Зачем?! Мы сделаем, это элементарно, но ЗАЧЕМ???
    — Так сказали в Верховном суде!
    — Я не верю, что они именно так сказали.
    — Да, именно так, попросили добавить именно ее [от себя: попросили устно, на уровне «мысли вслух»].
    — Кто именно?
    — Руководитель департамента статистики.
    — А вы пробовали ей объяснить, что такая колонка есть но с другим названием?
    — Как?! Вы что, это же Верховный суд! — многозначительно и перепугано таращит глаза, — Как мы можем им указывать?

    — Не указывать, а подсказывать, помогать... Имя, телефон!

    В общем, звоню. Руководитель департамента — нормальная адекватная женщина, суть проблемы сразу вкурила, задачу отменила, как не имеющую смысла.

    Так что, мой первый проект — уникальный во всех смыслах. Его можно приводить только в качестве примера, что такое возможно в принципе. Ненормальным, но нормой является второй пример, на такое, как правило и следует ориентироваться. К сожалению.

  • Некоторые правила улучшения временнóй оценки задачи

    Ну, они, фактически, и были заказчиками. Я, уже будучи гражданским, лет через пять после увольнения был случайно рядом, зашел в гости. Собственно с непосредственными пользователями и общался. Единственная проблема, которая была у них на тот момент, это архаичный DOS-овский интерфейс программы.

← Сtrl 1... 45678...12 Ctrl →