Друзья, добрый день! Продолжаем серию «неразрезанных» публикаций о проектах, связанных с разработкой, часто с приставкой «веб».
Сегодня мы поговорим о том, как наиболее правильно и быстро оценивать работу и планировать релизы программного комплекса.
Скорее всего, начинающие менеджеры и энергичные и корыстные разработчики будут шокированы рекомендациями, но поверьте, цель одна-единственная: помочь и сделать из вас настоящего джедая, который приносит пользу компании, продвигает проекты вперед, и одновременно развивает людей.
Такой джедай, который искренне не заслуживает того, чтобы его обнаружили мумией в темной серверной комнате между стойками веб-серверов и базами данных веб-проекта, летящего в будущее без мысленно документированного кода, ТЗ — только на энергии чистой» ХЗ».
Итак, начнем!
Производительность и близкие аналоги
Важно, чрезвычайно важно, особенно для ключевой проектной силы — разработчиков, прекрасных специалистов, ежедневно развивающих свои навыки в современных IDE, — понять, что отсутствие здравого смысла в оценке работы начинается еще до появления желания «задумать идею».Особенно часто такое случается в веб-разработке, где во время тендера нужно сделать вид, что политизированная проблема курицы и яйца имеет «строгое решение»:
- Клиент еще не знает, чего хочет, либо знает очень смутно и противоречиво (т. е.
не знает, но очень этого хочет и, главное, вовремя!)
- Клиент хочет, чтобы инженеры посчитали стоимость «пока не знаю чего» и обижается, если они не совсем укладываются в эту смету
- Клиент хочет, чтобы инженеры уложились в сроки и запустили «Пока не знаю что», скажем, 1 сентября и чтобы, конечно, «Пока не знаю что» не было ошибок
- Клиент часто делегирует выяснение деталей «пока не знаю чего» сотрудникам ниже по иерархии, которые, как ни удивительно, начинают играть в «прятки», отшучиваться, шаркать ногами, хлопать дверью.
и тянут ноги!
- красивое ухаживание самца с самкой перед. домашними разборками на кухне
- покупка картофеля на рынке
- гадание на кофейной гуще, астрология, нумерология
- жертвоприношения Ктулху и т. д.
Понятно, что легче пока не стало, особенно если вспомнить, что в выступлениях часто участвуют «дипломированные психологи» с обеих сторон, умеющие выглядеть убедительно, решительно, говоря «да, конечно, мы сделаем это!» » и непонимание основных принципов разработки программного обеспечения.
А если вспомнить, что иногда «уверенно выглядящие» на обоих концах проекта переходят линию фронта, братаются, объединяются и начинают от искреннего негодования требовать от инженеров чего-то конкретного, не давая внятных формализованных ответов на ясно поставленные вопросы.
- хочется просто поехать на академические каникулы в Антарктиду и забыться, обнимая пингвинов и холодноводных, но не менее красивых русалок :-)
Толчок любви
Инженерам достаточно больно трезво и аналитически строго воспринимать вышеописанное исполнение, до крови из глаз, поэтому они предпринимают несколько известных психологических шагов, приближающих конкретику и реальную работу:- Нам нужно улыбаться друг другу
- Вам нужно сказать «да», даже если вы НЕ уверены
- Нам нужно пообещать прийти друг другу на помощь.
- Вам нужно постучать по груди (как у КинКонга) и проявить уверенность!
- Тебе нужно поклясться в любви до смерти
- что нам еще предстоит разобраться в деталях и всплывет много интересного и неожиданного, но раз мы уже улыбнулись друг другу, то сможем решить это вместе
- если есть дедлайн, то нужно как можно быстрее распутать эмоциональный беспорядок, разобраться и начать делать самые важные дела в порядке убывания, а всегда что-то будет отменено и это правильно
- чем больше эмоционально-политического беспорядка в начале, тем больше времени нужно уделять фазе анализа и проектирования
«Мёртворожденные» проекты
К сожалению, иногда возникает буквально сразу понимание, что запускаемый проект. никому не нужен, он дернется, зависнет и будет закинут в архив:- У проекта нет четкой, харизматической цели.
Просто нужно что-то делать, потому что непонятно, что делать важнее.
Поэтому нужно ХОТЯ ЧТО-ТО делать, зарплату начисляют - должна быть причина :-)
- Делаются попытки найти не «драйверов» команды проекта, энергичных людей, которые вдохновляют себя и других и верят в достижимость цели, а ищут ответственных (на которых можно все свалить в случае возникновения проблем).
).
Почувствуйте разницу.
Ээффективные виды выступлений
Отрадно, но часто мы сталкиваемся с правильными стартами проектов, которые можно определить по следующим характеристикам.Придерживайтесь этого списка и постарайтесь всеми правдами и неправдами попасть в такие команды:
- Есть один или несколько человек, которые горят идеями и искренне верят в достижение цели.
Харизма и теплота, исходящие от них, позволят команде проекта проявлять гибкость и сглаживать возникающие недопонимания и плохие оценки.
- Со стороны клиента присутствует адекватное осознание неопределенности собственных желаний, рисков и желание пойти инженерам навстречу.
Есть осознание того, что придется много раз напрягать голову и думать, даже если ты как клиент уже за все заплатил.
- На стороне клиента либо есть, либо.
ЕСТЬ понимание необходимости привлечения критической массы «серого вещества» в виде адекватного аналитика(ов) и профильных экспертов, способных объяснить инженерам тонкости бизнес-логики предстоящего проекта без «э-э-э… ух…» проекта.
- Со стороны клиента присутствует желание достичь бизнес-целей максимально быстрым и коротким путем.
Я помню проект, где клиент хотел и потратил много времени на «красивую, продуманную админку веб-проекта» для сотрудников и серьезно упустил основные бизнес-задачи.
Они вытрясут из вас все знания паттернов проектирования, научат сразу писать простой код без ошибок, а желание сделать фабрику классов вместо 20-строчного PHP-скриптера вы отвергнете как демоническое искушение.
Утром, налив кофе, вы с удивлением обнаружите, что клиент после (после!) вашего отдела тестирования обнаружил и зарегистрировал в баг-трекере еще 30-40 ошибок и рекомендует вам (вам!) написать юнит-тесты.
еще внимательнее и менять мозги тестировщикам.
Но прокачивает хорошо :-)
Итак, как вы оцениваете программный проект?
Я буду говорить прямо.Разумные люди, в т.ч.
инженеры понимают, что, мягко говоря, невозможно оценить то, что еще не изобретено.
Можно только с уверенностью врать.
Но, как известно, формальная математическая логика работает не для всех, поэтому иногда все же встретишь собеседников, утверждающих, что 1+1=11, причем настолько убедительно, что даже слезы на глазах могут появиться.
Но выход есть: аналогия.
Недаром в современном Agile-подходе аналогия используется как фундаментальный элемент оценки.
Рабочие примеры аналогий в веб-разработке:
- Вам необходимо создать стандартный интернет-магазин.
Мы уже сделали парочку из них.
Оценку с поправкой на адекватность клиента/опыта команды объявляем в виде числа Фибоначчи.
- Мы оцениваем функцию в сюжетные точки , а не в человеко-часах.
И берем 1 магазин-поинт за сложность создания, например, информационный блок со списком новостей .
- Иногда можно примерно определить тип веб-проект по количеству стандартных модулей в нем и доле кастомизации.
Если были подобные типы проектов со схожим или похожим набором модулей и кастомизацией, то можно смело использовать аналогию.
- Иногда дают примерную оценку, измеряя толщину ТЗ в миллиметрах.
Я совершенно серьезно — я это видел и, на удивление, это работает.
- Эти тупицы неделю исправляли форму поиска, их четверо, а потом 2 недели исправляли ошибки.
Умножьте результат на 10.
- Этот разработчик может интегрировать сайт с версткой за неделю.
За хорошее поведение добавим еще 3 дня сверху.
Да, вы можете возразить, но как насчет ПМБОК, диаграммы Ганта, Скорость , карточки в Канбане, толстые книжки по «Agile Estimation», командному ускорению, метрикам, петрикам? Скажу честно — это не работает и проведу аналогию с «машинным обучением».
Машинное обучение и оценка
Вас будут преподавать 50 видов математики в университете 5 лет, потом еще полгода на дорогих курсах по DataScience и MachineLearning, а потом на практике вы вдруг узнаете, что.научного подхода в этой области нет, нужно перебрать все варианты гиперпараметров, вам только времени на это никто не даст (дни и месяцы) а остается божественный случайный поиск и самое главное ИНТУИЦИЯ.
И ничего не остается, как.
вернуться и начать читать теорию на курсах.
Так и с оценкой работы в программных проектах – теории много, но только крупицы знаний, смешанные с глубокой интуицией и, что то же самое, опытом работы на практике.
Чтобы по-настоящему научиться ценить трудоемкость программирования, нужно уехать из городов, жить с туземцами, есть сырое мясо, пить теплую пульсирующую кровь - оставаться ближе к природе = код, баги, заблудшее производство, бородатые админы, поспать парочку ночей в серверной и.
научись обходиться подорожником вместо туалетной бумаги.
Минимализм и желание делать всё просто и понятно позволят команде гораздо чаще попадать в рейтинги, а клиенту быстрее взлетать.
На самом деле нам необходимо как можно быстрее культивировать и внедрять в проект эту культуру сбережения.
Известные нарушения
Забавно, но иногда встречаются такие злоупотребления оценками, которые вызывают только улыбку у опытных инженеров:- Написано огромное техническое задание на 1000 страниц, которое уже на следующий день начинает устаревать и «пахнуть».
Никто не дочитал ее до конца, но на нее часто ссылаются.
Он противоречивый, водянистый, политический и неэротический.
Но это оценили, порезали на итерации, их тоже оценили, и теперь все пытаются вписаться в этот логический ад
- Создается огромная диаграмма Ганта.
Поскольку требования постоянно обсуждаются и меняются, для перемещения столбцов в диаграмме Ганта выделен отдел — они целыми днями сидят и движутся.
- Функции оцениваются и сохраняются в почтовом ящике.
Никто кроме менеджера не видел всех характеристик и оценок.
Менеджер внезапно совершает самоубийство, и проект. закрывается.
- Доски и маркеры есть, но фломастеры либо давно высохшие, либо перманентные, и написав на доске что-то нецензурное при показном общении и оценке, оказывается, что стереть это уже невозможно :-)
Полезные и рабочие практики оценки в проектах по разработке программного обеспечения
Если вы дочитали пост до этого момента, то, очевидно, вы уже не относитесь к категории «чем больше бумаги, тем она чище», «вы задаете неправильный вопрос», «вы не поставили задачу математически» », но вы действительно хотите выполнить программный проект в адекватные сроки и по разумной цене.Давайте запишем следующие практики, которые действительно работают:
- «Простой, средний, сложный».
Да, мы консультируемся с опытным разработчиком или командой и даем каждой функции в ProductBacklog оценку из 3 возможных.
Желательно пройтись по всем известным особенностям проекта и поставить хотя бы эту оценку.
Можно и нужно, только имея это в виду, уже планировать релизы.
- «Планирующий покер».
Информации на эту тему очень много, но если во время оценки вы обеспечите здоровую и позитивную атмосферу общения и доверия между вами, членами команды и клиентом, это работает хорошо.
- "Позвонить другу.
" Если вы знаете опытного разработчика в компании/команде или на стороне, поговорите с ним.
К сожалению, иногда команды вступают в сговор и пытаются растянуть время — адекватную оценку реализации может дать эксперт.
- Функционал и коммуникации максимально визуализированы.
Выделяются отдельные пробковые доски, на них висят бумажки с особенностями, люди подходят, обсуждают, рисуют на других досках, на которых, обратите внимание, не высохли фломастеры и работающая стиральная машина.
Вот отличный ресурс об этой теме.
Инструменты и эффективные практики часто важнее планов и сроков.
Надеюсь, стало ясно и очевидно, что даже если требования к программному проекту очень четкие и формализованные (это случается, хотя и редко), из-за неопытности инженера или аналитика может возникнуть столько неожиданных сюрпризов, что.
хорошо работает только интуиция и метод аналогий.
Давайте рассмотрим примеры неожиданностей – врага нужно знать в лицо:
- Даже если законы, создаваемые законодательными органами всего мира, часто могут содержать воду и логические противоречия, вызывающие физическую боль в мозгу, что уж говорить о ТЗ.
Естественно, при обнаружении противоречия срочно требуются изменения в коде.
Изменение происходит быстро, но после этого система ломается так, что на восстановление уходит N дней, а предсказать N с научной точки зрения невозможно!
- Обнаружен конфликт программных библиотек и нужно либо отключить одну из них, либо гладиолус.
Предсказать время простоя невозможно.
- При даже небольшой нагрузке выявляется неадекватность выбранных алгоритмов (заниженная оценка алгоритмическая стоимость сценарии использования), что приводит к замедлению работы системы.
Проблему можно найти и устранить за несколько часов или месяцев.
Это невозможно предсказать.
Опыт, только опыт, или пакетные решения .
- Ведущий разработчик переутомился перед релизом и под воздействием нахлынувших эмоций начал мочиться в серверной на стойку с веб-балансировщиками.
Утюг закоротил.
Внезапный простой - 2 дня.
Я просто скажу то же самое: если вы отжимаетесь, бегаете, делаете жимы с эспандером и делаете планку по вечерам, то вероятность дойти вечером до дома значительно выше.
Если планировать защиту от хулиганов с помощью диаграммы Ганта, рассчитав вероятность удара 2 или 3 человек в зависимости от маршрута домой и времени года, то это будет и сложнее, и гораздо дольше, а любые изменения вероятностей потребуют нужно учитывать каждый день :-) Мы друг друга, в общем, поняли.
- Доски, маркеры, вики – для максимально открытого общения друг с другом и с клиентами.
- Округление проекта.
Вместо иерархии, убивающей общение и порождающей потоки искаженной информации и медленно повреждаемые телефонные номера, проект доработан так, что все члены команды и представители клиента доступны на расстоянии локтя.
- ТЗ не где-то, а висит на досках, стенах, и как можно больше людей могут его «прочитать» и обсудить
- Доступные инструменты оценивания по аналогии, архив предыдущих оценок, доступный каждому
- Разработчики пишут автоматизированные модульные, модульные и интеграционные тесты для кода.
Примерно тестов должно быть столько, сколько кода
- Обычно в любом программном проекте есть несколько мест, которые покрыты туманом и в их водоворотах обитают демоны.
Необходимо как можно быстрее поднять прототипы, отражающие эти места, провести нагрузочные и другие испытания и получить по ним оценку.
Эта оценка будет очень полезна на более поздних этапах проекта.
И больше гарантий нам никто не даст – это факт жизни.
Общий
Подведем итоги.Короче говоря, мы увидели с разных сторон, что умные, давно политизированные методы оценки программных проектов в часах кролика-попугая работают только на тестовых данных в идеальных условиях, но не на практике.
Ситуация повторяет подходы и результаты в машинном обучении — можно много и долго учиться, чтобы понять, что работает только интуиция/опыт/аналогия.
Заранее разбирать всё детально на формальные кубики крайне дорого и, как правило, на это нет времени.
В реальных условиях для оценки лучше всего полагаться на метод аналогии, простые расставленные по приоритетности списки признаков, без каких-либо иерархий и взаимозависимостей.
Разработчики должны сделать код самодокументируемым, не полагаться на спецификацию, которая сразу же выйдет из строя, и писать автотесты для кода.
Внедрение и следование ценностям максимально открытых коммуникаций, визуализация требований программного проекта, теплая и вдохновенная атмосфера, простые категориальные оценки сделают гораздо больше для соблюдения сроков релиза, чем бесконечное перекладывание абстрактных палочек в диаграммах Ганта и тому подобное.
В этом и только этом случае есть все шансы увидеть команду проекта с шампанским в руках, с улыбками празднующую завершение релиза, совпавшего с Новым годом.
А про мумию менеджера в серверной - вам это только показалось :-) Всех с праздником и хорошего настроения! Теги: #оценка стоимости рабочей силы #оценка стоимости проекта #веб-разработка #планирование #agile #разработка веб-сайта #управление проектами
-
Как Фильтровать Журналы Git
19 Oct, 24 -
Aws: Проверка Статуса + Cloudwatch
19 Oct, 24 -
Новости - It-Новости В Стихах И Плакатах
19 Oct, 24 -
Google Play Отмечает Свой День Рождения
19 Oct, 24
