Кейс: dev's professional/moral issue

[Nataliya Trenina]

Есть вопросик к практикующим девелоперам..  особенно не-скраммастерам :)

Затравка такая (кейс): 

Команда разрабатывает продукт на горячий рынок, есть сильные конкуренты. Не хочется ударить лицом в грязь. Хочется сделать красивую работу. Что бы не стыдно было детям показать. Что бы гордо можно было с ним на IPO выйти. Понятные желания. А время тикает. И PO совсем не до IPO :) Пора случиться поставке, хоть какой.

Обсуждаем темы lean startup, feedback loop, fail fast - похоже, вовремя (в начале проекта) этим принципам уделили недостаточно внимания. А теперь у меня такое ощущение, что обсуждаешь moral issue - заставляешь девелоперов писать "плохо", то есть недостаточно великолепно. Как девелопер: я их понимаю; как "бизнес":- понимаю, но не поддерживаю; как коуч - такое ощущение, что несмотря на все примеры, все еще не хватает продуктового мышления, "тягу" хочется усилить.

Теперь метафора (о морали):

Недавно сына попросили написать историю на тему "почему ломать деревья плохо". Это у него легко получилось. А потом мы задели тему "когда ломать деревья нормально" и открыли немало кейсов ( и сухие ветки, и защитить кого-то от дикого зверя, и сохранить фундамент дома от корней и тп).

Вопрос:

Что вам (как девелоперам) "помогает" писать "плохие" решения? То есть, минимально хорошие - для этого этапа проекта и/или фазы жизни продукта. Можно ведь написать "постную" фичу, а можно - со стразиками, а стразики - можно купить, а можно построить заводик по их изготовлению. И далеко не всякий раз хочется спрашивать у PO его мнения - каким путем пойти. Ведь мы любим делать вещи профессионально :)

Интересны решения - не через работу с PO (тут вроде бы справляемся), а через внутреннюю работу над собой (борьба с перфекционизмом). Что для вас работает? 

Спасибо заранее за идеи.

Ната

P.S. Я хоть давно и не пишу сама, но та же фигня проявляется в других сферах (анонсах, дизайне раздатки, статьях)

[Alexander Burdun]

Помогает лень.
Помогает желание быть первым (это когда приступая к задаче сначала
гуглишь готовые решения, чтобы удостовериться что не станешь вторым, а
то если второй, то зачем напрягаться, лучше готовое взять).
Помогает нежелание изобретать велосипед (частный случай предыдущего пункта)
Помогает желание ставить галочки "выполнено".

17 октября 2012 г., 23:55 пользователь Nataliya Trenina
<nat.t...@gmail.com> написал:

> --
> Agile Software Development Group, Ukraine, http://www.agileukraine.org/
>
> To visit the group online see: http://groups.google.com/group/agile-ukraine/
> To post to this group send email to agile-...@googlegroups.com
> To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Александр Бурдун

tel: +38 097 137 0443
skype: a.burdun
AIM/ICQ: 307064073
http://burdun.com

[Sergey Alpaev]

Привет. 

Как ни странно, чем лучше девелопер умеет писать, тем легче ему писать плохие решения:-)

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

Я стараюсь объяснять, что техническая компетенция архитектора или senior разработчика в том числе не столько в том, чтобы знать и применять сложные способы решения проблем, а в том чтобы уметь  предложить простые решения, и вовремя перейти к рефакторингу, если понадобится, то есть следовать "Decide as late as possible" принципу. Это как раз и требует часто хороших и нестандартных технических решений, чтобы иметь возможность сделать "быстро" сейчас и потом перейти к "хорошо" без переписывания всего и именно здесь нужны хорошие скилы "уметь делать правильно". Просто смысл слова "правильно" изменяется и изменяются ожидания от "профессионального разработчика/архитектора"

 

17 окт. 2012, в 23:55, Nataliya Trenina написал(а):

[Evgeny Kompaniets]

