Итак, тезисы 6-ой встречи, посвященной внутреннему устройству продуктовой разработки. Еще раз выскажу благодарность за замечательный и очень содержательный доклад Денису Журавлеву.
Презентация Дениса доступна по ссылке: http://www.drexplain.com/t_/indigo_byte_pm_samara_2011_08_13.pdf
Участвовали: Денис Журавлев (Indigo Byte), Павел Шамаров (Mercury Development), Игорь Михеенков (Mercury Development), Олег Сапрыкин (Mercury Development), Алик Сергеев (СамараИнформСпутник), Андрей Чернов (СамараИнформСпутник), Денис Пушкин (Mercury Development), Анастасия Печкурова (Parcsis)
Денис в развернутой форме рассказал об истории и эволюции процесса разработки в Indigo Byte. По ходу рассказа и по завершению встречи прошло обсуждение – краткое содержание которого ниже.
1. Цитата: Всё-таки в любой работе должен быть Fun. Иначе – скучно жить.
2. Цитата: Философия Стартапа и философия Бизнеса – две большие разницы.
3. Цитата: Построение бизнеса похоже на bejeweled. Кому-то везет и после пары-тройки перестановок все складывается и он срывает джек-пот. А кому-то приходится очень долго переставлять камушки, пока не получится сколько-нибудь значительный результат.
4. Цитата: В программировании – полно нудной работы. Поэтому на работу надо брать отличников – они умеют себя заставить такую работу делать. Однако неотличники могут быть полезны в плане генерации оригинальных идей.
5. Всё-таки очень сложно решить, что же лучше: чтобы сотрудник был предсказуем или инициативен? It depends…
6. Цитата: Всё-таки в продуктовой разработке многое зависит от людей. И когда продукт растет вместе с квалификацией сотрудников – получается редкая эндемичная биосистема – в которую очень сложно влиться новому сотруднику, особенно опытному.
7. «У релиза продукта должна быть красивая идея» -- это типа внешнего врага. Очень мощный механизм, но как быть, если красивая цель не достигается? Ответ: часто цель всё же достигается, но разработчики после релиза переключаются на «нового врага» -- идею нового релиза.
8. В продуктовой разработке – возникает проблема поддержки пользователей предыдущих релизов/версий – фактически необходимость поддержки нескольких продуктов – соответствующих различным версиям. Ответ: засчет возможности бесплатного апдейта до последующей версии – количество поддерживаемых версий можно сократить. Альтернативно, можно выбрать специфическую форму поддержки: предоставлять пользователям помощь, но не фиксить ничего в определенных предыдущих версиях.
9. В разработке -- не всегда все задачи одинаково интересны. Как в продуктовой разработке распределить задачи между участниками команды? Ответ: пока, все занимаются всем; либо в порядке компетенции: человек решает задачи в участке функционала, в котором он наиболее компетентен. Стараемся комбинировать задачи различной интересности.
10. Как поступить в продуктовой разработке, если команда не успевает с разработкой каких-то фич, запланированных в релиз? Ответ: резать функционал к чертовой матери.
11. Цитата: Число pi при оценивании работ разработчиком – в продуктовой разработке работает железно.
12. По какому принципу формируется список задач на новый релиз? – Ответ: из to-Do листа, комбинируя баги и фича и всецело доверяя собственной интуиции. Иногда даже стараясь угадать за пользователя.
Если идти на поводу у пользователя – включая фичи, которые хотят конечные пользователи – то это может быть билет в один конец – продукт, смесь пылесоса с холодильником, просто погибнет по тяжестью разнородной функциональности. Комментарий: надо уметь говорить нет. Есть еще такой подход: не записывайте хотелки пользователей, так как о фичах, которые реально нужны --забыть не дадут.
13. В продуктовой разработке – демократии не место. Всё равно должен быть кто-то на кого хотя бы можно было бы свалить неудачу… Угадайте кто это?
14. Существуют ли некоторые стандарты, которые унифицируют привычки кодирования разработчиков в команде? Ответ: да, наш стандарт = мнение нашего тех-лида
15. Есть группа бета-пользователей. Насколько рано показывается релиз этим пользователям и какого рода собирается фидбэк? Ответ: Есть закрытая группа и открытая группа бета-пользователей. Закрытая группа, опытные преданные пользователи продукта, имеют доступ к достаточно ранним билдам (примерно альфа, или раньше). Открытая группа – получает уже стабилизированный билд (по крайней мере с некоторыми гарантиями того, что, например, не изменится формат файла)
16. Цитата: Не стоит придумывать процесс на пустом месте. Процесс надо совершенствовать, только если у вас идея сработала, и есть болевые точки роста. Если их нет, не трогайте то, что работает. Всё равно ваши изменения не приживутся.
17. Цитата: Форма Project Management Tools – должна содержать элемент компьютерной игры. Должен быть Fun. Иначе – это всё не имеет смысла.
18. Цитата: Scrum нам не подошел, так как из различий в расписании, мы не могли провести ежедневный Standup – просто никогда не бывало так, что все были в офисе в одно время… Поэтому мы внедрили Kanban.
19. Цитата: Почетное звание «Разбилдяй» -- человек, который ушел, не за-check-in-ясь или зачекинил код, ломающий сборку.
20. Были попытки ограничивать гранулярность задач. Ответ: пока нет. Пока фичи считаем по головам.
21. Нету Scrum, нет Scrum-митинга, но всё равно в рамках неформальной процедуры выясняются ответы на вопросы, что сделано, что планируешь сделать, какие проблемы – просто это не зафиксировано во времени, происходит полу-стихийно
22. Нет ли необходимости в рамках Kanban использовать не одну границу на количество незавершенных задач а 2? – между границами пытаться сделать некоторые упреждающие воздействия, чтобы недопустить возрастания количества задач до критической массы. Ответ: пока нет необходимости
23. Может ли быть количество задач в работе больше, чем количество сотрудников? Если бы было меньше – тогда можно было бы построить метрику эффективности/прогресса задачи. Если их больше чем сотрудников – то есть задачи которые «ждут» -- тогда такую метрику сделать нельзя.
24. Если фичи не оценивать – то у разработчика есть соблазн делать больше мелких фич – так как это улучшает статистику по проекту, а сложные фичи оставлять. В итоге, при разработке сложных фич на последних этапах, можно насажать багов в уже сделанных мелких фичах: Ответ: решается приоретизацией задач в бэклоге а также необходимостью сделать ВСЕ фичи в релиз, а не только самые мелкие – в итоге некоторый баланс.
25. Единственное ограничие по объему единичной фичи, к которому пришли на настоящий момент – это ограничение на тестируемость: фичу должно быть можно протестировать в течение достаточно короткого времени.
26. Стоит ли фиксить все баги, которые репортят конечные пользователи? Ответ: нет, надо смотреть на эконом. эффективность такого фикса.
27. Так как в процессе тестирование производится не человеком, который сделал фичу – необходимо описать фичу так, чтобы ее потом мог протестировать другой член команды – в этом есть элементы TDD.
28. Каким образом проходят интегральные тесты, тесты производительности и стабильности – как отдельные задачи в рамках процесса? Ответ – обычно фичи взаимозавязаны, и хочешь - не хочешь, все равно при тестировании одних, тестируешь интеграцию.
29. Каким образом учитываются пожелания при работе фич: ведь фича может формально удовлетворять описанию, но на деле работать плохо. Ответ: если это неотделимо от фичи – то надо переоткрыть фичу, предварительно обсудив со всеми. Иначе – завести отдельный issue.
30. У вас тестируют программисты. Имеют ли они возможность при тестировании менять код? Ответ: нет, по педагогическим причинам, а также непонятно кто после такого изменения будет проверять такой фикс.
31. Кто исправляет баги? Тот же, кто посадил баг? Ответ: обычно тот, кто кодил, так как другие программисты обычно сами быстро переассайнивают баг на автора проблемы.
32. Возможно, части процесса, которые присутствуют в классике, не были внедрены, так как владелец компании и продукта выступает в роли менеджера/продюсера.
33. Возможно, люди которые занимаются аутсорсом и продуктовой разработкой – это две разные породы людей.
Презентация Дениса доступна по ссылке: http://www.drexplain.com/t_/indigo_byte_pm_samara_2011_08_13.pdf
Участвовали: Денис Журавлев (Indigo Byte), Павел Шамаров (Mercury Development), Игорь Михеенков (Mercury Development), Олег Сапрыкин (Mercury Development), Алик Сергеев (СамараИнформСпутник), Андрей Чернов (СамараИнформСпутник), Денис Пушкин (Mercury Development), Анастасия Печкурова (Parcsis)
Денис в развернутой форме рассказал об истории и эволюции процесса разработки в Indigo Byte. По ходу рассказа и по завершению встречи прошло обсуждение – краткое содержание которого ниже.
1. Цитата: Всё-таки в любой работе должен быть Fun. Иначе – скучно жить.
2. Цитата: Философия Стартапа и философия Бизнеса – две большие разницы.
3. Цитата: Построение бизнеса похоже на bejeweled. Кому-то везет и после пары-тройки перестановок все складывается и он срывает джек-пот. А кому-то приходится очень долго переставлять камушки, пока не получится сколько-нибудь значительный результат.
4. Цитата: В программировании – полно нудной работы. Поэтому на работу надо брать отличников – они умеют себя заставить такую работу делать. Однако неотличники могут быть полезны в плане генерации оригинальных идей.
5. Всё-таки очень сложно решить, что же лучше: чтобы сотрудник был предсказуем или инициативен? It depends…
6. Цитата: Всё-таки в продуктовой разработке многое зависит от людей. И когда продукт растет вместе с квалификацией сотрудников – получается редкая эндемичная биосистема – в которую очень сложно влиться новому сотруднику, особенно опытному.
7. «У релиза продукта должна быть красивая идея» -- это типа внешнего врага. Очень мощный механизм, но как быть, если красивая цель не достигается? Ответ: часто цель всё же достигается, но разработчики после релиза переключаются на «нового врага» -- идею нового релиза.
8. В продуктовой разработке – возникает проблема поддержки пользователей предыдущих релизов/версий – фактически необходимость поддержки нескольких продуктов – соответствующих различным версиям. Ответ: засчет возможности бесплатного апдейта до последующей версии – количество поддерживаемых версий можно сократить. Альтернативно, можно выбрать специфическую форму поддержки: предоставлять пользователям помощь, но не фиксить ничего в определенных предыдущих версиях.
9. В разработке -- не всегда все задачи одинаково интересны. Как в продуктовой разработке распределить задачи между участниками команды? Ответ: пока, все занимаются всем; либо в порядке компетенции: человек решает задачи в участке функционала, в котором он наиболее компетентен. Стараемся комбинировать задачи различной интересности.
10. Как поступить в продуктовой разработке, если команда не успевает с разработкой каких-то фич, запланированных в релиз? Ответ: резать функционал к чертовой матери.
11. Цитата: Число pi при оценивании работ разработчиком – в продуктовой разработке работает железно.
12. По какому принципу формируется список задач на новый релиз? – Ответ: из to-Do листа, комбинируя баги и фича и всецело доверяя собственной интуиции. Иногда даже стараясь угадать за пользователя.
Если идти на поводу у пользователя – включая фичи, которые хотят конечные пользователи – то это может быть билет в один конец – продукт, смесь пылесоса с холодильником, просто погибнет по тяжестью разнородной функциональности. Комментарий: надо уметь говорить нет. Есть еще такой подход: не записывайте хотелки пользователей, так как о фичах, которые реально нужны --забыть не дадут.
13. В продуктовой разработке – демократии не место. Всё равно должен быть кто-то на кого хотя бы можно было бы свалить неудачу… Угадайте кто это?
14. Существуют ли некоторые стандарты, которые унифицируют привычки кодирования разработчиков в команде? Ответ: да, наш стандарт = мнение нашего тех-лида
15. Есть группа бета-пользователей. Насколько рано показывается релиз этим пользователям и какого рода собирается фидбэк? Ответ: Есть закрытая группа и открытая группа бета-пользователей. Закрытая группа, опытные преданные пользователи продукта, имеют доступ к достаточно ранним билдам (примерно альфа, или раньше). Открытая группа – получает уже стабилизированный билд (по крайней мере с некоторыми гарантиями того, что, например, не изменится формат файла)
16. Цитата: Не стоит придумывать процесс на пустом месте. Процесс надо совершенствовать, только если у вас идея сработала, и есть болевые точки роста. Если их нет, не трогайте то, что работает. Всё равно ваши изменения не приживутся.
17. Цитата: Форма Project Management Tools – должна содержать элемент компьютерной игры. Должен быть Fun. Иначе – это всё не имеет смысла.
18. Цитата: Scrum нам не подошел, так как из различий в расписании, мы не могли провести ежедневный Standup – просто никогда не бывало так, что все были в офисе в одно время… Поэтому мы внедрили Kanban.
19. Цитата: Почетное звание «Разбилдяй» -- человек, который ушел, не за-check-in-ясь или зачекинил код, ломающий сборку.
20. Были попытки ограничивать гранулярность задач. Ответ: пока нет. Пока фичи считаем по головам.
21. Нету Scrum, нет Scrum-митинга, но всё равно в рамках неформальной процедуры выясняются ответы на вопросы, что сделано, что планируешь сделать, какие проблемы – просто это не зафиксировано во времени, происходит полу-стихийно
22. Нет ли необходимости в рамках Kanban использовать не одну границу на количество незавершенных задач а 2? – между границами пытаться сделать некоторые упреждающие воздействия, чтобы недопустить возрастания количества задач до критической массы. Ответ: пока нет необходимости
23. Может ли быть количество задач в работе больше, чем количество сотрудников? Если бы было меньше – тогда можно было бы построить метрику эффективности/прогресса задачи. Если их больше чем сотрудников – то есть задачи которые «ждут» -- тогда такую метрику сделать нельзя.
24. Если фичи не оценивать – то у разработчика есть соблазн делать больше мелких фич – так как это улучшает статистику по проекту, а сложные фичи оставлять. В итоге, при разработке сложных фич на последних этапах, можно насажать багов в уже сделанных мелких фичах: Ответ: решается приоретизацией задач в бэклоге а также необходимостью сделать ВСЕ фичи в релиз, а не только самые мелкие – в итоге некоторый баланс.
25. Единственное ограничие по объему единичной фичи, к которому пришли на настоящий момент – это ограничение на тестируемость: фичу должно быть можно протестировать в течение достаточно короткого времени.
26. Стоит ли фиксить все баги, которые репортят конечные пользователи? Ответ: нет, надо смотреть на эконом. эффективность такого фикса.
27. Так как в процессе тестирование производится не человеком, который сделал фичу – необходимо описать фичу так, чтобы ее потом мог протестировать другой член команды – в этом есть элементы TDD.
28. Каким образом проходят интегральные тесты, тесты производительности и стабильности – как отдельные задачи в рамках процесса? Ответ – обычно фичи взаимозавязаны, и хочешь - не хочешь, все равно при тестировании одних, тестируешь интеграцию.
29. Каким образом учитываются пожелания при работе фич: ведь фича может формально удовлетворять описанию, но на деле работать плохо. Ответ: если это неотделимо от фичи – то надо переоткрыть фичу, предварительно обсудив со всеми. Иначе – завести отдельный issue.
30. У вас тестируют программисты. Имеют ли они возможность при тестировании менять код? Ответ: нет, по педагогическим причинам, а также непонятно кто после такого изменения будет проверять такой фикс.
31. Кто исправляет баги? Тот же, кто посадил баг? Ответ: обычно тот, кто кодил, так как другие программисты обычно сами быстро переассайнивают баг на автора проблемы.
32. Возможно, части процесса, которые присутствуют в классике, не были внедрены, так как владелец компании и продукта выступает в роли менеджера/продюсера.
33. Возможно, люди которые занимаются аутсорсом и продуктовой разработкой – это две разные породы людей.
Комментариев нет:
Отправить комментарий