Сообщение Re: Сколько у вас уходит времени на обдумывание и реализацию от 17.02.2017 14:26
Изменено 17.02.2017 14:30 Pauel
Re: Сколько у вас уходит времени на обдумывание и реализацию задачи?
Здравствуйте, Kocur, Вы писали:
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
K>2. Обдумывание (в том числе в нерабочее время)
K>3. Кодинг (реализацию)
п.1. обычно просто "поиск нужной информации". Как правило интернет здесь слабо помогает, только в простейших случаях.
Обычно п2. наибольший, примерно две трети всего времени. Кодинг самый короткий. Но вообще кодингом дело не заканчивается, за ним следует майнтенанс.
То есть, в упрощенном виде вот так
1 поиск информации (уточнение требований, ограничений и тд)
2 построение модели решения
3 кодинг (модель решения переводится в код)
4 майнтенанс
И это все происходит итерационно.
Но лучше строить работу примерно так
1. уточнить, что вообще нужно сделать, есть ли конечная цель, какой результат ожидается
Далее, если цель есть,
2. поставить гипотезу
3. подтвердить или опровергнуть при помощи доп. инфы (интернет, справочники, эксперимент и тд и тд). т.е. достижима ли цель
4. построение модели решения, если цель достижима
5. кодинг
6. майнтенанс
Если цели нет(открытая проблема), или цель недостижима, фактически есть проблема — то есть, неопределенность.
Начинается несколько итераций, целью будет собственно решение проблемы
Здесь формализовать довольно трудно, т.к. это до сих пор искусство
В целом неопределенность нужно исключить. Например так
1 гипотеза
2 исследования, эксперимент — выявление свойств проблемы, масштаб, характер, риски и тд и тд
3 модель проблемы
4 постановка целей/результаты
Например — много багов с точностью операций с плавающей запятой. Что за хрень? Пофиксить не получается — полгода убили, багов меньше не стало. Цель вроде бы есть, но не ясно, достижима ли она. Проблема — неизвестны причины возникновения багов с точностью.
Где искать проблему не всегда ясно. В данном случае была куча гипотез, из которых подтвердились только следующие
0. криворукие девелоперы
1. код работы с матрицами содержал косяк, который не виден был чз тесты
2. часть кода либы содержала ошибки, которые друг друга компенсировали, чз тесты были не видны
3. сервер втихаря вносил хаос, округлял младшие биты не в ту сторону
4. много дублирования и возможно мелкие ошибки в каждом из случаев
когда кое как пофиксили эти части, оказалось, что проблема все еще воспроизводится. Последняя гипотеза — последовательность вычислений содержала фундамендальный изъян — схема вычислений была упрощенной, корректной только для частного случая. Если менялся масштаб чисел, погрешность менялась случайным образом. Она подтвердилась.
Вернулись на исходную позицию, внесли основной фикс, около сотни багов ушло само собой. после этого 1, 2, 3 и 4 раскидали по спринтам, поскольку они только маскировали проблему, но не являлись причинами.
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
K>2. Обдумывание (в том числе в нерабочее время)
K>3. Кодинг (реализацию)
п.1. обычно просто "поиск нужной информации". Как правило интернет здесь слабо помогает, только в простейших случаях.
Обычно п2. наибольший, примерно две трети всего времени. Кодинг самый короткий. Но вообще кодингом дело не заканчивается, за ним следует майнтенанс.
То есть, в упрощенном виде вот так
1 поиск информации (уточнение требований, ограничений и тд)
2 построение модели решения
3 кодинг (модель решения переводится в код)
4 майнтенанс
И это все происходит итерационно.
Но лучше строить работу примерно так
1. уточнить, что вообще нужно сделать, есть ли конечная цель, какой результат ожидается
Далее, если цель есть,
2. поставить гипотезу
3. подтвердить или опровергнуть при помощи доп. инфы (интернет, справочники, эксперимент и тд и тд). т.е. достижима ли цель
4. построение модели решения, если цель достижима
5. кодинг
6. майнтенанс
Если цели нет(открытая проблема), или цель недостижима, фактически есть проблема — то есть, неопределенность.
Начинается несколько итераций, целью будет собственно решение проблемы
Здесь формализовать довольно трудно, т.к. это до сих пор искусство
В целом неопределенность нужно исключить. Например так
1 гипотеза
2 исследования, эксперимент — выявление свойств проблемы, масштаб, характер, риски и тд и тд
3 модель проблемы
4 постановка целей/результаты
Например — много багов с точностью операций с плавающей запятой. Что за хрень? Пофиксить не получается — полгода убили, багов меньше не стало. Цель вроде бы есть, но не ясно, достижима ли она. Проблема — неизвестны причины возникновения багов с точностью.
Где искать проблему не всегда ясно. В данном случае была куча гипотез, из которых подтвердились только следующие
1. код работы с матрицами содержал косяк, который не виден был чз тесты
2. часть кода либы содержала ошибки, которые друг друга компенсировали, чз тесты были не видны
3. сервер втихаря вносил хаос, округлял младшие биты не в ту сторону
4. много дублирования и возможно мелкие ошибки в каждом из случаев
когда кое как пофиксили эти части, оказалось, что проблема все еще воспроизводится. Последняя гипотеза — последовательность вычислений содержала фундамендальный изъян — схема вычислений была упрощенной, корректной только для частного случая. Если менялся масштаб чисел, погрешность менялась случайным образом. Она подтвердилась.
Вернулись на исходную позицию, внесли основной фикс, около сотни багов ушло само собой. после этого 1, 2, 3 и 4 раскидали по спринтам, поскольку они только маскировали проблему, но не являлись причинами.
Re: Сколько у вас уходит времени на обдумывание и реализацию
Здравствуйте, Kocur, Вы писали:
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
K>2. Обдумывание (в том числе в нерабочее время)
K>3. Кодинг (реализацию)
п.1. обычно просто "поиск нужной информации". Как правило интернет здесь слабо помогает, только в простейших случаях.
Обычно п2. наибольший, примерно две трети всего времени. Кодинг самый короткий. Но вообще кодингом дело не заканчивается, за ним следует майнтенанс.
То есть, в упрощенном виде вот так
1 поиск информации (уточнение требований, ограничений и тд)
2 построение модели решения
3 кодинг (модель решения переводится в код)
4 майнтенанс
И это все происходит итерационно.
Но лучше строить работу примерно так
1. уточнить, что вообще нужно сделать, есть ли конечная цель, какой результат ожидается
Далее, если цель есть,
2. поставить гипотезу
3. подтвердить или опровергнуть при помощи доп. инфы (интернет, справочники, эксперимент и тд и тд). т.е. достижима ли цель
4. построение модели решения, если цель достижима
5. кодинг
6. майнтенанс
Если цели нет(открытая проблема), или цель недостижима, фактически есть проблема — то есть, неопределенность.
Начинается несколько итераций, целью будет собственно решение проблемы
Здесь формализовать довольно трудно, т.к. это до сих пор искусство
В целом неопределенность нужно исключить. Например так
1 гипотеза
2 исследования, эксперимент — выявление свойств проблемы: масштаб, характер, риски, локализация, поведение, временные и фазовые особенности и тд
3 модель проблемы
4 постановка целей/результаты
Например — много багов с точностью операций с плавающей запятой. Что за хрень? Пофиксить не получается — полгода убили, багов меньше не стало. Цель вроде бы есть, но не ясно, достижима ли она. Проблема — неизвестны причины возникновения багов с точностью.
Где искать проблему не всегда ясно. В данном случае была куча гипотез, из которых подтвердились только следующие
0. криворукие девелоперы
1. код работы с матрицами содержал косяк, который не виден был чз тесты
2. часть кода либы содержала ошибки, которые друг друга компенсировали, чз тесты были не видны
3. сервер втихаря вносил хаос, округлял младшие биты не в ту сторону
4. много дублирования и возможно мелкие ошибки в каждом из случаев
когда кое как пофиксили эти части, оказалось, что проблема все еще воспроизводится. Последняя гипотеза — последовательность вычислений содержала фундамендальный изъян — схема вычислений была упрощенной, корректной только для частного случая. Если менялся масштаб чисел, погрешность менялась случайным образом. Она подтвердилась.
Вернулись на исходную позицию, внесли основной фикс, около сотни багов ушло само собой. после этого 1, 2, 3 и 4 раскидали по спринтам, поскольку они только маскировали проблему, но не являлись причинами.
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
K>2. Обдумывание (в том числе в нерабочее время)
K>3. Кодинг (реализацию)
п.1. обычно просто "поиск нужной информации". Как правило интернет здесь слабо помогает, только в простейших случаях.
Обычно п2. наибольший, примерно две трети всего времени. Кодинг самый короткий. Но вообще кодингом дело не заканчивается, за ним следует майнтенанс.
То есть, в упрощенном виде вот так
1 поиск информации (уточнение требований, ограничений и тд)
2 построение модели решения
3 кодинг (модель решения переводится в код)
4 майнтенанс
И это все происходит итерационно.
Но лучше строить работу примерно так
1. уточнить, что вообще нужно сделать, есть ли конечная цель, какой результат ожидается
Далее, если цель есть,
2. поставить гипотезу
3. подтвердить или опровергнуть при помощи доп. инфы (интернет, справочники, эксперимент и тд и тд). т.е. достижима ли цель
4. построение модели решения, если цель достижима
5. кодинг
6. майнтенанс
Если цели нет(открытая проблема), или цель недостижима, фактически есть проблема — то есть, неопределенность.
Начинается несколько итераций, целью будет собственно решение проблемы
Здесь формализовать довольно трудно, т.к. это до сих пор искусство
В целом неопределенность нужно исключить. Например так
1 гипотеза
2 исследования, эксперимент — выявление свойств проблемы: масштаб, характер, риски, локализация, поведение, временные и фазовые особенности и тд
3 модель проблемы
4 постановка целей/результаты
Например — много багов с точностью операций с плавающей запятой. Что за хрень? Пофиксить не получается — полгода убили, багов меньше не стало. Цель вроде бы есть, но не ясно, достижима ли она. Проблема — неизвестны причины возникновения багов с точностью.
Где искать проблему не всегда ясно. В данном случае была куча гипотез, из которых подтвердились только следующие
1. код работы с матрицами содержал косяк, который не виден был чз тесты
2. часть кода либы содержала ошибки, которые друг друга компенсировали, чз тесты были не видны
3. сервер втихаря вносил хаос, округлял младшие биты не в ту сторону
4. много дублирования и возможно мелкие ошибки в каждом из случаев
когда кое как пофиксили эти части, оказалось, что проблема все еще воспроизводится. Последняя гипотеза — последовательность вычислений содержала фундамендальный изъян — схема вычислений была упрощенной, корректной только для частного случая. Если менялся масштаб чисел, погрешность менялась случайным образом. Она подтвердилась.
Вернулись на исходную позицию, внесли основной фикс, около сотни багов ушло само собой. после этого 1, 2, 3 и 4 раскидали по спринтам, поскольку они только маскировали проблему, но не являлись причинами.