Я практикующий программист.
Для меня как раз великолепный код - это максимально простой и
реализующий ровно то, что нужно по текущим требованиям. Ничего
лишнего, ровно требования текущей итерации. Именно его легче всего
изменять в любую сторону. Т.е. фокус эффективного разработчика должен
несколько смещаться от "сделать красиво" к "сделать максимально
просто". Точнее максимально просто и станет красиво.
Вспоминается рекомендация Кента Бека по-моему, о том, что если в
текущей итерации вам не нужна реляционная бд, то и не используйте ее,
если проще сделать без нее. Даже если вы уверены что в следующей
итерации она точно будет.
Это способ двигаться максимально быстро с самым лучшим кодом в любой
момент времени.

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

Разработчики - это инструмент в руках ПО. ПО работает в среде с
неопределенностями: требования могут изменяться очень часто по
различным причинам. Хорошо когда у ПО появляется два уровня работы с
разработчиками: можно сдeлать продакшн качество и выпустить новую
версию продукта или очень быстро сделать "прототип", поигравшись с
которым можно принять решение о том делать ли его продакшн или
двигаться в другом направлении. При переделке прототипа в продакшн
часто имеет смысл полностью его выкинуть и написать заново.

Общий мотив - снимаем шапку архитектора заглядывающего в будущее.
Стремимся делать очень просто. Это красиво. Это не стыдно показать
детям. С этим можно дойти до IPO.

Не забываем что мы работаем на ПО. Наша задача быть удобным
инструментом в его руках.
Если ПО хочет на месте будущего этажа дома набросать из песка вариант
этого этажа, то очень здорово если мы умеем делать песочный вариант в
несколько раз быстрее каменного. Можно научить ПО пользоваться этим.
Естественно ПО должен понимать, что селить в песочный вариант людей
нельзя.

Не боимся делать без заглядывания вперед - неизвестно будут ли этажи
над тем, который вы сейчас строите, даже если вы строите первый а
вчера ПО упоминал про небоскреб. Если в спринте мы строим одноэтажный
дом, то фундамент делаем ровно под один этаж. Мы же умеем менять
фундамент потом.

2012/10/17 Nataliya Trenina <nat.t...@gmail.com>:

> --
> Agile Software Development Group, Ukraine, http://www.agileukraine.org/
>
> To visit the group online see: http://groups.google.com/group/agile-ukraine/
> To post to this group send email to agile-...@googlegroups.com
> To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Evgeny Kompaniets

[Borys Lebeda]

Женя, всё правильно. Вопрос в том как побудить так работать других
программистов при этом, не испортив отношения с ними.

Я обычно ещё до того как человек начал работать на проекте
ознакамливаю его с рекомендациями Кена Бека ("4 заповеди"):
http://c2.com/cgi/wiki?XpSimplicityRules и другими полезными вещами.
Вроде все всё понимают, но проблемы всё равно есть: мало кто хочет
быть инструментом в руках ПО ...

2012/10/18 Evgeny Kompaniets <evg...@gmail.com>:

--
Borys L.

[Alexander Burdun]

Вот кстати любимая ссылка:
http://en.wikipedia.org/wiki/KISS_principle

18 октября 2012 г., 9:56 пользователь Borys Lebeda
<borys....@gmail.com> написал:

--

[Evgeny Kompaniets]

Боря, ты напомнил мне старый вопрос: как убедить
заказчика/работодателя/коллег начать работать по скрам/xp/agile.
Сегодня этот вопрос уже не так популярен :)
И ответ на него у тебя свой есть, наверняка.
Для меня ответ на высоком уровне простой - найти для всех сторон
преимущества и заниматься их пропагандой.

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

Например показываешь человеку исходники проекта в несколько
человеко-лет, а там хороший код. И говоришь, это возможно, если
работать так как я.
Иногда разработчики просто не умеют "менять фундамент потом", из-за
этого и желание поархитектурить. Тогда появляется технический вызов -
научиться решать такие задачи. Это может быть для кого-то мотивацией.
Внутренная красота от простоты - технари это могут оценить.
Подобную культуру могут нести другие разработчики.
Это хорошо работает, если удается заработать авторитет. Именно
заработать! А тогда его начинают слушать, даже если он на первый
взгляд говорит что-то не то. Естественно это тяжело сделать тренеру и
скраммастеру, если он далек от кодирования. Потому я верю в то, что в
команде очень нужен технический авторитет. Он будет на одной стороне с
разработчиками и его влияние будет самым сильным. Парное
программирование с таким авторитетом сильнейшая вещь!

