С моей точки зрения, при решении бизнес задач, основной критерием изящества является оптимальность решения по сложности и трудоемкости поставленной задаче.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
Очень часто техническим долгом становятся как раз изящные решения, т.к. кроме автора их поддерживать никто не может.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
Как вы будете вести диалог в рамках agile процесса?
Если говорим про scrum, то там есть PBR и планирование спринта.
Объяснять придется владельцу продукта и всей команде, почему на задачу планируется спринт.
«Целеустремленная» предполагает наличие цели. Если сотрудник фокусируется на только понятных ему целях (посте он не смог объяснить, на что было потрачено время), то это идет в разрез с интересами работодателя.
Вы вызвали такси, чтобы доехать до аэропорта.
Где-то в глухом месте таксист вышел и вернулся спустя 2 недели. Сказал, что занимался фундаментальными исследования, но чем они заключались, объяснить не захотел.
И да, оплачивать эти исследования Вам.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
Если это предложение для «художников», то название статьи я бы ожидал увидеть «учитесь обосновывать свои совершенные решения» или «хочешь работать художником — устраивайся на позицию художника».
Я предпочитаю, когда диалог ведется при постановке или оценке задачи, т.е. на стадии планирования/проектирования.
А вот если сначала тратиться 2 недели на работу, а только потом думаем, как это обосновать, то я считаю это чем-то сродни навязанным услугам.
Если работающее решение требует 2 часа, а изящное 2 недели, то выбор должен быть за владельцем бюджета, а не исполнителем.
Все верно, стратегии есть разные.
И обычно об этом договариваются на берегу — при приеме на работу.
Скажем, если Вы пришли в стартап с ограниченным бюджетом, то долгосрочные инвестиции в совершенство кода приведут к банкротству — деньги закончатся раньше, чем продукт выйдет на рынок.
Если же Вас наняли в R&D отдел компании для инноваций, то там и постановка задач другая.
Я расцениваю это так, что 3 работодателя оплатили навязанную и бесполезную для них работу. 4-й выиграл в лотерею, но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
Критерии изящного решения Вы так и не привели. Поэтому не очень понятно, в чем заключался выигрыш.
А есть ли критерии изящества?
И в какой момент нужно остановиться?
«Работа над произведением искусства никогда не может быть закончена, а может быть только заброшена.»
Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу? Дурацкая притянутая за уши аналогия: я пригласил маляра покрасить стену, а он вместо краскопульта или валика расписал ее беличьей кистью №4. В один цвет, в лучшем случае дотянул по качеству до валика. «Художника может обидеть каждый»?
Бывают ситуации, когда компании выгодно иметь такого специалиста, если, простите за пошлость, «монетизация» идет через PR (статьи, конференции, олимпиады), обучение коллег, создание атмосферы «избранности» в команде или поддержание ЧСВ у учредителей. Но это какая-то отдельная история.
Как может быть рентабельной «домашняя» разработка достаточно типовой системы для 40 человек?
Передоложим, что команда в среднем была 4 человека, 3,5 года. Только ФОТ минимум 20 млн. Общие расходы на разработку за это время минимум 30 млн.
Jira service desk (для примера) 1,5 млн лицензия + 0,75 млн в год поддержка на 50 пользователей. Workflow кастомизируется, статусов можно хоть 15 сделать. Если чего-то не хватает — можно дополнительные плагины купить или заказать. Для интеграции есть API.
Окупаемость 25-35 лет, а не 3-5. И это при условии, что на поддержку своей системы не будет расходов в будущем. Но я так понимаю, что команда продолжает проедать 10 млн в год.
С моей точки зрения, из 4-х вариантов: покупка готового, кастомизация готового, заказная разработка и собственная разработка выбрали самый затратный и самый рискованный.
Как человек, имеющий опыт управления проектами в десятки человеко-лет, я не буду использовать классический водопад даже в случае выигранного тендера. Да, не будет обратной связи от заказчика, но итеративная разработка появилась раньше agile манифеста.
В случае продукта В, вы будите тратить время как минимум на регулярное планирование и прочие церемониалы.
Это инвестиции сродни покупке страхового полиса.
Если страховой случай не наступил, то кажется потерей денег.
Но без этих ритуалов очень сложно обеспечить прозрачный статус проекта.
Высокая степень неопределенности для реальных больших и сложных проектов — основная проблема водопада.
Детерминизм бывает только в простых проектах или тиражируемых решениях (типа сайта-визитки).
Ну и отдельный момент — мотивация команды и наработанная методология.
Перекраивать их ради одного проекта? Слишком накладно.
Еще есть тема морального духа и производительности, которая падает драматически в случае потери мотивации.
Просчёты архитектуры не связаны с методологией.
Просчеты не связаны, но некоторые методологии позволяют их выявить быстрее и устранить дешевле.
Проверка нефункциональных требований в водопаде начинается на стадии интеграционных или системных тестов. И если мы им не удовлетворяем — это не технический долг, это переделка (в лучшем случае).
Для меня Agile не является религией, т.к. я понимаю, какая «магия» скрывается за его эмпирическими методами и ритуалами.
Поэтому разоблачительную часть памфлета я не считаю убедительной, уж извините.
С некоторыми утверждениями я вполне согласен.
В традиционной иерархической организации с директивным управлением внедрить Agile невозможно, нужно каким-то образом менять отношения между сотрудниками и руководством.
Представим себе гипотетическую ситуацию, когда продукт А делают по водопаду, а конкурирующий продукт B по скраму. Оба продукта в итоге имеют один и тот же функционал. Какой продукт обойдётся дешевле по ресурсам? Очевидно, продукт А.
Нет, это совсем не очевидно.
Стоимость исправления дефектов разная в зависимости от того, на какой фазе ЖЦ он обнаружен.
Подход А позволяет выявлять дефекты на ранних стадиях за счет методологии и обратной связи, подход Б нет. Т.е. стоимость устранения архитектурных просчетов может может значительно сказаться на стоимости реализации.
Нет гарантий, что водопад эффективнее даже при статических требованиях.
Для меня не важна социализация на хабре.
Но какое это имеет отношение к обсуждаемому вопросу?
Комментирую я менее 1% от прочитанных статей.
Рассматривать современное общество и производственные отношения только с точки зрения экономических отношений… Да, я считаю, что это очень упрощенная модель. Вы не согласны?
Как в эту модель вписывается гемификация или другие нематериальные способы пощекотать ЧСВ? Почему зону комфорта предпочитают более высокой зарплате?
Возможно ли ускорить выход продукта, внедрив Agile?
Нет, невозможно.
Это же неверный вывод!
Agile методологии позволяют ускорять выход продуктов за счет нереализации ненужного или слабо востребованного функционала, который можно будет добавить позднее при наличии подтверждённого спроса, а не гипотез.
Ну и экономический вывод, что Agile работает там, где венчурный капитал — достаточно спорен. Управление портфелем проектов в крупных компаниях не имеет отношения к венчурному капиталу.
Но то, что для успешного внедрения требуются вполне определенные производственные отношения, здесь мне возразить нечего.
Agile расцвел, когда пофейлился RUP.
Стоимость детерменизма в «водопадной» разработке слишком высока для большинства проектов, которые востребованы на рынке.
Свопы, премиальные фонды — очень плохо работают там, где финансовый результат не зависит напрямую от трудозатрат. Это скорее средство удержания, а не мотивации. И своего рода лотерея (у меня были опционы в 2-х компаниях, миллионов не принесли).
«В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.»
Вот это достаточно сильное упрощение модели.
ПО, которое не изменяется, очень часто вызывает у пользователей только боль и со временем умирает.
Т.к. предсказывать будущее мало кто умеет, т.ч. причина для изменений может появится (новые бизнес-процессы, изменение норм, эволюция IT систем и т.п.)
И базируется утверждение на предпосылке, что заказчик точно знает чего хочет (т.к. пишет техническое задание). А реальные потребности и сценарии использования возникают на этапе внедрения и эксплуатации.
Возьмите автомобиль времен Маркса и современный. Можно ли было запроектировать так, чтобы потом ничего не менять?
Марксизм об Agile :-) Неожиданно.
На основании простейшей модели делаются тривиальные выводы.
Которые справедливы в той же мере, в какой модель отражает реальность.
Гибкие методологии разработки — это один из способов снижения рисков от неопределенности в ожидаемых результатах и оценке трудозатрат проектов.
Но Agile совершенно не является инструментом повышения эксплуатации.
А где Вы доказываете, что сокращение сроков разработки зависит именно от повышения эксплуатации?
Вы же совершенно верно пишете, что Agile — не делать лишнего, а не делать быстрее.
Ув. автор, вы решаете не ту задачу.
Вам была поставлена цель «автоматизировать до зубов».
Почему-то Вы решили, что она достигается внедрением CRM, и начали тестировать продукты на соответствие определению из Википедии.
Абстрагируйтесь от калек (CRM, ERP, BPM), подбирайте систему для решения своих задач.
У Вас маленькая компания, по бюджету может быть только коробочное решение, под которое нужно будет подстраивать свои процессы.
Любая уникальность в таких масштабах — это просто бардак.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
Уж извините.
Выводы делаются на основании личного опыта.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
Если говорим про scrum, то там есть PBR и планирование спринта.
Объяснять придется владельцу продукта и всей команде, почему на задачу планируется спринт.
Вы вызвали такси, чтобы доехать до аэропорта.
Где-то в глухом месте таксист вышел и вернулся спустя 2 недели. Сказал, что занимался фундаментальными исследования, но чем они заключались, объяснить не захотел.
И да, оплачивать эти исследования Вам.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
А вот если сначала тратиться 2 недели на работу, а только потом думаем, как это обосновать, то я считаю это чем-то сродни навязанным услугам.
Если работающее решение требует 2 часа, а изящное 2 недели, то выбор должен быть за владельцем бюджета, а не исполнителем.
И обычно об этом договариваются на берегу — при приеме на работу.
Скажем, если Вы пришли в стартап с ограниченным бюджетом, то долгосрочные инвестиции в совершенство кода приведут к банкротству — деньги закончатся раньше, чем продукт выйдет на рынок.
Если же Вас наняли в R&D отдел компании для инноваций, то там и постановка задач другая.
Критерии изящного решения Вы так и не привели. Поэтому не очень понятно, в чем заключался выигрыш.
И в какой момент нужно остановиться?
«Работа над произведением искусства никогда не может быть закончена, а может быть только заброшена.»
Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
Дурацкаяпритянутая за уши аналогия: я пригласил маляра покрасить стену, а он вместо краскопульта или валика расписал ее беличьей кистью №4. В один цвет, в лучшем случае дотянул по качеству до валика. «Художника может обидеть каждый»?Бывают ситуации, когда компании выгодно иметь такого специалиста, если, простите за пошлость, «монетизация» идет через PR (статьи, конференции, олимпиады), обучение коллег, создание атмосферы «избранности» в команде или поддержание ЧСВ у учредителей. Но это какая-то отдельная история.
Передоложим, что команда в среднем была 4 человека, 3,5 года. Только ФОТ минимум 20 млн. Общие расходы на разработку за это время минимум 30 млн.
Jira service desk (для примера) 1,5 млн лицензия + 0,75 млн в год поддержка на 50 пользователей. Workflow кастомизируется, статусов можно хоть 15 сделать. Если чего-то не хватает — можно дополнительные плагины купить или заказать. Для интеграции есть API.
Окупаемость 25-35 лет, а не 3-5. И это при условии, что на поддержку своей системы не будет расходов в будущем. Но я так понимаю, что команда продолжает проедать 10 млн в год.
С моей точки зрения, из 4-х вариантов: покупка готового, кастомизация готового, заказная разработка и собственная разработка выбрали самый затратный и самый рискованный.
Это инвестиции сродни покупке страхового полиса.
Если страховой случай не наступил, то кажется потерей денег.
Но без этих ритуалов очень сложно обеспечить прозрачный статус проекта.
Высокая степень неопределенности для реальных больших и сложных проектов — основная проблема водопада.
Детерминизм бывает только в простых проектах или тиражируемых решениях (типа сайта-визитки).
Ну и отдельный момент — мотивация команды и наработанная методология.
Перекраивать их ради одного проекта? Слишком накладно.
Еще есть тема морального духа и производительности, которая падает драматически в случае потери мотивации.
Просчеты не связаны, но некоторые методологии позволяют их выявить быстрее и устранить дешевле.
Проверка нефункциональных требований в водопаде начинается на стадии интеграционных или системных тестов. И если мы им не удовлетворяем — это не технический долг, это переделка (в лучшем случае).
Для меня Agile не является религией, т.к. я понимаю, какая «магия» скрывается за его эмпирическими методами и ритуалами.
Поэтому разоблачительную часть памфлета я не считаю убедительной, уж извините.
С некоторыми утверждениями я вполне согласен.
В традиционной иерархической организации с директивным управлением внедрить Agile невозможно, нужно каким-то образом менять отношения между сотрудниками и руководством.
Нет, это совсем не очевидно.
Стоимость исправления дефектов разная в зависимости от того, на какой фазе ЖЦ он обнаружен.
Подход А позволяет выявлять дефекты на ранних стадиях за счет методологии и обратной связи, подход Б нет. Т.е. стоимость устранения архитектурных просчетов может может значительно сказаться на стоимости реализации.
Нет гарантий, что водопад эффективнее даже при статических требованиях.
Но какое это имеет отношение к обсуждаемому вопросу?
Комментирую я менее 1% от прочитанных статей.
Рассматривать современное общество и производственные отношения только с точки зрения экономических отношений… Да, я считаю, что это очень упрощенная модель. Вы не согласны?
Как в эту модель вписывается гемификация или другие нематериальные способы пощекотать ЧСВ? Почему зону комфорта предпочитают более высокой зарплате?
Это же неверный вывод!
Agile методологии позволяют ускорять выход продуктов за счет нереализации ненужного или слабо востребованного функционала, который можно будет добавить позднее при наличии подтверждённого спроса, а не гипотез.
Ну и экономический вывод, что Agile работает там, где венчурный капитал — достаточно спорен. Управление портфелем проектов в крупных компаниях не имеет отношения к венчурному капиталу.
Но то, что для успешного внедрения требуются вполне определенные производственные отношения, здесь мне возразить нечего.
Agile расцвел, когда пофейлился RUP.
Стоимость детерменизма в «водопадной» разработке слишком высока для большинства проектов, которые востребованы на рынке.
Свопы, премиальные фонды — очень плохо работают там, где финансовый результат не зависит напрямую от трудозатрат. Это скорее средство удержания, а не мотивации. И своего рода лотерея (у меня были опционы в 2-х компаниях, миллионов не принесли).
«В итоге, если продукт разрабатывается под одного потребителя и не будет изменяться, применять Agile, следовать принципам и практикам SOLID, GRASP, DDD, TDD, KISS экономически нецелесообразно.»
Вот это достаточно сильное упрощение модели.
ПО, которое не изменяется, очень часто вызывает у пользователей только боль и со временем умирает.
Т.к. предсказывать будущее мало кто умеет, т.ч. причина для изменений может появится (новые бизнес-процессы, изменение норм, эволюция IT систем и т.п.)
И базируется утверждение на предпосылке, что заказчик точно знает чего хочет (т.к. пишет техническое задание). А реальные потребности и сценарии использования возникают на этапе внедрения и эксплуатации.
Возьмите автомобиль времен Маркса и современный. Можно ли было запроектировать так, чтобы потом ничего не менять?
На основании простейшей модели делаются тривиальные выводы.
Которые справедливы в той же мере, в какой модель отражает реальность.
Гибкие методологии разработки — это один из способов снижения рисков от неопределенности в ожидаемых результатах и оценке трудозатрат проектов.
А где Вы доказываете, что сокращение сроков разработки зависит именно от повышения эксплуатации?
Вы же совершенно верно пишете, что Agile — не делать лишнего, а не делать быстрее.
Вам была поставлена цель «автоматизировать до зубов».
Почему-то Вы решили, что она достигается внедрением CRM, и начали тестировать продукты на соответствие определению из Википедии.
Абстрагируйтесь от калек (CRM, ERP, BPM), подбирайте систему для решения своих задач.
У Вас маленькая компания, по бюджету может быть только коробочное решение, под которое нужно будет подстраивать свои процессы.
Любая уникальность в таких масштабах — это просто бардак.