Скажите на одного програміста? [зачинено]

Мене виставляють на рахунку як "експерта Windows" в моїй дуже маленькій компанії, яка складається з мене, інженера-механіка, який працює в сфері продажів і навчань, і президента компанії, який працює в розробці, розробці та підтримці.

Моя роль настільки ж загальна, але в першу чергу я розробляю та впроваджую будь-яке програмування нашого продукту для того, щоб наші матеріали працювали на тих версіях Windows, які є поточними.

Я щойно закінчив перегляд оглядової парадигми Scrum на високому рівні, наведеної у веб-трансляції. Моє запитання: чи варто мого часу дізнатися більше про такий підхід до розробки товару, враховуючи, що мої статті з розробки зазвичай надаються на дуже високому рівні, наприклад, "інтернаціоналізація та локалізація товару".

Якщо це так, як би ви запропонували адаптувати Scrum для використання лише одного програміста? Які інструменти, засновані на хмарі чи іншим способом, були б корисні для цього?

Якщо це не так, який би ви запропонували одному програмісту організовувати свої зусилля щодня? (Можливо, питання зводиться до цього простого питання.)

Learn Scrum: так. Якби тільки дізнатися про це, щоб додати до вашого загального набору навичок. (але аромат цього "Scrum-ban" - це, мабуть, те, що ви шукаєте ...)

Scrum - це приємна рамка, але основним принципом є "Ітерації (спринти) мають бути фіксованою тривалістю". Я ніколи не бачив цієї роботи в дуже малих командах, які більше керують перервами, ніж ні. Якщо ви справді можете зареєструватися та взяти на себе зобов’язання працювати у встановлений термін (1 тиждень?), Тоді Scrum - це крута рамка. Якщо ви не можете ... тоді Scrum приємно дізнатися, оскільки він має хороші поняття, які добре перекладають інші речі ... наприклад ...

Затримка - Скуріть чи ні, зберігайте пріоритетний список речей, які вам потрібно зробити. Мені подобається Excel (або електронна таблиця Google Doc ...) Можливо, вам сподобається щось інше. Я б зберіг дуже маленький інструмент, якщо ви дуже мала команда. (Електронна таблиця >> Текстовий процесор, оскільки ви можете легко сортувати.)

Розмежування планування та вчинення - Плануйте в абстрактній нотації (бали) та будьте послідовними (8пт - це приблизно 2х-кратне 4-кратне оповідання та 4х - очка в 2 бали) Коли час "виконати роботу", перегляньте проблему та замальовуйте її в години. Не змінюйте бали.

Зобов'язання - будьте видимі для інших, коли ви берете на себе зобов'язання, і виконайте свої зобов'язання

Ретроспектива - після того, як ви поставитеся, подумайте про те, що можна було зробити краще.

тощо.

Scrum досить легкий, щоб зрозуміти, що це може бути гарною відправною точкою. Якщо вам це подобається, я б подумав скористатись варіантом "Заборона заборони" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Ніщо інше не вражає мене, як "настільки добре задокументованого", з досить активною спільнотою для його підтримки.