Еще один ресурс - достучаться до ПО внутри каждого программиста. В
наше время модно стартапить и делать что-то для себя.
Т.е. многие программисты уже примеряли на себя эту роль. Знаю что
многие очень любят вникать в причины по которым ПО принимает решения.
Мы вообще любим обсуждать действия президента страны на кухне. Так что
любая домохозяйка может быть ПО :)
Это может быть мотивацией: ПО рассказывает бизнес причины его решений,
программисты ими проникаются и начинают больше играть на его стороне.
Также как если б они писали свой собственный продукт. Когда пишешь
свой продукт то очень легко убедить себя не делать лишнюю работу, если
она отдаляет тебя от успеха на рынке.
Здесь тоже я верю в силу авторитета ПО. Если программисты чувствуют,
что он силен в бизнес решениях с ним хочется работать вместе.

Есть еще один момент, даже если люди разделяют эти ценности, они
иногда (некоторые часто) увлекаются. Похоже чаще увлекаться
свойственно техническим людям сильным в каких-то технических областях
(в алгоритмах, технологиях и т.п). Когда ты владеешь огромным
арсеналом, который любишь, очень хочется его задействовать. И очень
здорово иметь в команде кого-то кто замечает что людей начинает
"заносить" и он сможет мягко вернуть людей из космоса на землю.
Хорошо, когда это не кто-то один, а вся команда помогает друг-другу не
увлекаться.

2012/10/18 Borys Lebeda <borys....@gmail.com>:

[Vlad Savitsky]

Привет,

Перфекционизм - это плохо. Особенно для таких случаев, когда нужно quick and dirty. Например, нужно сделать максимально быстро прототип, а не универсальное решение.

У нас обычно проблема противоположная - мы боремся за качество и требуем его.

Чтобы разработчик сделать "плохое" решение достаточно дать ему жесткие сроки и плохое описание задачи.

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

Чтобы он сделал просто "очень плохо" - плохое описание, нет сроков, нет контроля качества. Остальное разработчик сделает сам по вдохновению.

Влад.

2012/10/17 Nataliya Trenina <nat.t...@gmail.com>

--

Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
 Vlad Savitsky
(Team Lead, Shvets Group)

+380965302712
Skype: vlad_savitsky
vlad.s...@shvetsgroup.com

http://www.linkedin.com/in/vladsavitsky

[Artem Mygaiev]

Годный Джоэль на тему:

http://www.joelonsoftware.com/items/2009/09/23.html

У нас для лечения этой болезни отлично проходят примеры "идеального" кода, который никому не нужен - просто потому что продукт не вышел вовремя... Так объясняем важность time-to-market.

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

Артём

[Anton Naumov]

Все здрасте.

А я вот сейчас буду толсто троллить. Вот очень толсто.

--  

Здесь поскипана большая-пребольшая вводная на предмет того, что если что-то делаешь - 

делай хорошо. Кому интересно - велкам в личку 

--

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

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

И все мы умеем рассказывать более или менее красиво, почему перфекционизм зло. Даже статья

на Хабре была. Реальность, вместе с тем, вносит свои коррективы.

Что заставляет меня писать максимально упрощенный код - время и ресурсы. Если один из этих 

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

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

то мы не разводим философских бесед о будущем проекта через пять лет. Мы просто делаем 

максимально возможное количество функционала, минимально возможным способом за

минимально необходимое время.

И рюши со стразиками сами собой отваливаются.

Как заставить других? Разговаривать. Много, долго, нудно, постоянно. Разговаривать и доносить

простую мысль - у нас ограничено время и ресурсы, мы не можем себе позволить философских 

рассуждений и закладов на отдаленное будущее. Вместо этого у нас есть вполне себе близкое

настоящее, когда нам нужно сделать еще очень много.

И так, скорее всего, будет всегда. Кому это не по душе, давайте расставаться сейчас.

Честность - лучшая политика (с)

И последнее, почему это плохо. Когда в простую, без лишнего и не нужного, архитектуру проекта 

необходимо встроить дополнительную функциональность, в принципе похожую на все остальное,

но немного не такую. Часто это выливается в недели работы. Хотя могло бы решиться лишним 

интерфейсом или фабрикой.

Резюмируя

