Re: [agile-ukraine] Сводка для группы agile-ukraine@googlegroups.com - Сообщения: 8 в Темы: 2

[Andrii Nikitin]

Привет

2012/10/19 <agile-...@googlegroups.com>:
> Artem Mygaiev <jocu...@gmail.com> Oct 18 05:50AM -0700
...
> У нас для лечения этой болезни отлично проходят примеры "идеального" кода,
> который никому не нужен - просто потому что продукт не вышел вовремя... Так
> объясняем важность time-to-market.

А можно пару примеров?
Как контрпример возмем Chrome, который вышел когда рынок был успешно
поделен и сразу отхватил большую часть .
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

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

[Andrii Nikitin]

Извините за несуразный субжект - протупил

[Sergii Malyi]

Знаєте, Андрію, коли за продукт заплачено грубі гроші, замінити його
на інший, хай навіть більш успішний, не кожен відважиться...
А безкоштовний браузер - без проблем...
Тому time-to-market для комерційних продуктів має велике значення.

--
Sincerely,
Sergii Malyi

2012/10/19 Andrii Nikitin <lau...@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

[Artem Mygaiev]

Привет

Мы уже 1.5 года очень плотно работаем с Android, в основном НЕ на Java app уровне, а на системном - то есть развитие самой ОС и ядра; 2 года назад делали аналогичный проект дял ChromeOS на ARM. Смею Вас завертить, что и Chrome, и Android содержит такое количество crapcode что мы до сих пор воспринимаем относительную стабильность их работы как чудо. Как Google разрабатывет Android, я думаю, рассказывать не надо, смотрим здесь например http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html :) Ещё посмотреть на количество не-bugfix изменений в релизной ветке JB уже собственно после выхода релиза. Ещё можно посмотреть на количество комитов в Android со словом hack.

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

Теперь ещё. Вот Amazon пилит новый Kindle Fire. И успеть к "чёрной пятнице" - это для них настолько важно, что можно жертвовать фичами, красивостями, свистелками и #@$&елками направо и налево. Главное - выпустить продукт, обладающий каким-то Differentiator.

Далее. Все помнят выход превого iPhone? без многозадачности и всего того, что в других телефонах было уже давно сделано. Да, конечно Apple могли подождать ещё годика 3, доделать всё как следует и не париться с этой идиотской маркетинговой чернухой про "многозадачность = зло", но вроде как Epic Win и без того, правда?

Ещё интересный кейс. Давайте представим себе тестировщика-перфекциониста (как дополнение к девелоперу-перфекционисту). Он-то уже точно никогда не закончит тестирование - а вдруг там ещё есть проблемы? Не все же возможные тесты написаны. MTBF 100000 часов - это мало, вдруг пользователь этому будет не рад?

Bottomline

1. Вся красивая архитектура софта и тд - пользователю глубоко безразлична. Это всего лишь способ уменьшить количество [потенциальных] проблем в дальнейшем развитии продукта. А, да, ещё это в некоторой степени fun и даёт нам чувство завершенности. Дайте девелоперу пример - IDE в котором он работает. Пусть расскажет какая в нём прекрасная внутренняя архитектура и насколько она важна для его повседневной работы (в сравнении с фичами и производительностью этого самого IDE).

2. Хорошо, когда инженеры (девелоперы и тестировщики) знают что можно улучшать, и хотят улучшать продукт. Плохо когда они не понимают что действительно важно, а что не очень. Очень плохо, когда некому правильно расставить приоритеты и осмысленно отсекать ненужное.

3. На самом деле это всё вопросы качества продукта. А качество != идеал, и все в команде должны это понимать. И кто-то должен убедиться в том, что команда в курсе.

Артём

P.S. Сорри за несколько сумбурный пост

[Artem Mygaiev]

Да, примеры Failed Products из-за профаканного time-to-market при отсутствии какого-либо компенсирующего differentiator'а:

 - WebOS (бывший PalmOS) - всё писали, писали, улучшали, а выпускать не торопились

 - Современные Nokia Symbian смартфоны - практически никому не нужны (а зачем?)

 - Таблет от RIMM BlackBerry PlayBook - эпичный фэйл; так долго ковырялись что в какой-то момент решили выпускать что есть (как раз посреди очередного раз "улучшения" UI), получилось полное merde