Я також хотів би порекомендувати методики кристала Алістера Кокберна (http://alistair.cockburn.us/Crystal+methodologies+main+foyer та http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Невеликий / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), але це передбачає ще більше читання та риття.

Такі речі, як XP, містять докладніші відомості щодо конкретних практик, тому я також сказав би прочитати книгу: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= книги & ie = UTF8 & qid = 1304359834 & sr = 1-1

Підсумкова порада з читання: Якщо ви погоджуєтесь з маніфестом Agile та дотримуєтесь принципів: http://agilemanifesto.org/principles.html ви повинні бути в пристойній формі.

Особиста рекомендація: Прийняти TDD (не підлягає обговоренню, IMHO) Підтримуйте відставання (відповідно до Scrum). Завжди тримайте його за розмірами та сортуйте за пріоритетом. Розкладайте речі, "занадто великі, щоб робити між перервами", в менші шматки. два предмети отримують однаковий пріоритет. Завжди. Зробіть середовище побудови здатною створити / протестувати / розгорнути (для лабораторії навколишнього середовища) за 5-10 хв. Покажіть своїм клієнтам (внутрішні та зовнішні) результати завершення історії Історія не робиться до ваш клієнт погоджується. Потягніть історії з верхньої частини сторони і працюйте над ними, коли ви завершите поточну історію. Не тримайте більше двох речей за один раз. Завершіть одне відволікання, перш ніж починати інше.

сподіваюся, що це допомагає

Ви можете використовувати такі практики, які використовуються в Scrum, як відставання продукту, пріоритетність, відносна оцінка, поступова доставка, але використання цілого Scrum як процесу управління розробкою продукту командою самоорганізованих крос-функціональних членів - це, мабуть, не спосіб вийти на показ одного чоловіка .

Питання полягає в тому, чи зможете ви розбити свої предмети на невеликі шматки, які можна буде поступово доставляти? Якщо не використовувати більшість практик, немає сенсу. Також Scrum - про високу співпрацю з власником / замовником продукту. Це не повинно бути таким: "Ось у вас є завдання і повертайтеся, як тільки це буде зроблено".

Поки я нічого не скажу за або проти 1-го чоловіка Срум, я скажу, що система тягнення Kanban на 1 чоловіка працює дуже добре. Kanban у поєднанні з автоматизованим тестуванням Unit зробив мене набагато більш продуктивним та "задокументованим". Хоча жодна з методів насправді не є, але більше інструментів (і дуже різних у цьому), і вони змушують мене розбивати великі сольні проекти на шматочки розміру, а також дають мені своєрідний ритуал, щоб заохотити мене робити більше справ кожного день. Немає нічого такого задоволення, як натиснути "запустити всі тести" та побачити, як кожен елемент стає зеленим ... нічого, крім того, як взяти карту зі стовпця "У процесі роботи" на моїй дошці Kanban до "В процесі тестування" (або повністю поза дошкою) .

Я думаю, що справжньою проблемою роботи з солом є те, що ви обираєте з декількох методологій, які справді призначені для груп розробників, і налаштувати його, щоб найкраще підходити вам. Кінцева мета - це просто зробити вас підзвітними, продуктивними та щасливими. Хто знає, як це зробити краще, ніж ти сам (трохи потягнувшись звідси і трохи звідти).

Я це спробував, коли працював один раз в один момент. Добре працювали:

1. Маючи всі робочі предмети на дошці. Я дуже швидко міг побачити, яка там видатна робота; де були залежності і блокади. Крім того, багато людей зупинилися б біля моєї дошки і прочитали її - і ми поговоримо про це. Я думаю, що це допомогло їм зрозуміти, що "видовище" робить цілий день ;-)
2. Схема згоряння також була чудовою. Я просто використовував для цього Excel. Це дозволило мені покращитись в оцінці в тому середовищі. Це дало мені чудовий огляд того, куди я прямував із ітерацією. Моя менеджерка, яка не була технічною особою, також полюбила це, оскільки вона могла бачити всі різні речі, пов'язані з якоюсь функцією, і де вони були.
3. Щоденний стенд. Ну як найкраще міг. Кожного ранку я оновлював усі робочі елементи та графік згоряння та робив помітку про всі перешкоди, які потрібно було вирішити.
4. Автоматизоване тестування та безперервна інтеграція (MSTest / TFS), бажано TDD, допоможе будь-якій команді розробників, використовуючи будь-яку методологію - але тут варто згадати.
5. Короткі ітерації (1 тиждень) дійсно допомогли мені зосередитись на тому, щоб щось зробити.
6. Підтримка відставання була чудовою, тому що коли мені дали нову роботу, я зміг розмістити її в контексті всіх інших робіт і дозволити власнику продукту визначити пріоритет.

Що не спрацювало:

1. Працюючи самостійно, ти ніколи не отримуєш цього поштовху від співпраці з однодумцями; або почуття конкуренції та зосередженості, яке виходить від команди з дійсно великим духом та культурою. Немає іншого мозку, який можна вибрати, коли ви застрягаєте, тому подібні блокади не вдасться усунути майстром накрутки у щоденному вставанні.
2. Немає майстра розколу - значить, нікого не зупиняти на перебоях. У мене було багато проблем з людьми, які постійно задавали питання про інші речі і порушували свій потік. Під хорошим майстром розколу такі речі перехоплюються, і ви можете продовжувати працювати. Я ніколи не хотів бути грубим до людей (можливо, я м'який), тому це було проблемою. Крім того, без майстра scrum можна легко відмовитися від процесу.

Це була цікава вправа, але я трохи перестав її робити. Я думаю, що переваги Scrum слід бачити на відміну від традиційних водоспадних команд. Але обоє є суперечками, коли ти сам. Немає жодних проблем із спілкуванням чи співпрацею - ви просто робите роботу, яка встановлена, і тоді ви закінчите.

Я думаю, що кожен повинен вести бек-журнал, але робити TDD.

Елементи Agile / Scrum / Kanban, які, на мою думку, мають сенс в одному світі розробників:

1. Майте дошку, на якій ви впорядковуєте свої розповіді користувачів / активні елементи блоку, на індексних картах, як канбан.

2. Отримайте покупку від не розробників на цінність цих принципів:

   • Дайте мені час на роботу, не змінюючи своїх пріоритетів на мені чи мікроменеджменті (точка спринтів). Дайте мені час, і я спробую заздалегідь зрозуміти, скільки я можу зробити, і я зроблю все можливе, щоб зробити це багато.

   • Якщо мені щось потрібно (я заблокований), і я приходжу до вас, і ви не можете цього сортувати для мене, тоді спринт, можливо, доведеться скасувати аномально. (Це просто означає, що нам потрібен новий план.)

   • У середині спринту ніхто нічого не змінює. Або, якщо ми це робимо, ми просто скасовуємо спринт, і створюємо новий. якщо цього трапляється багато, продуктивність падає.

   • спілкування між людьми, які є зацікавленими сторонами, може відбуватися на регулярних щоденних зустрічах, що стосуються постійного обговорення, які передають більшість тих же речей, що і звичайні скандали, включаючи досягнення вашого розробника протягом дня. По суті, ви можете повідомити про речі, які зайняли більше часу, ніж ви думали, або пройшли добре, і про будь-які коригування, які ви вносите у свої плани щодо впровадження. (Я знайшов чотири нові помилки та ввійшов до них. Я думаю, що вони важливіші за цю необов’язкову функцію, і тому я думаю, що я витрачу час і виправлюю їх та висуну цю додаткову функцію.)

Я багато працював як окремий розробник, і можу сказати точно, що довіра між окремим розробником та його наглядачами / начальниками, що не розробляються, та хороша комунікація - це ключ, а не методологія. Але ти завжди можеш бути ефективнішим, якщо дотримуватись добрих принципів.

Я читав про це блог, і думаю, що це може допомогти вам у питанні.

Перша частина: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Друга частина: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Ви можете знайти більше інформації в цьому блозі.

Я жодним чином не пов'язаний; просто щось у мене було в улюблених. Сподіваюся, це може вам допомогти.

Так. І майте на увазі, що Scrum не повинен залучати вигадливих інструментів, це може бути просто 15-хвилинна стенд-ап зустріч, де всі говорять про те, над чим працюють. Перевага Scrum полягає в тому, що всі знають, що відбувається, і це полегшує вирішення проблем, перш ніж вони виникнуть, і передбачити проблеми в дорозі.

Дуже багато цих відповідей пропускають важливий момент.

Команді scrum не потрібно складатися виключно з програмістів.

Один з ваших колег займається дизайном / розробкою, а хтось продає.

Можливо, ваш колега з продажу може бути власником продукту (проксі). Які очікування замовника?

Дизайн та розробка вашого іншого колеги справді звучать як дисципліни команди scrum для мене. Розробка Scrum не поетапна, а вертикальна (вимоги, що вимивають, проектують та впроваджують в одному спринті).

Ви могли б зробити процес scrum з трьома.

Що потрібно, щоб це зробити? Спринт-планувальні зустрічі Scrum збільшують питання про те, що це таке. Що власник продукту очікує, щоб він вважався зробленим?

Під час зустрічі зі планування спринту ви можете дати своїм іншим колегам контекст щодо того, чому "інтернаціоналізація та локалізація товару" може бути технічно складною для реалізації.

Безліч причин використовувати scrum imho.

Я б запропонував спробувати Канбан і почати з основ: візуалізація та обмеження незавершеного виробництва (WIP).

Навіть якщо ви припините його пізніше, ви отримаєте більш спритний процес. І хоча Kanban хороший для "нормальної" розробки програмного забезпечення, Kanban + проточний процес (на відміну від ітерацій) перекриває інші інструменти процесу, коли у вас виникає ситуація з розробкою нових функцій та технічним обслуговуванням.

Я друге рекомендую книгу Канбана Девіда Андерсона, і ви також можете подивитися на мої слайди з місцевої зустрічі про те, чому і як розпочати роботу з простим Kanban , або crisp.se/kanban на короткий вступ.

Для вашого контексту у мене є кілька думок:

• видимість є ключовою, тому скоріше використовуйте фізичну дошку, ніж цифровий інструмент, якщо ви не можете її постійно відображати на (великому) екрані (якщо ви знаходитесь разом)
• почніть з вашого поточного процесу
• почніть тільки зі своєї сфери впливу, включаючи фази передачі вгору і за течією низхідного потоку (перетворюючись на чергу для вас, наприклад, розроблені функції, готові для розробника, або чергу від вас, наприклад, готові функції, готові до продажу)
• якщо ваші колеги зацікавлені розширити візуалізацію вгору чи вниз за течією, тим краще. Можливо, ви в кінцевому підсумку візуалізуєте весь потік цінності (або мережу) для вашої компанії, тобто, як вартість перетікає від концепції до грошових коштів
• мінімізувати багатозадачність (!) шляхом обмеження WIP. Якщо потік роботи видно вашим колегам, вони повинні зрозуміти, чому, і легко побачити, що на вашій тарілці
• можливо, буде корисно розділити роботу на 3 або 4 типи робіт (класи обслуговування), які мають різні вимоги до них: f.ex. помилки, критичні проблеми, робота з жорсткими термінами, робота без термінів
• спостерігайте за тим, як протікає ваша робота, наприклад, якщо ви десь отримуєте вузькі місця, або робота заблокована або ви «голодуєте» за роботу за дещо передбачуваними схемами. Це надовго простіше, якщо ви використовуєте цифровий інструмент, перегляньте деякі мої останні слайди.
• покращувати потік роботи крок за кроком

Якщо ви хочете спробувати щось зараз, сьогодні, поки ви приймаєте рішення, я рекомендую спробувати особистий канбан на стіні чи вікні чи шафі біля вас, як я робив минулого тижня ...

Прочитавши всі інші відповіді тут, я думаю, що проста прагматична відповідь:

Використовуйте процеси або прийоми чи методи, які використовуються, щоб дізнатись щось, що допоможе вам краще виконати свою роботу.

Тепер це може означати пріоритетність завдань - щодня - релігійно.

Це може означати розробка відставання.

Це може означати повідомити про свій прогрес - своєму начальнику (навіть якщо він не піклується ... робити це добре, щоб подумки дозволити ВАС скласти підсумки, де ви знаходитесь).

Ви можете використовувати всілякі методи або прийоми, оскільки вони в кінцевому підсумку дозволяють вам працювати краще, що = спати краще вночі.

Робіть речі, які працюють (для вас, у ваших поточних обставинах), відкидайте речі, які цього не роблять.

Якщо у вас немає наступного

• Засоби організації та визначення пріоритетності вхідних вимог.

• Точно оцінити зусилля, які будуть докладені, щоб ви знали, що ви можете зробити в ітерації

• Ітерації та постійне вдосконалення - Неоціненною є концепція ітерацій, в яких постійно інспектується та адаптується. Ця практика заохочує експериментувати, і це розвивається в подальшому навчанні. Scrum in Church, сторінка 4

• Ну, ви не можете проводити щоденні зустрічі з сутичками, але принаймні ви можете нагадати собі завдання, яке ви виконаєте сьогодні. Щоденні зустрічі з вигуками використовуються для того, щоб команди могли синхронізуватися між собою щодо того, що вони роблять.

• Рефлексія після спринту - в scrum це називається Retrspective Sprint, наприкінці кожної ітерації ви можете подумати про те, що станеться після ітерації, і подумати, що пішло не так і як ви можете вдосконалити його, які найкращі практики зберегти їх робити

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

Scrum - це не scrum, якщо ви не можете підходити до своїх потреб і адаптуватися до вашої поточної ситуації.