1. Хорошо и правильно не делать лишнего.
2. Хорошо и правильно все-таки думать, перед тем как делать.
3. Хорошо и правильно смотреть немного вперед, балансируя на грани между текущими необходимостями проекта и его ближайшим будущим.
4. Плохо говорить словами из книг, мыслями из твиттера, фразами с собеседований.
5. Совсем плохо рубить с плеча и категорично заявлять "перфекционизм - это плохо" или "перфекционизм - это хорошо".

Середа, 17 жовтня 2012 р. 23:56:10 UTC+3 користувач Natatara написав:

[Evgeny Kompaniets]

Согласен со всем написанным. И совершенно верно отмечено, что нельзя
быть категоричным.

2012/10/18 Anton Naumov <grays...@gmail.com>:

> --
> Agile Software Development Group, Ukraine, http://www.agileukraine.org/
>
> To visit the group online see: http://groups.google.com/group/agile-ukraine/
> To post to this group send email to agile-...@googlegroups.com
> To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Evgeny Kompaniets

[Anton Naumov]

>>Чтобы разработчик сделать "плохое" решение достаточно дать ему жесткие сроки и плохое описание задачи.

Верно.

>>Чтобы он сделал быстро - нужно дать ему очень хорошее описание задачи с продуманной архитектурой, чтобы осталась только реализация + жесткие сроки.

Частично верно. Вы при всем желании не сможете добиться, чтобы даже по очень хорошему описанию задачи с продуманной архитектурой гарантировано получить результат в "жесткие сроки". Любые жесткие сроки - очень большие риски для компании и проектного менеджмента, всегда что-то случается. Невозможно заранее учесть все риски. Большинство жестких сроков не реально. Большинство реальных "жеских сроков" завышены на 30-100%.

>> Чтобы он сделал просто "очень плохо" - плохое описание, нет сроков, нет контроля качества. Остальное разработчик сделает сам по вдохновению.

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

Четвер, 18 жовтня 2012 р. 13:42:01 UTC+3 користувач Vlad Savitsky написав:

[Borys Lebeda]

> Разговаривать и доносить
> простую мысль - у нас ограничено время и ресурсы, мы не можем себе позволить
> философских

В аутсорсинге это не всегда проходит: заказчик может давать
неадекватно много времени. Было бы нормально если бы с ростом
"идеальности" кода, уменьшались бы и накладные расходы, а они ведь не
всегда уменьшаются ...
"Идеальность" - вещь субъективная :)

>
> А я вот сейчас буду толсто троллить. Вот очень толсто.

Да уж. Затроллил, так затролил ...

> --
> Agile Software Development Group, Ukraine, http://www.agileukraine.org/
>
> To visit the group online see: http://groups.google.com/group/agile-ukraine/
> To post to this group send email to agile-...@googlegroups.com
> To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Borys L.

[Vlad Savitsky]

> Совсем плохо рубить с плеча и категорично заявлять "перфекционизм - это плохо" или "перфекционизм - это хорошо".

Можно было бы ответить в стиле "совсем плохо заявлять, что что-либо совсем плохо"...

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

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

Надеюсь, что теперь моя позиция будет более понятной.

Влад.

2012/10/18 Borys Lebeda <borys....@gmail.com>

--

[Nataliya Trenina]

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

Ната

18 октября 2012 г., 22:49 пользователь Vlad Savitsky <vlad.s...@shvetsgroup.com> написал:

--

Nataliya Trenina

Co-Owner & Agile coach @ SCRUMguides
Conference Producer      @ Agile Eastern Europe
Founder & Facilitator       @ InnovationFriends

Social profiles:    nattrenina
For urgent matters: +38 050 412 61 35

[Alexander Burdun]

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

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

19 октября 2012 г., 18:52 пользователь Nataliya Trenina <nat.t...@gmail.com> написал:

--

[Sergii Malyi]

Alexander Burdun, если не секрет, сколько успешных демо прошло и как давно система в продакшне крутится?

-- 
Sincerely,
Sergii Malyi 

2012/10/19 Alexander Burdun <a.bu...@gmail.com>

[Alexander Burdun]

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

19 октября 2012 г., 20:08 пользователь Sergii Malyi <serg...@gmail.com> написал:

[Alexander Burdun]

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

19 октября 2012 г., 20:18 пользователь Alexander Burdun <a.bu...@gmail.com> написал: